What Is HTTP/3?

The Evolution of HTTP

HTTP has gone through three major versions, each solving problems introduced by the previous one. HTTP/1.0 opened a new TCP connection for every single request. HTTP/1.1 added persistent connections and pipelining. HTTP/2 introduced multiplexing. HTTP/3 replaces TCP entirely with QUIC.

Each version was driven by the same pressure: the web keeps getting more complex, pages load more resources, and users expect faster experiences. The protocol had to evolve to keep up.

HTTP/1.1 and the Connection Problem

HTTP/1.1, published in 1997, allows persistent connections - the client can reuse a TCP connection for multiple requests instead of opening a new one each time. But it still processes requests sequentially on each connection. The server must respond to request A before it can respond to request B on the same connection.

Browsers worked around this by opening multiple TCP connections to the same server (typically six). This helped parallelism but created overhead: each connection required its own TCP handshake, its own TLS handshake, and its own congestion control state. Six connections meant six times the setup cost.

Web developers invented tricks to reduce the number of requests: CSS sprites (combining multiple images into one), JavaScript bundling, domain sharding. These hacks papered over the protocol's limitations but added complexity to every web application.

HTTP/2 - Multiplexing Over TCP

HTTP/2, standardized in 2015, introduced multiplexing. Multiple requests and responses can be in flight simultaneously on a single TCP connection. The protocol frames each request and response as a numbered stream, allowing the server to send data for multiple streams interleaved within the same connection.

graph TD
    subgraph "HTTP/1.1 - Sequential on Each Connection"
        A1[Connection 1] --> A2[Request A then Response A]
        A2 --> A3[Request B then Response B]
        A4[Connection 2] --> A5[Request C then Response C]
        A5 --> A6[Request D then Response D]
    end
    subgraph "HTTP/2 - Multiplexed on One Connection"
        B1[Single Connection] --> B2[Stream 1 - Request A]
        B1 --> B3[Stream 2 - Request B]
        B1 --> B4[Stream 3 - Request C]
        B1 --> B5[Stream 4 - Request D]
        B2 --> B6[All responses interleaved]
        B3 --> B6
        B4 --> B6
        B5 --> B6
    end

HTTP/1.1 needs multiple connections for parallelism - HTTP/2 multiplexes everything on one

This eliminated the need for multiple connections, domain sharding, and most of the HTTP/1.1 performance hacks. A single connection could handle all the resources a page needed.

HTTP/2 also introduced header compression (HPACK), which reduced the size of repeated headers across requests. Since many requests to the same server share identical headers (cookies, user-agent, authorization tokens), this saved significant bandwidth.

TCP's Head-of-Line Blocking Problem

HTTP/2 multiplexing works well at the HTTP layer. But underneath, TCP still treats everything as a single ordered byte stream. When one TCP packet is lost, TCP must pause delivery of all data on that connection until the lost packet is retransmitted and received.

This means a single lost packet for one HTTP/2 stream blocks delivery of all other streams on the same connection. The multiplexing benefit at the HTTP layer is undermined by the serialization at the TCP layer.

On reliable, low-latency connections (wired networks in data centers), this rarely matters. On lossy connections (mobile networks, congested WiFi), the impact is significant. Studies showed that HTTP/2 could actually perform worse than HTTP/1.1 on lossy connections because HTTP/1.1's multiple connections meant a packet loss only affected one of six connections, while HTTP/2's single connection meant all streams stalled.

HTTP/3 - HTTP Over QUIC

HTTP/3 solves the head-of-line blocking problem by replacing TCP with QUIC. QUIC implements streams as independent entities within the protocol. A packet loss on one stream does not block any other stream. Each stream has its own flow control and retransmission logic.

graph TD
    subgraph "HTTP/2 Over TCP"
        H2[HTTP/2 Framing] --> TLS2[TLS 1.2 or 1.3]
        TLS2 --> TCP[TCP - single byte stream]
        TCP --> IP1[IP]
        TCP -->|Packet loss| BLOCK[All streams blocked]
    end
    subgraph "HTTP/3 Over QUIC"
        H3[HTTP/3 Framing] --> QUIC[QUIC - independent streams]
        QUIC --> TLS3[TLS 1.3 integrated]
        TLS3 --> UDP[UDP]
        UDP --> IP2[IP]
        QUIC -->|Packet loss| ONLY[Only affected stream blocked]
    end

