HTTP/2 and HTTP/3 are modern versions of the web protocol used by browsers, apps, and servers to exchange resources efficiently. This cheat sheet helps students compare how requests, responses, streams, and connections work in each version. It is useful for understanding web performance, security requirements, and why newer protocols reduce delays compared with older HTTP/1.1 behavior.
HTTP/2 runs over TCP and uses binary frames, multiplexed streams, header compression with HPACK, and server prioritization features. HTTP/3 keeps the HTTP semantics but runs over QUIC, which uses UDP, built-in TLS 1.3, stream-level loss recovery, and faster connection setup. A key relationship is HTTP/2 = HTTP semantics + binary framing over TCP, while HTTP/3 = HTTP semantics + QUIC over UDP.
Key Facts
- HTTP/2 uses one TCP connection to carry many independent streams at the same time, which is called multiplexing.
- HTTP/3 uses QUIC over UDP, so the stack is HTTP/3 over QUIC over UDP over IP.
- HTTP/2 avoids many HTTP/1.1 delays because multiple requests can share one connection instead of waiting in strict order.
- HTTP/2 still suffers from TCP head-of-line blocking because one lost TCP packet can delay all streams on that connection.
- HTTP/3 reduces transport-level head-of-line blocking because QUIC handles loss recovery separately for different streams.
- HPACK compresses repeated HTTP/2 headers using indexed tables so common fields do not need to be sent in full every time.
- QPACK is the header compression system used with HTTP/3 and is designed to work safely with QUIC streams.
- A simple comparison rule is HTTP/2 = TCP + TLS + binary frames, while HTTP/3 = UDP + QUIC + TLS 1.3 + frames.
Vocabulary
- Multiplexing
- Multiplexing is the ability to send multiple request and response streams over one network connection at the same time.
- Stream
- A stream is an ordered flow of frames that carries one HTTP request and response or part of a larger exchange.
- Frame
- A frame is a small binary unit of protocol data used by HTTP/2 and HTTP/3 to structure messages.
- QUIC
- QUIC is a transport protocol built on UDP that provides encryption, connection management, streams, and loss recovery for HTTP/3.
- Head-of-line blocking
- Head-of-line blocking happens when one delayed or lost piece of data prevents later data from being processed.
- TLS
- TLS is the security protocol that encrypts web traffic and helps verify the identity of the server.
Common Mistakes to Avoid
- Saying HTTP/3 is just HTTP/2 with a new version number is wrong because HTTP/3 changes the transport from TCP to QUIC over UDP.
- Assuming UDP means HTTP/3 is unreliable is wrong because QUIC adds reliability, ordering within streams, encryption, and congestion control above UDP.
- Confusing multiplexing with parallel TCP connections is wrong because HTTP/2 and HTTP/3 can carry many streams inside a single connection.
- Claiming HTTP/2 completely removes head-of-line blocking is wrong because TCP packet loss can still block all HTTP/2 streams on the connection.
- Ignoring TLS requirements is wrong because modern HTTP/2 is almost always deployed over TLS, and HTTP/3 includes TLS 1.3 as part of QUIC.
Practice Questions
- 1 A browser needs to request 24 small image files from the same website. If HTTP/1.1 uses 6 parallel TCP connections with one active request per connection, how many request rounds are needed at minimum?
- 2 A web page sends 10 requests over one HTTP/2 connection. If one TCP packet is lost, which layer can cause all streams to wait for recovery?
- 3 Write the protocol stack for HTTP/3 from application to network layer using the format HTTP/3 over ____ over ____ over IP.
- 4 Explain why HTTP/3 can perform better than HTTP/2 on lossy mobile networks even though both support multiplexing.
Understanding HTTP/2 & HTTP/3 Reference
An HTTP request is broken into small pieces called frames before it crosses the network. Some frames carry headers, some carry body data, and some control the connection. Each piece has a stream number.
The receiving side uses that number to rebuild the correct request or response. This design lets a large image download share network time with a small style sheet or API response. Flow control limits how much data a sender may place in flight.
Those limits protect a phone, browser, or server from being overwhelmed by a fast sender. A slow receiver can increase its available window after it processes more data.
The important limitation in HTTP/2 appears below the HTTP layer. TCP delivers one ordered sequence of bytes. If a packet containing earlier bytes is missing, TCP holds later bytes until the missing packet arrives again.
It does this even when the later bytes belong to a different HTTP stream. QUIC tracks data separately within each stream. A lost piece of one response does not normally stop usable data from another response.
This does not make packet loss harmless. All streams can still compete for the same connection bandwidth, and congestion control reduces sending speed when the network appears overloaded. HTTP/3 improves independence between streams, not the physical capacity of a network.
Connection setup affects pages with many short visits. Before useful protected data is exchanged, the browser must establish encryption and confirm that it is talking to the intended server. QUIC combines transport setup with TLS 1.3 more closely than the older TCP and TLS sequence.
A returning client may use stored information to send some data sooner through zero round trip setup. This feature has limits. Early data can be replayed by an attacker in some cases, so servers should use it only for safe actions such as fetching a public page.
QUIC uses connection identifiers that can help a device continue a connection after switching from school Wi Fi to mobile data. Network policies, firewalls, and older equipment can still block or mishandle UDP traffic.
Header compression saves bytes because web requests often repeat fields such as cookies, language choices, and accepted formats. The sender and receiver maintain matching compression state, so they must stay synchronized. In HTTP/2, header decoding can become delayed if required compression information has not arrived in order.
QPACK was designed so HTTP/3 streams do not create the same broad delay. It can still allow a limited number of blocked header sections, which is a tradeoff between compression efficiency and quick decoding. When testing a site, use browser developer tools to compare request timing, transferred bytes, cache status, and protocol version.
Do not assume HTTP/3 always makes a page faster. File size, server location, caching, packet loss, priorities, and the user’s network usually matter more than the protocol label alone.