HTTP History
-
1991 HTTP/1.1
-
2009 Google designed SPDY based on TCP
-
2013 QUIC
-
2015 HTTP/2
-
2018 HTTP/3
HTTP/3 achieves high speed by using UDP while maintaining the stability of QUIC (choosing QUIC means choosing UDP), without sacrificing the security of TLS.
Overview of the QUIC Protocol
QUIC (Quick UDP Internet Connections) is a protocol based on UDP that leverages the speed and efficiency of UDP while integrating and optimizing the advantages of TCP, TLS, and HTTP/2. The relationship between them can be clearly illustrated in a diagram.
QUIC is designed to replace TCP and SSL/TLS as the transport layer protocol, with application layer protocols such as HTTP, FTP, IMAP, etc., theoretically able to run over QUIC. The protocol running over QUIC is referred to as HTTP/3, which is the meaning of HTTP over QUIC.
Therefore, to understand HTTP/3, one cannot bypass QUIC. Below are several important features of QUIC.
RTT Connection Establishment
RTT: round-trip time, only includes the time for the request to travel back and forth
Establishing a connection with HTTP/2 requires 3 RTTs. If session reuse is considered, meaning caching the symmetric key calculated during the first handshake, it still requires 2 RTTs. Furthermore, if TLS is upgraded to 1.3, then an HTTP/2 connection requires 2 RTTs, and considering session reuse requires 1 RTT. If HTTP/2 is not urgent for HTTPS, it can be simplified, but in reality, almost all browser designs require HTTP/2 to be based on HTTPS.
HTTP/3 only requires 1 RTT for the first connection, and subsequent connections only require 0 RTT, meaning the first packet sent by the client to the server contains request data. The main connection process is as follows:
-
First connection, the client sends an Inchoate Client Hello to request a connection;
-
The server generates g, p, a, calculates A based on g, p, a, and then places g, p, A in the Server Config before sending a Rejection message to the client.
-
After the client receives g, p, A, it generates b, calculates B based on g, p, a, and calculates the initial key K based on A, p, b. Once B and K are calculated, the client encrypts the HTTP data using K and sends it to the server along with B.
-
After the server receives B, it generates the same key as the client based on a, p, B, and then uses this key to decrypt the received HTTP data. For further security (forward secrecy), the server updates its 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 HTTP response data.
Here, the DH key exchange algorithm is used. The core of the DH algorithm is that the server generates three random numbers a, g, p, where a is kept by the server, and g and p are transmitted to the client. The client generates a random number b, and through the DH algorithm, both the client and server can calculate the same key. During this process, a and b are not transmitted over the network, greatly enhancing security. Since p and g are large numbers, even if p, g, A, and B are intercepted during transmission, they cannot be cracked with current computational power.
Connection Migration
TCP connections are based on a four-tuple (source IP, source port, destination IP, destination port). When switching networks, at least one factor changes, causing the connection to fail. If the original TCP connection is still used when the connection changes, it will lead to connection failure, and one must wait for the original connection to time out before re-establishing it. This is why we sometimes find that when switching to a new network, even if the network conditions are good, the content still takes a long time to load. If implemented well, when a network change is detected, a new TCP connection is immediately established. However, even so, establishing a new connection still takes hundreds of milliseconds.
QUIC is not affected by the four-tuple. When any of these four elements change, the original connection remains intact. The principle is as follows:
QUIC does not use the four elements for representation but instead uses a 64-bit random number known as the Connection ID. Even if the IP or port changes, as long as the Connection ID does not change, the connection can still be maintained.
Head-of-Line Blocking / Multiplexing
Both HTTP/1.1 and HTTP/2 have the problem of head-of-line blocking.
TCP is a connection-oriented protocol, meaning that after sending a request, it must receive an ACK message to confirm that the object has accepted the data. If each request must wait for the ACK message of the previous request before sending the next, the efficiency is undoubtedly very low. Later, HTTP/1.1 introduced the Pipeline technique, allowing multiple requests to be sent simultaneously over a single TCP connection, thus improving transmission efficiency.
In this context, head-of-line blocking occurs. For example, if a TCP connection transmits 10 requests simultaneously, and requests 1, 2, and 3 are received by the client, but the fourth request is lost, then requests 5-10 are blocked. They must wait for the fourth request to be processed before they can be handled. This wastes bandwidth resources.
Therefore, HTTP generally allows each host to establish six TCP connections, which can better utilize bandwidth resources, but the head-of-line blocking problem still exists within each connection.
HTTP/2’s multiplexing solves the above head-of-line blocking problem. In HTTP/2, each request is split into multiple frames and transmitted simultaneously over a single TCP connection, so even if one request is blocked, it does not affect other requests.
However, while HTTP/2 can solve blocking at the request level, the underlying TCP protocol still has head-of-line blocking issues. Each request in HTTP/2 is split into multiple frames, and frames from different requests form streams. A stream is a logical transmission unit on TCP, allowing HTTP/2 to achieve the goal of sending multiple requests simultaneously over a single connection. If Stream1 is correctly delivered, but the third frame of Stream2 is lost, TCP processes data in strict order, meaning that the first sent frame must be processed first. This requires the sender to retransmit the third frame, while Streams 3 and 4 may have arrived but cannot be processed, causing the entire link to be blocked.
Moreover, since HTTP/2 must use HTTPS, and HTTPS uses the TLS protocol, it also has head-of-line blocking issues. TLS organizes data based on records, encrypting a pair of data together, and after encryption, it is split into multiple TCP packets for transmission. Generally, each record is 16K, containing 12 TCP packets, so if any of the 12 TCP packets are lost, the entire record cannot be decrypted.
Head-of-line blocking can cause HTTP/2 to be slower than HTTP/1.1 in weak network environments where packet loss is more likely.
How does QUIC solve the head-of-line blocking problem? There are two main points:
-
QUIC’s transmission unit is a packet, and the encryption unit is also a packet. The entire encryption, transmission, and decryption are based on packets, which avoids the blocking issues of TLS.
-
QUIC is based on UDP, and UDP packets are not processed in order at the receiving end. Even if one packet is lost in the middle, it does not block the entire connection. Other resources can be processed normally.
Congestion Control
The purpose of congestion control is to prevent too much data from flooding the network at once, causing it to exceed its maximum load. QUIC’s congestion control is similar to TCP but has been improved upon. Let’s first look at TCP’s congestion control.
-
Slow Start: The sender sends one unit of data to the receiver, and upon receiving confirmation, sends 2 units, then 4, 8, and so on, exponentially increasing while probing the network’s congestion level.
-
Avoiding Congestion: After exponential growth reaches a certain limit, it switches to linear growth.
-
Fast Retransmit: The sender sets a timeout timer for each transmission. If it times out, it is considered lost and needs to be resent.
-
Fast Recovery: Based on the fast retransmit, when the sender resends data, it also starts a timeout timer. If it receives a confirmation message, it enters the congestion avoidance phase; if it still times out, it returns to the slow start phase.
QUIC re-implements the Cubic algorithm from TCP for congestion control, and here are the features of QUIC’s improved congestion control:
1. Hot Plugging
In TCP, modifying the congestion control strategy requires system-level operations, while QUIC can modify the congestion control strategy at the application level, dynamically selecting the congestion control algorithm based on different network environments and users.
2. Forward Error Correction (FEC)
QUIC uses Forward Error Correction (FEC) technology to increase the protocol’s fault tolerance. A segment of data is split into 10 packets, and an XOR operation is performed on each packet. The result is transmitted as an FEC packet along with the data packets. If one data packet is lost during transmission, the missing packet’s data can be inferred from the remaining 9 packets and the FEC packet, greatly increasing the protocol’s fault tolerance.
This is a solution that aligns with current network transmission technology; bandwidth is no longer the bottleneck for network transmission, but round-trip time is. Therefore, new network transmission protocols can appropriately increase data redundancy and reduce retransmission operations.
3. Monotonically Increasing Packet Number
To ensure reliability, TCP uses Sequence Numbers and ACKs to confirm whether messages arrive in order, but this design has flaws. When a timeout occurs, the client initiates a retransmission, and later receives an ACK confirmation message. However, since the ACK message for the original request and the retransmission request is the same, the client cannot determine whether the ACK corresponds to the original request or the retransmission request, leading to ambiguity.
-
RTT: Round Trip Time
-
RTO: Retransmission Timeout
If the client thinks it is an ACK for the retransmission, but it is actually the situation on the right, it will lead to a small RTT, and vice versa will lead to a large RTT.
QUIC solves the ambiguity problem mentioned above. Unlike Sequence Numbers, Packet Numbers are strictly monotonically increasing. If Packet N is lost, the retransmission will not have the identifier N but a larger number, such as N+M. This way, when the sender receives the confirmation message, it can easily determine whether the ACK corresponds to the original request or the retransmission request.
4. ACK Delay
TCP does not consider the delay between the receiver receiving data and sending the confirmation message when calculating RTT. This delay is known as ACK Delay. QUIC takes this delay into account, making RTT calculations more accurate.
5. More ACK Blocks
Generally, the receiver should send an ACK response after receiving a message from the sender to indicate that the data has been received. However, sending an ACK for every single data packet is cumbersome, so typically, multiple data packets are acknowledged at once. TCP SACK provides a maximum of 3 ACK blocks. However, in some scenarios, such as downloading, the server only needs to return data, but according to TCP’s design, an ACK must be returned for every three data packets received. QUIC can carry up to 256 ACK blocks, which can reduce retransmissions and improve network efficiency in networks with high packet loss rates.
Flow Control
TCP performs flow control on each TCP connection, meaning that the sender should not send data too quickly, allowing the receiver to keep up; otherwise, data overflow and loss may occur. TCP’s flow control is mainly implemented through a sliding window. Congestion control primarily controls the sender’s sending strategy but does not consider the receiver’s receiving capacity, while flow control addresses part of this capability.
QUIC only needs to establish one connection, over which multiple streams can be transmitted simultaneously. It is like having a road with multiple warehouses along the way, where many vehicles transport goods. QUIC’s flow control has two levels: Connection Level and Stream Level.
For flow control at the Stream level: When a stream has not yet transmitted data, the receive window (flow control receive window) is the maximum receive window. As the receiver receives data, the receive window continuously shrinks. Among the received data, some have been processed, while others have not yet been processed. In the diagram below, the blue blocks represent processed data, and the yellow blocks represent unprocessed data, which causes the stream’s receive window to shrink.
As data continues to be processed, the receiver can handle more data. When (flow control receive offset – consumed bytes) < (max receive window/2) is satisfied, the receiver will send a WINDOW_UPDATE frame to inform the sender that it can send more data. At this point, the flow control receive offset will shift, and the receive window will increase, allowing the sender to send more data to the receiver.
Stream-level flow control has limited effectiveness in preventing the receiver from receiving too much data, and it is necessary to rely on Connection-level flow control. Understanding Stream flow control makes it easy to understand Connection flow control. In a stream,
Receive window = Maximum receive window – Received data
For Connection, it is:
Receive window = Stream1 receive window + Stream2 receive window + … + StreamN receive window
If you like this article, please click the upper right corner to share it with your friends.If there are any technical points you would like to learn about, please leave a message for Ruo Fei to arrange a sharing session.
Due to changes in the public account’s push rules, please click “Looking” and add “Star Mark”to get exciting technical shares at the first time.
·END·
Related Articles:
- Understanding Microservices Architecture in One Diagram
- Analysis of Microservices Architecture Based on Spring Cloud
- Is Microservices Equal to Spring Cloud? Understanding Microservices Architecture and Framework
- How to Build Microservices Based on DDD (Domain-Driven Design)?
-
Is a Small Team Really Suitable for Introducing Spring Cloud Microservices?
-
The Reasons for the Rise of DDD and Its Relationship with Microservices
-
The Best Calling Methods Between Microservices
-
Summary of Microservices Architecture Design Practices
-
Design and Implementation of Microservices Projects Based on Kubernetes
-
Microservices Architecture – Design Summary
-
Why Must Microservices Have a Gateway?
-
The Battle of Mainstream Microservices Full-Chain Monitoring Systems
- Detailed Explanation of Microservices Architecture Implementation Principles
- Introduction to Microservices and Technology Stack
- Solutions for Data Consistency in Microservices Scenarios
- Designing a Fault-Tolerant Microservices Architecture
Source:Internet
Copyright Statement: Content sourced from the internet, for learning and research purposes only. Copyright belongs to the original author. If there is any infringement, please inform us, and we will delete it immediately and apologize. Thank you!
Architect
We are all architects!
Follow Architect (JiaGouX), add “Star Mark”
Get daily technical content and become an excellent architect together.
For technical groups, pleaseadd Ruo Fei:1321113940 to join the architect group.
For submissions, collaborations, copyright, etc., please email:[email protected]