The HTTP/3 protocol stack replaces TCP and separate TLS with QUIC over UDP

HTTP/3 also uses a new header compression scheme called QPACK, adapted from HTTP/2's HPACK to work with QUIC's independent streams. HPACK relied on TCP's ordered delivery to keep encoder and decoder states synchronized. QPACK handles out-of-order delivery by using separate unidirectional streams for header table updates.

The Alt-Svc Header

Browsers discover HTTP/3 support through the Alt-Svc (Alternative Service) HTTP response header. When a client makes an initial connection to a server over HTTP/2 (or HTTP/1.1), the server can include a header like:

Alt-Svc: h3=":443"; ma=86400

This tells the client that the server supports HTTP/3 (h3) on port 443, and this information is valid for 86400 seconds (24 hours). The client can then attempt a QUIC connection for subsequent requests.

This discovery mechanism means the first connection to a new server typically uses TCP. Only after receiving the Alt-Svc header will the browser try QUIC. Once the browser knows a server supports HTTP/3, it will attempt QUIC first for future connections and fall back to TCP if QUIC fails (for example, if UDP is blocked).

Performance Gains

HTTP/3's performance improvements are most visible in specific scenarios. On reliable, low-latency networks, the difference between HTTP/2 and HTTP/3 is minimal. The biggest gains appear on lossy connections - mobile networks, congested WiFi, and high-latency satellite links.

Connection establishment is faster: QUIC's 1-RTT handshake (or 0-RTT for repeat connections) saves time compared to TCP + TLS. On a 100ms latency connection, this saves 100-200ms on every new connection.

Connection migration means fewer interrupted transfers. When a mobile user switches from WiFi to cellular, HTTP/3 connections survive the transition. HTTP/2 connections over TCP would need to be re-established from scratch.

graph TD
    subgraph "Connection Setup Time Comparison"
        TCP1[TCP - SYN] --> TCP2[TCP - SYN-ACK]
        TCP2 --> TCP3[TCP - ACK]
        TCP3 --> TLS1[TLS - ClientHello]
        TLS1 --> TLS2[TLS - ServerHello]
        TLS2 --> DATA1[First data - 3 RTT total]
    end
    subgraph "QUIC New Connection"
        Q1[QUIC Initial + ClientHello] --> Q2[QUIC Handshake + ServerHello]
        Q2 --> QDATA1[First data - 1 RTT total]
    end
    subgraph "QUIC Repeat Connection"
        R1[QUIC Initial + Early Data] --> RDATA[First data - 0 RTT]
    end

QUIC reduces connection setup from 3 round trips to 1 - or zero for repeat visitors

Security Implications

HTTP/3 is always encrypted. QUIC mandates TLS 1.3 with no option for unencrypted connections. This is a significant security improvement over HTTP/1.1 and HTTP/2, which technically allow unencrypted HTTP (though most sites have moved to HTTPS).

The encryption extends beyond the payload. QUIC encrypts most of its transport headers, making it harder for network observers to analyze traffic patterns, correlate connections, or interfere with the protocol. With TCP, headers like sequence numbers and acknowledgment values are visible to anyone on the network path.

For enterprise security teams, this increased encryption can be a double-edged sword. The same encryption that protects users from surveillance also makes it harder for security tools to inspect traffic for threats. Network-based intrusion detection systems and firewalls that rely on TCP header inspection need updates to handle QUIC traffic.

What This Means for Network Monitoring

If you are monitoring network traffic, you will increasingly see UDP packets on port 443 instead of TCP. This is HTTP/3. Traditional packet capture tools that display TCP handshakes and TLS negotiations will show unfamiliar patterns.

Security monitoring tools need QUIC-aware parsers to extract useful information from HTTP/3 traffic. Without them, a significant portion of web traffic becomes opaque.

Understanding how protocols evolve - from TCP to QUIC, from HTTP/1.1 to HTTP/3 - is essential for anyone working in network security. The BLEShark Nano helps you explore the wireless layer where all of this traffic begins, giving you visibility into the 2.4GHz spectrum that carries WiFi and the protocols running on top of it.