Faster Web-Delivery via QUIC

Sumeet Kumar

Follow

4 min readAug 20, 2021

--

A TCP Rival or TCP2.0? — Part 2

In this part we will discuss about how a QUIC Handshake happens and related parameters with Wireshark analysis.

[ You can can check about QUIC packets structure and what TCP limitations it helps overcome, in Part 1]

Broadly, the QUIC Handshake looks like:

Source: https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study

In our example we browsed “facebook.com” and collected a WireShark capture of the handshake between Client and Server. [Client being my machine and server being “Facebook”]
Remember, QUIC packets are encrypted. So, we can only see Connection IDs and Packet Number assigned from Source and Destination and Client and Server Hello.
Before an actual Handshake happens QUIC sends “Initial” packets to check if we should begin QUIC session.
It looks something like this:

We can see that the TLS Handshake starts from the very first packet.
Connection are being identified based on the Connection ID from source and client sets the Connection ID for destination.
Packets are number in a straight forwards manner staring from 0 to whoever is the initiator and destination selects random number for its packet number.
Along with the Client-Hello, client also send the QUIC parameters that defines how the connections will be carried out:

But here we do not know what is happening inside the other Frames as they are encrypted, and we see this:

So now, we need to decrypt the conversation with our SSL Keys.You can check how to decrypt a conversation from: 
https://www.youtube.com/watch?v=5qecyZHL-GUhttps://support.f5.com/csp/article/K50557518

Post decryption, the conversation looks like:

We can right away see that the communication is happening over HTTP/3 .

Let’s look a little deeper now, and look at the server response:

Server responds:

Server send the Server-Hello to the client packet and Acknowledges Packet Number 0 (which was the first packet sent from Client) and we can see its own PKN [Packet Number] as, 7995648.
So, when the Client responds back to Server at later stage, we would see an ACK of this same packet.

Unlike TCP, QUIC packets are ACK-ed directly with the same number as initial sent packet. The next packets from client and server would just be +1 increment of their current packet number.
From RFC: When a packet containing an ACK frame is acknowledged, the receiver can stop acknowledging packets less than or equal to the Largest Acknowledged field in the sent ACK frame.
Once the Handshake finishes, we observe, Finished message:

Now, actual communication between Client and server can start.

To define the connections in QUIC, we make use of Long Header.
It exposes more information where we define the source and destination connection ID along with Connection ID Length.