So now that we understand how a server can hand off a TCP connection to QUIC,
now let's learn how a connection is established with a QUIC handshake.
Now, let's review the old way of doing this,
of establishing a transport layer connection.
This should be pretty familiar to us.
And really,
almost every TCP connection on the planet starts with a three‑way handshake.
Now, since security and encryption are also important,
especially to protect from passive listeners listening along the path,
then we establish that TLS handshake.
Now, the latest version of TLS, version 1.3,
it does it in just 1 network round‑trip,
which helped to speed up these Initial communications.
So after the TCP and TLS handshakes have completed,
the application can then use the connection to finally send application traffic.
Now,
you might hear this in many industry blogs or analysis
tools that call this time to first byte,
meaning,
how much time does it take until the first byte of actual
application traffic is received on this connection?
In this example, it took three network round trips to get that to happen.
So now, let's contrast this with a simple look at the QUIC handshake.
Now, to keep it very basic, the client sends an Initial packet to the server,
which includes instructions about how it would like to set up the connection.
The server then responds with its end of the connection information.
After this,
the handshake completes and the client can begin to send requests to the server.
Now,
this flow should look familiar because it kind of gets us back to the older
TCP connection flow where there was a simple handshake,
and immediately, the application followed; however,
there is much more going on under the hood here.
Let's go ahead and dig a little bit deeper into this handshake.
So in establishing a QUIC connection,
there is a couple types of QUIC packets that are used.
Now, these are called Initial and Handshake packets.
The first message that's sent to the server from
the client is the Initial packet.
Now, this is where the client can also send,
or imbed, if you will, the TLS Client Hello.
It also can advertise some transport parameters,
and it uses something called a Long Header to fully identify the connection.
In this packet as well,
the client can also advertise the application layer
protocol that it would like to use, so HTTP/3,
for example.
So after receiving this packet,
the server can respond immediately with an Initial packet,
and that will include the first part of the TLS 1.3 Server Hello.
Now,
right on the heels of that Initial packet is a Handshake packet
from the server, and embedded in that Handshake packet is the
rest of the TLS setup instructions, but this packet will already
begin to use encryption.
So the point is,
these are called handshake packets, and they can include other QUIC
messages, such as acknowledgements. Now, on the client end, the
final packet of the handshake is a finished message, and that lets
the server know that the TLS handshake is complete, and application
data will soon follow.
Now, missing from our chart here,
there are some other communications between the client
and server that aren't pictured,
and typically, these are acknowledgements or packets with very small data, and we'll see those in our demo in just a minute.