Have they actually worked out how to implement a HTTP/2 front end cache in the face of ill-behaved clients, crashy servers, and the way wireless breaks a lot of the assumptions that would make "one big TCP session" a good idea in the first place?
If TCP+TLS handshakes are so expensive, wouldn't it be a better investment of everyone's resources to work on an L3 protocol for setting up a fast second session? Leave the multiplexing to packet people.
A client can say it does not want push in the settings frame up front. And then it can make one request at a time, effectively avoiding multiplexing, although each frame in the response will have a 9-byte frame header (similar to the overhead in chunking today in 1.x).
By saying it does not want push, it relieves itself of having an object cache. It will still be on the hook for having an HPACK table as state. (In practice this will be coded once in each language in a library and most developers will never think about it.)
> Have they actually worked out how to implement a HTTP/2 front end cache in the face of ill-behaved clients, crashy servers, and the way wireless breaks a lot of the assumptions that would make "one big TCP session" a good idea in the first place?
The community has indeed been working on a corpus of interoperability libraries, servers, clients, and proxies: https://github.com/http2/http2-spec/wiki/Implementations
> If TCP+TLS handshakes are so expensive, wouldn't it be a better investment of everyone's resources to work on an L3 protocol for setting up a fast second session? Leave the multiplexing to packet people.
It's multiplexing with declared weighting and dependency trees. So for example, the client can tell the server that it wants files A, B, C, and D, but to have B, C, D is useless until it has A, and once A is finished, the relative importance of B is twice as much as C or D. That's much easier to do on one socket.
Also one socket gets the header compression in HPACK to benefit from all the headers going through the same state engine. Giant sets of cookies (more common than we'd like to believe) are now more efficiently expressed.
One socket also helps the server-side keep statistics and logs more organized as related requests are together.
I understand your suggestion to do it on a lower level, and that's a fine idea, but I also understand why the working group did it on an HTTP layer, especially with SPDY as precedent.
I work at Akamai, and I'm one of the open source library contributors (the Common Lisp one). These opinions are my own.
The rare occasion where this will be a big difference for me is telnetting to port 80 and typing HTTP by hand. Honestly, I only do that out of habit; I can do the same things just as well with curl. But even when HTTP/2 ships, I'm sure it will be at least a decade before servers stop supporting HTTP/1.1. Probably longer. So I'm not expecting this to make a big difference to my debugging habits.
What about tools for reading corrupt binary HTTP/2 frames?
Their more involved properties require dozens to even hundreds of requests in order to perform complex tasks like showing a list of plain text posts.
And, of course, they can't possibly impose any kind of discipline on the way they do things, so instead the entire internet has to change to accommodate them.
Now I could optimize that even more by inlining everything with data-inline: but that would impact caching code and be strictly worse for the network.
A property from google even websearch has fancy transitions and animations and dynamic content. And Google has every incentive to limit the number of connections to their page. When I worked there I worked on some of those technologies specifically to avoid too many connections.
Blaming Google for not being disciplined enough disregards their economic incentives to be disciplined enough. They invested a lot of energy in this before SPDY came out. There comes a time where you just have to recognize that the protocol is fighting against you and either give up or evolve the protocol.
No, wait a sec. That doesn't sound right. Could it be that our tools exist to serve humans? And that rather than putting effort into accommodating ourselves to the limitations of our current tools, we should instead put our effort into making tools that work the way we want?
Nah, sounds crazy. If HTTP/1 was good enough for my grand-dad, it's good enough for me.
(1) index.html, (2) app.nocache.js (3) A56284CFC0D680C7DBA0F93CA9AE8F75.cache.js (cache fragment for given page/state) (4) XHR for page data/state to display
Now, if you've got some CSS and minor images/fonts, these can be an your options request (5) resource bundle. On many Google properties, (2 and 5) are inlined into (1).
The take away? These technologies and frameworks have been out there for a long time (8 years in the case of GWT), so you don't have to make hundreds of requests if you're disciplined. I can only assume Google has thrown in the towel trying to get script kiddies to ever be disciplined.