关于网络控制协议之中的慢启动。

在多数的网络控制协议之中，都存在一种名为 “慢启动 ssthresh” 的机制，它的目的是尽可能的让链接利用网络链路可以承受的最大吞吐宽频能效。

举例：

在没有慢启动的机制情况下，假设RTT为100MS，窗口为64KB，即最好的情况下，宽频吞吐能效为：640 KB。

那么当我们的带宽为1000Mbps 的时，64KB窗口即便RTT延迟很低也很难做到带宽利用最大化。

假设1MS的RTT，那么相当于一秒钟可以做工1000次，则约为 64,000KB，大约 600Mbps 带宽利用率，但现实网络环境之中，这很不现实的。

为了提高带宽的利用率，我可以直接把窗口大小跟带宽总大小、RTT时间之间进行计算，得出理想之中最佳的窗口大小，但这很不科学，因为没有考虑网络的动态拥塞问题。

故此，在多数的网络控制协议之中，都引入慢启动机制来解决这个问题，不同的控制协议对于慢启动的实现都有很大的差异，毕竟应用侧重面是不同的。

慢启动存在一个致命的缺点是，当双方RTT过大时，启速是很慢的，因为慢启动需要往返RTT确认来逐步的提高窗口的大小，但这个时间，或许会过于漫长，而定向提前计算出来的窗口大小却不会存在这样的困扰，启速就非常接近最大链路宽频利用率了。

比如：

在TCP协议中，对于慢启动的增加条件为：

增加的窗口大小 = 发送端已确认发送的段字节大小

在KCP协议之中，对于慢启动的增加条件为：

增加的窗口大小 = 发送端已确认发送的帧数量

在一些专业游戏加速器协议之中，对于慢启动的增加条件为：

A：增加的窗口大小 = 发送端已确认发送的帧数量 * 帧分片大小

B：增加的窗口大小 = 发送端已确认发送的字节数

但人们需要注意；

这取决于控制协议的具体实现及设计。

举例：

若控制协议每个不同FLAGS的控制帧都背负WND（发送端的接收窗口大小），那么在慢启动的时增加的窗口大小为：

增加发送端的 “接收窗口大小”，而不是增加 “发送端的发送窗口大小”，因为对端发送过来的每个不同类型的 FLAGS 帧都会覆盖更新 “接收端的发送窗口大小”。

注意：

发送端跟接收端只是形式上的区别，如果接收端收到发送端的PUSH/ACK，处理了背负段数据的入队，并且覆盖了发送窗口的大小，不可以忽略传递过来的WND的大小，否则会引发网络拥塞的问题。

那么在PUSH背负的ACK积累确认后，可能改变当前接收端的发送窗口大小（因为慢启动，在未达到最大阈值之前），但这没有意义。

举例：

假设对端窗口一直投递为64KB，那么接收端因为慢启动增加的发送窗口大小是没有意义的，这只会超过对端的接收窗口最大能力，导致丢包、拥塞问题的产生。

对于：

慢启动增加的窗口大小减少，根据不同的控制协议实现

但都是基于：在丢包的时候进行带宽退让的触发条件，区别不过是退让的处理方式不同。

但大体为以下两类：

1、在TCP协议中，慢启动增加的窗口退让为次方运算，每次退让一个2的次幂，即 >> 1

2、在其它协议重，慢启动增加的窗口退让可以为，每次减少重传的段大小或退让一个MSS
 

这两类各有优点，TCP慢启动窗口增加的退让形式，可能在丢包时产生略大的波动（抖动），但对于网络拥塞层度的控制比较好，节约宽频流量成本，第二类相对抖动小点，但网络宽频成本略大。

想要更大吞吐量，不想付出代价是不现实的，做任何事情，都需要付出相应的代价，这个在任何场景上面都是适用的。