HTTP/3 is here! The TCP protocol that has existed for more than 20 years is finally abandoned!

On June 6, Robin Marx, a member of the IETF QUIC and HTTP working group, announced that after five years of hard work, HTTP/3 was standardized as RFC 9114, the third major version of the HTTP hypertext transfer protocol. At the same time, HTTP/2 was also updated to the RFC 9113 standard, and HTTP/1.1 and general HTTP semantics and caching concepts were also strengthened in RFC 9110-9112.

TCP is one of the most widely used and deployed protocols on the Internet and has been regarded as the cornerstone of the Internet for many years. With the official standardization of HTTP/3 and the successful "upgrading" of the QUIC protocol, UDP has "replaced" TCP as the basic protocol. Where did TCP "lose"?

​​​​​

HTTP/3 uses the UDP-based QUIC protocol that Google has been exploring for many years. Its original name was HTTP-over-QUIC, and it was approved by IETF to be renamed HTTP/3 in 2018. Currently, Cloudflare, Google Chrome, and Firefox Nightly all support HTTP/3.

Why do we need HTTP/3?

Many people may have this question: why was HTTP/2 standardized in 2015, and why is HTTP/3 needed so soon?

In fact, we don't really need a new HTTP version, but rather an upgrade to the underlying Transmission Control Protocol (TCP).

The Inextricable Bond Between TCP and HTTP

The first official version of HTTP (Hypertext Transfer Protocol 1.0) was completed in 1996. However, HTTP/1.0 did not fully consider the needs of layered proxies, caches, long connections, and the impact of virtual hosts. So a year later, HTTP/1.1 was released, which is also the most widely used version.

In HTTP/1.1, the browser can only download one file at a time through a TCP connection. If a page requires 10 js files, then these files will be downloaded in sequence. The delay of one file will block the subsequent content, which is what we often call head-of-line blocking.

In 2015, the HTTP protocol was updated and HTTP/2 was released. One of the major features of HTTP/2 is multiplexing. The introduction of binary frames and stream mechanisms allows the use of a single TCP connection to download resources in parallel through Stream, which improves transmission efficiency. However, the multiplexing technology of HTTP/2 makes multiple requests actually based on the same TCP connection. Therefore, in HTTP/2, the impact of TCP head-of-line blocking will be greater. If a request causes TCP head-of-line blocking, multiple requests will be affected.

In fact, in environments with high packet loss, HTTP/1.1 performs better.

In addition, when initiating an HTTP request, it is necessary to go through the TCP three-way handshake and four-wave handshake process, and the entire process requires a total of 3 RTT delays to send the request data. If the client and server are far apart, each RTT may take more than 100 milliseconds, resulting in significant delays.

RTT: Round Trip Time, which refers to the time it takes for a client browser to send a request packet to the server and then receive a response packet from the server. RTT is an important indicator of network performance.

​​​​​

TCP has been the cornerstone of the Internet for decades, but various problems have forced everyone to think about how to replace it, that is - QUIC. QUIC is very different from TCP in several key aspects, and it will be very difficult to run HTTP/2 directly on it. Therefore, HTTP/3 itself is a relatively small adaptation of HTTP/2 to make it compatible with the new QUIC protocol.

​​​​​

What is QUIC protocol

QUIC is a new universal, secure, multiplexed transport layer network protocol that aims to replace TCP.

• In 2012, the QUIC protocol was developed by Jim Roskind, who was still working at Google at the time.
• In 2013, QUIC was officially announced to the public.
• In 2015, QUIC was submitted to IETF for standardization.

However, it was not until six years later, in May 2021, that the IETF released the first standardized version of QUIC, named RFC 9000. At the same time, the IETF also released a standardized version of HTTP/3 that uses QUIC. QUIC incorporates many properties similar to TCP, as well as TLS encryption, and places them in the application layer above UDP transmission.

​​​​

QUIC is very similar to TCP and can be used for many use cases besides HTTP and web page loading. For example, DNS, SSH, SMB, RTP, etc. can all run on QUIC.

UDP+QUIC=The best combination

UDP is the most basic transport protocol. It does not provide any features other than port numbers (e.g., HTTP uses port 80, HTTPS uses port 443, and DNS uses port 53). It does not establish connections through handshakes, and is not reliable: if a UDP packet is lost, it is not automatically retransmitted. UDP's "best effort" approach does not guarantee reliability, does not wait for handshakes, and does not have HoL blocking. In practice, the UDP protocol is mainly used for applications that require high real-time performance but do not require integrity, such as real-time video conferencing or gaming. It is also useful for situations where low pre-delay is required, for example, DNS domain name lookups can be completed with only one round trip.

On top of UDP, QUIC combines decades of deployment and practical experience of TCP and can implement almost all of TCP's features. QUIC's transmission is absolutely reliable, and can prevent overload through flow control and congestion control mechanisms, and implements these features in a smarter and more efficient way than TCP.

QUIC's improvements to TCP can be summarized into four aspects: QUIC is deeply integrated with TLS, QUIC supports multiple independent byte streams, QUIC uses connection IDs, and QUIC uses frames.

