rfc-visual
GitHub

RFC 9000 · May 2021 · J. Iyengar, M. Thomson

QUIC: A UDP-Based Multiplexed and Secure Transport

PROPOSED STANDARDIETF stream
4 verified errata4 held for document update

Index fetched 2026-10-19 from rfc-editor.org

How it works

Built by hand from RFC 9000. Every arrow, step and field cites the RFC sentence it comes from, and an automated test checks each quote against the RFC text. Provisional: not yet reviewed by a second engineer. Help verify this visual

100%

RFC 9000 §7.1 Figure 5 provides an overview of the 1-RTT handshake. Each line shows a QUIC packet with the packet type and packet number shown first, followed by the frames that are typically contained in those packets.

  1. 1. Client → Server: Initial[0] CRYPTO[CH]

    The client's first packet is an Initial packet with packet number 0, holding a CRYPTO frame that carries the TLS ClientHello.

    RFC 9000 §7.1 Initial[0]: CRYPTO[CH] ->

  2. 2. Server → Client: Initial[0] CRYPTO[SH] ACK[0]

    The server's first flight starts with an Initial packet carrying its handshake reply in a CRYPTO frame and acknowledging the client's packet 0.

    RFC 9000 §7.1 Initial[0]: CRYPTO[SH] ACK[0]

  3. 3. Server → Client: Handshake[0] CRYPTO[EE, CERT, CV, FIN]

    The rest of the server's cryptographic handshake travels in a Handshake packet, again inside a CRYPTO frame.

    RFC 9000 §7.1 Handshake[0]: CRYPTO[EE, CERT, CV, FIN]

  4. 4. Server → Client: 1-RTT[0] STREAM[1, ... ]

    The server's first flight can also include "0.5-RTT data" in 1-RTT packets, here stream data on stream 1.

    RFC 9000 §7.1 <- 1-RTT[0]: STREAM[1, "..."]

  5. 5. Client → Server: Initial[1] ACK[0]

    The client acknowledges the server's Initial packet.

    RFC 9000 §7.1 Initial[1]: ACK[0]

  6. 6. Client → Server: Handshake[0] CRYPTO[FIN], ACK[0]

    The client finishes its side of the cryptographic handshake in a Handshake packet and acknowledges the server's Handshake packet.

    RFC 9000 §7.1 Handshake[0]: CRYPTO[FIN], ACK[0]

  7. 7. Client → Server: 1-RTT[0] STREAM[0, ... ], ACK[0]

    The client sends its own stream data (stream 0) in a 1-RTT packet and acknowledges the server's 1-RTT packet.

    RFC 9000 §7.1 1-RTT[0]: STREAM[0, "..."], ACK[0] ->

  8. 8. Server → Client: Handshake[1] ACK[0]

    The server acknowledges the client's Handshake packet.

    RFC 9000 §7.1 Handshake[1]: ACK[0]

  9. 9. Server → Client: 1-RTT[1] HANDSHAKE_DONE, STREAM[3, ... ], ACK[0]

    The server sends a HANDSHAKE_DONE frame in a 1-RTT packet, along with more stream data and an acknowledgment.

    RFC 9000 §7.1 <- 1-RTT[1]: HANDSHAKE_DONE, STREAM[3, "..."], ACK[0]

Not shown: Receiving part of a stream state machine (Section 3.2: Recv, Size Known, Data Recvd, Reset Recvd, Data Read, Reset Read); Bidirectional stream composite states (Section 3.4); Per-packet-type long header fields (Reserved Bits, Packet Number Length, Length, Packet Number; Sections 17.2.1-17.2.5) and the short header (Section 17.3); Simplified handshake (Figure 4) and 0-RTT handshake (Figure 6); TLS details live in RFC 9001; Connection lifecycle: address validation, connection IDs, migration, idle timeout and closing; Flow control, loss detection and congestion control.

Lineage

No other RFCs obsolete or update this one.

Text

Loading the RFC text…