Skip to content

QUIC and HTTP/3

HTTP/2 vs HTTP/1.1

In HTTP/2, each HTTP request/response exchange is associated with its own stream. Multiple streams can be multiplexed on the same TCP connection. Streams are largely independent of each other, so a blocked or stalled request or response does not prevent progress on other streams within the same connection. This contrasts with HTTP/1.1 where a blocked connection can stall all ongoing transactions (head of line blocking).

HTTP/2 is a binary protocol. Streams are represented in a binary form, which allowsmore efficient and less error-prone parsing of messages compared to HTTP/1.1's whitespace-delimited text fields.

  • Header Compression: HTTP/2 includes header field compression, which reduces the amount of redundant and verbose header data sent over the network, leading to lower overhead and faster initial connection setup.
  • Server Push: HTTP/2 introduces unsolicited push of representations from servers to clients. This allows a server to proactively send resources that a client is likely to need, potentially reducing latency.
  • Most regular HTTP header fields from HTTP/1.1 are still used in HTTP/2. However, there are some important differences in how they are treated (connection-specific headers are no longer used, header field names must be lowercase and other).

  • HTTP/2 uses special pseudo-header fields (starting with a colon, :) to convey the target URI, the method of the request, and the status code for the response (which were part of the start-line in HTTP/1.1):

    • :method replaces the HTTP method from the request line.
    • :authority largely replaces the Host header field.
    • :path replaces the path and query parts of the request URI.
    • :status replaces the status code from the status line.

HTTP/3 (QUIC) vs HTTP/2

HTTP/3 uses QUIC as its transport protocol, which runs over UDP.

QUIC provides stream multiplexing at the transport layer, whereas HTTP/2 implements it at the application layer as a framing layer on top of TCP. QUIC provides flow and congestion control across the entire connection, not at the stream level.

QUIC provides reliability at the stream level: if a packet is lost, only the affected QUIC stream might be delayed, not necessarily all streams on the connection. HTTP/2 is instead susceptible to head-of-line blocking at the connection level: a lost or reordered TCP packet can stall all active HTTP/2 transactions on that connection.

Connection establishment

QUIC incorporates TLS 1.3 at the transport layer. QUIC's handshake combines connection establishment and security negotiation, potentially reducing the number of round trips compared to establishing a separate TCP connection and then a TLS handshake as is typical with HTTP/2.

TLS 1.3:

  • When establishing a new connection to a server that hasn't been seen before, it typically takes two RTT before data can be sent. TLS 1.3 aims to reduce this latency (1-RTT mode) by allowing the client to send Diffie-Hellman key shares in the first message. This is possible due to a simplified cipher negotiation model and a reduced set of key agreement options.
  • TLS 1.3 also introduces zero-RTT resumption (0-RTT), which allows clients to send encrypted data in their first message, resulting in no additional latency cost compared to unencrypted HTTP. This is for resumed sessions where the client and server have previously established a shared secret (PSK).

QUIC:

  • A full handshake for a new connection typically takes 1 RTT, as QUIC leverages TLS 1.3's optimized handshake. In rare situations where the server does not support the client's initial key share in a 1-RTT handshake, the server can send a HelloRetryRequest, requiring an additional RTT.
  • A resumed handshake using pre-shared keys (PSK) can achieve 0 RTT.