Shulou(Shulou.com)06/01 Report--

This article mainly explains "the video interview transmission protocol is TCP or UDP". The explanation in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn whether the video interview transmission protocol is TCP or UDP.

QUIC

QUIC (Quick UDP Internet Connection) is an efficient and reliable protocol based on UDP proposed by Google. It is the same application layer protocol as HTTP.

Why is it efficient? Because it is based on connectionless UDP rather than TCP.

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

Why do I need QUIC?

The Internet has been developed for decades, but when it comes to network protocols, TCP protocol is most used in the transport layer, HTTP protocol is most used in the application layer, and of course, TCP protocol is also used in the bottom layer of HTTP. Although the Internet has been developed for such a long time, the development for TCP is still slow. The biggest improvement should be the TCP Fast Open published by Google at the ACM CoNEXT conference to improve the response latency of Web applications. By modifying the TCP protocol to use three-way handshake for data exchange, this can be supported in the Linux kernel 3.7.1 and later. Because modifying the TCP protocol will inevitably modify the kernel and lead to system upgrade, this is very difficult to promote.

Since we can't modify the kernel, Google proposes a way to modify the application layer protocol, which is called QUIC.

Who is using it?

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

Why is QUIC so awesome? 0RTT makes a link

RTT ((Round-Trip Time) means round-trip delay. 0RTT means that QUIC can bring data with it when it is sent for the first time. Students familiar with our TCP should know that TCP will have a three-way handshake, so in fact, there will be one RTT:

If it is HTTPS, the extra handshake from SSL/TLS will be used, and there will be 3 RTT:

So how does the link QUIC of 0RTT do? First of all, we have to say that QUIC's 0RTT is not a complete 0RTT. He also needs 1RTT to do a secret key negotiation. Diffie-Hellman key exchange is used in QUIC. This algorithm is a method of establishing a key, not an encryption method, but the resulting key can be used for encryption, key management or any other encryption method. The purpose of this key exchange technology is to enable the secure exchange of keys (KEY) between two users for future message encryption. DH algorithm uses the relevant knowledge of discrete logarithm, here do not expand the explanation, interested can come down to search this algorithm. After QUIC creates a secure connection through the DH algorithm, the client will cache the original connection information and so on. In the subsequent process, as long as you establish a link with the same server, the data is sent directly, and there is no need to negotiate the secret key again, thus realizing the subsequent 0RTT.

Better congestion control

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

In QUIC, a better mechanism is used to control congestion control. It 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.

Better retransmission mechanism

There is an important term in the retransmission mechanism, that is, RTO (Retransmission Timeout) retransmission timeout. Generally, this data will be calculated according to RTT, so we can definitely have a better RTO if we have a more accurate RTT.

When the sequence number remains the same when retransmitted in TCP, our RTT will be inaccurate. For example, when you retransmit, you don't know whether your request matches the original request or retry request, which will cause our sampling RTT to be inaccurate.

In QUIC, the sequence number is incremented, and the real location in the package 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 sent from the response, but the time calculated in this way is not accurate, and the time of server Ack Delay is subtracted from QUIC, which makes it more accurate.

Similarly, there is a SACK option in TCP, which is used to record the range of some unacknowledged data during transmission to facilitate subsequent directional retransmission of multiple groups of lost data instead of all, so more range facilitates more options for retransmission, which also means less retransmission frequency. However, TCP supports up to 3 SACK ranges, while QUIC can support 255s.

Multiplexing without head-of-line blocking

Students who are familiar with HTTP2.0 should know that if you access the same server in 2.0, there will be only one TCP connection, and all requests will go through this connection:

Each request is called Stream in Connection, and there can be multiple Stream in a Connection. The problem here is that the packet in TCP is timed. If a Stream loses a packet, it will also affect other Stream. In more serious cases, multiplexing is not as good as multiple links in HTTP1.1.

In QUIC, because the underlying UDP,UDP does not need to guarantee the timing of the packet, it will only reorganize the packet when it is received, so this problem does not exist. This is why Google proposes to use QUIC in HTTP3.

Better flow control

It is said above that QUIC is multiplexed, and flow control can be carried out for both Stream and Connection in QUIC.

The flow control of QUIC is a little different from that of TCP. In order to ensure reliability, the length of the left side of the window sliding to the right depends on the number of bytes that have been confirmed. If packet loss occurs in the middle, even if a Segment with a larger sequence number is received, the window cannot exceed this sequence number.

However, QUIC is different, even if some packet did not receive it before, its sliding only depends on the maximum number of offset bytes received.

The most important thing is that we can configure dynamically, when there is insufficient memory or upstream processing performance problems, we can limit the transmission rate through flow control to ensure service availability.

Connection migration

Nowadays, it is a common thing to switch between mobile traffic and wifi on the mobile phone. The ip address will change every time. If it is TCP, the connection will be interrupted and the link will be re-established.

In QUIC, it is no longer identified by IP and port quad, but by a 64-bit random number as ID. In this way, connections can be reused without re-establishing new connections.

Thank you for reading, the above is the content of "video interview transmission protocol is TCP or UDP". After the study of this article, I believe you have a deeper understanding of whether the video interview transmission protocol is TCP or UDP, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.