Is the transmission protocol for video interview TCP or UDP?

[[340127]]

This article is reprinted from the WeChat public account "Coffee Latte", the author is Coffee Latte. Please contact the Coffee Latte public account to reprint this article.

background

The annual autumn campus recruitment has begun again. In the past, companies would arrange on-site interviews for students at the company or school. However, due to the epidemic this year, students are not allowed to conduct an interview on site, so this year's interview format has changed from offline to online. Although the interview format has changed, the way we assess students has not changed.

There is a big difference between students recruited from campus and those recruited from society. They do not have rich work experience and not many project experiences. So how do we measure a student recruited from campus? That is the foundation and potential. How do we understand the foundation? As the saying goes, a journey of a thousand miles begins with a single step, and a river is formed without the accumulation of small streams. If you do not have a good foundation, how can you become an excellent engineer? How to examine the quality of a student's foundation? I think there are three aspects that are more important: computer networks, operating systems, algorithms, and data structures. Generally speaking, computer networks are examined particularly frequently. Some common questions:

• Network model layering
• Difference between TCP and UDP
• TCP three-way handshake and four-way wave
• Differences between HTTP versions

The questions listed above are only part of them. The answers to these questions can basically be found in the textbooks. If you don't know these, then it can only be said that your foundation is 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 reveal the answer, you can also think about which network protocol is used. During the interview, all the students answered that UDP should be used. I asked why UDP is used? Basically, they will answer that UDP is a connectionless protocol, which does not need to guarantee reliability and has a fast transmission speed. I asked again if UDP does not guarantee reliability, and I ask you questions during the video interview. If the video stream of your answer is lost, then I can't hear your answer, and the experience of the video interview will be very low. Many students will change their answers at this time and say that TCP should be used. I will ask again that TCP needs to ensure reliability, but in the complex environment of the public network, buffering or jamming should often occur. Many students will be speechless at this time.

In fact, the answer to this question is not difficult to figure out. We can combine the characteristics of TCP and UDP to make this protocol both reliable and real-time. This is what we call RUDP (Reliable UDP). Common RUDP protocols include QUIC, WebRTC, Aeron, etc. Here I mainly introduce QUIC proposed by Google, and take you to appreciate the wonderfulness of RUDP and see how they can be both reliable and efficient.

QUIC

QUIC (Quick UDP Internet Connection) is an efficient and reliable protocol based on UDP proposed by Google. Like HTTP, it is also an application layer protocol.

Why is it efficient? Because it is based on connectionless UDP instead of TCP.

Why is it reliable? Because it imitates the reliability of the TCP protocol and ensures reliability at the application layer.

Why do we need QUIC?

The Internet has been developed for decades, but when it comes to network protocols, the most commonly used transport layer is still TCP, and the most commonly used application layer is HTTP. Of course, the underlying HTTP also uses TCP. Although the Internet has been developed for so long, TCP is still developing slowly. 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 and using the three-way handshake to exchange data, this can be supported in Linux kernel 3.7.1 and higher versions. Since modifying the TCP protocol will inevitably modify the kernel and lead to system upgrades, this is very difficult to promote.

Since we cannot modify the kernel, Google proposed a way to modify the application layer protocol, which led to QUIC.

Who is using it?

The first to use it will definitely be Google. It is said that 50% of Google's requests are based on the QUIC protocol. Weibo is also using the QUIC protocol in its entirety. At the same time, some video cloud services such as Qiniu are also using it. There are also many departments within Tencent that use QUIC extensively, so there is no need to worry about the use of this protocol.

Why is QUIC so powerful?

0RTT Link Establishment

RTT (Round-Trip Time) means the round-trip delay. 0RTT means that QUIC can carry data when it is sent for the first time. Students who are familiar with TCP should know that TCP will have a three-way handshake, which actually means there will be 1 RTT:

If it is HTTPS, an additional handshake of SSL/TLS will be used, and there will be 3 RTTs:

So how does QUIC establish a connection with 0RTT? Here we must first say that QUIC's 0RTT is not completely 0RTT. It also needs 1RTT to do a secret key negotiation. The Diffie-Hellman key exchange is used in QUIC. This algorithm is a method of establishing keys, not an encryption method, but the keys it generates 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 exchange keys (KEY) securely for future message encryption. The DH algorithm uses the relevant knowledge of discrete logarithms, which will not be expanded here. Those who are interested can 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, data is sent directly without the need to negotiate the secret key again, thus realizing the subsequent 0RTT.

Better congestion control

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

QUIC uses a better mechanism to control congestion. It can use different congestion control algorithms for different services, different network standards, and even different RTTs. It also uses packet pacing to detect network bandwidth to improve network utilization.

Better retransmission mechanism

There is an important term in the retransmission mechanism, that is RTO (Retransmission Timeout). Generally, this data is calculated based on RTT. If we have a more accurate RTT, we can definitely have a better RTO.

When TCP retransmits, the sequence number remains unchanged, which will cause our RTT calculation to be inaccurate. For example, when retransmitting, you don’t know whether your request matches the original request or the retry request, which will cause our sampled RTT to be inaccurate.

In QUIC, sequence numbers are incremented, and the actual position in the packet is determined by offset, so that a more accurate RTT can be obtained.

The method of calculating RTT in TCP is to subtract the time of sending from the time of response, but the time calculated in this way is not accurate. In QUIC, the time of server Ack Delay is subtracted, which makes it 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 data that has not been confirmed during the transmission process, so as to facilitate the subsequent directional retransmission of multiple groups of lost data instead of retransmission of all data. Therefore, more ranges facilitate more selective retransmissions, which also means less retransmission packet frequency. However, TCP supports up to 3 SACK ranges, while QUIC can support 255.

Multiplexing without head-of-line blocking

Students who are 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 in a Connection is called a Stream. A Connection can have multiple Streams. The problem here is that the packets in TCP are time-ordered. If a packet is lost in a Stream, it will also affect other Streams. In more serious cases, multiplexing is not as good as multiple links in HTTP1.1.

In QUIC, because the underlying layer is based on UDP, UDP does not need to guarantee the timing of packets and only reassembles the packets when they are received, so this problem does not exist. This is why Google proposed using 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.

QUIC's flow control is a little different from TCP. In order to ensure reliability, the length of the left edge of the TCP window sliding to the right depends on the number of bytes that have been confirmed. If there is 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 only depends on the maximum number of offset bytes received.

The most important thing is that we can perform dynamic configuration. When there is insufficient memory or problems with upstream processing performance, we can limit the transmission rate through flow control to ensure service availability.

Connection Migration

Nowadays, switching between mobile data and WiFi on mobile phones is a common thing. The IP address will change every time it is switched. If it is TCP, the connection will be interrupted and the link will be re-established.

In QUIC, the IP and port quadruple is no longer used as an identifier, 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 many other features in QUIC, such as:

• Ensuring stream order through header stream
• The underlying layer ensures persistent connection
• Source address tokens prevent address spoofing
• Compressing certificates during handshake to avoid amplification attacks will not be introduced here one by one

I won’t explain it in detail here, you can search for information on your own.

Summarize

In fact, this post can be regarded as a literacy post. I believe that many friends have not heard of things related to RUDP, or have heard of it but always thought it was something very complicated and difficult to understand. In fact, here I will explain that RUDP is composed of a UDP+application layer reliable protocol. I hope that after reading this article, you can gain something.

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 low-latency network transport layer protocol based on UDP - QUIC detailed explanation: http://www.52im.net/thread-1309-1-1.html

Analysis of QUIC protocol, performance testing and practice in QQ members: https://www.cnblogs.com/wetest/p/9022214.html