HTTP/3 Explained

HTTP/3 is the evolution of the HTTP standard with UDP. It’s based on a new transport-layer protocol called QUIC, which allows better parallelism of the features of HTTP/2.

HTTP/2 introduced multiplexing, which lets the browser send multiple requests without first waiting for the response. This appears parallel at the HTTP level, but it still relies on a single TCP connection. That means that any lost packet will hold up the chain of requests until that packet can be re-transmitted.

HTTP/3’s solution continues to use a single connection, but allows transmission from other logical streams while waiting for a lost packet to be retransmitted. That requires implementing a new protocol that retains TCP’s features but allows more control over transmission of packets.

Streams

QUIC brings HTTP streams to the transport layer. They are independently flow-controlled and independently head-blocked, with prioritization still done at the HTTP layer.

Ossification

Changing standards like TCP comes with costs: The Internet relies on a lot of intermediaries to survive, but many are not frequently updated — they will often drop packets on seeing TCP options that they don’t recognize. QUIC gets around this by operating purely with secure connections, preventing intermediaries from inspecting traffic.

This has been a problem with TCP Fast Open, the standard that allows sending data on the first handshake transmission. QUIC offers its own fast open handshake to address that.

Regardless, there are still barriers to using UDP as a transport - many routers block UDP traffic on the standard HTTP ports, for example. This means that HTTP/1 or /2 will still have to exist as a fallback and that connections to unknown hosts will have to be initiated that way.

Adoption

It’s already in use across much of the Internet - 7% of all Internet traffic in 2017. While the original Google-introduced protocol was just for HTTP, the IETF version includes a layer for non-HTTP protocols. The implementation for that is still in progress.

Adoption requires coordinating support among those who determine the path of the web, including browser vendors, Apache and nGinx, and TSL implementors.