English
Menu

HTTP/1.1 vs HTTP/2 vs HTTP/3: Transport, Multiplexing, Head-of-Line Blocking, Header Compression and Encryption

The three versions share the same HTTP semantics (RFC 9110), such as methods, status codes and header fields; what differs is the format and the transport used to carry them. HTTP/1.1 (RFC 9112) sends text messages over TCP and returns responses one at a time on each connection. HTTP/2 (RFC 9113) splits messages into binary frames and multiplexes several streams over one TCP connection. HTTP/3 (RFC 9114) uses QUIC (RFC 9000), which runs over UDP and handles stream multiplexing and TLS 1.3 encryption in the transport. This avoids TCP head-of-line blocking, where the loss of a single packet stalls every stream.

AspectHTTP/1.1HTTP/2HTTP/3
SpecificationRFC 9112 (semantics in RFC 9110, shared by all three versions)RFC 9113RFC 9114 (QUIC is RFC 9000)
TransportTCPTCPQUIC (runs over UDP)
Message formatText: a request line and header fields written one per lineBinary framesBinary frames (on QUIC streams)
MultiplexingNone: one connection handles one request and response at a time, so fetching in parallel requires opening several connectionsSeveral streams are sent in parallel over one TCP connectionSeveral QUIC streams are sent in parallel; the streams are managed by the transport
Head-of-line blockingOccurs at the HTTP layer: on the same connection, the next response cannot be sent until the previous one finishes (even with pipelining, responses come back in request order)Solved at the HTTP layer, but because TCP delivers bytes strictly in order, the loss of one packet makes every stream wait for the retransmissionQUIC manages ordering per stream, so a loss affects only the streams whose data was lost
Header compressionNone (the body can be compressed, but headers are sent as plain text)HPACK (RFC 7541)QPACK (RFC 9204), an adaptation of HPACK that works even when streams arrive out of order
EncryptionOptional: https uses TLS, while http is sent in cleartextThe specification defines both over TLS (h2) and cleartext (h2c); over TLS it requires TLS 1.2 or later. Major browsers support HTTP/2 only over TLSMandatory: TLS 1.3 is built into QUIC, and there is no cleartext mode
Round trips to set up a connectionOne for TCP, plus one more with TLS 1.3, so the request is sent after two round trips in totalSame as HTTP/1.1 (two round trips for TCP and TLS)QUIC combines the transport and cryptographic handshakes into one round trip; 0-RTT, which sends data in the very first flight, is also available for servers contacted before
When the network changesA TCP connection is identified by the source and destination addresses and ports, so a new connection is needed when the IP address changesSame as HTTP/1.1QUIC identifies connections by connection IDs, so the same connection can continue when switching from wireless LAN to a mobile network (connection migration)

Figures are typical orders of magnitude and vary by process generation and product.

When to use which

HTTP/1.1
The baseline version that every client and server can use. It is also used for communication inside server systems and for simple web interfaces such as device settings pages.
HTTP/2
When a web page that loads many small files should be delivered efficiently over one connection. Because it works on networks that block UDP, it is the fallback even for sites that support HTTP/3.
HTTP/3
When you want to keep streams from stalling each other on lossy, high-latency links such as mobile networks, or want faster connection setup. Some networks block UDP, so sites usually support HTTP/2 or HTTP/1.1 as well.

FAQ

Didn't HTTP/2 eliminate head-of-line blocking?

It eliminated it at the HTTP layer, but it remains at the TCP layer. HTTP/2 multiplexes several streams over one TCP connection, but TCP does not know which stream the data belongs to and delivers bytes strictly in order. So when one packet is lost, data for unrelated streams is also held back from the receiving application until the retransmission arrives. In HTTP/3, QUIC manages ordering per stream, so only the streams containing the lost data have to wait.

How does a client know that a server supports HTTP/3?

HTTP/3 uses UDP, so it has to be started separately from a TCP connection. Typically, the client first connects with HTTP/1.1 or HTTP/2 over TCP, and the server announces in the Alt-Svc response header that HTTP/3 (h3) is available. The client then uses QUIC for later connections. Separately, whether HTTP/1.1 or HTTP/2 is used over TLS is decided by ALPN during the TLS handshake.

Are there caveats to 0-RTT in HTTP/3?

Yes. Data sent with 0-RTT can be recorded by an attacker and sent again (a replay attack). With 0-RTT, care is therefore needed, for example sending only requests such as GET that cause no harm if received more than once.

Do web applications have to be rewritten for HTTP/2 or HTTP/3?

In most cases, no. The meaning of methods, status codes and header fields is shared by all three versions (RFC 9110); only the way they are carried differs. Because the version is chosen per connection, a common setup has a reverse proxy or CDN accept HTTP/2 or HTTP/3 from browsers and talk HTTP/1.1 to the application servers behind it.

Check your understanding

Which of the following correctly lists the elements in the first line (the request line) of an HTTP/1.1 request?

  1. AThe method, the request target (such as a path) and the HTTP version
  2. BThe HTTP version, the status code and a short reason phrase
  3. CThe source IP address, the destination port number and the method
Show answer and explanation

Answer: A. The method, the request target (such as a path) and the HTTP version

