Two TCP flow control problems

Two basic questions , It can be used as an interview topic ：

1. TCP window scale What's the biggest ？ Why? ？
2. TCP Does a single stream have an upper throughput limit ？ If there is , What is it? ？ without , Why? ？

The first question is , If the answer is 14 , That must be very familiar with the logo ,rfc1323 TCP WINDOW SCALE OPTION This section is devoted to .

Why 14 ？

It is necessary to identify whether one serial number is in front or behind another , The window must not be larger than half 2^32 byte , The maximum value is 2^31 byte , That is to say 2 GB, The reasons are as follows ：

b and b‘ Respectively and a What is the relationship of ,before,or after ？

Take a semicircle arc , An endpoint is placed on a ：

• If b In order to a In a semicircular arc clockwise from the starting point , that before(a, b) It's true .
• If b In order to a In a semicircular arc counterclockwise from the starting point , that after(a,b) It's true .

Considering the timing synchronization between the sender and the receiver , Maximum window fetch 2^30 byte .

TCP Window fields 16bits , namely 2^16, solve equations 2^16 * 2^x = 2^30,x That is to say 14. This is the answer to the first question .

The second question ？ A pit .

If you answer the first question , The second question is easy to fall into the pit .

Since the maximum window size is 2^30, inference BDP Maximum 1 GB, With 100Gbps Link as an example .

100 Gbps = 12.5 GBps,1 GB Of BDP, Can support the largest RTT by 1 GB / 12.5 GBps = 0.08 s = 80 ms. namely 80 ms Of RTT yes 100Gbps The upper limit of the network card .

It follows that , Link bandwidth and RTT Calculation ,TCP The fixed upper limit of the window means that there is a transmission upper limit for any connection .
Is that true ？

The problem is “ The biggest window 1 GB signify DBP by 1 GB”. There is no indicator limit “ The largest window is the largest BDP”. At least there is no such limit in theory .

It's still an old problem , If application receives fast enough , If the receiving rate is greater than or equal to the rate of the network card at the sending end ,TCP Can handle any bandwidth .

Reiterated ,TCP The transmission bandwidth should not be limited by windows , A window is a quantity , Bandwidth is a rate that carries a time factor , If the reception is fast enough and ACK Feedback is timely enough , Even if 1 The byte window can also be filled with any large bandwidth .

1 The byte window can fill the bandwidth ？ Is it not easy to understand ？TCP Isn't transmission acceleration always in pursuit of large windows ？

in fact ,TCP The reason is not that the window is not big enough , It is ACK Not fast enough .

The most direct means of congestion control is packet conservation ,ACK One byte sends one byte ,ACK Fast enough means fast enough to send , Outside this base , Detecting idle bandwidth is an extra operation .

unfortunately TCP From the beginning, we have been controlling the quantity rather than the rate . This leads to either end-to-end flow control or congestion control , Are controlling the quantity ：

• Flow control does not consider the application read rate , cause rwnd Become a limitation .
• Congestion control does not consider link bandwidth , cause cwnd Become a limitation .

BBR To some extent, it has changed this cognition , But flow control Rate-based The implementation hasn't changed yet , But I did implement a simple version , The idea is in the following article ：
new TCP Flow control

No matter how fast the network card is bit One bit The hair , isn't it? ？ Windows are not restrictions .

So the answer to the second question is ,TCP There is no upper limit for the throughput of a single stream .

In this way , If the flow control is completely based on the rate ,Window Scale This option It is unnecessary in itself .

Of course , Ideal is one thing , Reality is another matter ,Linux TCP Not according to the above ideal , It may not change in the future ,Linux TCP Code has become a shit mountain , unbearable Rate-based Flow control has been reformed .

Yesterday afternoon, I had a special meeting with my friends TCP An accelerated discussion , Two problems are abstracted , To sum up .

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