3 ms·

> it's "just" slow start making it slower Six connections with H1 means waiting for the server to process only up to six responses at a time. You also can't se

> it's "just" slow start making it slower Six connections with H1 means waiting for the server to process only up to six responses at a time. You also can't send any additional requests until one of those six ongoing requests has finished. So at the very least, you're paying a full round trip cost per request where no useful work is happening. Let's say the server makes a 250ms request to an auth service on each request. For every six requests, you're sitting and waiting a quarter second for the server to sit and wait. With H2, you essentially pay that 250ms cost once, because ~every request happens concurrently. With H1, you pay it once per request on each connection. It's also the case that many servers stream their responses. If I make 12 requests and the storage that the server pulls the data from responds more slowly than the server can send it to the client, H2 means that I get twelve half finished requests instead of six half finished requests and six requests that never even got sent. For content that doesn't require the full file to be loaded, that's a win. H2 also has header compression. Sending HTTP requests on H1 often takes multiple packets, especially if you have more than one cookie. HPACK can basically eliminate much of the overhead of actually sending the request, eliminating multiple TCP round trips. Which means the server is able to start processing more requests in parallel sooner because it's not waiting for the requests to arrive as long. H3 eliminates many of the problems caused by head of line blocking. If you have packet loss on one of your connections, whatever was being transmitted is now blocked until TCP sorts out the missing packet. H3 limits the congestion only to the individual request impacted by the lost packet rather than all of the requests being made over that connection. In any case, it's not "just" TCP slow start that makes H2/H3 better than H1 in regards to concurrency.

Dylan16807 4y ago
> Six connections with H1 means waiting for the server to process only up to six responses at a time. You also can't send any additional requests until one of those six ongoing requests has finished. So at the very least, you're paying a full round trip cost per request where no useful work is happening. Browsers disable pipelining on H1 now, but it used to be a real feature to avoid this problem.
- aseipp 4y ago
  Well, to be fair, it was disabled because it mostly didn't work correctly in a wide amount of circumstances, because a lot of HTTP/1.1 servers didn't support it correctly. Not because people didn't want better performance. It was bolted on and HTTP/1.x lets you get away with an incredible amount of stuff[1] while continuing to "work". It is also another thing that introduces head-of-line blocking; and that one isn't fixable even if the servers were. Moving multiplexing directly into the "data path" of the protocol was the correct move in the case of HTTP/2 and later, because you can't get this part wrong and still have things work; multiplexing is simply a core feature of the system. This is true of many other things as well. [1] Stuff like this is guaranteed to happen IMO because HTTP/1.1 is a perfect example of "deceptively complex." Everyone says that HTTP/2 got complicated, but HTTP/1.1 was already incredibly complicated to get working reliably and efficiently. The difference is you can't write an "HTTP/2 server" in under 200 lines of code that ignores 99.9% of the whole specification, while you could get away with this in HTTP/1.1. The /2 spec was, in this sense, largely an admission of the complexity of the problem, which protocol developers were already acutely aware of.

Dylan16807 4y ago

> Six connections with H1 means waiting for the server to process only up to six responses at a time. You also can't send any additional requests until one of those six ongoing requests has finished. So at the very least, you're paying a full round trip cost per request where no useful work is happening. Browsers disable pipelining on H1 now, but it used to be a real feature to avoid this problem.

aseipp 4y ago
Well, to be fair, it was disabled because it mostly didn't work correctly in a wide amount of circumstances, because a lot of HTTP/1.1 servers didn't support it correctly. Not because people didn't want better performance. It was bolted on and HTTP/1.x lets you get away with an incredible amount of stuff[1] while continuing to "work". It is also another thing that introduces head-of-line blocking; and that one isn't fixable even if the servers were. Moving multiplexing directly into the "data path" of the protocol was the correct move in the case of HTTP/2 and later, because you can't get this part wrong and still have things work; multiplexing is simply a core feature of the system. This is true of many other things as well. [1] Stuff like this is guaranteed to happen IMO because HTTP/1.1 is a perfect example of "deceptively complex." Everyone says that HTTP/2 got complicated, but HTTP/1.1 was already incredibly complicated to get working reliably and efficiently. The difference is you can't write an "HTTP/2 server" in under 200 lines of code that ignores 99.9% of the whole specification, while you could get away with this in HTTP/1.1. The /2 spec was, in this sense, largely an admission of the complexity of the problem, which protocol developers were already acutely aware of.