Chapter 9. TCP, QUIC, and HTTP/3

HTTP/2’s aim was to improve the inefficiencies inherent in the HTTP protocol, mainly by allowing a single, multiplexed connection. Under HTTP/1.1, the connection was vastly underused, because it could be used for only one resource at a time. If there were any delays in answering a request (such as because the server was busy generating that resource), the connection was blocked and not being used. HTTP/2 allows the connection to be used for multiple resources, so other resources can still use the connection in this scenario.

In addition to preventing wasted connections, HTTP/2 provides improved performance, because HTTP connections are inefficient in themselves. There’s a cost to creating an HTTP connection; otherwise, there’d be no real benefit in multiplexing. The costs aren’t due to HTTP itself, but to the two underlying technologies used to create this connection: TCP and TLS used to provide HTTPS.

In this chapter, I investigate these inefficiencies and show that although HTTP/2 is better at handling most of these inefficiencies, in certain scenarios, HTTP/2 can be slower than HTTP/1.1 because of these inefficiencies. Then I discuss QUIC, which makes several improvements.

9.1. TCP inefficiencies and HTTP

9.1.1. Setup delay in creating an HTTP connection

9.1.2. Congestion control inefficiencies in TCP

9.1.3. Effect of TCP inefficiencies on HTTP/2

9.1.4. Optimizing TCP

9.1.5. The future of TCP and HTTP

9.2. QUIC

9.2.1. Performance benefits of QUIC

9.2.2. QUIC and the internet stack

9.2.3. What UDP is and why QUIC is built on it

9.2.4. Standardizing QUIC

9.2.5. Differences between HTTP/2 and QUIC

9.2.6. QUIC tools

9.2.7. QUIC implementations

9.2.8. Should you use QUIC?

Summary