⚠️ this article for nuggets community first contract article, not authorized to forbid reprint
Those of you who have studied network technology know that HTTP/3 is actually based on UDP. In the impression of many students, UDP belongs to a very low-level protocol: transmission is unreliable, there is no congestion mechanism, it is unthinkable to use it in the accurate and reliable transmission of the World Wide Web.
But is this really the case? Let’s close our mouths and see why HTTP/3 can be based on UDP and is a very smart choice.
To understand this choice, we first need to clear up some misunderstandings about UDP.
1. UDP is the purest transport layer protocol
In fact, UDP is not as unreliable as many people think, it is simply because of its simplicity that you have such a perception. On the other hand, it is actually the purest transport layer protocol.
So what is the position of UDP in network transmission? We need to take a brief look at typical network layering.
Physical layer and connection layer
- The physical layer is at the bottom of the network, and it processes all the ones and zeros, and it’s the hardware layer that keeps our information going
- The connection layer makes a preliminary integration of these ones and zeros to form fixed length information frames, each of which contains
SRCandDST(here’s the MAC address), allowing our two machines to communicate point-to-point
At this time, network packets can not escape from the LOCAL area network, want to larger transmission, it needs the help of the network layer.
The network layer
In order to make these addresses meaningful, the network layer adds the IP protocol to locate the target machine through the IP address. Finally, after the translation by the router, the connection layer is responsible for the transmission of specific information. For example, I captured packets in the following Wireshark.
EthernetIIIt’s what we call the connection layer Ethernet, and the information that’s transmitted is the Frame- The following is the IPv4 protocol, indicating an IP packet.
If you look at the IP packet, you will find that it is in a very strange format. When routing, the intermediate node needs to unpack and then packet. This is because THE IP protocol is a network layer protocol, and its header, such as the IP address, is actually the connection layer protocol’s packet (PlayLoad).
With IP, we’re close to UDP.
The transport layer
IP protocol only solves the problem of computer to computer communication, but we will have different processes on each machine, how to distinguish them? That’s what the transport layer protocol does.
UDP and TCP identify a process by adding a port number. The IP address plus the port number is the socket that we write the code to. Most network traffic today, including HTTP/1, HTTP/2, etc., is based on TCP.
At the protocol level, UDP is actually the cleanest protocol. It completely exposes all the content of IP. Compared to IP, it has only one more port number, so UDP has all the characteristics of IP. Disorder, for example, does not guarantee Best Effort. As for more advanced traffic negotiation control, such as congestion mechanisms, UDP doesn’t care about that at all.
UDP, which has no features, is much narrower than TCP. We usually introduce TCP/IP protocol as a whole, so as to ignore the most original and purest UDP protocol.
Let’s look at a typical UDP protocol. As shown above, compared to IP protocol, UDP protocol has only two more ports, one length, and one checksum, which is indeed unparalleled in purity.
2. TCP is too complex as a basic protocol
You may ask, both TCP and UDP are transport-layer protocols, so why isn’t HTTP/3 based on TCP? That’s because TCP itself is very complex, with a lot of historical baggage.
In order to ensure reliable transmission of information, sequential transmission, and throughput, TCP has done a lot of work. Compared with UDP, we can take a look at what TCP protocols are more content. The following figure shows a typical TCP protocol packet captured by wireshark.
We often talk about three handshakes (four merged into three), four wave, is the combination of Flags and serial number logic combination. If the TLS security protocol is added, the handshake process will be longer.
After the connection is established, the efficiency of TCP is not very high because of the question and answer ACK confirmation mode. It sends a lot of crap, and it waits.
In order to improve the efficiency of network transmission, TCP uses sliding window to solve the batch transmission, and at the same time to solve the sequentiality problem. To solve network congestion, TCP uses mechanisms such as slow start, congestion avoidance, fast retransmission, and fast recovery to keep the network throughput at a certain level.
Take a look at a detailed map of the TCP protocol on Wikipedia, which covers it in great detail in TCP/IP Detail Vol. 1: Protocols. As you can see, there are a lot of details.
What is an agreement? An agreement is a set of standards that we all follow, and all agreements are the result of a community of shared interests. For example, my distributed database uses the access layer protocol of MySQL, so it must follow a series of standards set by the MySQL protocol, otherwise it will not run.
** The lower the protocol, the higher the stability requirement. **TCP protocol, has been encoded in the operating system, whether it is protocol upgrade, or BUG repair, are all broken bones.
3. Why does UDP work?
To get past the historical baggage, HTTP/3 chose UDP primarily to address the problem of header blocking. Its underlying protocol, known as QUIC, is a protocol that runs at the transport (or application) layer. Unlike TCP, QUIC code is not hardcoded into the operating system kernel, but runs entirely in user space, with TLS integrated by default.
As you can see above, HTTP/3 is based on QUIC, which is based entirely on UDP.
But isn’t UDP supposedly connectionless? How does it implement additional features such as reliability?
In fact, the word “connection” is a virtual concept. There is no such a line of connection in the network. The connection is just for your logical understanding. Consider your current client server is client, server is server. Then the client and server packet interaction may take the following path.
In the absence of data interaction, server and client are simply two points. Even if you unplug the cable and plug it in again (with no interaction), they continue to send data to each other.
UDP claims to be connectionless, but it’s no different than TCP connections. The only difference is that after UDP sends the packet, it doesn’t care about anything. The peer may or may not receive the message. When the data sent is acknowledged with an ACK each time, it becomes TCP.
It doesn’t matter whether this validation code is in the transport layer or the application layer; But whether the code is in an operating system or in a package that can be upgraded independently matters a lot.
QUIC can be released independently of the operating system, avoiding the problem of slow operating system upgrades. The implementation of QUIC, still facing the message reliability, sliding Windows, congestion control and other scenarios, you can think of it as A TCP, but it is fundamentally different from TCP.
These differences can be seen by comparing the different versions of HTTP in terms of data transfer.
- In earlier implementations of HTTP1.0, if a large number of resources needed to be fetched from the server, N TCP short links were opened, fetching information in parallel. But because of TCP’s three-handshake and four-wave mechanism, the overall cost becomes larger as the number of connections increases
- In HTTP/1.1, this situation is improved by multiplexing long connections, but the problem is that resource acquisition must be queued due to TCP’s message acknowledgement and sequencing mechanisms and traffic control policies. A request needs to wait for the transmission of another request before it can start
- HTTP/2 is multiplexed so that multiple resources can share a single connection. But it only solves the reuse of the application layer, in the TCP transmission is still blocked, the resources behind the need to wait for the previous transmission to complete before continuing. This is the
Head-of-line blocking - QUIC abstracts the concept of a stream. Multiple streams can reuse a connection, so the concept of sliding Windows does not apply to connections, but to streams. The transmission of these packets can be performed concurrently due to the send-as-you-go nature of UDP. The server side of the protocol, will parse and cache these data packets, assembly and collation. Because the concept of stream is abstracted, the transmission of a packet fails, which only affects the accuracy of a stream, but not the accuracy of the entire connection
End
After reading the above, I believe you can come to the conclusion that HTTP/3 is based on UDP and is very reliable. It not only realizes the reliability transmission, but also can obtain the larger performance enhancement. To summarize QUIC’s improvements:
- QUIC is able to implement all the functional requirements of THE TCP protocol, and the integration of TLS, the function of the catch-up TCP
- A connection, multiple streams concurrent transmission, real multiplexing, effectively solve the queue head blocking phenomenon, performance beyond TCP
- Reducing the number of handshakes, especially with TSL transmission, has a lower handshake delay
- Because it is easy to upgrade, it provides great imagination space for the update and development of the agreement
The cause of QUIC is mainly due to the limitation of TCP. Connections are a valuable resource, and creating, destroying, and transferring over them can be time-consuming. The reliability mechanism of TCP, in the early development of computer network, is indeed very effective, but with the upgrade of hardware, its ACK transmission mode, in the efficiency of the development of higher performance. Because the CONCEPT of the TCP standard is so ingrained, its code even exists directly in the kernel, making it difficult to upgrade the protocol.
As the network infrastructure improves, the reliable transmission mode of TCP becomes a constraint. It would be great if all of our information processing could be done on one link. In this way, some intensive resource transmission, such as batch small pictures, video on demand, weak network transmission, will not be affected by RTT. In addition, my data cache and congestion control, etc., will be more flexible. To take an extreme example, my memory is large enough to cache a stream, and I can even tolerate a file of 1MB size where the first byte arrives after 10 seconds, rather than retransmitting all the time like TCP (because it’s limited to the TCP window).
Why is it possible to do this? Again, thanks to UDP’s pure nature, it’s just a programming interface for the IP protocol. It’s really a blank sheet of paper. If you want, you can even replicate all the functionality of TCP on top of UDP, as long as you can match the server and the client. That’s what QUIC does.
⚠️ this article for nuggets community first contract article, not authorized to forbid reprint