更快的网络与TCP慢启动机制

还在纠结到哪里能找到“最好最快的”网络提供商？最近我听取并比较了十多个不同的方案之后，有人提醒了我一个简单的事实：业界采用的主要指标（带宽）实际上极具误导性。其实对于大部分网站浏览的应用来说，超过几兆的网络连接对于性能只有很小的提升。

罪魁祸首之一就是“TCP慢启动”，对，这是个功能，不是缺陷。要理解其中的原因，我们必须到TCP栈里面一探究竟，这样我们也能学到一些建立更快速网络服务的有趣的小技巧。

TCP慢启动

TCP协议提供了许多内置的功能，其中我们感兴趣的两个是拥塞控制和拥塞避免。TCP慢启动是TCP层内部实现拥塞控制的一种机制。

慢启动和其它一些算法联合使用，避免发送过多的数据以至网络无力传输，也就是防止网络拥塞。

－ wikipedia

表面上的流程很简单：客户端发送一个SYN包，它告知本端的最大缓存大小（rwnd － 接收窗口），发送端回传几个包作为应答（cwnd-拥塞窗口），之后，每次它收到来自客户端的ACK包，它就把发送包（传输中并未收到确认的）的数量加倍。

这个过程也被称作TCP连接的“指数增长”阶段。OSI学院有一个很好的动画演示这个过程：（滚动到底点击播放）。那么，这和我们有什么关系呢？不管你的带宽有多大，每一个TCP连接都要经历这个过程，这也就是说，通常情况下，实际用到的带宽受制于发送端和接收端的缓存大小的设置。

HTTP和TCP慢启动

或者，稍微换个说法，一个10M的带宽平均上只用了16％的容量。老天！这说明，如果我们要提高网速，我们应该着眼于降低客户端和服务器之间的往返时延， 而不一定要一味地花钱提高带宽。当然，当你在缓冲一个大文件的时候高带宽很有用，或者跑个速度测试也能唬唬人。问题是，基于HTTP的交互倾向于应用短 暂、突发的连接 － 在这样的情况下，我们常常无法占用信道的全部容量！Google做一个研究表明，当带宽从5M升高到10M，页面加载时间只提高了让人失望的5％。

CWND的故事

如果TCP慢 启动很慢的话，我们不能让它快一点么？其实，直到最近，Linux TCP栈本身把拥塞窗口（cwnd）的初始值硬编码为3到4个包，这也就是4kb的大小（一个包大约1360字节）。还有个频繁发生的问题，HTTP有每 获取一个资源要建立一个连接的毛病。这些加在一块，你的性能就受到了严重限制。

在 内核2.6.33版本里，经过了长期讨论和提交很多的IETF修改建议之后，cwnd的初始值被设为10个包。这本身就是一个很大的进步。但是有个问题， 猜猜现在大部分服务器跑的是什么版本的内核？没错，也许现在是时候更新你的服务器了。给你个实用的小提示，如果你考虑你的网络服务开始使用SPDY，那么 如果不在最近的几个内核上面跑，你实际上不会得到任何的性能提升！TCP栈的一个小小的改动在全局能产生巨大的变化。

那么我该怎么办？

TCP慢 启动是一个功能，不是缺陷，而且它的确包含有趣而重大的意义。作为开发者，我们经常会忽视客户端到服务器的往返时延，但是如果如果我们真有志于建立更快的 网站，现在该去研究一下这些选择了：在和网络服务通信的时候重用TCP连接，建立支持HTTP keep-alive和流水线的网络应用，重视端到端的时延。噢，还有，别在高于10兆的宽带上浪费钱了，可能你根本就不需要。