Eliminating Head of Line Blocking - The Evolution of HTTP Protocols

Head of line blocking has been a persistent issue with HTTP protocols, causing delays and frustration for users. In this blog post, we explore how HTTP 2.0 and the latest version, HTTP 3.0 (also known as QUIC), have addressed this issue through the use of multiple data streams and running over UDP. We examine the advantages and disadvantages of each protocol and their impact on system design and network protocols. Whether you are a developer or a system designer, this post will help you understand the evolution of HTTP protocols and make informed choices for your projects.

HTTP 1.0

Remember a time when you had to stand in a queue?

At the airport checkin counter, someone always has a LOT of requests. And everyone must wait while this person completes their request.

Q → 😅😣😣😣😣😣😣😣😣

This is called head of line blocking. It was a big problem with HTTP 1.0, where requests would wait patiently for all requests in front of them.

What is be a way to reduce this wait time?

HTTP 2.0

Just increase the number of queues.

Q1 → 😅😣😣
Q2 → 😊😐😐
Q3 → 😊😐😐

And so HTTP 2.0 is born. But there is a catch.

The underlying protocol of TCP still has head of line blocking!

Despite allowing concurrency on the application layer, the underlying TCP packets can get stuck waiting for a particularly slow packet.

We need to change the fundamental transport protocol of HTTP.

HTTP 3.0

Guaranteed delivery and message ordering are core features of the TCP protocol. But forcing packet ordering accross clients creates problems. We only want to force ordering amongst packets related to each other. That is called Causal Ordering!

If A is dependent on B and not dependent on C: A has to occur anytime after B, but does not depend on the execution of C. The possible orderings of such a situation are:
B → A → C
C → B → A
B → C → A

If B depends on C, then the only possible ordering would be:
C → B → A

Unfortunately, TCP is too restrictive to allow this kind of causal ordering. To implement concurrent requests with causal ordering, we must implement HTTP over UDP.

The different versions of HTTP - GRPC - QUIC
The different versions of HTTP - GRPC - QUIC

The latest version of HTTP, with data streams support, is written over UDP. It's called QUIC (Quick UDP Internet Connections).

HTTP 3.0 supports concurrent data streams and reliable delivery.

How has QUIC changed the world?

Most browsers support QUIC, and the videos you see from Instagram, YouTube and Gmail are on QUIC. Meta's recent AtScale engineering talks were all about QUIC!

Goes to show that simple ideas can change the world.

So which one should you pick? If you can, go for the latest version of HTTP 3.0, which is also known as QUIC. It has all the amazing features of the previous protocols, and is widely adopted.

If you don't care at all about head of line blocking, and are looking for universal adoption, HTTP 2.0 is the protocol for you.

References:

Head of Line Blocking - https://interviewready.io/learn/system-design-course/networks_deep_dive/head_of_line_blocking
Causal Ordering - https://interviewready.io/learn/system-design-course/consistency-in-distributed-systems/Causal-Consistency
HTTP, TCP and UDP - https://interviewready.io/learn/system-design-course/networks_deep_dive/http_web_sockets_tcp_and_udp

Start Preparing for your Dream Job today!

The most comprehensive Interview prep platform ever built

Start Prep