Login
ChallengesLearn
Scoreboard
Teams
SPNZ

LearnWEB ProtocolsHTTP/2 & HTTP/3
WEB Protocols·Lesson 2 of 8

HTTP/2 & HTTP/3

Binary framing, multiplexing, server push, HPACK header compression, QUIC transport, 0-RTT handshake, and the evolution from HTTP/1.1 pipelining to HTTP/3 connection migration.

Beginner14 min
HTTP/2HTTP/3QUIC
Loading lesson…
PreviousHTTP/1.1 FundamentalsNextDNS Deep Dive

© 2026 SPNZ.

Terms of ServicePrivacy PolicyCookie Policy

HTTP/1.1 has a fundamental performance bottleneck: it can only process one request at a time per TCP connection. HTTP/2 and HTTP/3 were designed to fix this. HTTP/2 introduces binary framing and multiplexing to eliminate head-of-line blocking at the application layer. HTTP/3 replaces TCP with QUIC over UDP to eliminate it at the transport layer too.

What you'll be able to do
  • Explain how binary framing enables multiplexing in HTTP/2.
  • Describe how HTTP/3 eliminates head-of-line blocking at the transport layer.
  • Compare the performance characteristics of HTTP/1.1, HTTP/2, and HTTP/3.
  • Recognise the security implications of the HTTP/2 rapid reset attack.
Key terms
Binary framing layer
HTTP/2's mechanism for breaking messages into binary frames (HEADERS, DATA, SETTINGS, etc.) that can be interleaved across multiple streams on a single connection.
Multiplexing
The ability to send multiple concurrent request-response exchanges over a single TCP connection by assigning each exchange to a numbered stream.
HPACK
HTTP/2's header compression algorithm that uses a static and dynamic table to avoid repeatedly transmitting the same header names and values.
QUIC
A transport protocol built on UDP that provides encryption, multiplexed streams, 0-RTT handshake, and connection migration - the foundation of HTTP/3.
What is it?

HTTP/2 and HTTP/3

HTTP/2 (RFC 7540, later RFC 9113) was standardised in 2015 and is based on Google's SPDY protocol. Its core innovation is the binary framing layer: instead of sending plain-text request and response messages, HTTP/2 breaks them into small binary frames that are multiplexed across numbered streams within a single TCP connection.

Each stream carries the frames for one request-response pair. The client can open multiple streams simultaneously, and the server can interleave frames from different streams on the wire. This means one slow resource does not block others - a problem known as head-of-line (HOL) blocking at the application layer.

textbinary framing
HTTP/2 Frame:
+-----------------------------------------------+
| Length (24 bits) | Type (8) | Flags (8)       |
+-----------------------------------------------+
| R | Stream Identifier (31 bits)               |
+-----------------------------------------------+
| Frame Payload (variable)                      |
+-----------------------------------------------+

Types: HEADERS (0x1), DATA (0x0), SETTINGS (0x4),
       PRIORITY (0x2), RST_STREAM (0x3), GOAWAY (0x7), PING (0x6)

HTTP/2 also introduced HPACK header compression, which uses a static table of common header fields (like :method: GET and :path: /) and a dynamic table that learns headers seen on the connection. This dramatically reduces overhead when many requests share the same headers. Server push allows the server to send resources the client has not yet requested, anticipating what a page will need.

However, HTTP/2 still runs over TCP. If a TCP packet is lost, all streams on that connection pause until the packet is retransmitted - transport-layer HOL blocking. HTTP/3 (RFC 9114) solves this by replacing TCP with QUIC, a transport protocol built on UDP. QUIC provides built-in encryption (TLS 1.3), independent stream delivery (one lost packet does not block other streams), and a 0-RTT handshake for returning clients.

HTTP evolution comparison
Mini Map
Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.
Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.
Try it

Compare protocol performance

The simulator below lets you compare how a page with 8 resources loads under HTTP/1.1, HTTP/2, and HTTP/3. Watch the waterfall chart and see the total load time. For HTTP/3, toggle the "Switch WiFi" button to observe connection migration in action.

Protocol Labdev
Sstudent@lab
Select a protocol and click Simulate Page Load to compare performance
Key insight

HTTP/1.1 loads each resource sequentially per connection (head-of-line blocking at the application layer). HTTP/2 multiplexes all resources over a single connection, removing application-layer HOL blocking. HTTP/3 goes further by using QUIC over UDP, eliminating transport-layer HOL blocking and supporting connection migration.

Real-world relevance

Adoption and performance impact

As of 2024, HTTP/2 serves approximately 40% of all web traffic, with HTTP/3 at roughly 30% and growing quickly. Major CDNs - Cloudflare, Google, Meta - already support HTTP/3. The performance gains are substantial: HTTP/2 multiplexing eliminates application-layer HOL blocking, while HTTP/3's QUIC transport removes the TCP-level bottleneck entirely.

Connection migration in HTTP/3 is a game-changer for mobile users. When a phone switches from WiFi to cellular, QUIC can continue the same connection without a new handshake. No more interrupted streams, no more loading spinners because the TCP connection died. This alone can shave hundreds of milliseconds off every network transition.

Mitigation

Security and deployment considerations

HTTP/2 introduced a new attack surface: the rapid reset attack. An attacker opens many streams and immediately resets them via RST_STREAM frames, causing the server to do work (parse headers, allocate resources) for each reset. This can be a more efficient denial-of-service vector than traditional HTTP/1.1 attacks. Mitigations include limiting the rate of stream creation, enforcing a minimum stream inter-arrival time, and using connection-level flow control.

Deploying HTTP/2 and HTTP/3 requires TLS (they are mandated in practice, even if the spec allows cleartext for HTTP/2 via h2c). Reverse proxies and load balancers must be configured to support protocol negotiation via ALPN (Application-Layer Protocol Negotiation). Server push has been deprioritised by most browsers due to low adoption and caching complexity; with 0-RTT, HTTP/3 already provides much of the latency benefit.

Key takeaways

What to remember

  • HTTP/2 uses binary framing and multiplexing to eliminate application-layer head-of-line blocking.
  • HTTP/3 replaces TCP with QUIC (over UDP) to eliminate transport-layer HOL blocking, with 0-RTT handshake and connection migration.
  • HPACK compression in HTTP/2 reduces header overhead, especially for repeated headers across many requests.
  • The rapid reset attack exploits HTTP/2's stream creation mechanism for denial of service - servers must enforce stream rate limits.
Further reading
  • HTTP/2 - RFC 9113(IETF)
  • HTTP/3 - RFC 9114(IETF)
  • QUIC - RFC 9000(IETF)

Knowledge check

0/3 answered · 0 correct

  1. 1.What problem does multiplexing in HTTP/2 solve?

  2. 2.How does HTTP/3 differ from HTTP/2 at the transport layer?

  3. 3.What is the purpose of HPACK in HTTP/2?