Tip:
- The platform will compress the picture, can be in wechat public number FEPulse (ID: FEPulse) back HTTP3 get high definition large figure;
- Tencent summer internship recruitment has been fully launched. Please contact me on the background of the official account for internal promotion. Interested teams such as AlloyTeam can also be recommended.
After the HTTP/2 standard was published in 2015, most major browsers supported it by the end of that year. Since then, with the advantages of multiplexing, header compression, server push, HTTP/2 has been favored by more and more well-known Internet companies. Just when everyone was excited to learn about HTTP/2’s new features, HTTP/3 was gearing up. Today I will talk to you about the third generation of HTTP technology.
1. The HTTP history
Before introducing HTTP, let’s take a quick look at the history of HTTP to understand the context in which HTTP/3 emerged.
proposed
2. QUIC
2.1 QUIC Protocol Overview
TCP has long been the dominant transport-layer protocol, while UDP has never been. When asked in an interview what distinguishes TCP from UDP, the answer is often a few words. UDP has long had a reputation as a fast but unreliable transport-layer protocol. But sometimes a weakness can be a strength from another perspective. QUIC (Quick UDP Internet Connections) is based on UDP, which is the speed and efficiency of UDP. QUIC also integrates and optimizes TCP, TLS, and HTTP/2. The relationship between them can be clearly represented by a picture.
So if you want to understand HTTP/3, there is no way around QUIC. Here are a few important features to give you a deeper understanding of QUIC.
2.2 Zero RTT Establishes the connection
You can visualize the difference between HTTP/2 and HTTP/3 in one diagram, as shown in Figure 2-2 and Figure 2-3.
HTTP/2 connections require 3 RTT, and 2 RTT if session reuse is considered, i.e. the symmetric key calculated from the first handshake is cached. Further, HTTP/2 connections require 2 RTT if TLS is upgraded to 1.3, and 1 RTT if session reuse is considered. Some would argue that HTTP/2 doesn’t necessarily require HTTPS, and that the handshake process can be simplified. This is fine, the HTTP/2 standard does not need to be based on HTTPS, but virtually all browser implementations require HTTP/2 to be based on HTTPS, so an encrypted HTTP/2 connection is essential. HTTP/3 requires only 1 RTT for the first connection and 0 RTT for subsequent connections, meaning that the first packet sent from the client to the server contains request data, which HTTP/2 cannot match. So what’s behind this? In combination with Figure 2-3, we take a look at the connection process of QUIC in detail.
Step1: During the first connection, the Client sends Inchoate Client Hello to the server to request the connection.
Step2: the Server generates g, p and a, calculates a according to g, p and a, and then puts g, p and a into the Server Config and sends Rejection message to the client.
Step3: after receiving g, p, and A, the client generates itself into b, calculates b according to g, p, and b, and calculates the initial key K according to A, p, and b. After B and K are calculated, the client encrypts HTTP data with K and sends the data together with B to the server.
Step4: after receiving B, the server generates the same key as the client according to a, p, and B, and uses the key to decrypt the received HTTP data. For further security (forward security), the Server updates its own random number A and public key, generates a new key S, and sends the public key to the client via Server Hello. Along with the Server Hello message, there is HTTP return data;
Step5: after receiving Server Hello, the client generates a new key S consistent with that of the Server. The subsequent transmission is encrypted with S.
It takes 1 RTT for QUIC to send HTTP data from the request to the Server Config. If the client caches the Server Config, it can send HTTP data directly. Realize 0 RTT to establish the connection.
A technical detail of QUIC’s implementation of 0 RTT is the use of the DH key exchange algorithm. Figure 2-4 is used to better understand the above process.
2.3 Connection Migration
The TCP connection is based on a quad (source IP address, source port, destination IP address, and destination port). At least one factor may change during network switchover, causing the connection to change. When the connection changes, if the original TCP connection is still used, the connection will fail and the original connection will have to be re-established after the timeout, so we sometimes find that when we switch to a new network, even though the new network is in good condition, the content still takes a long time to load. If implemented well, a new TCP connection can be established as soon as a network change is detected, and even then it can take hundreds of milliseconds to establish a new connection.
The connection of QUIC is not affected by the quadruple, and the original connection remains when the four elements are changed. So how does that work? QUIC connections are not identified by quads, but by a 64-bit random number called the Connection ID. Even if the IP address or port number changes, as long as the Connection ID does not change, the Connection will continue.
2.4 Queue head blocking/multiplexing
HTTP/1.1 and HTTP/2 both have a blocking Head. What is a blocking Head?
TCP is a connection-oriented protocol. After a request is sent, an ACK message is sent to confirm that data has been received. If each request is made after receiving an ACK message from the previous request, it is inefficient, as shown in Figure 2-5. Since HTTP/1.1, Pipelining technology has been introduced to allow a TCP connection to send multiple requests simultaneously, which greatly improves transmission efficiency, as shown in Figure 2-6.
HTTP/2 multiplexing solves the above queue head blocking problem. Unlike HTTP/1.1, where all packets of the previous request are transmitted before the next request can be transmitted, HTTP/2 splits each request into multiple frames and transmits them simultaneously over a TCP connection, so that even if one request is blocked, other requests are not affected. As shown in Figure 2-8, different colors indicate different requests, and the color blocks in the same color indicate the frames in which the requests are divided.
So how does QUIC solve the queue blocking problem? There are two main points.
- The transmission unit of QUIC is Packet, the encryption unit is Packet, the whole encryption, transmission and decryption are based on Packet, so as to avoid the TLS queue blocking problem;
- QUIC is based on UDP. UDP packets are processed in no sequence at the receiving end. Even if a packet is lost, the whole connection is not blocked, and other resources are processed normally.
2.5 Congestion control
The purpose of congestion control is to prevent too much data from flooding into the network at a time, causing the network to exceed the maximum load. QUIC’s congestion control is similar to and improved upon TCP. So let’s take a brief look at TCP congestion control.
TCP congestion control consists of four core algorithms: slow start, congestion avoidance, fast retransmission, and fast recovery. By understanding these four algorithms, you have a general understanding of TCP congestion control.
- Slow start: The sender sends one unit of data to the receiver. After receiving the confirmation, the sender sends two units of data, then four, then eight… This process is to continuously test the network congestion degree. If the network congestion exceeds the threshold, the network congestion will occur.
- Congestion avoidance: Exponential growth cannot be infinite, exponential growth becomes linear growth after reaching a certain limit (slow start threshold);
- Fast retransmission: The sender sets a timeout timer every time it sends a message. After the timeout, it considers that the message is lost and needs to be retransmitted.
- Fast recovery: On the basis of the above fast retransmission, the sender also starts a timeout timer when resending data. If the sender receives an acknowledgement message, the sender enters the congestion avoidance phase. If the sender still times out, the sender returns to the slow start phase.
QUIC reimplements the TCP protocol Cubic algorithm for congestion control, and makes many improvements on this basis. Here are some of the features of QUIC’s improved congestion control.
Hot plug
To modify a TCP congestion control policy, perform operations at the system level. QUIC changes the congestion control policy only at the application layer. QUIC dynamically selects the congestion control algorithm based on different network environments and users.
Monotonically increasing Packet Number
To ensure reliability, TCP uses Sequence Number and ACK to confirm whether messages arrive in order. However, this design has defects.
After the timeout occurs, the client initiates a retransmission and receives an ACK confirmation message. However, the client is frustrated because the ACK message received by the original request is the same as that received by the retransmission request. Therefore, the client does not know whether the ACK corresponds to the original request or the retransmission request. If the client thinks it is the ACK of the original request, but it is actually as shown in Figure 2-11, the calculated sample RTT is too large. If the client thinks it is an ACK of the retransmission request, but the ACK is actually as shown in Figure 2-12, the sample RTT will be too small. There are a few terms in the diagram. RTO stands for Retransmission TimeOut, much like the familiar RTT (Round Trip Time). Sampling RTT will affect THE CALCULATION of RTO, so it is very important to accurately grasp the timeout time, either longer or shorter is not appropriate.
ACK Delay
TCP calculation of RTT does not consider the Delay between receiving data and sending an acknowledgement message, as shown in Figure 2-15. This Delay is called ACK Delay. QUIC took this delay into account, making the RTT calculation more accurate.
More ACK blocks
In general, the recipient should send an ACK response after receiving the message from the sender, indicating that the data was received. However, it is too troublesome to return an ACK reply every time a data is received. Therefore, it is generally not an immediate reply, but a reply after receiving multiple data. TCP SACK provides up to three ACK blocks. Some scenarios, such as downloads, require only the server to return data, but TCP is designed to “politely” return an ACK for every three packets received. QUIC can piggyback up to 256 ACK blocks. On a network with a high packet loss rate, more ACK blocks reduce retransmission and improve network efficiency.
2.6 Flow Control
TCP controls the flow of each TCP connection. Traffic control means that the sender should not send too fast and the receiver should receive the data in time. Otherwise, data overflow and loss may occur. It can be seen that congestion control mainly controls the sending policy of the sender, but does not take into account the receiving ability of the receiver. Traffic control is the complement to this part of the ability.
QUIC only needs to establish a connection that can simultaneously transmit multiple streams, like a road with a warehouse at either end and a lot of vehicles on the road carrying supplies. QUIC has two levels of flow control: Connection Level and Stream Level, for example, to control the total flow of the road, do not rush in too many vehicles at once, the goods can not be processed, nor can one vehicle transport too many goods at once, so that the goods can not be processed.
So how does QUIC achieve flow control? Let’s first look at flow control for a single Stream. The flow Control Receive window is the maximum flow control receive window before the Stream transmits data. As the receiver receives data, the flow control receive window shrinks. In the received data, some data has been processed, and some data has not yet been processed. As shown in Figure 2-16, the blue block represents processed data and the yellow block represents unprocessed data. The arrival of these data reduces the receiving window of Stream.
As data is processed, the receiver is able to process more data. When (flow control receive offset-Consumed Bytes) < (Max Receive window / 2), The receiver will send a WINDOW_UPDATE frame telling the sender that you can send more data. Then the flow control receive offset will be offset, the receive window will be enlarged, and the sender can send more data to the receiver.
Flow control Receive window = Max Receive window - Highest received byte offset
Receive window = Stream1 receive window + Stream2 Receive window +... + StreamN receive window
3. QUIC application
3.1 Upgrade Through Negotiation
Since you are not sure whether the server supports QUIC, you need to go through a negotiation upgrade process to determine whether you can use QUIC.
For the first request, the client will use HTTP/1.1 or HTTP/2. If the server supports QUIC, the alt-SVC header will be returned in the response data, mainly containing the following information:
- Quic: listening port.
- Ma: Valid time, in seconds, committed to support QUIC during this time;
- Version numbers: QUIC is iterating quickly, and all supported version numbers are listed here.
After confirming that the server supports QUIC, the client initiates a QUIC connection and a TCP connection to the server at the same time, compares the speed of the two connections, and selects the faster protocol. This process is called “racing”, and GENERALLY, QUIC wins.
3.2 Application
At present, Google, Gmail, QQ members and other businesses have been using QUIC. This article mainly focuses on the introduction of QUIC itself, but also limited to the author’s practical experience in this aspect, THE application of QUIC will not be detailed, you can find relevant practical articles, such as this article “To make the Internet faster protocol, QUIC in Tencent’s practice and performance optimization”.
4. To summarize
QUIC discarded the burden of TCP and TLS, based on UDP, and use the experience of TCP, TLS and HTTP/2 for reference and improvement, to achieve a secure, efficient and reliable HTTP communication protocol. With zero RTT connection establishment, smooth connection migration, basically eliminating queue head blocking, improved congestion control and flow control, QUIC achieves better results than HTTP/2 in most scenarios, and HTTP/3 has a promising future.