| The alternative would be using multiple connections, or reimplementing your own version on top of HTTP/2. HTTP/2 is re-implementing multiple connections on top of a single TCP stream. It's turtles all the way down. The above is much more useful in the presence of streaming. H2 has first class support for bidirectional streaming. It is now feasible to do a stock ticker, or chat room, or whatever over a normal H2 connection, and not have a whole extra protocol or browser work-arounds. Web sockets work, and hanging GET request work, but they are extra burden. This is in contrast to HTTP/1.1. However, we already have support for bidirectional streaming in the form of TCP. Stock tickers, chat rooms, or whatever, have always worked over TCP. Web sockets and hanging GET requests are extra burden because, the real problem, browsers don't support and networks/firewalls are not configured to support, end-to-end blind TCP connections, the concentration is on HTTP. TCP Keep alive only works over TCP. In the case of not using TCP (like Unix Sockets) The comparison to UNIX domain sockets not supporting keepalive is a mild red herring. TCP keepalive exists to address the limitations of a distributed system, recovering from disconnections and lost packets, which doesn't exist in the UNIX domain sockets model because UNIX domain sockets are centrally managed. Google is planning on using HTTP/2 as its new intra/inter-Datacenter RPC transport (See gRPC). The protocol is good enough to support browsers, mobile, and servers without having to transliterate between protocols. This portability across different networks and form factors is definitely a strong rationale for HTTP/2. When it comes down to it, the true advantage of HTTP/2 is that it is closer to Layer 7 than it is to Layers 3 or 4. This addresses the social and political disadvantages of trying to use things that are lower in the stack. It's non-trivial to get support for anything new that isn't in Layer 7. The RFC process is arduous and there ends up being a lot of vested interests attempting to co-opt a standard for their own aims, making adoption of a layer 4 protocol nearly impossible, not the least of which you need to get operating system and network hardware vendors to support the changes, and then users (read: companies) to understand them. With changes closer to Layer 7, it's application only changes, so a single vendor can implement and deploy something to, effectively, the entire internet, without having to mess with getting everyone else on board. Only once you're looking at portability/interoperability does it then become worth going through a standardization process. This is exactly what happened with Speedy and HTTP/2 and it's made adoption much easier and faster than other things that have required mass scale (I'm thinking of things like IPv6 and SPF/DomainKeys/DMARC here, which require a much larger group on board in order to see any progress on deployment). |
There is an entirely valid reason to do so (that TCP connections need to have slow-start to avoid congestion). TCP will always be inefficient for sending single, small files.
HTTP/2 doing this is great, because it means you can do away with the hacks that were used with HTTP/1.1 to get around connection limits, and you can do away with the hacks like putting all your JS in a single file to get around slow-start (by reducing the number of files sent), which is bad for caching (if users have your site cached and you change one JS file, their browsers have to download the whole concatenated collection of files again).
I'm all for trying to keep things simple, but I think much of the complexity in HTTP/2 is solving valid, real problems that will improve the speed of the web, which is a good thing.