So let's go ahead and tackle that first question, why replace TCP?
Now, first, about TCP.
Now, this protocol was standardized in September of 1981 as RFC 793,
but think about that.
TCP is now over 40 years old, which speaks to its durability and resilience,
although the TCP that we use today looks a whole lot
different than the one 40 years ago.
Since then,
there's been some big adjustments in the use of TCP
options and congestion control to help TCP to continue to
do its thing over modern networks.
After all, all the way back in 1981,
no one ever conceived of a 40‑GB per second link
across the ocean with 80 ms of latency, did they?
Now, TCP really has become the protocol of the world because it's reliable,
connection‑oriented,
and is still used to carry most application traffic in the internet.
Let's learn a bit more about the development of web‑based applications over TCP.
Now, if we go all the way back to 1991, this is when HTTP 0.9 was developed,
and it used TCP as a transport protocol.
But by today's standards, it was pretty basic.
The only real function that it had was the GET method,
so this was a simple protocol, able to access and retrieve just simple websites.
Not too much later, in May 1996, came HTTP 1.0 over TCP.
Now, this version of HTTP introduced other methods, such as POST and HEAD,
but would only issue a single request over a single TCP connection.
So for a client to request a page, or a file,
or an image from a server, a client would need to open up a new TCP connection,
request that image or file, then close the connection.
Then, if it needed something else,
it would have to open up another connection to do another request.
Obviously,
this was not very efficient since we needed to burn time in
establishing TCP connections for all new requests.
This brought about the need to pipeline multiple requests
or POSTs over a single TCP connection.
In HTTP 1.1, which was released January 1997,
as soon as one request finished,
another could start right on its heels using the same TCP connection.
When there were many workloads to do between a client and a server,
browsers just started to open up several TCP connections in parallel so that
requests could be multiplexed to cross different connections.
And for almost two decades, this is largely how web applications worked.
Go, HTTP 1.1!
But then we hit another problem, not only could traffic be captured,
read, and adjusted right off the wire,
but it was also difficult for a client to validate that it was
talking to the real server that it intended to talk to.
Now, HTTP 1.1 started to use TLS, or even before that,
SSL, to encrypt data much earlier than May 2015,
but this became the rule when HTTP/2 was released.
Now,
HTTP/2 was designed for multiple streams of web data
over a single TLS and TCP connection.
Think about it this way, if a highway was the TLS in TCP connection,
then HTTP/2 could create multiple lanes,
or we'll call them streams.
Now, this is how the majority of us access web services today; however,
this hasn't been good enough for the Googles and the other services
wishing to trim microseconds from the user experience.
In order to set up an HTTP/2 conversation,
you first have to burn several network round‑trips with the TCP handshake and
then the TLS handshake before data can really get moving.
Now, this brings us to the bleeding edge version of HTTP,
version 3,
which is built from the ground up to use UDP‑based QUIC
with built‑in TLS as a transport protocol.
Now, there are many reasons for this adjustment,
which we'll explore over the next few minutes.
Now, as of this recording,
QUIC is right at the verge of being released as an RFC,
which will cause it to tip the scales and then explode all over the internet.
But that begs a question, doesn't it?
Why replace TCP?
Back up a minute.
Web over UDP?
Isn't that an unreliable protocol?
Besides, what's wrong with TCP?
Now, first, let's talk about TCP.
We've already discussed how it's a 40‑year‑old protocol.
Really, at this point, we have limited room to migrate or to change.
Now, that's due to the structure of the headers and overall operation.
There really isn't much more room to squeeze additional performance out of TCP,
no matter how hard the network tries.
After all, think about it,
it was designed when the internet and networking world
was a much different place. Also, WAN accelerators,
firewalls, and intrusion detection systems have been baked in to observe and
even adjust specific behaviors of TCP, so making major changes to TCP at
this point could end up breaking other things.
Second,
another big problem with TCP for web delivery is a
problem called head‑of‑line blocking.
Now, we're going to discuss this in detail in a little bit. But for now,
just know that when loss happens,
TCP becomes very busy to recover from that loss,
which can affect the upper‑level application.
This can impact application performance because the brakes get pulled
on all requests as TCP can deal with those retransmissions. Now,
another reason for the shift from TCP is that in order for an
application to start new connections,
it first has to wait through several network round‑trips
as TCP and TLS established themselves.
Reducing the number of round trips will reduce the overall connection time,
which will increase performance for the end user. Let's go ahead and focus on that facet for just a moment.