Insouciant

I see, so your main point really is that you don't think the new features proposed in HTTP/2.0 are worth the change in wire representation. Prioritization: Generally speaking, documents (HTML) > script/stylesheets (JS&CSS) > subresources (e.g. images). https://insouciant.org/tech/resource-prioritization-in-chromium/ https://insouciant.org/tech/throttling-subresources-before-first-paint…

At least if you're going to dive into the transport layer, pick a capability that hasn't been added and then unceremoniously backed out- https://insouciant.org/tech/status-of-http-pipelining-in-chromium/ SPDY begins to offer some very appealing alternatives where when sending a document the transport can push all of the individual dependent documents. It really does fix things, begins pushing all the data at once, in a glorious resource-oriented fashion. That said, I would also enjoy a spec that does resource-description of subresources so we can send linked data around without having to have every piece of data be an endpoint. That said, the immediate follow on question arises- now that we're sending sub-resources, can we get the most important agent to understand and grok our sub-resources- can the browser follow our subresourcing and those subresources to their canonical URLs, and serve those subresources if it's seen them inside another document? There are two questions- first, is your spec good enough to enable that facility where addressing can be well known- here, in this Json Resource Description spec presented yes, via URI templates, very good- and second, does the browser bother to inspect the JSON it sees? No? Well, I'm not super bothered by this academic interest not being materialized, knowing at least in principle the specs make it possible.

While I agree QUIC is a better long term solution[1], saying TCP ordering affects HTTP/2 is misleading. It is true, but it is quite easy to avoid bad behavior by using TCP_NOTSENT_LOWAT (also created by Google), to avoid HoL blocking. For example, SPDY had a similar problem which was ameliorated by only sending when the water mark is low enough: https://insouciant.org/tech/prioritization-only-works-when-theres-pend… [1] https://news.ycombinator.com/item?id=12282898

That would apply but it's somewhat odd to see the tone of surprise for something which has been widely mentioned as an optimization-turned-antipattern for SPDY or HTTP/2 since at least 2012 or so. I believe at least Chrome has also optimized so addresses which share the same IP (or SSL cert?) will be collapsed into the same existing connection rather than opening new ones. Opening all of those connections is also something of an anti-pattern even for HTTPS depending on how much data you're exchanging relative to the SSL handshake cost – see e.g.: https://insouciant.org/tech/network-congestion-and-web-browsing/#Googl…

Will Chan of Chromium wrote a good post explaining the congestion issues with opening many TCP connections - https://insouciant.org/tech/network-congestion-and-web-browsing/

This was on HN eight months ago, when the post was actually made. And the takeaway is pretty clear, you probably won't see a benefit in using SPDY in front of a site optimized in ways that don't take advantage of SPDY's strengths. If you want to see big improvements with SPDY (like Google does) then you need to adjust how you're serving your resources. Resource prioritization is a perfect example of this: https://insouciant.org/tech/prioritization-is-critical-to-spdy/

Notice it says "on average". SPDY isn't a switch you flip on to make things faster. Very often, there are low-hanging fruits for performance improvement, especially in SSL: https://insouciant.org/tech/ssl-performance-case-study

I didn't have to look hard to find bug reports for pipelining. An example is https://bugs.launchpad.net/ubuntu/+source/apt/+bug/948461 for Amazon's S3. I'd be interested if the problem is still reproducible now. Also, one of the comments mentions Squid 2.0.2 as being buggy. Also, see https://insouciant.org/tech/status-of-http-pipelining-in-chromium/ for a link to Firefox's blacklist of buggy servers (and a good discussion of pipelining in Chromium). Most of the improvements in SPDY are latency improvements, so if you're downloading sites with netcat and then viewing them in a browser, I'm pretty sure the overhead of that would dwarf anything SPDY would save. That having been said, there's ample evidence of SPDY improving things. From http://bitsup.blogspot.com/2012/11/a-brief-note-on-pipelines-for-firef… : "Also see telemetry for TRANSACTION_WAIT_TIME_HTTP and TRANSACTON_WAIT_TIME_HTTP_PIPELINES - you'll see that pipelines do marginally reduce queuing time, but not by a heck of a lot in practice. (~65% of transactions are sent within 50ms using straight HTTP, ~75% with pipelining enabled).... Check out TRANSACTON_WAIT_TIME_SPDY and you'll see that 93% of all transactions wait less than 1ms in the queue!"