Faster Web-Delivery via QUIC
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:
- 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.
QUIC also makes use of Short Header, where we just define the Destination Connection ID and Flags.
- So, how do data flows? — We do it via STREAM frame type, which looks like:
- This is how we can transfer data between Client and Server and vice-versa.
What are some tools that we can use to check if QUIC is supported for a given server?
2.) chrome://net-export/ and https://netlog-viewer.appspot.com/#import. — Here we directly capture logs in the Chrome browser itself.
Further Reading:
- http://web.cs.ucla.edu/~lixia/papers/UnderstandQUIC.pdf
- https://blog.cloudflare.com/the-road-to-quic/
- https://www.youtube.com/watch?v=HnDsMehSSY4
- https://www.youtube.com/watch?v=dQ5AND4DPyU
- https://quicwg.org/ops-drafts/draft-ietf-quic-manageability.html
- https://www.rfc-editor.org/rfc/rfc8999.html
- https://www.pluralsight.com/courses/quic-protocol-deep-dive — Cristopher Greer.
- This brings us to the end.
- In my opinion QUIC is neither a rival nor a complete successor for TCP just yet.
- TCP is here to stay for a while as most of the Internet is based on it, along with other application that it helps support. QUIC needs some more time to get there.