From HTTP/1.1 to HTTP/2, the HTTP protocol has always used TCP as the transport protocol.
However, in the latest HTTP/3, HTTP directly abandoned TCP, extended a hand to the isolated UDP, and implemented a reliable transport protocol - QUIC at the application layer based on the UDP protocol.
Many students may be curious, HTTP has been using TCP for decades, and TCP is already such a perfect reliable transmission protocol, and there are timeout retransmission, sequential reception, flow control, congestion control these characteristics, why suddenly abandoned TCP? What exactly is TCP doing well enough? Is it picking bones in the egg?
So, today I will talk to you about the reasons why TCP is not "good" enough.
TCP has a head-of-line blocking issue
The problem of TCP head-of-line blocking should be viewed from two perspectives, one is the header-blocking of the sending window, and the other is the head-of-line blocking of the receiving window.
1. The head of the sending window is blocked.
The data sent out by TCP needs to be confirmed in order, and only after the data is confirmed in order, the sending window will slide forward. For example, if the sender in the figure below sends all the data in the sending window, the size of the available window is 0, indicating that the available window is exhausted and cannot continue to send data until the ACK acknowledgement is received.
Then, when the sender receives the ACK acknowledgment reply to the 32~36th byte, the sliding window moves 5 bytes to the right, because 5 bytes of data are answered for confirmation, and then the 52~56th byte becomes a usable window, then the 52~56 bytes of data can be sent later.
However, if a data packet is lost or its corresponding ACK packet is lost in the network, the sender cannot move the sending window, and then it cannot send new data, and can only retransmit the data packet over timeout, until the ACK of the retransmitted message is received, the sending window will move and continue the subsequent sending behavior.
For example, in the following figure, the client is the sender and the server is the receiver.
The client sends the 5~9th byte of data, but the 5th byte ACK acknowledgment packet is lost in the network, so even if the client receives the 6~9-byte ACK acknowledgment packet, the sending window will not move forward.
At this time, the 5th byte is equivalent to the "team head", because the ACK confirmation packet of the "team head" is not received, resulting in the sending window cannot move forward, at this time the sender cannot continue to send the following data, which is equivalent to pressing the pause button of the sending behavior, which is the blocking problem of the team head of the sending window.
2. The team head of the receiving window is blocked.
The data range received by the receiver must be within the receiving window range, if the data is received beyond the receiving window range, the data will be discarded, for example, the range of the receiving window in the following figure is 32 ~ 51 bytes, if the data above the 52nd byte is received, it will be discarded.
When can the receiving window slide? When the receiving window receives ordered data, the receiving window can slide forward, and then the "ordinal" data that has been received and acknowledged can be read by the application layer.
However, when the data received by the receiving window is not ordered, such as receiving the 33~40th byte of data, because the 32nd byte data is not received, the receiving window cannot slide forward, then even if the 33~40th byte of data is received first, these data cannot be read by the application layer. Only when the sender retransmits the 32nd byte of data and is received by the receiver, the receive window will slide forward, and then the application layer can read the 32~40th byte of data from the kernel.
Well, so far the head blocking problem of the sending window and the receiving window is finished, the reason for these two problems is because TCP must process data in order, that is, the TCP layer in order to ensure the orderliness of data, only after processing ordered data, the sliding window can slide forward, otherwise stay.
- Staying in the "send window" makes it impossible for the sender to continue sending data.
- Staying in the "receive window" makes it impossible for the application layer to read new data.
In fact, you can't blame the TCP protocol, which was originally designed to ensure the orderliness of data.
HTTP/2 is blocking at the head of the queue
HTTP/2 implements HTTP concurrent transmission by abstracting the concept of Stream, and a Stream represents the request and response in HTTP/1.1.
On HTTP/2 connections, frames of different streams can be sent out of order (so different streams can be concurrent), because the header of each frame will carry Stream ID information, so the receiver can assemble HTTP messages into HTTP messages through Stream IDs in an orderly manner, and frames inside the same Stream must be strictly ordered.
However, HTTP/2 multiple Stream requests are transmitted on a TCP connection, which means that multiple Streams share the same TCP sliding window, so when data loss occurs, the sliding window cannot be moved forward, and all HTTP requests will be blocked, which belongs to TCP layer header blocking.
QUIC without head-to-head blockage
QUIC also borrows the concept of Stream in HTTP/2, and multiple HTTP requests (Streams) can be sent concurrently on a QUIC connection.
However, QUIC assigns a separate sliding window to each stream, so that there is no dependency between multiple streams on a connection, and they are all independent sliding windows controlled by each other.
If Stream2 loses a UDP packet, it will only affect the processing of Stream2, not other streams, unlike HTTP/2, HTTP/2 as long as the packet in one stream is lost, other flows will also be affected.
The delay for TCP to establish a connection
For HTTP/1 and HTTP/2 protocols, TCP and TLS are layered, respectively belonging to the transport layer implemented by the kernel and the presentation layer implemented by the openSSL library, so they are difficult to merge together, and need to be handshake in batches, first TCP handshake (1RTT), and then TLS handshake (2RTT), so it takes a delay of 3RTT to transmit data, even if the Session session takes it, it needs at least 2 RTT, which increases the delay of data transmission on a certain program.
TCP three-way handshake and TLS handshake delay, as shown in the figure:
Although HTTP/3 requires a QUIC protocol handshake before transmitting data, this handshake process only needs 1 RTT, and the purpose of the handshake is to confirm the "connection ID" of both parties, and the connection migration is based on the connection ID.
But the QUIC protocol of HTTP/3 is not layered with TLS, because QUIC is also a protocol implemented by the application layer, so the process of handshake between QUIC and TLS protocol can be merged together, QUIC contains TLS internally, and it will carry the "record" in TLS in its own frame, plus QUIC uses TLS1.3, so only 1 RTT can complete the connection and key negotiation "at the same time", and even at the second connection, the application packet can be with QUIC handshake information (connection information + TLS information) is sent together to achieve the effect of 0-RTT.
In the right part of the figure below, HTTP/3 When the session resumes, the payload data is sent together with the first packet, which can achieve 0-RTT (the lower right corner of the figure below):
Upgrading TCP is difficult
The TCP protocol was born in 1973, and the TCP protocol is still implementing more new features.
However, the TCP protocol is implemented in the kernel, and the application can only use it and cannot be modified, if you want to upgrade the TCP protocol, then you can only upgrade the kernel.
The work of upgrading the kernel is a very troublesome thing, the troublesome thing is not that the operation of upgrading the kernel is very troublesome, but because the kernel upgrade involves the update of the underlying software and runtime, our service program needs to regression test whether it is compatible with the new kernel version, so the kernel upgrade of the server is also conservative and slow.
Many new features of the TCP protocol need to be supported by both the client and the server to take effect, such as TCP Fast Open, although it was proposed in 2013, but many system versions of Windows still do not support it, because the system upgrade lag on the PC side is very serious, Windows XP is still used by a large number of users, although it has existed for almost 20 years.
Therefore, even if TCP has a relatively good feature update, it is difficult to promote quickly, and users often take several or ten years to experience it.
On the contrary, QUIC is at the application layer, so if you upgrade the QUIC protocol, it is as easy as upgrading software. Moreover, QUIC can set different congestion control algorithms for different applications, so that the flexibility is high, which TCP cannot do, because TCP changes the congestion control algorithm to take effect for all applications in the system, and it is not possible to set different congestion control policies according to different applications.
Network migration requires the TCP connection to be re-established
The HTTP protocol based on the TCP transport protocol, because a TCP connection is determined by a quad (source IP, source port, destination IP, destination port).
Then when the mobile device's network switches from 4G to WIFI, it means that the IP address has changed, so it is necessary to disconnect and re-establish the TCP connection.
The process of establishing a connection includes the delay of TCP three-way handshake and TLS four-way handshake, as well as the slowdown process of TCP slow start, giving users the feeling that the network suddenly stutters, so the migration cost of the connection is very high.
The QUIC protocol does not use a quadruple to "bind" the connection, but marks the two endpoints of communication by the connection ID, and the client and server can each choose a set of IDs to mark themselves, so even if the network of the mobile device changes, resulting in the IP address changing, as long as the context information (such as connection ID, TLS key, etc.) is still maintained, the original connection can be reused "seamlessly", eliminating the cost of reconnection, without the slightest sense of lag, to achieve the function of connection migration.
summary
After HTTP/3 abandons TCP, the reliable transport QUIC protocol based on UDP brings these four benefits:
- Reduce connection time: Implement 0-RTT to establish a connection when the client has a cache
- More flexible congestion control: In user mode, you can configure different congestion control policies for each request
- Multiplexing without head blocking: Each request flow has a sliding window independently and does not affect each other
- Connection migration: Network switching does not interrupt data transfer
However, HTTP/3 also faces some challenges, QUIC is based on the UDP protocol implemented in user space reliable transport protocol, if some network devices do not recognize the QUIC protocol, then in the eyes of these network devices it is a UDP protocol.
And almost all telecom operators "discriminate" UDP packets, and it's easy to see why, given that several notorious DDoS attacks in history have been UDP-based. A domestic city broadband directly banned non-port 53 UDP packets in some areas, while other operators strictly restricted UDP even if they did not block UDP.
Since QUIC was officially made public in 2013, it has developed for almost 10 years by 2023, and there are already many popular open source projects on the Internet, in addition to the leading big brother Google in completing its own search engine support, but also pulled up Gmail, YouTube and other sites. But for the vast majority of sites in China, most of them are still HTTP/2 protocols, and the road to HTTP/3 seems to be stuck in the Eastern Tang Dynasty.