I just recently got my company to switch over to http2 and halved our load time across the board. It might go down as the greatest improvement in customer experience for the simplest action I’ll ever do.
Browsers allow for somewhere around 6 simultaneous TCP connections (which means around 6 concurrent requests with http1.1). Http2 allows for http requests at the speed of the clients upload connection (effectively unlimited).
HTTP/2 has indeed massively benefitted CDNs by providing more effective capacity per buck, but UDP based 3.0/QUIC will singlehandedly destroy it, and bring it to below HTTP 1.1.
Cloudflare: https://blog.cloudflare.com/http3-the-past-present-and-futur...
Akamai: https://developer.akamai.com/blog/2020/04/14/quick-introduct...
Fastly: https://www.fastly.com/blog/why-fastly-loves-quic-http3
Not to mention Google, which uses it a lot for regular pages and for content (eg: YouTube video).
Adoption client-side also seems to be moving quickly too. I looked at the stats for 2 of my sites and HTTP/3 is now at 60-70%, with HTTP/2 having dropped to 25-30% already.
Also, if this blog post from 2020 is correct, performance per buck isn't that bad with some teaks: https://www.fastly.com/blog/measuring-quic-vs-tcp-computatio...
I assume things have evolved since 2020.
Also, if you had a sent request waiting behind a slow/large response, you had to decide whether or not to send an extra request on a separate connection to get the resource sooner. And when a server closed a connection after sending a response (the spec allows it for multiple reasons), it was hard to know whether it was that the server was just not accepting more requests on that connection or whether a particular request caused it and hence whether any of the waiting request(s) should be re-sent or treated as being in error.
Some browsers implemented it, at least temporarily. However the important point no one mentions is that servers implemented it, permanently. I have been using HTTP/1.1 pipelining continuously since the mid 2000's. I could not even name an httpd that does not implement support for HTTP/1.1 pipellining (no doubt some HN commenter will come up with one, but it is a rare exception to the general rule).
1. I do not need compressed HTTP headers either. I like ASCII headers as they are useful record separators for catenated HTML. I have the forward proxy configured to add useful headers that provide additional information about the connection.
Over one tcp connection, these "unlimited" requests are interleaved, blocking each other for periods of time.
With multiple tcp connections I can have parallelism. It seems like for larger requests, you would suffer performance loss with http2? What am I missing here. Must be something.
The parallelism you see with multiple TCP connections comes from the fact that the NIC is not (generally) saturated sending and receiving bits.
So with that out of the way, where's the benefits?
One is eliminating the TCP slow start [1]. TCP was designed generally with the notion that you'd only ever have 1 connection between 2 computers. As a result, it has baked into the protocol network congestion sensing protocols. More connections == more congestion control == slower requests. It also, however, means that the first request of every connection will be penalized as the connection warms up. A single connection pays that penalty once.
Another is the latency problem. In order for a connection to be used, you need to send the data from the client to the server and then receive a response from the server. During that time, your connection is bound up (ignore http pipelining, it never worked well). You cannot add more bits down that connection, you have to wait for the server to process and send back response. If that round trip time takes 200ms, that's 200ms of sitting around doing nothing. During that time, over a 100Mbps connection your client could have sent 2.5MB worth of requests to the server. Because http request are typically very small (usually in the bytes), that's a lot of potential requests. This leads to the servers more than likely being able to saturate the connection which is what you want if you are trying to maximize performance.
> It seems like for larger requests, you would suffer performance loss with http2?
A little tricky, it depends on what you are measuring. A large request will block other requests going through while it is streaming. In that scenario, you'd still be saturating the network line but the perceived concurrency would be down. So, from a requests/sec standpoint, that could end up being lower. But from a data-throughput standpoint, you'll be better off still than http1 due to the better network congestion handling of a single TCP connection. (The ole latency v throughput problem).
This is where we enter HTTP3, which bucks TCP as the primary request carrier for UDP messages instead. HTTP3 allows for much lower connection establishment costs (so making multiple QUIC connections isn't as expensive) but also contains protocol changes for errors which keeps an bad packet from blocking all the inbound packets (TCP will freeze the stream while it goes back up the connection to get the correct packet).
This is an excellent comment and very helpful. Thank you.