【TCP—慢启动、ssthresh、拥塞避免、公平性的真实含义】本文主要阐述TCP拥塞控制中s_傻大方

按关键词阅读：

本文主要阐述TCP拥塞控制中ssthresh的来历以及为什么拥塞避免探测到丢包的时候， ssthresh会被设置为当前窗口的一半。什么是ssthresh？它的值有什么讲究，几乎所有的资料都说，如果窗口大于ssthresh ，那么就执行线性增窗的拥塞避免阶段，否则执行慢启动...这让几乎所有人记住了这个结论，并且在长期被洗涤之后，很多人对这个不知所以然的事实却表现的不以为然，其实也包括我自己。因此当我明白了ssthresh到底是怎么一回事的时候，当我知道了丢包后ssthresh的1/2系数与公平性之间的关系的时候，我便迫不及待地想把这些东西分享出来！
TCP数据段填满端节点之间的网络假设端系统A和B之间在进行TCP通信，那么只要A和B之间存在空间距离，由于光速的传播时延，一定意味着A和B之间存在一定的容量，可以容纳若干的数据段，你可以将其想做是一般的缓存，另外，为了更具普遍性，我们认为A和B之间的所有路由器，交换机等中间节点的队列缓存，也包含在A和B的网络缓存之中。如下图所示：
TCP—慢启动、ssthresh、拥塞避免、公平性的真实含义文章插图
为了达到最高的网络利用率，我们希望A和B之间的缓存(包括节点队列以及网络本身)中完全充盈着TCP的数据段，并且是持续维持。
TCP数据段无间隙地持续流动如上图所示，当A ， B之间的网络被填满时， A和B之间一共有N个数据段，发送端还可以继续发送数据吗？事实上是可以的，因为在网络被填满之后，发送端每发送一个数据段，接收端同时也会消费掉一个数据段，同时发出一个ACK ，直到填满A ， B间网络的那个数据段的ACK到达发送端为止，依照假定， ACK的速率和数据段的速率一致，我们算一下，发送端一共可以持续发送2*N个数据段，这2*N个数据段发送的开始时间点是第1个数据段发送的时间，结束时间点是第一个数据段的ACK回到发送端的时间，正好是一个RTT ，设发送速率为r ，那么以下的等式显而易见： 2*N = r*RTT过程如下图所示：
TCP—慢启动、ssthresh、拥塞避免、公平性的真实含义文章插图
我们还可以看到，前N个段是为了填满A ， B之间的网络，后N个段是在“A ， B之间已经满载的情况下”TCP的ACK clock驱动的pacing 。紧随着这2*N个数据段的是一个新的周期，又是一个RTT内2*N个数据段，这就是理想情况下的情景，数据段充盈着网络，不间断地源源不断从发送端发出， ACK亦不间断地从接收端返回。
需要C/C++ Linux服务器架构师学习资料私信“资料”（资料包括C/C++ ， Linux ， golang技术， Nginx ， ZeroMQ ， MySQL ， Redis ， fastdfs ， MongoDB ， ZK ，流媒体， CDN ， P2P ， K8S ， Docker ， TCP/IP ，协程， DPDK ， ffmpeg等），免费分享
TCP—慢启动、ssthresh、拥塞避免、公平性的真实含义文章插图
两个区域(safe--tt-darkmode-color: #999999;">dangerous区域：
文章插图
我们来比对一下窗口在这两个区域时的特性，如果说安全区域的目标是填满网络的话，那么在安全区域我们已知的是网络并未被填满，此时只要有ACK到来就可以增窗，直到网络被填满，现在我们来看危险区域，此时我们已知的事实是网络已经满了，我们希望让它继续满下去，能满则保持，提高网络的利用率，我们知道TCP的发送窗口(即可以发送多少数据)是ACK驱动的， ACK就像时钟一样，我们希望数据可以持续发送以保持网络满载，就要保证ACK源源不断地到来，因此在这个阶段继续发送数据的目标仅仅是为了消除ACK时钟的空白期，或者称作停摆期，因为只有这样，源源不断的ACK才能驱动数据源源不断地被发送。回过头来再看一下增窗过程图的t20这个时间点，网络被4 ， 5 ， 6 ， 7这四个数据包已经充满，但是在下一个时刻t21 ，随着4被接收，由于没有到达的ACK ，网络被清空了1个MSS ，理论上，我们知道最终的窗口肯定就是2*N ，此例中， N就是4 ，在例子中，最终也确实窗口增加到了8 ，然而在现实中，拥塞随时都会发生，也就是说在窗口从4增加到8的期间，随时会发生丢包，这也就意味着窗口可能永远都增加不到8！那么我们怎么可以知道当前的窗口是合理的，然后尝试继续增加窗口呢？答案就是前一个窗口的数据全部被确认！这就是拥塞避免的由来，这个过程很慢，并不是设计的问题，而是它必须这么慢。拥塞避免这个名字非常好，确实在避免！理解了上面的描述，我们可以给出TCP管道的概念了，然后所有的真相就大白了。