background

Is the annual autumn school recruitment began, in the past school recruitment each company will be in the company site or school site to arrange students for on-site interviews? However, due to the epidemic situation this year, students are not allowed to conduct an interview on site, so this year the form of interview has been changed from offline to online, but the way we assess students remains unchanged.

The students recruited by school are very different from those recruited by social organizations. They do not have rich work experience or too much project experience. So how do we measure a student recruited by school? That’s the foundation and potential. How do you understand the foundation? As the saying goes, no accumulation, no thousands of miles, no small streams, no rivers and oceans, if there is no good foundation then how can become an excellent engineer? How to examine the quality of a student’s foundation? I think there are three areas that are very important, computer networks, operating systems and algorithms and data structures. Generally speaking, networks are studied a lot. Some common problems:

• Network model layering
• Differences between TCP and UDP
• TCP three handshakes and four waves
• Differences between HTTP versions

The questions listed above are just a few of them. The answers to these questions can be found in the books in class. If you don’t know these questions, you can only say that the foundation is relatively poor. Since this is a video interview, I usually ask you whether you think the video interview is TCP or UDP? Before I give you the answer, you can also think about which network protocol you’re using. In the interview, all the students said that it should be UDP. I asked why UDP? UDP is a connectionless protocol with no reliability and high transmission speed. I asked if UDP does not guarantee reliability. If I ask you a question during the video interview, if the video stream of your answer is lost, I cannot hear your answer, and the experience of the video interview will be very low. At this time, many students will change the answer and say that TCP should be used. I will ask TCP because it needs to ensure reliability, but in the complex environment of the public network, it must often appear buffering or lag 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 features of TCP and UDP to ensure the reliability and real-time performance of the protocol, which is also called RUDP (Reliable UDP). Common RUDP protocols include QUIC,WebRTC,Aeron and so on. I’m going to focus on Google’s QUIC and give you a taste of RUDP and how they can be both reliable and efficient.

QUIC

Quick UDP Internet Connection (QUIC) 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? Because it is implemented based on connectionless UDP rather than TCP.

Why is it reliable? Because it imitates the reliability of TCP protocol, the reliability is guaranteed on the application layer.

Why QUIC?

The Internet has developed for several decades, but when it comes to network protocols, TCP is the most commonly used protocol at the transport layer, HTTP is the most commonly used protocol at the application layer, and of course TCP is also used at the bottom of HTTP. Although the Internet has been developing for a long time, the development of TCP is still slow. The biggest improvement should be the TCP Fast Open that Google presented at THE ACM CoNEXT conference to improve the response latency of Web applications. This is supported in Linux kernel 3.7.1 and later. Since modifying TCP would inevitably change the kernel and lead to a system upgrade, this is a very difficult push.

Since we couldn’t modify the kernel, Google came up with a way to modify the application layer protocol, and QUIC came into being.

Who is using it?

Google must be the first to use it. It is said that 50% of Google’s requests are QUIC protocol, And Weibo is also using QUIC protocol in an overall way. Meanwhile, some video cloud services such as Qiniu are also using QUIC protocol.

Why is QUIC so awesome?

0RTT Establishes a link

RTT((round-trip Time)); 0RTT (round-trip Time); 0RTT (round-trip Time); 0RTT (round-trip Time); 0RTT (round-trip Time)

If HTTPS is used and an additional HANDSHAKE of SSL/TLS is used, there will be 3 RTT:

So how does 0RTT build links QUIC? QUIC’s 0RTT is not a complete 0RTT. It also needs 1RTT to conduct a secret key negotiation. Diffie-hellman key exchange is used in QUIC, and this algorithm is a key establishment method rather than encryption method. However, 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 securely exchange keys for future message encryption. The DH algorithm uses some knowledge about discrete logarithms, so I’m not going to extend it here, but if you’re interested, you can go down and search for this algorithm. After QUIC uses the DH algorithm to create a secure connection, the client caches the original connection information. In the subsequent process, as long as the link is established with the same server, the data is directly sent without the need to negotiate the secret key again, thus realizing the subsequent 0RTT.

Better congestion control

