原文: http://www.stevesouders.com/blog/2010/07/13/velocity-tcp-and-the-lower-bound-of-web-performance/
John Rauser（Amazon）是我在Velocity大会上最喜欢的演讲者。他关于创建文化变迁的keynote非常好，我建议你去看这个视频。
John做了另外一个更长更技术性的报告――”TCP与低带宽网络的性能“。但是不幸的是没有安排在录像室进行。但是昨天Mike Bailey联系我说他已经将这个报告记录下来了。经过John的允许后，Mike已经将该视频上传于他的Blog上（链接请点击）。
John以从东岸到西岸的往返路程的延迟作为报告的开头：
从西岸到东岸的折返距离是7400公里光在真空中传播的速度是299,792.458 公里/秒那么理论上最小的往返延迟时间是25毫秒 （译注： 24.68毫秒）但是由于光实际上并不是在真空中传播，而是在玻璃光纤中传播玻璃的折射率是1.5 ， 这样就意味着光在玻璃光纤中传播的速度是在真空中传播速度的三分之二也就是说实际的折返时间大约是37毫秒使用一个思科的Linksys无线路由器和康卡斯特的电缆连接，这个往返的时间大约是90毫秒。考虑到其他因素的影响，这个时间并不是很差。（译注：John在自己家里通过ping来测试这个时间）
问题是这样的情况已经10多年了，1996年Stuart Cheshire描述了类似的延迟情况。在开发响应式的web应用时，了解网络延迟的情况是非常重要的。
在这个背景下，John进入TCP历史的描述并引领我们到目前的网络延迟状态。互联网诞生于1981年9月，其标志是RFC 793的传输控制协议（Transmission Control Protocol），就是我们现在所说的TCP协议。
当任何主机传输的往返时间都超过最大的重传间隔时间，该主机会产生许多的相同数据包发送到网络中。这样会导致网络的情况变得严峻。最终所有的交换节点间的可用缓冲区将被填满，许多数据包将丢失。主机把每个数据包发送了多次，最后数个相同的副本到达了目的地，这就是拥塞崩溃。
这个状态时是稳定的，一旦达到了饱和点，如果选择要丢弃的包的算法是公平的，网络会继续以退化的状态进行操作。拥塞崩溃和病态的拥塞在ARPANET和MILNET系统中并不常见，是因为这些网络有实质性的超额容量。
在1984年，RFC896在编写的时候，网络拥有”实质性的超额容量”的情况快速被改变了。在1981年，网络上只有213个主机，但是这时主机的数目开始快速增长。在1986年10月份，网络上已经有超过5000个主机了，这时发生了第一次的一系列拥塞崩溃事件。
这种情况导致了TCP缓启动算法的发展，在RFC2581，3390和1122中有描述。这个算法的关键点是介绍了一个新的概念――阻塞窗口（congestion window， cwnd），阻塞窗口由服务器管理。基本的算法如下：
初始cwnd为3个完整的报文段对每个确认字符ACK，根据一个完整报文段增加cwndTCP缓启动算法有广泛的适应性。如下面的数据包流动图，数据包的数目开始很小并且是成倍增加的，于是可以预先避免拥塞冲突。
但是这样效率依然不够高。在某些情况下，发送了太多的确认字符ACK，于是我们在RFC813中有了ACK延迟算法。下面的图可以看到数据包数量的增长比较合理。
在引用了这么多RFC文档和确认字符ACK的图片后，John问到”为什么我们要关心这个问题？”。 John带我们回到web开发人员每天都要处理的基本问题上。
记住每个报文段的大小是1460个字节（RFC894上描述的是1500个字节，相差的40个字节用来存放的是TCP和IP协议的头部）。我们来看发送不同的有效负载需要多少轮往返路程。（以KB格式表示，红色）
John的总结是：TCP缓启动意味着网络延迟严格的限制了新链接的吞吐量。他针对这种情况给出以下的建议：
非常小心的考虑每一个字节的内容考虑什么应该放在最前面的部分数据包保持你的cookie足够小在前面的三个数据包里为有用的资源打开链接先下载小的资源接受光的速度（使内容更贴近用户）所有的Web开发人员至少都应该对他们应用程序所使用的协议有一个基本的了解。John做了一个信息丰富和吸引人的报告，如同真正的外卖店，好好享受吧。
Steve Souders
2010-7-13
（译注：本文已经得到Steve Souders的同意进行翻译，John的ppt这里）