An HTTP request consists of the request line, the headers (one "Name: value" per line), a blank line and the body, in that order. For example, "GET /docs/index.html HTTP/1.1" is a line that requests /docs/index.html with the GET method. In HTTP/1.1 the Host header must also be sent, so that the server can tell which site a request is for even when several sites are run on the same IP address. The first line of a response is the status line, which lists the version, the status code and the reason phrase, as in "HTTP/1.1 200 OK".

Which of the following correctly describes HTTP/2 and HTTP/3?

  1. AHTTP/2 can handle several requests in parallel over one TCP connection, but a packet loss can make other streams wait too; HTTP/3 reduces this with QUIC over UDP
  2. BHTTP/2 uses messages in the same text format as HTTP/1.1 and opens a new TCP connection in parallel for each request, so that several resources can be received at once
  3. CHTTP/3 runs over TCP like HTTP/2 and only changes the header compression method; the effect of packet loss is the same as in HTTP/2, and it does not use UDP
Show answer and explanation

Answer: A. HTTP/2 can handle several requests in parallel over one TCP connection, but a packet loss can make other streams wait too; HTTP/3 reduces this with QUIC over UDP

Even HTTP/1.1 can reuse one TCP connection with persistent connections (keep-alive), but responses on one connection are received one at a time in order, so browsers opened several connections in parallel. HTTP/2 splits messages into binary frames and multiplexes several streams over one TCP connection so they are sent in parallel. However, because TCP delivers its byte stream in order, when a single packet is lost, data of unrelated streams must also wait until the retransmission arrives (head-of-line blocking). HTTP/3 uses QUIC, which runs over UDP and manages ordering per stream, so the effect of a loss stays within that stream.

From a web server with an RTT of 40 ms, one HTML file and the four images it references are fetched one after another. Assume that establishing a TCP connection takes one round trip and each request and response take one round trip, and ignore data transfer time, server processing time, TLS and connection teardown. Which of the following is the difference in total time between opening a new TCP connection for each object and reusing one TCP connection (a persistent connection)?

  1. A160 ms
  2. B200 ms
  3. C400 ms
Show answer and explanation

Answer: A. 160 ms

There are five objects in total. With a new connection each time, each object takes two round trips, one for connection setup and one for the request and response, giving 5 × 2 × 40 = 400 ms. With a persistent connection, the connection is set up only once at the start, followed by just the five requests and responses, giving (1 + 5) × 40 = 240 ms. The difference is 400 − 240 = 160 ms, which is the four connection setups saved. In HTTP/1.1, persistent connections are the default behavior.

  1. A client makes a new HTTPS connection (TLS 1.3 over TCP) to a web server with a round-trip time (RTT) of 100 ms. Roughly how long does it take until the response to the first request starts to arrive? Assume DNS resolution is already done, and ignore server processing time and data transfer time.
  2. Which of the following does HTTPS (HTTP protected by TLS) protect?

Practice Web Technology Basics questions

Key terms explained

HTTP (Hypertext Transfer Protocol)
The application-layer protocol for exchanging HTML, images and data between web browsers and web servers, among others. A client sends a request made up of a method, a URL, headers and a body, and the server returns a response made up of a status code, headers and a body. As a protocol it is stateless, so state such as a login is kept with cookies and similar means. HTTP/1.1 uses a text format and persistent connections, HTTP/2 multiplexes several streams over one TCP connection, and HTTP/3 runs over QUIC on UDP. HTTP protected by TLS is called HTTPS.
TLS
Transport Layer Security. A protocol that encrypts communication, detects tampering and authenticates servers with certificates. HTTPS is HTTP protected by TLS.
Three-way handshake
The procedure that establishes a TCP connection. Three exchanges, the client's SYN, the server's SYN+ACK and the client's ACK, confirm each side's initial sequence number.
HTTP method
The word in an HTTP request that states the operation to perform on a resource. Examples are GET (retrieve), HEAD (retrieve the headers only), POST (process or create), PUT (replace), PATCH (partially update), DELETE (delete) and OPTIONS (ask which features are available). A method that does not change the server's state is called "safe", and one that leaves the same state however many times it is sent as when it is sent once is called "idempotent". GET is safe and idempotent, PUT and DELETE are idempotent but not safe, and POST is in general neither.
HTTP status code
A three-digit number in the first line of an HTTP response that indicates the result of the request. The hundreds digit gives the class: 1xx is informational, 2xx is success (200 OK, 201 Created, 204 No Content), 3xx is redirection (301 Moved Permanently, 302 Found, 304 Not Modified), 4xx is a client error (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found) and 5xx is a server error (500 Internal Server Error, 503 Service Unavailable). 401 is used when authentication information is missing or invalid, and 403 when the client is authenticated but lacks permission.
Reverse proxy
A server placed in front of web servers that receives users' requests on the servers' behalf and relays them to one or more servers behind it. It takes on roles such as handling HTTPS encryption in one place (TLS termination), storing and returning frequently used responses, spreading load over several servers and hiding the configuration of the servers behind it. It differs in placement and in what it protects from a forward proxy, which sits on the users' side and connects to outside sites on their behalf.

Related comparisons