There are many TCP congestion control algorithms, such as those based on packet loss feedback (Tahoe, Reno, New Reno and SACK) and those based on delay feedback (Vegas and Westwood). Among them, Reno is the most familiar one, which is divided into four stages: Slow start, congestion avoidance, fast retransmission, fast recovery.

However, QUIC uses a more excellent mechanism to control congestion control, which can use different congestion control algorithms for different services, different network systems, and even different RTT. At the same time, packet pacing will be used to detect network bandwidth to improve network utilization rate.

Better retransmission mechanism

There is an important term in the Retransmission mechanism, that is, RTO(Retransmission Timeout). Generally, this data will be calculated according to RTT. Therefore, a more accurate RTT will ensure a better RTO.

In TCP, the serial number is unchanged when retransmitting, which will lead to inaccurate RTT calculation. For example, when retransmitting, you do not know whether your request matches the original request or the retry request, which will lead to inaccurate RTT of our sample.

In QUIC, serial numbers are incremented, and offset is used to determine the true position in the package, so that a more accurate RTT can be obtained.

In TCP, RTT is calculated by subtracting the sending time from the response time, but this time is not accurate. In QUIC, the Ack Delay time of the server is subtracted so that it is more accurate.

Similarly, TCP has a SACK option. This option, when turned on, is used to record the range of some unacknowledged data during transmission, which facilitates subsequent retransmission of multiple groups of lost data rather than all of them. Therefore, more ranges facilitate more options for retransmission, which also means less frequency of retransmission. TCP supports a maximum of three SACK ranges, while QUIC supports 255.

Multiplexing without queue head blocking

Those familiar with HTTP2.0 should know that in 2.0 there is only one TCP connection to access the same server, and all requests go through that connection:

Each request is called a Stream in a Connection, and there can be multiple streams in a Connection. The problem here is that packets in TCP are guaranteed to be sequential. If one Stream loses a packet, it will also affect other streams. In more serious cases, multiplexing is worse than multiple links in HTTP1.1.

In QUIC, however, because the underlying layer is based on UDP,UDP does not need to ensure packet timing and only reorganizes packets when receiving them, so this problem does not exist. This is why Google has proposed using QUIC in HTTP3.

Better flow control

QUIC is multiplexed. In QUIC, flow control can be performed for both Stream and Connection.

QUIC’s flow control is a bit different from TCP, which, to ensure reliability, swipes the left edge of the window to the right depending on the number of bytes acknowledged. If packet loss occurs in the middle, the window cannot exceed the sequence number even if it receives a Segment with a larger sequence number. But QUIC is different. Even if some packets have not been received before, it slides only depending on the maximum offset bytes received.

The most important thing is that we can do dynamic configuration, you can use flow control to limit the transfer rate and ensure service availability in the event of memory shortage or upstream processing performance problems.

Connect the migration

Now it is a common thing to switch between mobile traffic and wifi on mobile phones. Every time the IP address will change. If it is TCP, the connection will be interrupted and re-established.

QUIC is no longer identified by IP and port quads, but by a 64 bit random number as ID. In this way, connections can be reused and new connections will not be established.

other

There are many other features in QUIC, such as:

• Ensure stream order through header Stream
• The bottom layer ensures that the connection is persistent
• Source address tokens prevent address spoofing
• Compression of certificates during handshake to avoid amplification attacks is not introduced here

Here is no detailed introduction, we can consult the information search.

conclusion

This post is actually a literacy, and believe that there are a lot of friends is not something I heard of RUDP related, or heard of but he always thought is a complicated and difficult to understand, but here the chorus RUDP is a reliable UDP + application layer protocol, hope after you read this article, learn something.

Reference article:

• QUIC protocol is how to achieve zero RTT encryption transmission: blog.csdn.net/dog250/arti…
• Technology Literacy – A new generation of UDP based low latency Network Transport Layer protocol — QUIC Details :www.52im.net/thread-1309…
• QUIC protocol analysis, performance testing, and the QQ member practices: www.cnblogs.com/wetest/p/90…

If you find this article helpful to you, your attention and forwarding will be my biggest support.