基于TCP拥塞控制算法的现实研究与性能提升

在现有复杂的网络环境中，如果我们的产品提供网络传输功能，特别是提供点对点的大数据量网络传输服务，我们会经常收到一小部分用户的抱怨，传输不稳定而且速度慢。针对这部分环境，在排除了应用实现的代码问题之后，通过抓包分析，我们可以发现，TCP的拥塞控制实现策略对现有的低速网络，特别是上行受限的ADSL用户网络不具很好的适应性。我们把发送端标记为A，接收端标记为B, 具体如下：

A、B建立连接后，A端拥塞控制窗口cwnd=mss, 应用层向A的TCP发送缓冲区放入数据之后，A向B发送一个mss长度的TCP封装数据，B端收到并发回ACK，A端收到ACK，cwnd += mss(cwnd=2*mss)，A再次向B发送2个mss的TCP封装数据。当cwnd增大到n * mss时，A向B发送n个mss长度的TCP封装数据包，B向A确认，但是只确认了前i（i < n）个, 即是 B没有收到 i + 1 到 n个包。则由TCP的实现策略，当i >= 3时，传输将进入超时重传或快速恢复。i< 3,则只有进入超时重传。不管是进入哪个流程，都会影响到传输的效率。如果 n <= 3,则传输会频频进入超时重传流程，对于以100毫秒为基本单位的定时器实现的超时检查，每次该事件发生时，将至少浪费数百毫秒连接无利用，严重影响传输的速度。

针对这类问题，如果我们使用的是操作平台提供的TCP传输通道，我们只能通过侦测传输通道的网络状况，计算出每次发送包合适的大小，减少拥塞发生的概率。这种处理方式能够稍稍增强传输的稳定性，甚至可以提高传输速度，增强用户体验。

但是这种方式是通过控制发送数据包在一定大小实现的，对于传输定量的数据，显然是增加了send函数的系统调用，降低了程序的系能。同时也不是解决问题的根本之道，因为应用层获取TCP连接的拥塞控制窗口cwnd是不现实的，通过应用层的逻辑计算很难保证准确，从架构角度讲不应该是应用层所关心的事情。

重写tcp的实现对于一般的产品而言，是不现实的，但是不应该是阻止我们研究该问题的理由。通过前面的分析，我们知道在现实的网络环境中，有些环境下两端点之间的物理设备由于带宽以及处理能力的限制，每次发送超过2个或3个mss大小的数据包就高概率丢包，由此进入频繁的超时重传。如果可靠传输控制流程能够加入侦测机制，当发现发送超过m个mss大小的数据包时，在运行环境内就会丢包，如此设定拥塞控制窗口的一个关系值m，当达到m后，进入一个比拥塞控制流程更慢的增长过程，则系统能够大大提高传输速度。