When neither UDP (User Datagram Protocol) User Datagram Protocol A simple transport protocol with no reliability, no flow control and no congestion control. introduced in ch. 1 nor TCP (Transmission Control Protocol) Transmission Control Protocol The Internet transport protocol that delivers data reliably and in order, with flow control and congestion control. introduced in ch. 1 quite fits, you can build what you need in the application layer instead — and QUIC (Quick UDP Internet Connections) Quick UDP Internet Connections A transport-like protocol built in the application layer over UDP, carrying HTTP/3. The IETF now treats QUIC as a name rather than an abbreviation. introduced in ch. 2 is what happens when someone does that seriously.
Words you will meet
- QUIC — Quick UDP Internet Connections: an application-layer protocol that does TCP’s job.
- QUIC stream — one independent, reliably delivered flow inside a QUIC connection.
- Connection ID — what identifies a QUIC connection, carried in every packet header.
- HTTP/3 — the version of HTTP (HyperText Transfer Protocol) HyperText Transfer Protocol The application-layer protocol that requests and transfers Web documents. introduced in ch. 1 built on QUIC rather than TCP.
Why this matters
This is the last teaching section of the chapter, and a good place to end. QUIC uses nearly everything the chapter built — reliable data transfer, congestion control, connection management — assembled somewhere the chapter did not expect.
It also closes two accounts opened in chapter 2. Section 2.2.5 described head-of-line blocking and section 2.2.6 showed HTTP/2 solving it within a connection while leaving the TCP-level problem untouched. QUIC finishes the job.
There is no longer “the” TCP
Three decades of experience has found circumstances where neither UDP nor TCP is ideally suited, and transport-layer design has kept evolving.
| Built for | |
|---|---|
Cells marked ⓘ have an explanation — click to read it. Sortable columns have a ↕ in the heading.
A selection of the versions the book names, and what each was built for.
A remarkable sentence about the Internet’s most important protocol
The book puts it plainly: it is probably not even correct anymore to refer to “the” TCP protocol. Perhaps the only features they all share are the segment format of Figure 3.29, and an obligation to compete fairly with one another in the face of congestion.
That second condition is not a formality. Section 3.7.2 showed BBR (Bottleneck Bandwidth and Round-trip propagation time) Bottleneck Bandwidth and Round-trip propagation time A delay-based congestion-control protocol [Cardwell 2017] that Google uses on its B4 network and public servers (§3.7.2). introduced in ch. 3 having to add specific machinery so that a delay-based sender would not be trampled by loss-based ones. Interoperating on the wire is easy; sharing a bottleneck politely is the hard part.
QUIC
Suppose an application needs more than UDP gives but does not want everything TCP brings, or wants something different again. The designer can always roll their own protocol at the application layer. That is the approach taken in QUIC quic Simple An application-layer protocol over UDP that does TCP’s job, faster and per stream. Precise Quick UDP Internet Connections [Langley 2017, RFC 9000]: a connection-oriented, encrypted, congestion-controlled protocol implemented in the application layer on top of UDP. It merges the connection, authentication and encryption handshakes into one exchange, so setup costs fewer round trips than TCP plus TLS, and it provides reliable in-order delivery separately per stream. Its congestion control is based on TCP NewReno [RFC 6582]. HTTP/3 is built on it. introduced in ch. 3 — open in glossary [Langley 2017, QUIC 2020].
QUIC is a new application-layer protocol, designed from the ground up to improve the performance of transport-layer services for secure HTTP (HyperText Transfer Protocol) HyperText Transfer Protocol The application-layer protocol that requests and transfers Web documents. introduced in ch. 1 . It is already widely deployed, though still being standardised as an RFC (Request For Comments) Request For Comments The name of an IETF standards document. There are currently nearly 9000 of them. introduced in ch. 1 .
Where it runs, and how much of the Internet it carries
Google has deployed QUIC on many public-facing web servers, in the mobile YouTube app, in the Chrome browser, and in Android’s Google Search app. More than 7 % of Internet traffic was QUIC as measured in [Langley 2017].
The stack is: QUIC over UDP over IP (Internet Protocol) Internet Protocol The network-layer protocol that defines the datagram format and addressing every Internet device must use. introduced in ch. 1 , with a simplified but evolved version of HTTP/2 above it. HTTP/3 http/3 Simple The version of HTTP built on QUIC rather than on TCP. Precise The HTTP version that natively incorporates QUIC, so that the reliability, congestion control and encryption HTTP/2 obtained from TCP and TLS come from QUIC over UDP instead. Each object in a page travels on its own QUIC stream, so a loss affecting one object does not hold up the others. introduced in ch. 3 — open in glossary natively incorporates QUIC [HTTP/3 2020].
Give the year with the 7 % figure — it is a 2017 measurement, in a 2021 book.
Connection-oriented, and always encrypted
Like TCP, QUIC is connection-oriented between two endpoints, and needs a handshake to establish connection state. Two pieces of that state are the source and destination connection ID.
All QUIC packets are encrypted. And because encryption was assumed from the start, QUIC combines the handshakes needed to establish connection state with those needed for authentication and encryption. The traditional stack cannot do that: TLS runs on top of TCP, so TCP’s handshake must finish before TLS’s can begin.
Two negotiations, one after the other. TCP must finish before TLS can begin, because TLS runs on top of it.
Click any arrow to see what that message says and why it is sent.
Two stacks, the same goal. Switch between them and count the exchanges before any application data moves.
Read this diagram as text
- Client sends SYN to Server. The three-way handshake of section 3.5.6 begins. No application data can travel yet.
- Server sends SYN, ACK to Client.
- Client sends ACK to Server. The TCP connection now exists. One full round trip has been spent, and nothing has been encrypted or authenticated.
- Client sends TLS handshake begins to Server. Only now can TLS start negotiating keys and certificates, over the connection TCP just built. Chapter 8 covers what this exchange contains; the point here is that it is a SECOND negotiation, and it could not begin any earlier.
- Server sends TLS handshake continues to Client.
- Client sends HTTP request, at last to Server. Multiple round trips have gone before a single byte of the request. Section 2.2.2 counted the TCP part of this cost; the TLS part is on top of it.
Lifelines, left to right: Client (host), Server (server).
Streams
QUIC lets several application-level streams quic stream Simple One independent, reliably delivered flow inside a QUIC connection. Precise An abstraction for reliable, in-order, two-way delivery between two QUIC endpoints. Many streams share one QUIC connection and new ones can be added quickly; each has a stream ID, carried with the connection ID in the packet header. Because loss recovery is per stream, a lost UDP segment delays only the streams whose data it carried — which is how QUIC removes the head-of-line blocking of §2.2.5. In HTTP/3 there is one stream per object in a Web page. Not to be confused with TCP’s single byte stream. introduced in ch. 3 — open in glossary be multiplexed through a single connection, and once the connection exists, new streams can be added quickly.
A stream is an abstraction for reliable, in-order, two-way delivery between two QUIC endpoints. In HTTP/3, there is a different stream for each object in a web page. Each connection carries a connection ID and each stream a stream ID, both in the QUIC packet header. Data from several streams may travel in a single QUIC segment inside one UDP segment.
This idea is older than QUIC
The Stream Control Transmission Protocol, SCTP (Stream Control Transmission Protocol) Stream Control Transmission Protocol An earlier reliable, message-oriented protocol [RFC 4960] that pioneered multiplexing several application streams over one connection. Used in 4G and 5G control-plane protocols (§3.8). introduced in ch. 3 [RFC 4960, RFC 3286], is an earlier reliable, message-oriented protocol that pioneered multiplexing multiple application-level streams through a single connection.
It is still in use: chapter 7 shows SCTP carrying control-plane protocols in 4G and 5G cellular networks.
And this is what removes head-of-line blocking
TCP delivers one in-order byte stream. Nothing past a gap can be handed up, however cleanly it arrived.
Click any arrow to see what that message says and why it is sent.
Four objects being fetched. In both runs the same segment is lost. Watch what happens to the objects that arrived perfectly.
Read this diagram as text
- Server sends object 1 to Client.
- Server sends object 2 to Client — lost. Lost in the network.
- Server sends object 3 to Client. Arrives intact — and is buffered, not delivered. Section 3.5.4 showed that real TCP implementations do buffer out-of-order segments; what they cannot do is hand them to the application, because that would break the in-order guarantee.
- Server sends object 4 to Client. Also intact, also stuck behind the gap.
- Server sends object 2 (retransmitted) to Client — retransmission. Only when this arrives can objects 2, 3 and 4 all be delivered together. Objects 3 and 4 waited for a retransmission of something else entirely — head-of-line blocking, exactly as section 2.2.5 described it.
Lifelines, left to right: Server (server), Client (host).
The problem chapter 2 could only half solve
Section 2.2.5 introduced head-of-line blocking, and section 2.2.6 showed HTTP/2 attacking it by cutting messages into interleaved HTTP/2 frames. That helped — but it left the deeper problem alone.
Because TCP provides reliable, in-order byte delivery, everything sent over one connection must be delivered in order. If bytes from one HTTP message are lost, the messages behind them cannot be delivered until the lost bytes have been retransmitted and received. HTTP/2’s interleaving happens above a connection that still blocks.
QUIC provides reliable in-order delivery per stream. A lost UDP segment affects only the streams whose data it carried; messages in other streams keep being delivered. That is the piece HTTP/2 could not reach, and it is why HTTP/3 exists.
Its reliable delivery uses acknowledgement mechanisms similar to TCP’s, as specified in RFC 5681 — the same document behind section 3.5.4.
Congestion control
QUIC’s congestion control is based on TCP NewReno [RFC 6582], a slight modification of the Reno protocol from section 3.7.1.
Its own draft specification says it best: “Readers familiar with TCP’s loss detection and congestion control will find algorithms here that parallel well-known TCP ones.”
In plain words
QUIC did not invent new transport machinery. It took what this chapter spent a hundred pages building — sequence numbers, acknowledgements, timers, retransmission, a probing congestion window — and moved it somewhere it could be changed.
That is the whole argument. TCP is in the operating system, so changing it means changing operating systems, and in practice middleboxes too. QUIC is in the application, so changing it means shipping a new browser.
| TCPin the operating system | QUICin the application | |
|---|---|---|
| Layer | ||
| Runs over | ||
| Connection-oriented | ||
| Encryption | ||
| In-order delivery is guaranteed across | ||
| Congestion control | ||
| How fast it can change |
Cells marked ⓘ have a reason behind them — click to read it.
QUIC does almost everything TCP does. What changed is where it lives — and one thing it does differently.
Why the layer matters more than the algorithms
QUIC is an application-layer protocol providing reliable, congestion-controlled data transfer between two endpoints. Its authors stress what that buys: changes can be made at “application-update timescales” — far faster than TCP or UDP can be updated.
Look back at what this chapter has covered and notice how much of it is thirty or forty years old. Slow start and congestion avoidance were standardised in the late 1980s. The segment format has not changed. That stability is a virtue and also a cage, and QUIC is an escape from it rather than a replacement for what is inside.
Check yourself
Check yourself
0 of 6 answered1.Which layer does QUIC belong to?
Look at what it runs on top of.
2.predictSwitch the handshake ladder to QUIC. Why does it need fewer exchanges than TCP with TLS?
3.predictIn the head-of-line blocking comparison, a segment carrying part of object 2 is lost. What happens to objects 3 and 4?
4.What is QUIC's congestion control based on?
5.The book says it is "probably not even correct anymore to refer to 'the' TCP protocol". What do the many versions still share?
6.Why does it matter that QUIC lives in the application layer?
What to remember
- QUIC is an application-layer protocol running over UDP. It does TCP’s job from a place where it can be changed quickly, and that timescale — application updates rather than operating-system updates — is the real gain.
- Because encryption was assumed from the start, QUIC merges the connection and security handshakes. The traditional stack must do TCP first, then TLS on top.
- A QUIC stream is reliable, in-order, two-way delivery, and HTTP/3 uses one per object. Per-stream delivery is what finally kills head-of-line blocking: a lost segment delays only its own streams.