Explore the connection, the network, and the application. Every card has an example and an explained answer.
01 / Connection setup
0-RTT and replay
A returning client can send early data before setup finishes. The server can reject it, and an attacker may replay it.
Previous session→Early request→Accept or retry
Example
A client sends an instruction to purchase a camera as early data.
Does encryption make repeating that instruction harmless?
No. Encryption does not prevent replay. Use an application policy that excludes unsafe early operations and handles rejection without duplicate effects.
A saved round trip does not imply that every operation belongs in 0-RTT.
Source: RFC 9001 §8
02 / HTTP/3
QPACK header dependencies
QPACK compresses HTTP fields with static entries, dynamic entries, and literals. A header block can wait for a referenced dynamic entry.
Insert entry 12→Header references 12→Decode after insert
Example
A response header reaches the decoder before the encoder instruction that creates its referenced entry.
Can the decoder finish just because its request stream arrived?
No. It waits for that QPACK dependency. Static entries or literals avoid this particular wait, with a different compression tradeoff.
Independent QUIC streams do not remove dependencies introduced by HTTP/3.
Source: RFC 9204 §2
03 / Network capacity
Congestion control
The sender limits outstanding traffic to avoid overwhelming the path. Acknowledgments and loss help the controller adjust its sending behavior.
Send within budget→Observe the path→Adjust and pace
Example
Eight streams share one connection. The network becomes congested.
Does opening eight more streams double the path capacity?
No. The streams share a congestion budget on this path. More streams do not create bandwidth. Compare controllers with a repeatable workload and measured delay.
The diagram does not rank BBR, CUBIC, or other controllers.
Source: RFC 9002 §7
04 / Network signals
Path size and ECN
Path MTU constrains packet size. Explicit Congestion Notification (ECN) can report congestion without requiring a packet drop.
Try a probe size→Check delivery→Keep a supported size
Example
A path carries smaller probes but repeatedly fails to carry a larger probe.
Should the sender assume that every route accepts a 1500-byte UDP payload?
No. UDP payload limits depend on the path and header overhead. Probe carefully and use a supported size. ECN requires separate validation and feedback.
An IP MTU and a UDP payload size are different measurements.
Source: RFC 9000 §13.4 and §14
05 / Observable metadata
Spin bit and connection IDs
The optional spin bit exposes a latency signal. Connection IDs help routing and migration, but their use can also affect linkability.
Protected payload→Visible metadata→Privacy choices
Example
An observer sees packets on two networks with identifiers that are easy to relate.
Does encrypted application data hide every connection detail?
No. Addresses, sizes, timing, and some header fields remain observable. Connection ID rotation and spin-bit policy address parts of this exposure.
Rotating an ID is not a complete anonymity guarantee.
Source: RFC 9000 §17.4 and §9.5
06 / Changing paths
Connection migration
Supported client migration associates a new network path with an existing connection. The endpoints validate reachability on that path.
Wi-Fi path→Validate mobile path→Continue connection
Example
A phone leaves Wi-Fi coverage during a transfer.
Must its QUIC connection keep one unchanged connection ID?
No. Connection IDs can change. Endpoint policy, usable IDs, path validation, and reachability determine whether migration succeeds.
Migration does not promise zero loss or zero delay.
Source: RFC 9000 §9
07 / Delivery policy
Unreliable datagrams
The DATAGRAM extension carries messages without transport retransmission. It still uses congestion control and does not guarantee arrival order.
Position 41 lost→Position 42 arrives→Discard stale values
Example
A dashboard needs the latest position, while newer samples replace older samples.
What must the receiver add when it accepts missing updates?
Add sequence or timestamp checks and a policy for stale or absent updates. The application decides whether a late value is still useful.
Support and size limits must be negotiated. A datagram is not an unlimited message.
Source: RFC 9221 §5
08 / Handshake privacy
Encrypted ClientHello
ECH encrypts an inner TLS ClientHello using a published configuration. The outer ClientHello remains visible to the network.
Fetch ECH configuration→Encrypt inner hello→Send outer hello
Example
A client uses ECH while contacting a server at a visible IP address.
Does ECH conceal the destination IP address or traffic timing?
No. ECH protects selected handshake information. It does not hide the network destination, packet sizes, timing, or all information from DNS.
ECH needs suitable client and server support. QUIC alone does not imply ECH support.
Source: RFC 9849
09 / Receiver capacity
Flow control
The receiver advertises a stream limit and a connection limit. Both must permit additional stream bytes before the sender can send them.
Stream credit→Connection credit→Send within both
Example
Stream A reaches its limit. Stream B still has credit, and the connection still has credit.
Must B stop because A is flow-control blocked?
No. B can use its remaining allowance. If the connection allowance is exhausted, additional stream data across the connection must wait.
Credit is not bandwidth. Retransmitting the same byte range does not consume new flow-control credit.
Source: RFC 9000 §4
10 / Feedback timing
Acknowledgment frequency
An acknowledgment reports packet receipt. The ACK Frequency proposal lets an endpoint request changes to its peer’s acknowledgment behavior.
Data packets→Receiver feedback→Loss and timing estimates
Example
A link has a constrained return path, and acknowledgments consume some of it.
Is the largest possible acknowledgment delay always best?
No. Fewer acknowledgments can reduce overhead, but delayed feedback affects timing and recovery. Evaluate the tradeoff and negotiated support.
Draft-14 was listed as expired on 2026-09-20. This card explains the proposal, not a baseline QUIC v1 requirement.
Source: ACK Frequency draft-14
11 / Lost connection state
Stateless reset
An endpoint that loses connection state can use a stateless reset under the protocol’s conditions. A known reset token lets the peer recognize it.
Connection state lost→Recognized reset token→Connection ends
Example
A server restarts and receives a packet for a connection it no longer knows.
Does every restart require a stateless reset response?
No. Stateless reset has prerequisites and response restrictions. An arbitrary packet must not become a valid reset merely because it arrived.
This terminates a connection. RESET_STREAM affects one sending direction of one stream.
Source: RFC 9000 §10.3
12 / Compatible endpoints
Version negotiation
Endpoints need a mutually supported QUIC version. Compatible version negotiation can let suitable versions negotiate without restarting connection setup.
Client version→Server support→Validate the selection
Example
A server advertises a list of versions to a client.
Does seeing that list prove downgrade protection works?
No. A displayed list is not a validation result. Check the applicable negotiation and transport-parameter rules for the versions in use.
RFC 9368 extends version negotiation. It does not make every version pair compatible.
Source: RFC 9368
13 / Handshake bytes
CRYPTO reassembly
CRYPTO frames carry TLS handshake bytes with offsets. The receiver reassembles those bytes within the relevant encryption level.
Offset 4 arrives→Offset 0 arrives→Contiguous handshake bytes
Example
Bytes at offsets 4–7 arrive before bytes at offsets 0–3.
Are these bytes on an ordinary application stream with a stream ID?
No. CRYPTO frames have no application stream ID. The receiver handles their offsets separately for each encryption level and supplies contiguous bytes to TLS.
Duplicate ranges can occur during recovery. An overlap alone is not proof of a protocol error.
Source: RFC 9000 §19.6
14 / Using several paths
Multipath QUIC
Multipath extends QUIC so a connection can use several paths. Scheduling, path validation, and congestion behavior affect the result.
Wi-Fi path→Path scheduler→Cellular path
Example
Two paths have different delays, and the application needs ordered bytes on one stream.
Does total useful throughput always equal the sum of both path rates?
No. Reordering, shared bottlenecks, scheduling, and receiver behavior can reduce the benefit. Measure the workload instead of adding advertised rates.
This card uses draft-21. Multipath support is separate from baseline client migration.
Source: Multipath draft-21
15 / Application interface
WebTransport sessions
WebTransport over HTTP/3 establishes sessions through Extended CONNECT. A session can expose reliable streams and unreliable datagrams.
HTTP/3 connection→WebTransport session→Streams and datagrams
Example
A browser application needs file delivery and replaceable telemetry in one session.
Does WebTransport choose the correct delivery policy for each message?
No. The application chooses streams or datagrams and defines framing, expiry, and failure behavior. Browser and server support must also match.
This card uses draft-16. WebTransport sessions and QUIC connections are distinct concepts.
Source: WebTransport over HTTP/3 draft-16