HTTP/1.1, HTTP/2 and HTTP/3

01HTTP/1.1: one request at a time

HTTP/1.1 (1997, refined in RFC 9112) is text-based. Keep-alive lets a connection be reused, but on each connection requests are answered strictly one after another: if one response is slow, everything behind it waits. This is head-of-line blocking at the HTTP level. Browsers work around it by opening about six connections per host, and developers used tricks: domain sharding across several hostnames, image sprites, and concatenating all JavaScript into one file. Headers are sent as plain text with every request, so cookies and user agents repeat thousands of times. Analogy: a single checkout lane where each customer must finish before the next starts, so shops open six lanes.

02HTTP/2: multiplexing and HPACK

HTTP/2 (2015, now RFC 9113) keeps the same methods, headers and status codes but changes the wire format to binary frames. Its key feature is multiplexing: many requests and responses travel at the same time over one TCP connection as independent streams, interleaved frame by frame. One slow response no longer blocks the others at the HTTP level. HPACK compresses headers using a table of previously sent values, so repeated cookies and headers cost a few bytes. Prioritization lets the browser signal what matters most. Server push existed but was removed from browsers because it rarely helped; 103 Early Hints with preload replaces it. In practice browsers only use HTTP/2 over TLS, negotiated through ALPN during the handshake.

• One connection per origin instead of six: fewer handshakes.
• Domain sharding now hurts: it forces extra connections.
• Many small files are fine; split bundles by route instead of one giant file.

03The remaining problem: TCP head-of-line blocking

HTTP/2 fixed blocking at the HTTP layer but not underneath. TCP guarantees that bytes arrive in order. If one packet is lost, TCP holds back everything after it until the lost packet is retransmitted, even data that belongs to other streams. On a clean office network this is rare. On mobile networks with 1–2% packet loss, one lost packet stalls every image, script and API call on that connection. In bad conditions HTTP/2 over one connection can even be slower than HTTP/1.1 with six. TCP also lives in the operating system kernel, so improving it takes years of OS updates. This is why a new transport was needed.

04HTTP/3: QUIC over UDP

HTTP/3 (RFC 9114, 2022) runs over QUIC (RFC 9000), a transport built on UDP. QUIC implements reliability, congestion control and streams itself, and every stream is independent: a lost packet delays only its own stream. TLS 1.3 is built into QUIC, so a new connection needs one round trip instead of the two or three of TCP plus TLS, and resumed connections can send data immediately (0-RTT, which should be limited to safe, idempotent requests because it can be replayed). Connections are identified by a connection ID, not by IP and port, so a phone moving from Wi-Fi to mobile data keeps its connection. Headers use QPACK, a variant of HPACK. Browsers discover HTTP/3 through the Alt-Svc header or the HTTPS DNS record and fall back to HTTP/2 if UDP 443 is blocked.

05Enabling it in nginx and Cloudflare

On nginx 1.25.1 or newer, HTTP/2 is turned on with the http2 directive (the old listen ... http2 parameter is deprecated) and HTTP/3 with a quic listener on the same port, built with the QUIC module, which current official packages include. Advertise HTTP/3 with an Alt-Svc header and open UDP 443 in the firewall. On Cloudflare, HTTP/2 and HTTP/3 to visitors are on by default; you can check them under Speed or Network settings. The connection from Cloudflare to your origin is separate: it uses HTTP/1.1 or HTTP/2 over TCP, so the origin does not need HTTP/3 when it is behind Cloudflare. Verify with curl or the Protocol column in the browser's Network tab.

1server {
2    listen 443 ssl;
3    listen 443 quic reuseport;   # reuseport only once per port
4    http2 on;
5    http3 on;
6    server_name example.com;
7    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
8    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
9    ssl_protocols TLSv1.2 TLSv1.3;
10    add_header Alt-Svc 'h3=":443"; ma=86400' always;
11}
12# sudo ufw allow 443/udp
13# curl -sI --http2 https://example.com/ | head -1

06What it means for performance work

