Let's learn more about how QUIC can buy us time.
So let's say that this client on the left wants to request a
service from the server over on the right.
If TCP is used,
it will first have to establish a connection using a three‑way handshake.
After this, in order to encrypt the traffic,
it needs to establish a TLS handshake to generate encryption
keys and TLS settings for the connection.
In TLS 1.3, this will be another network round trip.
Now older versions of TLS,
there's even more round trips to get all of this set up.
Finally, after these two handshakes have been completed,
the client can send its first request.
So we can see that there is time that's spent just to set up the connection.
Now this is one major improvement of the QUIC protocol. From the first
packet, it already can embed the TLS handshake into the connection setup
and get data moving in one network round trip.
And even better than that,
if this client has already communicated with this server
or service in the very recent past,
the client can even send the GET along with the initial
packet of handshake to the server,
resulting in what's called 0‑RTT performance. So from
packet number 1, we're already moving data.
Now one final note about the need to replace TCP is the
fact that the full header is unencrypted,
even if the encompassed data is not. So using just the headers,
there's plenty that we can learn about the application,
how it moves, how well it responds,
and we can even hijack the connection because so much can be
passively observed. Now QUIC will address this problem because security is part of its design from the ground up.