web业务尽快升级到centos 6.4的理由

   最近看到centos 6.4网络底层变化了不少的东西，建议做web业务的，尤其是做CDN业务系统建议都升级到centos 6.4的版本，下面我说说升级的理由

   在这里我主要说明一下，centos 6.4的内核层面针对tcp协议优化了哪些东西，主要的还是google的几个补丁。

   1. tcp: RFC2988bis + taking RTT sample from 3WHS for the passive open side

   我们都知道对于tcp在3次握手过程中，如果网络比较差，出现syn包丢失，再发生一个syn包请求时间默认为3秒，这个时候整个请求的响应时间将大于3秒，而中国这样的电信，网通，小运营商互联之差，出现丢包是很正常的一个事情，6.4的内核当中增加了一个RFC2988bis的补丁，使得RTO(retransmission time out)重试时间由默认的3秒变成了1秒。

   2.Initcwnd

   对于一个正常的tcp协议的经过的三次握手到接收数据包大概是这样一个图形的的过程

   a.浏览器发送一个请求给服务器端，在三次握手的时候客户端发送syn包时告知服务器端，我的接收窗口大小为65535字节

   b.服务器端确认这个数据包，并告知客户端我的接收窗口大小为4236字节

   c.这个时候客户端请求一个url

   d.由于默认的内核初始的拥塞控制窗口为3，那么服务器端发送3个数据包给客户端，发送的数据包大小为4之4.3 kb (3个最大传输单元mss)

   e.客户端确认服务器端发送的数据

   f.服务器端发送剩余的数据包

   在这个交互的过程中，我们看到由于默认的拥塞控制是3，每次第一次发送只能发送4到4.3k大小的数据，对于web业务这种短连接来说，滑动窗口还没有达到最大，连接就结束了，如果我们稍微的调整慢启动的拥塞控制窗口的大小，就可以减少tcp交互的过程，另外，由于tcp每次发送数据，客户端确认后才能再次发送，确认时间依赖于网络的延迟，对于网络延迟不是很好的情况，减少确认的次数，就大大的减少了，web页面拉取的速度，但是它也有缺点，就是当传输过程中，出现丢包，那么重传的数据就大。

   那么怎么开启它，内核是通过iproute进行控制，一般对于单路由的机器，直接执行这条命令就OK了

ip route change default via xxx.xxx.xxx.xxx dev eth0 initcwnd 10

   确认路由信息

ip route show

   对于多路由机器,用iproute的方式，设置多个路由表

ip route change default via xxx.xxx.xxx.xxx table tel initcwnd 10

ip route change default via xxx.xxx.xxx.xxx table cnc initcwnd 10

   确认

ip route ls table tel

   3.initrwnd

   针对上面的发送拥塞控制窗口，另外还有一个增大接收拥塞控制窗口大小提升性能的，对于cdn的机器来说，回源永远是永恒的话题，而源服务器一般选择我们控制不了，但是我们能控制我们回源的机器的接收拥塞控制窗口大小

   设置方法如下

ip route change default via xxx.xxx.xxx.xxx table tel initcwnd 10 initrwnd 10 

   确认

ip route ls table tel

   另外开启了上面的内容后，记得在内核当中关闭tcp的连接传输的慢启动

sysctl -w net.ipv4.tcp_slow_start_after_idle=0

   4.Proportional rate reduction

   Google观察到，当发生丢包时一个会话的完成时间慢了7-10倍，部分原因在于TCP当发生丢包看作是拥塞指示，从而减半其拥塞窗口(snd_cwnd)，这导致发送方必须等待一半已经发送出去的数据的确认到达之后才能继续发送新数据，这意味着发送方有一段发送时间停顿，这个行为符合RFC3517。Linux并没有完全遵守RFC3517，它使用了一种称为rate-halving的方案，这个方案不立即减少拥塞窗口，而是在之后每到达一个确认，再从拥塞窗口减少一个MSS。虽然有所改进，但这个方案也有不足之处：它没有提供及时增长拥塞窗口的方法。现在问题清晰多了：在TCP丢包时，我们减少拥塞窗口太“狠”了，Proportional rate reduction的工作方式是在发生丢包，先估算一下两个参数：仍然在网络中传输中的数据量(in_flght)、使用目前在用的拥塞控制算法计算目标拥塞窗口值(target)。如果in_flight < target，进入慢启动算法，慢启动其实不慢，它可以以指数速率增长拥塞窗口；反之，使用类似于rate-halving的方法，拥塞窗口的减少量取决于target，而不是直接减半。当遇到突发丢包时，会根据in_flight进行调整，从而使恢复更为平滑。这么做的好处呢，平均延迟降低了3%-10%，恢复超时减少了5%。这个方法已经广泛部署于Google服务器上，并可能会在3.2版本的内核中合并。详见：https://tools.ietf.org/html/draft-mathis-tcpm-proportional-rate-reduction-01