One lost packet froze all 30 of your HTTP/2 requests

transcript

Your app sends 30 requests over one HTTP/2 connection. On a shaky mobile network. One packet goes missing. All 30 freeze.

Here's why. Five packets leave the sender. Packet 2 is lost on the way. 3, 4 and 5 arrive fine. But TCP promised order. So they wait. Your app sees packet 1, then nothing, then everything at once. Head-of-line blocking.

HTTP/1.1 did one request at a time per connection. So browsers opened 6 to 8. HTTP/2 multiplexes many streams over one connection. Problem solved? But here's the catch. It still runs on TCP. One loss blocks every stream.

Over TCP, all 30 stall until the packet is resent. HTTP/3 runs on QUIC, over UDP. It tracks each stream on its own. Now a lost packet only delays its own stream. The other 29 keep moving.

Bonus: it connects faster. TCP plus TLS 1 point 2 costs 3 round trips first. TLS 1 point 3 makes it 2. QUIC does it in 1. Resume a connection, and it's zero.

TCP promises order. And order means waiting for the slowest packet. On lossy mobile networks, that's why HTTP/3 left TCP behind.

Full breakdown in the lecture.