TCP head of line blocking

HTTP/2 is done over TCP and with much fewer TCP connections than when usingearlier HTTP versions. TCP is a protocol for reliable transfers and you canbasically think of it as an imaginary chain between two machines. What isbeing put out on the network in one end will end up in the other end, in thesame order - eventually. (Or the connection breaks.)

With HTTP/2, typical browsers do tens or hundreds of parallel transfers overa single TCP connection.

If a single packet is dropped, or lost in the network somewhere between twoendpoints that speak HTTP/2, it means the entire TCP connection is brought toa halt while the lost packet is re-transmitted and finds its way tothe destination. Since TCP is this “chain”, it means that if one link issuddenly missing, everything that would come after the lost link needs towait.

An illustration using the chain metaphor when sending two streams over thisconnection. A red stream and a green stream:

It becomes a TCP-based head of line block!

As the packet loss rate increases, HTTP/2 performs less and less well. At 2%packet loss (which is a terrible network quality, mind you), tests have proventhat HTTP/1 users are usually better off - because they typically have up tosix TCP connections to distribute lost packets over. This means for every lostpacket the other connections can still continue.

Fixing this issue is not easy, if at all possible, with TCP.

Independent streams avoids the block

With QUIC there is still a connection setup between the two end-points thatmakes the connection secure and the data delivery reliable.

When setting up two different streams over this connection, they are treatedindependently so that if any link goes missing for one of the streams, onlythat stream, that particular chain, has to pause and wait for the missing linkto get retransmitted.

Illustrated here with one yellow and one blue stream sent between twoend-points.