Now let's take a closer look at why QUIC is the
transport protocol for the future of HTTP.
So we're going to take a step back for a moment and
discuss the head of line blocking problem and how HTTP/3
over QUIC is designed to fix it.
So let's just say you're checking out at a grocery
store, you choose your checkout line,
which seems to be the shortest, and sure enough,
something happens with the customer up ahead of you and
it holds up the line for everybody.
Well, that's an example of head of line blocking.
But let's see how this happens with web over TCP today.
So HTTP/2 is designed to support multiplexed
streams over a single TCP connection.
So what that means is that it can send multiple GET (or POST or HEAD or
whatever the method is) requests to the server in parallel.
In fact, if there's space within the packet,
it can even do so within the same physical IP packet.
Sounds pretty great, right?
Well, yeah, until a packet gets lost.
Now there's a lot that goes on here,
but we're just going to keep this very simple. So, let's just
imagine that along its way to the server, this packet with
information for the second GET request, gets dropped along the route.
The packet after,
though, the one that contains the stream for the third GET, makes it to the
server just fine. Now, TCP, remember that it doesn't know anything about
these requests from the application perspective.
TCP just understands bytes of data.
So it has no idea that a complete GET, that GET 3, arrived at the
server, and that there's no need to hold up that segment with the batch
that came in until we can plug all the holes.
See, TCP likes to make sure that everything gets to that server reliably.
So before the TCP buffer will send everything upstairs into the application,
it first needs to make sure that everything has been received.
So before the server can respond to that third GET, it first
has to wait to receive all of the GET 2 data,
which it will then start to respond to.
Now, keep in mind, remember,
TCP does not understand anything about the application itself.
This is all just blind bytes to TCP. Now, there's a whole lot more
going on under the hood here, but that's a simple way that we can
understand what head of line blocking is.
So, HTTP/3 over QUIC was specifically designed to overcome this problem.
Now, here we can see several GETs in the same way being sent over to the
server, but this time they're being sent over QUIC over UDP.
Now when a GET get arrives, or when that data gets sent up to the application,
that server can begin responding immediately to complete datasets that it
gets. The loss that happened will only impact GET 2, or whatever data was
encompassed within the packet that was actually lost.
So in this case, the client will have a timeout mechanism, much like TCP,
and will retransmit the information that was lost in GET2, which the server can then respond to.