Let’s talk about the new features of HTTP/3. Why did you choose to use the UDP protocol?

[[399228]]

This article is reprinted from the WeChat public account "Learn Front-end in Three Minutes", author sisterAn. Please contact the WeChat public account "Learn Front-end in Three Minutes" to reprint this article.

introduction

This article is mainly divided into the following aspects to gradually enter HTTP/3:

• HTTP/2 and TCP's fatal flaws
• Why QUIC protocol chooses UDP
• QUIC and HTTP/3 New Features
• QUIC and HTTP/3 Future Development Outlook

HTTP/2 and TCP flaws

HTTP/2 uses binary transmission, header compression (HPACK), multiplexing, etc., which greatly improves the data transmission efficiency compared to HTTP/1.1. However, it still has the following fatal problems (mainly caused by the underlying TCP protocol):

• Long time to establish connection
• Head-of-line blocking is more serious than HTTP/1.1

1. Long time to establish connection

RTT Round Trip Time

How to define the time to establish a connection? Here we introduce a concept: RTT (Round-Trip Time), which means the total time from the start of sending data to the sender receiving the confirmation from the receiver (the receiver sends the confirmation immediately after receiving the data, excluding the data transmission time), that is, the time for communication to go back and forth.

TCP connection establishment time

TCP establishes a TCP virtual channel through three handshakes, which costs a total of:

• SYN: The client sends a connection request segment to the server. This segment contains its own data communication initial sequence number. After the request is sent, the client enters the SYN-SENT state.
• Second round (SYN+ACK): After the server receives the connection request segment, if it agrees to connect, it will send a response, which will also contain its own data communication initial sequence number. After sending, it will enter the SYN-RECEIVED state
• 3. ACK: When the client receives the connection agreement, it also sends a confirmation message to the server. After the client sends this message segment, it enters the ESTABLISHED state. After the server receives this response, it also enters the ESTABLISHED state. At this time, the connection is successfully established.

This is equivalent to one and a half round trips, so TCP connection establishment time = 1.5 RTT

HTTP Transaction Time

When the client requests data, it first spends 1.5 RTT to establish a TCP connection, and then TCP starts to transmit the HTTP request. The browser receives the server's response and has to wait for:

• One go (HTTP Request)
• Second round (HTTP Responses)

Therefore, HTTP transaction time = 1 RTT

Since TCP does not need to wait for the server's response during the third handshake, it saves 0.5 RTT. Then the total time spent on HTTP communication based on TCP transmission is:

Total HTTP communication time = TCP connection establishment time + HTTP transaction time = 1 RTT + 1 RTT = 2 RTT

HTTPS communication time

HTTP/2 continues the "plain text" feature of HTTP/1. It can transmit data in plain text as before, and does not force the use of encrypted communication. However, HTTPS is already a general trend, and major browsers have publicly announced that they only support encrypted HTTP/2. Therefore, HTTP/2 in real applications is still encrypted:

HTTPS is actually the abbreviation of HTTP+SSL/TLS

Therefore, HTTPS communication time = TCP connection establishment time + TLS connection time + HTTP transaction time

TLS connection time

In the TLS 1.2 protocol handshake, 2 RTTs are required:

• One: The client sends a random number C, the client's TLS version number and a list of supported cipher suites to the server
• Second round: The server receives the random value from the client, generates a random value S, uses the corresponding method according to the protocol and encryption method required by the client, and sends its own certificate (if verification of the client certificate is required, please explain)
• Third: The client receives the server's certificate and verifies whether it is valid. If the verification is successful, a random value pre-master will be generated, which will be encrypted with the public key of the server's certificate and sent to the server. If the server needs to verify the client's certificate, it will be accompanied by a certificate (two-way authentication, such as using a USB shield for online banking)
• Round 4: The server receives the encrypted random value and uses the private key to decrypt it to obtain the third random value. At this time, both ends have three random values. These three random values ​​(C/S plus pre-master calculate the master key) can be used to generate a key according to the previously agreed encryption method. The subsequent communication can be encrypted and decrypted using the session key.

Total HTTPS communication time = TCP connection establishment time + TLS connection time + HTTP transaction time = 1 RTT + 2 RTT + 1 RTT = 4 RTT

If the server is very close to the client and the RTT time is short (< 10ms), then the HTTPS communication time will not exceed 40ms and the user will not feel it. However, if the distance is far, tens of thousands of kilometers apart, an RTT time is usually more than 200ms, then the HTTPS communication will take 800ms or even more than 1s, which seriously affects the user experience.

Note: In the TLS 1.3 protocol, only one RTT is required to establish a connection for the first time, and no RTT is required to restore the connection later.

Total HTTPS communication time (based on TLS1.2) = TCP connection establishment time + TLS1.2 connection time + HTTP transaction time = 1 RTT + 2 RTT + 1 RTT = 4 RTT

Total HTTPS communication time (based on TLS1.3) = TCP connection establishment time + TLS1.3 connection time + HTTP transaction time = 1 RTT + 1 RTT + 1 RTT = 3 RTT

2. Head-of-line blocking is more serious than HTTP/1.1

Because HTTP/2 uses multiplexing, generally speaking, only one TCP connection is needed for the same domain name. If packet loss occurs in this connection, the performance of HTTP/2 will be worse than that of HTTP/1.

Because in the case of packet loss, the entire TCP will start waiting for retransmission, which will cause all subsequent data to be blocked. However, for HTTP/1, multiple TCP connections can be opened. This situation will only affect one of the connections, and the remaining TCP connections can still transmit data normally.