With HTTP/2 or HTTP/3 enabled, focus on what still costs time. Round trips still matter, so keep the critical path short: preload the hero image and main font, avoid long redirect chains, and serve from a CDN near users. Bytes still matter, so compress and ship less JavaScript. Concatenation is less important, but thousands of tiny modules still have overhead; bundlers' route-level splitting is the sweet spot. Avoid domain sharding and unnecessary third-party origins, since each new origin needs DNS, connection and TLS setup; use preconnect for the ones you must keep. Measure real users: improvements from HTTP/3 show up mainly on slow and lossy networks, not on your fast desktop.

07Prioritization: from dependency trees to Extensible Priorities

Multiplexing raises a new question: when twenty responses share one connection, which bytes go first? HTTP/2 originally let clients build a dependency tree with weights, but it was complex, browsers used it inconsistently and many servers ignored it, so RFC 9113 deprecated it. The replacement is Extensible Priorities (RFC 9218), used by HTTP/2 and HTTP/3. A client sends a simple Priority header or frame: urgency u from 0 (highest) to 7, and an incremental flag i meaning the response is useful in pieces, like a progressive image. Servers and CDNs schedule data accordingly, so CSS and the LCP image can overtake a large analytics script. On the page, fetchpriority and preload are how you influence what the browser sends. If prioritization is broken somewhere along the path, multiplexing can actually delay critical files behind big ones.

1GET /css/main.css HTTP/2
2priority: u=0
3 
4GET /img/hero.avif HTTP/2
5priority: u=1, i
6 
7GET /js/analytics.js HTTP/2
8priority: u=5

08Flow control and HTTP/2-specific attacks

HTTP/2 and QUIC have flow control per stream and per connection: each side advertises a window of bytes it is willing to receive, and the sender must wait for WINDOW_UPDATE before sending more. Small default windows can limit throughput on fast, long links, which is why servers tune them. Multiplexing also created new denial-of-service patterns. In 2023 the Rapid Reset attack (CVE-2023-44487) opened and immediately cancelled streams in huge numbers, so servers did work for requests that were never counted against concurrency limits; it produced record-breaking floods. HPACK and QPACK need limits on header table size to prevent memory exhaustion. Defences are mostly in software updates and sane limits: keep nginx and proxies patched, cap concurrent streams (http2_max_concurrent_streams, default 128 in nginx), limit header sizes, and let a CDN absorb volumetric attacks.

09QUIC under the hood: handshakes, loss recovery, migration

QUIC packets are encrypted, including most of the header, so middleboxes cannot inspect or tamper with transport details, which keeps the protocol evolvable. Packet numbers never repeat, even for retransmissions, which removes TCP's ambiguity about which copy an acknowledgement refers to and makes round-trip estimates more accurate. Before the client's address is validated, a server may send at most three times the bytes it received, which stops QUIC from being used for amplification attacks; a Retry packet with a token can validate the address first under load. Connection IDs let a phone switch networks without a new handshake, and the endpoint probes the new path before trusting it. The costs: QUIC runs in user space, encryption is per packet, and UDP send and receive paths are less optimised than TCP, so CPU use per byte is higher. Kernel features like UDP GSO and larger socket buffers narrow the gap.

10Discovery, fallback and the real-world mix

A browser cannot know in advance that a server speaks HTTP/3. The common path: the first visit uses HTTP/2 over TCP, the response includes Alt-Svc: h3=":443", and the next connections race QUIC against TCP and use whichever works. The HTTPS DNS record can advertise h3 before the first connection, skipping that step. If UDP 443 is blocked or rate-limited by a firewall, the browser quietly falls back to TCP and may remember the failure for a while, so a misconfigured server rarely looks broken; it simply never gets HTTP/3 traffic. On the server, check that the firewall and any cloud security group allow UDP 443, that the same certificate is served on both listeners, and that load balancers forward UDP. In logs, record the protocol per request ($server_protocol in nginx) to see the real share of each version.

1# Ask for HTTP/3 directly (curl built with HTTP/3 support)
2curl -sI --http3-only https://example.com/ | head -1
3# Is h3 advertised?
4curl -sI https://example.com/ | grep -i alt-svc
5dig example.com HTTPS +short
6# nginx log format: add the protocol per request
7# log_format main '$remote_addr "$request" $status $server_protocol';