QUIC and TLS are deeply integrated

TLS (Transport Layer Security) is responsible for protecting and encrypting data sent over the Internet. When using HTTPS, plain text HTTP data is first encrypted by TLS and then transmitted by TCP. TLS versions 1.2 and lower usually require two RTTs, while the new version TLS 1.3 only requires one RTT.

​​​​

In the early days of the Internet, encrypting traffic was expensive to process and therefore unnecessary in many cases. TLS is a completely separate protocol that can be optionally used on top of TCP, which is what differentiates HTTP (without TLS) from HTTPS (with TLS).

Over time, our attitude toward Internet security has shifted to "secure by default." So the designers of QUIC chose to embed encryption deeply into QUIC itself. While TLS 1.3 can still run independently on top of TCP, QUIC encapsulates TLS 1.3. In other words, QUIC cannot be used without TLS; QUIC (and HTTP/3) are always fully encrypted. In addition, QUIC encrypts almost all packet header fields. This provides several benefits to QUIC:

• QUIC is safer for users: There is no way for QUIC to run in clear text, so network attackers have fewer options.
• QUIC's connection setup is faster: While with TLS-over-TCP, both protocols require their own separate handshakes, QUIC combines the transport and encryption handshakes into one, saving one round trip.
• QUIC is easier to update: if we want to add new features to QUIC in the future, we only have to update the end devices, not all the middleware.

QUIC supports multiple independent byte streams

With HTTP/1.1, the resource loading process is very simple because each file has its own TCP connection. For example, if we have files A, B, C, we will have three TCP connections. The first will see the byte stream of AAAA, the second BBBB, and the third CCCC (each letter repetition is a TCP packet). This works, but it is also very inefficient because each new connection incurs some overhead.

One of the main goals of HTTP/2 is to improve this situation. The HTTP/2 protocol no longer opens a new TCP connection for each file, but downloads different resources through a single TCP connection. This is achieved by multiplexing different byte streams. For example, if we are transmitting three files A, B, and C, we will get a TCP connection, and the incoming data can be in the form of AABBCCAABBCC, etc. Generally speaking, using HTTP/2 is as fast or faster than HTTP/1.1, but with much less overhead.

​​​​

The multiplexing mechanism of HTTP/2 solves the head-of-line blocking problem at the HTTP layer, but the head-of-line blocking problem still exists at the TCP layer.

After receiving the data packet, the TCP protocol may arrive out of order, but TCP must collect, sort and integrate all the data before sending it to the upper layer. If one of the packets is lost, it must wait for retransmission, resulting in a packet loss blocking the use of the entire connection. For example, AABBCCAABBCC at the HTTP level is just XXXXXXXXXXXX in the eyes of TCP. If B is lost at this time, it will not find out who is lost, but retransmit the entire packet.

Solving head-of-line blocking at the transport layer is one of the main goals of QUIC. Unlike TCP, QUIC is clearly aware that it is multiplexing multiple independent byte streams. Therefore, QUIC can perform packet loss detection and recovery logic on a per-stream basis.

In the above scenario, QUIC will only retain B's data and pass A and C's data to the HTTP/3 layer as quickly as possible.

​​​​

QUIC uses connection IDs

A TCP connection is determined by a four-tuple (source IP address, source port, destination IP address, destination port), which means that if the IP address or port changes, TCP and TLS will need to re-handshake, which is not conducive to scenarios where mobile devices switch networks, such as switching from a 4G network environment to a WIFI network. These problems are inherent to the TCP protocol.

​​​​

To solve this problem, QUIC introduces a new concept called connection identifier (CID). Each connection is assigned another number on top of the 4-tuple that uniquely identifies it between the two endpoints.

​​​​

More importantly, because this CID is defined at the transport layer of QUIC itself, it does not change when moving between networks. With this setup, even if one of the items in the 4-tuple changes, the QUIC server and client only need to look at the CID to know that it is the same old connection and can continue to use it. No re-handshake is required and the download state can remain as is. This feature is often called connection migration.

QUIC uses frames

Unlike TCP, QUIC does not use a single fixed packet header to send all protocol metadata. Instead, QUIC has a short packet header and uses various "frames" within the packet payload to convey additional information. For example, an ACK frame (for confirmation), a NEW_CONNECTION_ID frame (used to help establish connection migration), and a STREAM frame (used to carry data), as shown in the following figure:

​​​​

This is mainly an optimization, since not every packet carries all possible metadata (so TCP headers usually waste quite a few bytes). Using frames also has the benefit that it will be very easy to define new frame types as extensions to QUIC in the future. For example, a very important frame is the DATAGRAM frame, which allows sending unreliable data over an encrypted QUIC connection.

Summarize

In general, QUIC has many advantages over TCP, but it is difficult to fully promote it. Many companies, operators and organizations will intercept or limit UDP traffic other than port 53 (DNS) (these traffic are often abused for attacks), so the transmission of the UDP-based QUIC protocol may be blocked. In addition, many intermediate devices do not support and optimize UDP to a high degree.

However, despite some unknown difficulties, the era of HTTP/3.0 will definitely come!