Why QUIC protocol chooses UDP

Then someone might consider modifying the TCP protocol, but this is actually an impossible task because TCP has existed for too long and is already used in various devices. In addition, this protocol is implemented by the operating system, so it is not very realistic to update it.

For this reason, Google started a new protocol called QUIC based on UDP.

Google's move may seem unexpected, but it makes sense when we compare TCP and UDP:

• There are many devices and protocols developed based on TCP, which makes compatibility difficult
• The TCP protocol stack is an important part of Linux, and the cost of modification and upgrade is very high.
• UDP itself is connectionless, with no link establishment and teardown costs.
• UDP packets have no head-of-line blocking problem
• UDP transformation cost is low

From the above comparison, we can see that it is not easy for Google to transform and upgrade TCP. Although UDP does not have the problems caused by TCP in order to ensure reliable connections, UDP itself is unreliable and cannot be used directly.

Therefore, it is only natural that Google decided to transform a new protocol based on UDP that has the advantages of the TCP protocol. This new protocol is the QUIC protocol (Quick UDP Internet Connection), and it is used on HTTP/3. Of course, HTTP/3 was previously called HTTP-over-QUIC. From this name, we can also find that the biggest transformation of HTTP/3 is the use of QUIC.

QUIC and HTTP/3 New Features

Although QUIC is based on UDP, it has added many new features, such as multiplexing, 0-RTT, TLS1.3 encryption, flow control, ordered delivery, retransmission, etc. Here we will select several important features to learn about the content of this protocol.

1. Multiplexing to solve the head-of-line blocking problem

Although HTTP/2 supports multiplexing, the TCP protocol does not have this feature after all. QUIC natively implements this feature

The QUIC protocol is implemented based on the UDP protocol. Multiple streams can be created on the same QUIC connection to send multiple HTTP requests. In addition, there is no dependency between multiple streams. The transmission of a single stream can ensure orderly delivery without affecting other data streams.

For example, in the figure below, if stream2 loses a UDP packet, it will not affect the following streams 3 and 4. This technology solves the head-of-line blocking problem that existed in TCP before.

And QUIC will perform better than TCP on mobile terminals. Because TCP identifies connections based on IP and port, this method is very fragile in the ever-changing mobile network environment. But QUIC identifies a connection by ID. No matter how your network environment changes, as long as the ID remains unchanged, you can quickly reconnect.

2. 0RTT

By using a technique similar to TCP Fast Open, the context of the current session is cached. When the session is resumed next time, only the previous cache needs to be passed to the server for verification before transmission can begin.

0RTT connection can be said to be the biggest performance advantage of QUIC compared to HTTP2. So what is 0RTT connection?

There are two meanings here:

• The transport layer 0RTT can establish a connection.
• Encryption layer 0RTT can establish an encrypted connection.

The left side of the above figure shows the connection establishment process of a full handshake of HTTPS, which requires 2-3 RTTs to start transmitting data. The right side of the QUIC protocol can contain valid application data in the first packet.

Of course, the QUIC protocol can implement 0RTT, but this is also conditional. In fact, it is 1RTT for non-first connection and 0RTT for first connection. The first connection process:

It can be seen that when the connection is first made, the actual business data has already been sent in step 4, and steps 1 to 3 take exactly 1RTT to go back and forth, so the cost of the first connection is 1RTT.

3. Forward Error Correction Mechanism

The QUIC protocol has a very unique feature called Forward Error Correction (FEC). In addition to its own content, each data packet also includes some data from other data packets. Therefore, a small amount of packet loss can be directly assembled through the redundant data of other packets without retransmission.

Forward error correction sacrifices the upper limit of the data that can be sent in each data packet, but reduces data retransmission due to packet loss, because data retransmission will consume more time (including the time consumed in steps such as confirming packet loss, requesting retransmission, and waiting for new data packets).

If I want to send three packets this time, the protocol will calculate the XOR value of these three packets and send a separate verification packet, that is, a total of four packets are sent.

When a non-verification packet is lost, the content of the lost data packet can be calculated through the other three packets.

Of course, this technology can only be used when one packet is lost. If multiple packets are lost, the error correction mechanism cannot be used and only retransmission can be used.

4. Encrypted and authenticated messages

The TCP protocol header is not encrypted or authenticated, so it is easy to be tampered, injected, and eavesdropped by intermediate network devices during transmission. For example, modifying the sequence number and sliding the window. These behaviors may be for performance optimization or active attacks.

However, QUIC packets are fully armed. Except for individual packets such as PUBLIC_RESET and CHLO, all packet headers are authenticated and the message bodies are encrypted.

In this way, the receiving end can detect any modification to the QUIC message in time, effectively reducing security risks.

As shown in the figure above, the red part is the message header of the Stream Frame, which is authenticated. The green part is the message content, which is all encrypted.

QUIC and HTTP/3 Future Development Outlook

Although the QUIC protocol is implemented based on UDP, it implements and optimizes the important functions of TCP. At the same time, the attempt in the direction of encrypted transmission has also promoted the development of TLS1.3. The future is still promising.

It's just that the power of TCP protocol is too strong now, and many network devices even have many unfriendly strategies for UDP data packets, so TCP is still the world for the time being???♀?, but QUIC has shown strong vitality, let us wait and see!

refer to

Illustration | Why HTTP3.0 uses UDP protocol: https://network..com/art/202009/625999.htm

What do you think of HTTP/3?: https://www.zhihu.com/question/302412059/answer/533223530

Source: https://github.com/Advanced-Frontend/Daily-Interview-Question