Transport, made visibleIllustration · no network traffic

Same network. Different delivery rules.

Follow five concepts. Change one condition and see what the receiver can do.

01 / Protocol layers

QUIC uses UDP. It adds its own transport rules.

Read downward from the application to the network. These examples compare HTTP/2 and HTTP/3.

HTTP/2 path

TLS over TCP

  1. HTTP/2 requests and responses
  2. TLS 1.3 encryption
  3. TCP one ordered byte stream
  4. IP addressing and routing
HTTP/3 path

QUIC over UDP

  1. HTTP/3 requests and responses
  2. QUIC + TLS 1.3 streams and encryption
  3. UDP datagram carrier
  4. IP addressing and routing

UDP does not recover lost data. QUIC implements recovery for its reliable streams above UDP.

Read more: RFC 9000 §1 and RFC 9001 §4. Link and physical layers are omitted here.

02 / Connection setup

Count the waits before a client sends a request.

A fresh connection, TLS 1.3, no loss, no Retry, and no TCP Fast Open. DNS and processing time are excluded.

TCP + TLS 1.3

Two sequential setup exchanges

ClientServer SYN SYN-ACK ACK + TLS ClientHello Server TLS handshake Client Finished + request

160 ms 2 × RTT before request send

QUIC + TLS 1.3

Transport and crypto together

ClientServer Initial + TLS ClientHello Server TLS handshake Client Finished + request Request leaves the client earlier.

80 ms 1 × RTT before request send

0-RTT is a separate resumption case. Eligible clients can send early data, but the server can reject it and replay remains a concern.

These counts describe request-send timing, not response latency or a speed benchmark. RFC 9001 §4; RFC 8446 §8.

03 / Head-of-line blocking

A gap in A does not have to block B.

A and B are independent application streams on one connection. The lost packet in this example carries only A2.

Multiplexed over TCP

One transport delivery order

Application chunks in TCP byte order
A1delivered
B1delivered
A2in flight
B2in flight

Later bytes wait behind the missing range.

QUIC streams

A delivery order for each stream

Stream A
A1delivered
A2in flight
Stream B
B1delivered
B2in flight

A1 and B1 arrived. A2 and B2 are in flight. Drop A2 to compare delivery.

QUIC packets can carry data from several streams. Streams still share congestion control, and application dependencies can cause additional waiting.

The boxes represent application chunks, not complete packet formats. RFC 9000 §2 and §13.

04 / Connection migration

A new path can keep the same QUIC connection.

Assume an established connection, supported client migration, and a reachable server on the new path.

Ordinary TCP

The address tuple changes

Wi-Fi
Server

Original connection active

Ordinary TCP identifies the connection by its addresses and ports.

QUIC

Connection identity and path differ

Wi-Fi
Server

Original connection active

Connection IDs help associate packets with the existing connection.

Both examples use Wi-Fi. Switch the client's network to change its address.

Path validation uses PATH_CHALLENGE and PATH_RESPONSE. Connection IDs can change; an unchanged ID is not required. Migration is not a zero-loss guarantee.

This comparison excludes TCP extensions and VPNs that preserve a stable address. RFC 9000 §8–9.

05 / Delivery choice

Choose what the application needs to preserve.

Reliable stream

Recover missing bytes

The receiver gets bytes in order while the stream remains active. A gap can delay later bytes on that stream.

Useful when the complete content matters.

QUIC DATAGRAM extension

Permit missing messages

Lost DATAGRAM frames are not retransmitted. The application handles missing, late, or reordered messages.

Useful when a newer value replaces an older one.

Reliable does not mean on time. Datagram does not mean congestion-free. Commands also need expiry, acknowledgment, and failure behavior where appropriate.

This example concerns position telemetry, not an emergency-stop system. RFC 9221 §5.