background
It's the beginning of the annual autumn school recruitment. In the past, every company will arrange students to conduct on-site interviews at the company or school site? However, due to the epidemic this year, students are not allowed to conduct an interview on the spot, so this year's interview format has changed from offline to online. The interview format has changed, but the way we evaluate students has not changed.
The students recruited by the school are very different from the students recruited by the society. They do not have rich work experience and not much project experience. So how do we measure the students recruited by the school? That is the foundation and potential. How to understand the foundation? As the saying goes, if you don't accumulate steps, you can't reach thousands of miles, if you don't accumulate small currents, you can't become a river. If you don't have a good foundation, how can you become an excellent engineer. How to examine the quality of a student's foundation? I think three aspects are more important, computer networks, operating systems, algorithms and data structures. Generally speaking, there are a lot of surveys on computing networks, some common problems:
- Network model layering
- The difference between TCP and UDP
- TCP three-way handshake and four waved hands
- The difference between HTTP versions
The questions listed above are only part of them. These questions are basically answered in the class books. If you are not good at these, you can only say that the basics are relatively poor. Since this is a video interview, I usually ask you whether you think the video interview of Niuke.com uses TCP or UDP? Before I announce the answer, you can also think about which network protocol is used. During the interview, all the students answered that it should be UDP. I asked why UDP is used? Basically, I will answer that UDP is a connectionless protocol, without guaranteeing reliability and fast transmission speed. I also asked if UDP does not guarantee reliability. During the video interview, I will ask you a question. If the video stream for answering the question is lost, then I will not hear your answer. The video interview experience will be very low. Many students will change the answer at this time and say that TCP should be used. I will ask again because TCP needs to ensure reliability, but in the complex environment of the public network, there should be buffers or jams. Stop the phenomenon, many students will be speechless at this time.
In fact, the answer to this question is not difficult to come up with. We can combine the characteristics of TCP and UDP, so that this protocol can guarantee both reliability and real-time performance. This is what we call RUDP ((Reliable UDP) , Common RUDP protocols include QUIC, WebRTC, Aeron, etc. Here I will mainly introduce the QUIC proposed by Google, and take you to a taste of RUDP and see how they can be reliable and efficient.
QUIC
QUIC (Quick UDP Internet Connection) is an efficient and reliable protocol based on UDP proposed by Google. It is also an application layer protocol like HTTP.
Why is it efficient? It is because it is based on connectionless UDP rather than TCP.
Why is it reliable? Because it imitates the reliability of the TCP protocol, reliability is guaranteed at the application layer.
Why do you need QUIC?
The Internet has been developing for decades, but when it comes to network protocols, the TCP protocol is the most used in the transport layer, and the HTTP protocol is the most used in the application layer. Of course, the bottom layer of HTTP also uses the TCP protocol. Although the Internet has been developing for so long, the development of TCP is still slow. To say that the biggest improvement should be the TCP Fast Open published by Google at the ACM CoNEXT conference to improve the response delay of Web applications, by modifying the TCP protocol to use the three-way handshake Data exchange at the time, this is supported in Linux kernel 3.7.1 and later versions. Because modifying the TCP protocol will inevitably modify the kernel and lead to system upgrades, this push is extremely difficult.
Since we can't modify the kernel, then Google proposed a way to modify the application layer protocol, and then QUIC.
Who is using it?
The first person to use it must be Google. It is said that 50% of Google's requests are QUIC protocol. Weibo is also fully using QUIC protocol. At the same time, some video cloud services such as Qiniu are also using it, and there are many departments within Tencent. QUIC is widely used, so there is no need to worry about the use of this protocol.
Why is QUIC so good?
0RTT establish link
RTT ((Round-Trip Time), as the name implies, means round-trip delay. 0RTT means that QUIC can bring data when it is sent for the first time. Students who are familiar with TCP should know that TCP has a three-way handshake so practical There will be 1 RTT:
If it is HTTPS, additional handshake of SSL/TLS will be used, and there will be 3 RTTs:
So how does 0RTT establish link QUIC? Here we must first say that the 0RTT of QUIC is not a complete 0RTT. He also needs 1RTT to do a key negotiation. The Diffie-Hellman key exchange is used in QUIC. This algorithm is a method of establishing a key. Encryption method, but the generated key can be used for encryption, key management or any other encryption method. The purpose of this key exchange technology is to enable two users to safely exchange keys (KEY) for future use Encrypted messages. The DH algorithm uses the knowledge of discrete logarithms, so I won’t expand the explanation here, and those who are interested can come down to search for this algorithm. After QUIC creates a secure connection through the DH algorithm, the client will cache the original connection information, etc. In the subsequent process, as long as the link is established with the same server, the data is sent directly, and the secret key does not need to be negotiated again, thus realizing the subsequent ORTT.
Better congestion control
There are many algorithms for congestion control in TCP, such as packet loss feedback based (Tahoe, Reno, New Reno, SACK) and delay feedback based (Vegas, Westwood). Among them, Reno is the one we are most familiar with. It is divided into Four stages: slow start, congestion avoidance, fast retransmission, and fast recovery.
In QUIC, a more excellent mechanism is used to control congestion control. It can use different congestion control algorithms for different services, different network standards, and even different RTTs. At the same time, packet pacing is also used to detect network bandwidth to improve network utilization.
Better retransmission mechanism
There is a more important term in the retransmission mechanism, that is, RTO (Retransmission Timeout) retransmission timeout. Generally, this data will be calculated based on RTT, so if we have a more accurate RTT, we can have a better one. RTO.
When retransmitting in TCP, the sequence number remains unchanged, which will cause our RTT to be calculated inaccurately. For example, when retransmitting, you don’t know whether your request matches the original request or the retry request. This will cause us The sampled RTT is not accurate. 
In QUIC, the serial number is incremented, and the real position in the packet is determined by the offset, so that a more accurate RTT can be obtained.
The method of calculating RTT in TCP is to subtract the sent time and the response time, but the calculated time is not accurate. In QUIC, the server Ack Delay time will be subtracted, which is more accurate. 
Similarly, there is a SACK option in TCP. When this option is turned on, it is used to record the range of some unacknowledged data in the transmission process, which is convenient for subsequent directed retransmission of multiple groups of lost data instead of all retransmissions, so more range Facilitate more options for retransmission, which also means less retransmission packet frequency. But TCP supports up to 3 SACK ranges, while QUIC can support 255.
Multiplexing without head-of-line blocking
Students familiar with HTTP2.0 should know that in 2.0, if you access the same server, there will only be one TCP connection, and all requests will go through this connection:
Each request is called Stream in Connection, and there can be multiple Streams in a Connection. There is a problem with the timing of packets in TCP. If a Stream loses a packet, it will also affect others. Stream, when it is more serious, multiplexing is not as good as multiple links of HTTP1.1.
In QUIC, because the bottom layer is based on UDP, UDP does not need to guarantee the timing of the packet, and only reorganizes the packet when it is received, so this problem does not exist. This is why Google proposed to use QUIC in HTTP3.
Better flow control
As mentioned above, QUIC is multiplexed, and flow control can be performed on both Stream and Connection in QUIC.
The flow control of QUIC is a bit different from TCP. In order to ensure reliability, the length of the left edge of the window when sliding to the right depends on the number of bytes that have been confirmed. If there is a packet loss in the middle, even if a segment with a larger sequence number is received, the window cannot exceed this sequence number.
But QUIC is different. Even if some packets have not been received before, its sliding depends only on the maximum offset bytes received.
The most important thing is that we can perform dynamic configuration to limit the transmission rate through flow control and ensure service availability when there is insufficient memory or upstream processing performance problems.
Connection migration
Switching between mobile traffic and wifi on a mobile phone is now a relatively common thing. Every time the ip address is switched, the connection will be interrupted and the connection will be re-established if it is TCP.
In QUIC, the IP and port quadruples are no longer identified, but a 64-bit random number is used as the ID. In this way, the connection can be reused without re-establishing a new connection.
other
There are more other features in QUIC, such as:
- Ensure stream order through header stream
- The bottom layer ensures that the connection is durable
- Source address token prevents address spoofing
- Compress the certificate to avoid enlargement during handshake*** I won’t introduce them here.
I won’t explain it in detail here, and you can search for information by yourself.
to sum up
In fact, this post can be regarded as a literacy post. I believe that many of my friends have not heard of something related to RUDP, or have heard of it but always thought it was a very complicated and difficult thing to understand. In fact, I spread it out here. RUDP is composed of a UDP+application layer reliable protocol. I hope everyone can gain something after reading this article.
Reference article:
- How does the QUIC protocol achieve 0RTT encrypted transmission: https://blog.csdn.net/dog250/article/details/80935534
- Technical literacy-a new generation of UDP-based low-latency network transport layer protocol-QUIC detailed explanation: http://www.52im.net/thread-1309-1-1.html
- QUIC protocol analysis, performance testing and practice in QQ members: https://www.cnblogs.com/wetest/p/9022214.html
If you think this article is helpful to you, your attention and reposting are my greatest support
