Head of line blocking

What this lesson covers

This lesson explains head of line blocking in HTTP. A sends message 1 to B, B acknowledges it, A sends message 2, and if that message or its acknowledgement fails (a router problem or corruption), A keeps retrying. Because delivery is ordered, messages 3, 4 and 5 wait behind message 2 even when they belong to unrelated customers. Ordering only matters where it is needed, for example two operations on the same bank account, so the video proposes ordering messages 1 and 2 separately from 3, 4 and 5. HTTP 2.0 makes this possible with multiplexing: each message is broken into frames and sent inside a stream with its own ID, and a blocked stream does not stop other streams. gRPC runs on top of HTTP 2.0. The catch is that HTTP 2.0 still runs over TCP, which uses acknowledgements, so frames on different streams share one TCP connection and therefore one queue. A dropped packet makes TCP retry and blocks every stream on that connection, so the problem was only solved at the application layer. HTTP 3.0 solves it at the transport layer by running over UDP, which has no acknowledgements. It keeps the behaviour of HTTP 2.0, including streams, ordered delivery and guaranteed delivery, while avoiding head of line blocking across streams. The protocol is called QUIC, which the video notes is a name rather than an acronym.

• Head of line blocking happens when a failed message at the front of an ordered queue holds back unrelated messages behind it
• HTTP 2.0 multiplexing breaks messages into frames sent on streams with their own IDs, so one blocked stream does not stop the others
• Streams on one TCP connection still share a queue, so a dropped packet blocks them all at the transport layer
• HTTP 3.0, called QUIC, runs over UDP and keeps the behaviour of HTTP 2.0 without head of line blocking across streams