TCP拥塞控制机制之慢启动

什么是慢启动

最初的TCP的实现方式是，在连接建立成功后便会向网络中发送大尺寸的数据包，假如网络出现问题，很多这样的大包会积攒在路由器上，很容易导致网络中路由器缓存空间耗尽，从而发生拥塞。因此现在的TCP协议规定了，新建立的连接不能够一开始就发送大尺寸的数据包，而只能从一个小尺寸的包开始发送，在发送和数据被对方确认的过程中去计算对方的接收速度，来逐步增加每次发送的数据量（最后到达一个稳定的值，进入高速传输阶段。相应的，慢启动过程中，TCP通道处在低速传输阶段），以避免上述现象的发生。这个策略就是慢启动。

慢启动导致客户端与服务器之间经过几百毫秒才能达到接近最大速度的问题，对于大型流式下载服务的影响倒不显著，因为慢启动的时间可以分摊到整个传输周期内消化掉。可是，对于很多HTTP连接，特别是一些短暂、突发的连接而言，常常会出现还没有达到最大窗口请求就被终止的情况。换句话说，很多Web应用的性能经常受到服务器与客户端之间往返时间的制约。因为慢启动限制了可用的吞吐量，而这对于小文件传输非常不利。慢启动重启除了调节新连接的传输速度，TCP还实现了SSR（Slow-StartRestart，慢启动重启）机制。

这种机制会在连接空闲一定时间后重置连接的拥塞窗口。道理很简单，在连接空闲的同时，网络状况也可能发生了变化，为了避免拥塞，理应将拥塞窗口重置回“安全的”默认值。毫无疑问，SSR对于那些会出现突发空闲的长周期TCP连接（比如HTTP的keep-alive连接）有很大的影响。因此，我们建议在服务器上禁用SSR。在Linux平台，可以通过如下命令来检查和禁用SSR：

$>sysctlnet.ipv4.tcp_slow_start_after_idle
$>sysctl-wnet.ipv4.tcp_slow_start_after_idle=0

为演示三次握手和慢启动对简单HTTP传输的影响，我们假设纽约的客户端需要通过TCP连接向伦敦的服务器请求一个20KB的文件，下面列出了连接的参数。

•往返时间：56ms。

•客户端到服务器的带宽：5Mbit/s。

•客户端和服务器接收窗口：65535字节。

•初始的拥塞窗口：4段（4×1460字节≈5.7KB）。

•服务器生成响应的处理时间：40ms。

•没有分组丢失、每个分组都要确认、GET请求只占1段。

•0ms：客户端发送SYN分组开始TCP握手。

•28ms：服务器响应SYN-ACK并指定其rwnd大小。

•56ms：客户端确认SYN-ACK，指定其rwnd大小，并立即发送HTTPGET请求。

•84ms：服务器收到HTTP请求。

•124ms：服务器生成20KB的响应，并发送4个TCP段（初始cwnd大小为4），然后等待ACK。

•152ms：客户端收到4个段，并分别发送ACK确认。

•180ms：服务器针对每个ACK递增cwnd，然后发送8个TCP段。

•208ms：客户端接收8个段，并分别发送ACK确认。

•236ms：服务器针对每个ACK递增cwnd，然后发送剩余的TCP段。

•264ms：客户端收到剩余的TCP段，并分别发送ACK确认。

大家可以练习一下，如果将cwnd值设置为10个TCP段，那么图2-5所示的过程将减少一次往返，性能可以提升22%！通过新TCP连接在往返时间为56ms的客户端与服务器间传输一个20KB的文件需要264ms！作为对比，现在假设客户端可以重用同一个TCP连接（图2-6），再发送一次相同的请求。

•0ms：客户端发送HTTP请求。

•28ms：服务器收到HTTP请求。

•68ms：服务器生成20KB响应，但cwnd已经大于发送文件所需的15段了，因此一次性发送所有数据段。

•96ms：客户端收到所有15个段，分别发送ACK确认。

同一个连接、同样的请求，但没有三次握手和慢启动，只花了96ms，性能提升幅度达275%！

以上两种情况下，服务器和客户端之间的5Mbit/s带宽并不影响TCP连接的启动阶段。此时，延迟和拥塞窗口大小才是限制因素。事实上，如果增大往返时间，第一次和第二次请求的性能差距只会加大。大家可以练习一下，试试不同的往返时间会有什么结果。理解了TCP拥塞控制机制后，针对keep-alive、流水线和多路复用的优化就简单得多了。

增大TCP的初始拥塞窗口。把服务器的初始cwnd值增大到RFC6928新规定的10段（IW10），是提升用户体验以及所有TCP应用性能的最简单方式。好消息是，很多操作系统已经更新了内核，采用了增大后的值。可以留意相应的文档和发布说明。在Linux上，IW10是2.6.39以上版本内核的新默认值。但不要就此满足，升级到3.2以上版本还有其他重要更新。

典型案例：

问题描述：

hbase主备集群之间增量同步，主集群在上海，备集群在张北，服务器均为万兆网卡，且带宽没有达到上限；长途带宽为专线，带宽足够，不会成为瓶颈。跨长途带宽复制数据，由于数据量较大，总是有延迟。

解决方法：

将内核参数从1调整到0，禁用慢启动：

sysctl-w net.ipv4.tcp_slow_start_after_idle=0