The web as we know it wouldn’t exist without our old friend Hypertext Transfer Protocol (HTTP). The latest iteration, HTTP/3, promises to revolutionize the way we interact with the web. In this article, we’ll delve into the differences between HTTP/2 and HTTP/3, look into why TCP got the boot in favor of QUIC, and explore some of the advantages of HTTP/3.
What is HTTP/3?
A little history may be in order before we dive face first into the new stuff. HTTP is a request-response protocol, meaning that a client (usually a web browser) sends a request to a server, and the server responds with the requested information.
HTTP/1.1 was the first standardized version of HTTP, published in 1997. It defined the basic rules and standards for communication on the web, including the request-response model, HTTP methods (such as GET, POST, PUT, and DELETE), and HTTP headers. HTTP/1.1 also introduced the concept of persistent connections, which allowed multiple requests and responses to be sent over a single connection, and pipelining, which allowed a second request to be sent before the first was answered.
HTTP/2, published in 2015, was a major revision of HTTP that introduced multiplexing, which allows multiple requests and responses to be sent simultaneously over a single connection, reducing the overhead of establishing and closing connections. HTTP/2 also introduced header compression, reducing the size of HTTP headers and improving page load times.
HTTP/2 is backwards compatible with HTTP/1.1, meaning that clients and servers can communicate using either standard. This isn’t the case with HTTP/3. It is not backwards compatible with HTTP/2. To understand why, we have to look a little deeper into these protocols.
How HTTP Is Structured
HTTP may stand for “Hypertext Transfer Protocol,” but it’s only a single protocol in the same sense that Voltron is a single robot. Just like five lion robots coming together to form the pieces of a larger, more powerful robot, HTTP combines several protocols to get the job done.
Each version of HTTP relies on a combination of protocols, each with different responsibilities.
TLS
Transport Layer Security (TLS), part of the stack for both HTTP/2 and HTTP/3, is a cryptographic protocol used to provide end-to-end security over a network. It should be noted that TLS doesn’t actually secure any data on the systems at either end, but focuses on preventing eavesdropping or alteration of the data as it’s passed along. TLS is the successor to the Secure Sockets Layer (SSL) protocol, the last version of which was deprecated in 2015. Wait, doesn’t this mean we should be calling SSL certificates TLS certificates?
HTTP/2 uses TLS for authentication, key negotiation, session resumption/0-RTT, and encryption decryption. It still does most of that in HTTP/3, with the exception of encryption/decryption, which is handled by QUIC.
TCP
Transmission Control Protocol (TCP) is a transport-layer protocol used to ensure reliable communication over IP networks. It is a connection-oriented protocol, which means that a connection is established between the sender and receiver before data is sent. This connection is maintained throughout the duration of the communication, and both the sender and receiver must acknowledge the data that is sent.
TCP is used to ensure that data is delivered reliably and in the correct order. It uses a sequence number to keep track of the data packets that are sent, and it can resend packets that are lost or corrupted. TCP also provides flow control and congestion control, which helps to prevent network congestion and ensure that the receiver can handle the amount of data being sent.
TCP is part of HTTP/2, but isn’t in the HTTP/3 stack. QUIC handles most of what TCP did in HTTP/2, with the exception of port numbers. In HTTP/3 this is done by UDP.
QUIC
Quick UDP Internet Connections (QUIC) is a transport-layer protocol developed by Google and intended to replace TCP as the primary protocol used for web traffic, and it is designed to be more efficient and secure than TCP. Most of what’s new in HTTP/3 really comes down to QUIC, as it overcomes the limitations of TCP.
QUIC uses a connection-oriented approach, similar to TCP, but it is designed to be more lightweight and efficient. It establishes a connection between the client and server before sending data, but it does not use the same kind of handshake protocol as TCP. Instead, QUIC uses a zero-round-trip (0-RTT) handshake, which combines the transport and cryptographic handshakes. This reduces the latency for establishing a connection, making QUIC faster than TCP.
UDP
User Datagram Protocol (UDP) is a transport-layer protocol that is used to send datagrams (packets of data) between devices on a network. It is a connectionless protocol, which means that it does not establish a connection between the sender and receiver before sending data. Instead, the sender simply sends the datagram to the receiver, and the receiver does not acknowledge receipt of the datagram. Like QUIC, UDP is not present in the HTTP/2 stack.
The Limitations of TCP
TCP has several limitations that make it less than ideal for the modern web, especially for applications that require low latency, such as real-time video streaming or online gaming.
TCP requires a significant amount of overhead to maintain the connection and ensure reliable delivery of data. This overhead includes acknowledgement messages, retransmission of lost packets, and congestion control mechanisms. This overhead can add significant delay and reduce the overall performance of the connection.
One of the biggest drawbacks of TCP is that, in some ways, it still parties like it’s 1999. TCP basically loads pages as if they were a single HTML file, maybe with a few images and some embedded CSS. Modern pages, on the other hand, may contain hundreds of files.
There have been plenty of attempts to update TCP over the years, but it eventually became obvious that tinkering wasn’t enough, leading to the development of QUIC.
How TLS and QUIC Work in HTTP/3
HTTP/3 still uses TLS, but it works a little differently than in HTTP/2, shifting some of its responsibilities over to QUIC. Below is a quick breakdown of the different roles and responsibilities of TLS and QUIC in HTTP/3.
Encryption/Decryption: TLS is not used for encryption/decryption in HTTP/3, as QUIC provides end-to-end encryption for all data sent over the connection. QUIC uses the ChaCha20-Poly1305 encryption algorithm, which is more efficient and secure than the encryption algorithms used in TLS.
Authentication: TLS is used for authentication in HTTP/3, providing a secure way to verify the identity of the server and client. QUIC does not provide authentication functionality.
Key Negotiation: TLS is used for key negotiation in HTTP/3, allowing the client and server to agree on a shared secret key for encryption.
Session Resumption/0-RTT: TLS is used for session resumption and 0-RTT in HTTP/3, allowing the client and server to resume a previously established connection without requiring a full handshake.
Congestion Control: QUIC is responsible for congestion control in HTTP/3, using its own congestion control algorithm to manage the flow of data and prevent network congestion.
Reliability: QUIC is responsible for reliability in HTTP/3, ensuring that data is delivered correctly and in the correct order. In HTTP/2, this was handled by TCP.
Connection Orientation: QUIC is responsible for connection orientation in HTTP/3, managing the establishment and teardown of connections.
Connection Migration: QUIC is responsible for connection migration in HTTP/3. This feature wasn’t present in HTTP/2.
How Connection Migration Works
Connection migration is a feature in HTTP/3 that supports network changes without the need to send another handshake. Each QUIC packet header has an unencrypted connection identifier (CID) attached, so switching to a new network doesn’t require that the connection be reset. This allows connections to change networks and IP addresses in ways impossible for TCP to accomplish.
For example, an in-progress download won’t be interrupted by a network change under HTTP/3. It just keeps rolling along, smoothly switching networks as they become available.
QUIC uses a feature called linkability prevention to make sure the unencrypted CIDs can’t be used to track someone physically by monitoring the CID across various networks. A list of connection IDs. all mapped to the same connection, are randomly generated and agreed to by the client and server at the beginning of the session. A new CID from the list is used every time a network change occurs. This prevents different networks being linked to the same user.
QPACK Vs. HPACK
HPACK is used in HTTP/2 and is designed to compress the headers of HTTP/2 requests and responses. It works by encoding the headers using a combination of Huffman coding and dictionary-based compression. HPACK uses a static dictionary of frequently used header fields and values, and it can also create a dynamic dictionary for each connection.
QPACK, used in HTTP/3, is similar to HPACK in that it also uses a combination of Huffman coding and dictionary-based compression. However, QPACK has some key differences:
- QPACK uses a single, shared dictionary for all connections, whereas HPACK uses a separate dictionary for each connection.
- QPACK allows for more efficient compression of headers by using a more advanced encoding scheme, called “quick encoding,” which can encode headers in a single byte.
- QPACK also supports more advanced compression techniques, such as compression of the header table itself, which can further reduce the size of the compressed headers.
- QPACK is designed to be more efficient and faster than HPACK, as it uses a more efficient encoding scheme and requires fewer computations to compress and decompress headers.
- QPACK is also more flexible than HPACK, as it allows for more customization of the compression settings and can be used with different transport protocols.
QPACK offers better compression ratios, faster compression and decompression speeds, and more flexibility than HPACK.
HTTP/2 vs HTTP/3: Performance Comparison
HTTP/2 and HTTP/3 are both designed to improve the performance of the web, but they approach it in different ways.
Latency
HTTP/3 has lower latency than HTTP/2 due to its zero-round-trip (0-RTT) handshake and faster connection establishment. This means that HTTP/3 can send and receive data faster than HTTP/2, resulting in a faster page load time.
Throughput
HTTP/3 has a higher throughput than HTTP/2 due to its ability to multiplex multiple requests and responses over a single connection. This means that HTTP/3 can send and receive multiple requests and responses simultaneously, resulting in faster overall performance.
Resource Utilization
HTTP/3 is designed to be more efficient in terms of resource utilization than HTTP/2. HTTP/3 uses a newer and more efficient encryption algorithm called “ChaCha20-Poly1305” which is more efficient than the encryption algorithms used in HTTP/2. Additionally, HTTP/3’s multiplexing feature allows for better resource utilization, as multiple requests and responses can be sent and received over a single connection.
Server Push
HTTP/3 supports server push, which allows the server to proactively send resources to the client, even if the client hasn’t requested them yet. This can result in faster page load times and improved performance. HTTP/2 also supports server push, but HTTP/3’s implementation allows the client to set the number of acceptable pushes, preventing wasted bandwidth.
Prioritization
HTTP/3 allows for better prioritization of requests and responses than HTTP/2. HTTP/3’s multiplexing feature allows for better prioritization of requests and responses, as the most important requests and responses can be sent and received first.
Wrapping Up (#wrapping-up)
The usage of HTTP/3 has been inching up over the past year, according to [W3Techs](https://w3techs.com/technologies/details/ce-http3, currently used by about 27% of websites.
TCP has limitations that QUIC does not, including slow start-up time, high overhead, limited scalability, and inability to handle large numbers of simultaneous connections. By contrast, QUIC was designed from the ground up to address these limitations.