Mastodawn

In our next edition textbook we will be expanding our coverage of QUIC, the most successful effort to date to add another transport protocol to the TCP/IP suite. While QUIC targets the performance of Web traffic as its primary goal, it really addresses a long-standing need for a protocol with different properties than either TCP or UDP. Specifically, there has never really been a good transport for RPC (remote procedure call), which has request/response semantics, rather than the reliable byte-stream that TCP delivers. And when you look at what loading a web page entails—a series of requests for content that can be generally be served in any order—it becomes clear why a new abstraction was needed. https://systemsapproach.org/2026/04/06/quic-the-third-transport-protocol/ 🧵 1/n

Show thread

Systems Approach Apr 7

There is lots of good information in the original QUIC design spec as well as some conference publications on the design and evaluation of SPDY (predecessor of HTTP/2) and QUIC.

https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit?usp=sharing

https://www.usenix.org/conference/nsdi14/technical-sessions/wang

https://dl.acm.org/doi/10.1145/3718958.3754353

2/n

QUIC: Design Document and Specification Rationale

QUIC Quick UDP Internet Connections MULTIPLEXED STREAM TRANSPORT OVER UDP Jim Roskind <[email protected]> To paraphrase a famous quote: I apologize in advance for the length of this document, and if I had more time, I would surely have written less. First Draft 2012-04 Revised: 2013-06-24 Minor...

Google Docs

Show thread

Systems Approach Apr 7

QUIC is defined in four RFCs spanning a few hundred pages, so making sense of that for textbook length coverage is no small task. But that's what we're willing to do for the devoted readers of our books.

There's a disconcerting (for old school types) lack of packet headers in the QUIC specs, where textual representation of packet headers has been used. We decided to make some packet header pictures anyway.

We hope the person who gave us a one-star review entitled "Wall of Text" appreciates the effort.

https://www.amazon.com/gp/customer-reviews/R1IVEX207N7WY8/ref=cm_cr_arp_d_rvw_ttl?ie=UTF8&ASIN=B004VF6216

(For comparison, here is the same header as described in the spec:

Long Header Packet {
Header Form (1) = 1,
Fixed Bit (1) = 1,
Long Packet Type (2),
Type-Specific Bits (4),
Version (32),
Destination Connection ID Length (8),
Destination Connection ID Length (8),
Destination Connection ID (0..160),
Source Connection ID Length (8),
Source Connection ID (0..160),
Type-Specific Payload (..),
}
3/n

Show thread

Systems Approach

Because QUIC differs from TCP in many ways large and small, trying to describe its most important features feels a bit like the parable of the blind men and the elephant. One aspect that grabs our attention is the way the layering with TLS was redesigned in QUIC. Here is the picture we use to show this:

More on this topic:
https://systemsapproach.org/2021/09/27/the-importance-of-thinking-across-layer-boundaries/

The redesigned layering allowed several round-trip times of connection establishment to be reduced to a single RTT, with the potential for application data to be sent in the first RTT. 0-RTT data is a good example of a complex tradeoff between performance and security. Even without 0-RTT data, the redesigned layers of QUIC and TLS reduce the number of RTTs needed to get a secure channel established, thus providing a real performance benefit to the application.

More on 0-RTT tradeoffs:
https://systemsapproach.org/2025/11/17/tradeoffs-in-system-security/

4/n

The Importance of Thinking Across Layer Boundaries - Systems Approach

Strict layering is not always the best way to think about protocols. QUIC provides a case study in protocol layering for better performance

Systems Approach

Show thread

Systems Approach Apr 7

Streams are the primary mechanism making QUIC a better fit for request/response operations(and RPC). When HTTP runs over TCP, the only way to allow one request to proceed independently of another is to open multiple parallel TCP connections. With each connection running its own congestion control loop, congestion on one connection is not apparent to the other connections; each connection tries to figure out the appropriate amount of bandwidth to consume on its own, while competing with the others. And if HTTP runs over a single TCP connection, a single dropped packet blocks the entire progress of any requests in flight until that lost packet is retransmitted.

So QUIC allows for many streams within a single connection, and each stream can make progress independently from the others. A single packet loss only impacts the stream (or streams) whose data was in that packet. At the same time, QUIC can use that one packet loss to respond appropriately to congestion.

5/n

Show thread

Systems Approach Apr 7

QUIC's approach to congestion control is, by default, modeled on TCP NewReno, but QUIC also allows more accurate detection of packet loss and expanded SACK (selective acknowledgement) capability. RFC 9002 is all about how QUIC does loss detection and congestion control.

https://www.rfc-editor.org/info/rfc9002

6/n

Information on RFC 9002 » RFC Editor

Show thread

Systems Approach Apr 7

QUIC has a lot going for it. Since 2012 the team has paid close attention to deployment considerations (which is why it runs over UDP—the TCP/UDP duopoly lives on thanks to middleboxes). And with a carefully considered design, QUIC has made a real difference to the performance of the web and of other applications needing request/response semantics.

More here:

https://systemsapproach.org/2026/04/06/quic-the-third-transport-protocol/

/FIN

QUIC: The Third Transport Protocol - Systems Approach

QUIC will be about as important as TCP in the coming years. Not only does it improve web performance but it's a suitable protocol for RPC

Systems Approach