The QUIC protocol, developed by Google and standardized by the IETF in RFC 9000, represents a significant evolution in how modern internet communication is handled. By building on the strengths of UDP and integrating security directly into its design, QUIC offers reduced latency, improved connection management, and robust encryption. In this post, we’ll take a deep dive into the structure of QUIC packets and walk through a practical example of how a POST request with parameters is transmitted over QUIC.
What is QUIC?
QUIC (Quick UDP Internet Connections) is a transport layer protocol designed to enhance performance for web applications by reducing connection times and improving network resilience. Unlike traditional TCP, QUIC operates over UDP and integrates the TLS 1.3 handshake, ensuring that connections are both fast and secure right from the start.
The QUIC Packet Structure
QUIC packets are the basic units of data transmission. They can be categorized into two main types: Long Header Packets and Short Header Packets. Long header packets are primarily used during connection establishment, while short header packets take over once the connection is established, optimizing the data flow for efficiency.
Long header packets are used during the initial stages of a QUIC connection. These packets include more extensive header information, such as version negotiation and connection establishment details. A typical long header packet might look like this:
| Header Form | Version | DCID Length | DCID | SCID Length | SCID | Token Length | Token | Length | Packet Number | Payload (Frames) |
- DCID and SCID are the Destination and Source Connection IDs, respectively, which help identify the connection at both ends.
- Payload contains the actual data, including the various QUIC frames like CRYPTO or STREAM frames.
Once the connection is established, QUIC switches to short header packets to streamline communication. These packets are more compact and are primarily used for data transmission:
| Header Form | DCID | Packet Number | Payload (Frames) |
The short header packet structure focuses on efficiency, with minimal overhead, making it ideal for high-performance data transfer.
A Practical Example: POST Request over QUIC
To bring this to life, let’s consider an example where we send a POST request to `https://example.com/api/data` with a few parameters: `Name`, `Age`, and `Occupation`.
The HTTP/3 POST Request:
When sending a POST request over HTTP/3 (which runs on QUIC), the request might look something like this:
POST /api/data HTTP/3
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 33
Name=John+Doe&Age=30&Occupation=Engineer
Encapsulating the POST Request in a QUIC Packet:
Now, let’s see how this request is encapsulated within a QUIC packet. We’ll focus on a short header packet, assuming the connection is already established:
Header:
- Header Form: Short Header
- Destination Connection ID (DCID): A unique identifier for the connection.
- Packet Number: A number that uniquely identifies this packet within the connection.
Payload:
- STREAM Frame: This frame carries the actual POST request data.
- Stream ID: Identifies the stream within the connection.
- Offset: Indicates where in the stream this data belongs.
- Length: Specifies the length of the data.
- Data: The HTTP/3 POST request.
Here’s a simplified visualization of how this might look:
Header (Short Header):
| Header Form | DCID | Packet Number |
Payload (STREAM Frame):
| Frame Type | Stream ID | Offset | Length | Data |
Hex Representation of the QUIC Packet:
For those who enjoy diving into the nitty-gritty, here’s how this packet might be represented in hexadecimal:
Header (Short Header):
| 0b01000010 | 1A2B3C4D | 0123 |
Payload (STREAM Frame):
| 16 | 01 | 00000000 | 21 | 504F5354 202F6170692F6461746120485454502F33 0D0A486F73743A206578616D706C652E636F6D 0D0A436F6E74656E742D547970653A206170706C69636174696F6E2F782D77772D666F726D2D75726C656E636F6465640D0A436F6E74656E742D4C656E6774683A2033330D0A0D0A4E616D653D4A6F686E2B446F65264167653D3330264F636375706174696F6E3D456E67696E656572
Conclusion
QUIC’s design is a masterclass in combining speed, security, and efficiency. By examining the structure of QUIC packets and understanding how common HTTP/3 requests like POST are encapsulated and transmitted, we gain valuable insights into the mechanics that make QUIC a game-changer in the world of internet protocols.
Now that we understand this better, our next good steps would be to fuzz this protocol and explore what's in store for us. Something we could explore in our next blog!
References:
https://dl.acm.org/doi/pdf/10.1145/3098822.3098842
https://www.f5.com/glossary/quic-http3
https://datatracker.ietf.org/doc/html/rfc9000