Transport protocols that have been less voluminous over the years have accelerated

Mobile Internet and 4G With the development of the Internet, the content of the Internet becomes more and more rich and easier to get , This promotes CDN, The development of live broadcasting , Almost all Internet companies that produce content face the same problem ：

• How to send the content to the user's terminal in the fastest and most effective way .

Because of almost everything ( If not all ) All the contents must pass or TCP, or UDP The bearer is delivered to the opposite end , So for content producers , The first problem is how to take some measures for these transmission control protocols , Make them perform better .

So almost all Internet companies that produce content have such jobs ：

• Transport protocol acceleration
• Transmission protocol optimization
• TCP Protocol stack acceleration
• TCP Protocol stack optimization
• QUIC…

If you don't know much about this field , You may feel that as long as you are right TCP The protocol stack implementation does something similar spinlock,hash table Optimization of search ,TCP The hosted content will reach the opposite end faster . It will be a few microseconds faster , But in fact, transport protocol optimization does not pay attention to these .

Drive from Shanghai to Suzhou , Must Audi arrive before Otto ？ not necessarily . alike ,TCP It's just a car , The key to the acceleration effect depends on the road .

Take the ordinary road , Audi really doesn't have to arrive before Otto , But in the scene of bad road conditions , Audi must have arrived before Otto , This involves whether the feedback mechanism against bad conditions is excellent , For example, climbing a slope , Audi can easily cross , Because the power is enough , High torque , Alto seems to be able to show that it is almost as fast as Audi on the flat road .

With TCP Take acceleration as an example , Ability to resist weak network environment , It can more directly show the advantages and disadvantages of the algorithm . In the evaluation of TCP When accelerating the algorithm , It's meaningless to simulate a direct machine fight , Because you can't see anything unusual happening , How do these algorithms deal with , In fact, it is difficult to simulate the unexpected anomalies in the weak network environment .

TCP The general idea of acceleration is to expand the congestion window , Radical attack , I don't agree with this . How big the window can expand , It's like this CUBIC,BBR Well done , If you have to add three or five window quotas on this basis , Obviously, you have to design countermeasures for packet loss caused by this extra quota , This is obviously an adventure .

Even if you don't add additional window quotas , Packet loss is inevitable , This is caused by the nature of the pavement , It has nothing to do with the car , Packet loss may be caused by network congestion , It may be line noise and bit error , It has nothing to do with End-to-end protocols ,TCP What can be done is how to detect packet loss faster , And how to recover packet loss retransmission faster .

In the weak network environment , How to detect packet loss , How to quickly retransmit , That's what it is. TCP Optimization focus , Instead of adding a few quotas to the congestion window , Over sending . Alto can't climb the slope because it doesn't have enough oil .

In a non weak network environment ,TCP The point of acceleration is to choose a smoother road , It is still not to add a few quotas for the congestion window . Whether it is packet loss caused by natural congestion , Or packet loss caused by over sending , Retransmission is essential , Retransmission of a message requires an additional RTT Time for ,RTT The bigger it is , The more it costs , Choosing a smoother and less congested path can obviously save a lot of additional costs introduced by packet loss retransmission RTT Time .

However TCP Unable to control the choice of route . For transparent transmission of content , You can use a proxy , Segmented tunnels solve this problem . in any case , The purpose is to reduce the time consumed by packet loss retransmission .

After the problems of packet loss and retransmission are solved , For example, you already have a super fierce algorithm , Packet loss can be detected quickly , And it can quickly retransmit and recover packet loss , And have the ability to choose a smoother path , Increasing the sending quota is the thing to consider . And this is more difficult . You need an algorithm to calculate how much data you can send , The algorithm should have a theoretical basis , So we can deduce , Predictable , reproducible .

The goal of increasing the transmission quota is to improve the bandwidth utilization , Not speculation .

As an end-to-end transport protocol , Whether it's TCP, Or based on UDP Of QUIC, The things to do for acceleration are the following ：

• Design an algorithm , Find packet loss as soon as possible .Linux Kernel TCP The congestion state machine has done well enough .
• Design an algorithm , Recover the lost packet retransmission as soon as possible .Linux The retransmission mechanism in the kernel has been iteratively optimized .
• Ensure that the sending cache at the sending end is sufficient , Ensure that the receiving buffer at the receiving end is sufficient .
• Packet loss prediction , On the basis of retransmission recovery , Design an algorithm , Improve bandwidth utilization .
• stay overlay Plan a smooth path on the network , With the , Technologies such as tunneling introduce flow into the path .
• …
• Send one less bag , Can save at least one pacing slot Time for , Save up to one RTT Time for .

The last point is the core , No matter how smooth and fast transmission is, it's better not to transmit , Don't optimize things that shouldn't exist . If the application layer can cooperate to encode the data , Compress , This optimization is better than any TCP All levels of optimization should be easy to use .

Network data plane technology has been rolled up , Transport protocol acceleration has not yet . This is natural in the field anti- Agile decision .

An algorithm can't iterate quickly one version a day , You can't even do version planning at all , This field is more like an academic category .

Transport protocol optimization is difficult to achieve good performance by iterating over multiple versions , Maybe even a year may not come to a clear conclusion , This means that the field is almost difficult to adapt to the result orientation of Internet companies . A good algorithm doesn't mean long code , such as BBR The algorithm is 1200 Line code , One C file . In an inner volume environment, a person spent half a year writing only one 1200 Line code C file , What does this mean? The manager knows , Not to mention that you may not write for a year 1000 That's ok , This means very low output . This is the reason why this field is not involved .

But this field is interesting , Not many have done well , This means that it can't be rolled up in the short term , If you have any ingenious ideas, you can quickly start experimenting and testing , Don't worry about whether others' output exceeds their own , Instead, it is easier to bring about a substantive breakthrough . Like myself , I'll happily change over the weekend BBR, I also changed a version yesterday .

Yes , That's what I used to do , Although the main business is not in this field now , However, I still use the barbell principle to continue to do this , There is interest in , Welcome to the discussion , Welcome to join us . by the way , Barbell principle , Namely 《 Anti frailty 》 The barbell principle in that book .

Zhejiang Wenzhou leather shoes wet , It's not fat when it's raining .