fast tcp

tcp拥塞控制

tcp提供可靠的数据传输，也就意味着tcp的接收端接收到的数据即没有丢失（如果丢失，发送端会重传，直到接收端确认收到），也不会乱序。这个目标是通过发送端和接收端配合实现的。我们总是希望快速的发送包以提高网络传输速率，但是发送方发包速度受两个方面的限制。

1. 接收方的缓存区大小。

2. 网络链路的承载能力。

第一个问题通过滑动窗口协议来控制。第二个通过拥塞窗口来控制。在任意时刻发送方可以发送的数据是 

min(滑动窗口大小，拥塞窗口大小)。

第一个问题目前已经不是大问题，因为接收方的缓存一般都足够大了，接收端的处理速度一般总是大于发送速度。第二个问题是由于传输链路的瓶颈导致的，虽然接收方可以接收64k的数据，但是中间的物理链路并非能够承载，路由器会丢掉它处理不过来的包，导致重传，激进的发包是火上浇油。为了控制发送速度，tcp引入拥塞窗口的控制。每个tcp连接都有一个拥塞窗口cwnd，cwnd设置多大合理是个问题，因为：

1. 带宽大小无法事先知道。

2. 带宽是动态变化的。

reno算法

1. 连接从尝试建立的时候起即为慢启动阶段，这个阶段接收方每确认一个包的接收，cwnd++。这是一个随时间指数增长的方式。因为如果发送4个包，那么在一个rtt内，这4个包将被确认，cwnd会自增4次变长8。

2. 如果传输过程中出现超时 cwnd = 1，依然是慢启动阶段。如果出现重复确认 cwnd = cwnd / 2，然后进入拥塞避免阶段。

3. 拥塞避免阶段，接收方每收到一个包的确定，cwnd = cwnd + 1/cwnd。这是一个随时间线性增长的方式。

这里我们忽略了很多细节，并对算法做了简化，精确的算法见<<>tcp/ip详解>。但从这个简化版本可以看到，reno在一开始会通过指数增加cwnd窗口的方式来探测链路的带宽，一旦出现丢包，即cwnd减半，然后继续线性增长cwnd。

这种拥塞控制的算法的特点如下：

1.  在连接刚建立的时候，总是通过指数增加cwnd来摸索网络的最高承载能力。

2.  一旦出现丢包，那么cwnd 减半，并线性增长。

3.  reno从来不知道网络带宽的真正承载能力，总是在丢包，cwnd减半，然后线性增加cwnd，然后再丢包间来回震荡。reno对带宽的利用率不高，并且不稳定。

在超高速网络中还呈现以下特点：

1. 线性增长cwnd太慢，比如1G的光纤，cwnd可以达到 100M, 假如当前cwnd为50M，那么增长到100M需要大约12800个RTT，如果一个rtt是10ms, 那么需要128s才能达到1G。在在128s中，网络带宽浪费了很多。

2. 在128s的增长过程中，如果再出现丢包（这么长时间谁能保证不出个小意外），cwnd会下降到50M以下。

fast tcp 算法

fast tcp 算法尝试找到链路的真实带宽，然后调整cwnd窗口接近于真实带宽，避免丢包的发生。fast tcp 利用排队时延来估计链路的带宽。

排队时延

这是一个传输模型，假如路由器不忙，那么一个包从发送者到接收者之间的时间就是网络带宽能达到的极限。如果发送者发送过快，路由器处理不过来，数据包在路由器里排队，那么一个数据包从发送者到达接收者必然经历更长的时间。数据包在路由器里排队的时间即为排队时延。fast 算法即基于排队时延来感知网络的带宽，最终做出调整。

算法

fast tcp 周期性的更新cwnd的窗口。

cwnd = cwnd * （baseRTT/RTT） + a

baseRTT是目前为止测量到的最短的RTT， RTT为最近测量的RTT，a为一个增长常数，不同的网络采用不同的值，他的物理意义是在路由器你排队的数据包的个数。

这个算法的特点：

1. 他是个线性增长函数，cwnd的增长比指数增长要慢，比reno的线性增长要快，reno的增长系数是1，他是a.

2. 在增长到接近链路的极限后，他会停止增长，并且小范围波动。

3. 正式因为他的线性增长特性，在带宽很高的网络中，他的启动太慢，还不如reno。

FastStart

为了解决启动慢的问题，fast tcp还有一个快速启动的算法 faststart，但是这个算法没有找到公开的文档。其实可以参照cubic的解决方法。

HyperBurst

回到最初的公式

可以发送的包 = min(滑动窗口大小，拥塞窗口大小)。

当拥塞窗口控制的很好的时候，滑动窗口的大小就将成为瓶颈，尤其是在高速网络中，拥塞窗口如果是1M，但是接收方的接收能力有限，比如一次只能接收64k，发送方也无法一次发送1M的数据。为了解决这个问题， fast tcp还有一个在接收方的算法HyperBurst，用来动态的调整滑动窗口，以提高传输效率。

目前的win7也有动态调整滑动窗口的算法。

总结

fast tcp 的优点

1. 在长肥管道中优于reno。但目前绝大多数linux配置的已经是优化后的cubic。与cubic相比，优势缩小了。

2. 在非长肥管道中，fast tcp 并无任何优势。

缺点

1.  算法并未完全公开。公开的算法无法解决启动慢的问题。

2.  已经商业化，需要付费。

3.  需要修改内核，部署困难，风险难料。

4.  适用范围有限，只有在特殊的场景中优化效果明显。