HTTP/1.1 vs HTTP/2 vs HTTP/3 and QUIC Explained
HTTP/1.1 sends one request at a time per connection, HTTP/2 multiplexes many over one TCP connection, and HTTP/3 does the same over QUIC on UDP, which also shortens connection setup and avoids TCP-level head-of-line blocking. The newer versions save round trips on a first connection and help most on high-latency or lossy links. Caching headers decide whether a request reaches the server at all, so honest latency measurement must bypass caches.
On this page
- How did HTTP/1.1 work, and what is keep-alive?
- What does HTTP/2 change?
- What is QUIC and how does HTTP/3 use it?
- How many round trips does each version need to connect?
- Do the newer protocols change ping or raw network latency?
- How do HTTP headers work?
- How does HTTP caching work?
- What is a cache-busting query string and why does it matter for honest measurement?
- What do HTTP status codes tell you?
- Common mistakes and myths
- What to do next
Quick answer: HTTP is the request-and-response language of the web. HTTP/1.1 handles one request at a time per connection, so browsers open several connections. HTTP/2 sends many requests concurrently over a single TCP connection (multiplexing). HTTP/3 does the same over QUIC, a UDP-based transport that merges the transport and encryption handshakes and avoids stalls caused by a single lost packet. For latency, the headline difference is the number of round trips needed before the first response byte: about 3 for HTTPS over HTTP/1.1 or HTTP/2 with TLS 1.3, and about 2 for HTTP/3.
How did HTTP/1.1 work, and what is keep-alive?
HTTP/1.1 (1997, clarified in later revisions) is a text-based protocol: the client sends a request line and headers, the server replies with a status line, headers, and a body. Early HTTP opened a new TCP connection for every file, which was expensive because each needed a TCP handshake (and later a TLS handshake, see TLS and the HTTPS handshake). HTTP/1.1 made persistent connections (keep-alive) the default, so one connection carries many requests one after another.
The weakness is that requests on one connection are strictly ordered. If the first response is slow, everything queued behind it waits. This is head-of-line (HOL) blocking at the HTTP level. Pipelining, which allowed sending several requests without waiting, was defined but fragile in practice and is not used by browsers. The workaround was to open multiple parallel connections per host (browsers commonly use about six), plus site tricks such as bundling files and spreading assets over several hostnames, which increased the number of handshakes.
What does HTTP/2 change?
HTTP/2 (2015) keeps the same meaning for methods, status codes, and headers but changes how they are carried:
- Binary framing: messages are split into frames tagged with a stream number.
- Multiplexing: dozens of streams share one connection, interleaved, so a slow response does not block others at the HTTP layer.
- Header compression (HPACK): repeated headers such as cookies and user-agent strings are sent as short references after the first time.
- Stream prioritisation: clients can hint which resources matter most. Support varies and the original scheme was simplified later.
Browsers only use HTTP/2 over TLS, so one connection per host replaces the six, saving handshakes. The remaining limitation is that all streams ride on one TCP byte stream. TCP delivers bytes in order, so if one packet is lost, every stream waits until it is retransmitted, even those whose data already arrived. This is TCP-level head-of-line blocking. On clean networks it is rarely visible; with several percent packet loss (see packet loss explained) a single HTTP/2 connection can perform worse than several HTTP/1.1 connections.
What is QUIC and how does HTTP/3 use it?
QUIC is a transport protocol carried inside UDP datagrams. It was designed to fix limitations of TCP that are hard to change because TCP is implemented in operating systems and middleboxes. Key properties:
- Built-in TLS 1.3: encryption is part of the transport. Transport and crypto setup happen together in one round trip.
- Independent streams: loss on one stream only delays that stream, removing TCP-level HOL blocking.
- Connection IDs: a connection survives a change of IP address or network (for example Wi-Fi to mobile), because it is identified by an ID rather than the address pair. Migration support depends on implementation.
- 0-RTT resumption: a returning client can send a request in its first packet, with the replay caveats described in the TLS guide.
- User-space implementation: libraries can be updated without waiting for operating-system releases.
HTTP/3 (standardised 2022) is HTTP semantics mapped onto QUIC streams, with header compression adapted as QPACK. QUIC typically uses UDP port 443. Some corporate networks and a minority of home firewalls block or throttle UDP, in which case clients fall back to HTTP/2. For background on the two transports, see TCP and UDP explained.
How many round trips does each version need to connect?
Counting from a cold start with the IP address already known (DNS cached), until the first byte of the response arrives:
| Protocol stack | Handshake round trips | Request/response | Total to first byte | With resumption |
|---|---|---|---|---|
| HTTP/1.1, plain HTTP (no TLS) | 1 (TCP) | 1 | 2 RTT | 2 RTT |
| HTTP/1.1 or HTTP/2 over TLS 1.2 | 1 TCP + 2 TLS = 3 | 1 | 4 RTT | 3 RTT |
| HTTP/1.1 or HTTP/2 over TLS 1.3 | 1 TCP + 1 TLS = 2 | 1 | 3 RTT | 3 RTT (or 2 with TCP Fast Open plus 0-RTT, rarely used) |
| HTTP/3 over QUIC (TLS 1.3 built in) | 1 | 1 | 2 RTT | 1 RTT with 0-RTT |
Worked example. A visitor is 120 ms from the server (RTT). HTTP/2 over TLS 1.3 needs about 3 × 120 = 360 ms to first byte, plus server time. HTTP/3 needs about 2 × 120 = 240 ms. The 120 ms saving is one full round trip. If the same visitor is 15 ms from a CDN edge, the saving is only 15 ms. This is why newer protocols matter most for distant or high-latency users such as mobile and satellite connections, and why placing content close to users helps even more (CDN and anycast).
Do the newer protocols change ping or raw network latency?
No. HTTP/2 and HTTP/3 do not make packets travel faster; the speed of light in fibre and the route length are unchanged (speed of light and cables). They reduce the number of times a client must wait for the network, and they avoid some stalls under loss. A single-request test against a nearby server will look about the same under all three versions, apart from handshake differences on the first request.
How do HTTP headers work?
Headers are name: value lines attached to requests and responses. Some that influence timing:
Host(or:authorityin HTTP/2 and 3): which site is wanted.Accept-EncodingandContent-Encoding: whether gzip or Brotli compression is used, shrinking transfer sizes.Cache-Control,ETag,Last-Modified,Age,Expires: caching behaviour.Connection: keep-alive(HTTP/1.1) andAlt-Svc: connection reuse and advertisement of HTTP/3 availability.Set-CookieandCookie: cookies add bytes to each request; large cookies inflate request size, especially noticeable on slow uplinks.
Time to first byte (TTFB) is measured when the first part of the response arrives, which means after the response headers begin. See TTFB and web performance for how this breaks down.
How does HTTP caching work?
A cache stores a copy of a response and answers later requests without contacting the origin server. Caches exist in the browser, in corporate proxies, and in CDNs. The main controls:
| Header or directive | Meaning | Effect on a repeat request |
|---|---|---|
Cache-Control: max-age=N | Fresh for N seconds | Served from cache, no network, about 0 to 2 ms |
Cache-Control: no-cache | Stored, but must revalidate | One round trip to ask "still valid?"; a 304 response carries no body |
Cache-Control: no-store | Do not store | Full fetch every time |
Cache-Control: s-maxage=N | Lifetime for shared caches such as CDNs | CDN may answer without contacting origin |
ETag / If-None-Match | Content fingerprint for validation | 304 Not Modified if unchanged |
A cached response can be so fast that it hides network conditions entirely. A browser that answers from its disk cache in 1 ms tells you nothing about a 90 ms path.
What is a cache-busting query string and why does it matter for honest measurement?
Caches key on the URL. Adding a unique parameter such as ?cb=8f3a29 or a timestamp makes each URL new, so the response cannot come from a stored copy. Site owners also use versioned file names or query strings (app.js?v=42) to force browsers to pick up new releases; that is a deployment technique, whereas a random value per request is a measurement technique.
For latency testing this is essential. If a test fetched the same URL repeatedly and let caches answer, the first pass would show the real network time and every later pass would show near zero, producing a flattering and meaningless average. GlobeLatency adds a cache-busting query string to every request and sets cache: no-store, so the browser does not serve results from its own HTTP cache. Be aware of two limits: cache busting does not prevent connection reuse (so later passes may skip DNS, TCP and TLS setup), and a CDN configured to ignore query strings could still answer from its edge cache. That is acceptable when you want to measure the distance to the edge, but it does not measure the origin. See how GlobeLatency measures and CDN performance testing.
What do HTTP status codes tell you?
| Range | Class | Common examples |
|---|---|---|
| 1xx | Informational | 100 Continue, 103 Early Hints |
| 2xx | Success | 200 OK, 204 No Content, 206 Partial Content |
| 3xx | Redirection | 301 Moved Permanently, 302 Found, 304 Not Modified |
| 4xx | Client error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests |
| 5xx | Server error | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout |
For timing, remember that a redirect adds a full extra request (and sometimes a new connection if the hostname changes), so http://example.com redirecting to https://www.example.com can add two or more round trips. Also, an error response still arrives in network time. A browser tool using no-cors mode cannot read the status code, so a 404 gives a valid timing, while a failed connection gives no reply. A 5xx often indicates slow server-side processing rather than a slow network.
Common mistakes and myths
- "HTTP/3 lowers my ping." It does not change propagation delay; it removes waiting steps.
- "HTTP/2 always beats HTTP/1.1." On lossy links, a single TCP connection can suffer more head-of-line blocking.
- Measuring cached responses and believing a site is fast everywhere.
- Forgetting redirects when counting round trips.
- Assuming UDP is always allowed. Blocked UDP quietly forces fallback, and the browser's developer tools (Network tab, protocol column) show which version was actually used.
- Using the same cache-busting value on every request in a test, which defeats the purpose after the first call.
What to do next
Open your browser's developer tools on a site you care about and check the protocol column to see which version is in use. For site owners, enabling HTTP/2 and HTTP/3 at the CDN is usually a setting rather than a rebuild; see latency for websites and APIs. To see how many milliseconds your own connection to destinations around the world takes, run a free latency test and read ping vs HTTPS latency for how application-level timings relate to raw round trips.
Frequently asked questions
Is HTTP/3 faster than HTTP/2?
Often, but not always. HTTP/3 saves a round trip or two when opening a connection, and it handles packet loss better because one lost packet no longer stalls every stream. On a fast, clean connection to a nearby server the difference can be a few milliseconds or unnoticeable. The benefit grows with distance and with loss, such as on mobile or poor Wi-Fi.
What is QUIC?
QUIC is a transport protocol built on UDP that integrates TLS 1.3 encryption, reliable delivery, congestion control and independent streams. It was standardised by the IETF in 2021 and is the transport used by HTTP/3. Because it runs in user space rather than inside the operating system kernel, it can be updated faster than TCP.
What is head-of-line blocking?
Head-of-line blocking happens when something at the front of a queue delays everything behind it. In HTTP/1.1 a slow response blocks the next request on the same connection. In HTTP/2 over TCP, one lost packet stalls all streams until it is retransmitted. HTTP/3 removes that second form because QUIC streams are recovered independently.
What does Cache-Control do?
Cache-Control is an HTTP header that tells browsers and intermediate caches whether and for how long a response may be reused. For example, max-age=3600 allows reuse for an hour without asking the server, no-store forbids storing the response, and no-cache requires revalidation before reuse. It determines whether a repeat request is answered locally in about a millisecond or travels across the network.
What is a cache-busting query string?
It is a changing value added to a URL, such as ?t=1731234567, so that every request looks like a new resource to caches. Because the URL differs each time, browsers and CDNs cannot answer from a stored copy. It is used to force a real fetch, for example when measuring network latency rather than cache speed.
What does HTTP status 404 or 503 mean?
Status codes are three-digit results. 404 means the server could not find that URL, and 503 means the service is temporarily unavailable or overloaded. Codes starting with 2 mean success, 3 redirection, 4 a client-side problem such as a bad URL, and 5 a server-side problem. Note that a 404 still returns quickly, so it can still reveal network timing.
Does my browser use HTTP/3 automatically?
Modern browsers support it and use it when a server advertises it, typically via an Alt-Svc header or DNS records. The first visit often uses HTTP/2 over TCP, then later connections switch to HTTP/3. If UDP is blocked by a network or firewall, the browser silently falls back to HTTP/2 or HTTP/1.1.