Google 将在今年 12 月的 ACM CoNEXT 会议上发表他们在改善 Web 应用响应时延方面的一个工作，通过修改 TCP 协议利用三次握手时进行数据交换的“TCP Fast Open”。虽然 paper 是两天前才释出，但相关的 RFC 草案则早在 2011 年 3 月份就提交到了 IETF，并且在两周前进行了一次 UPDATE，这里是 DIFF。

    对于 TCP Fast Open 方案的内容，淘宝的一个朋友已经根据 RFC 草案进行了解读。我就不再赘述，感兴趣的朋友可以去看 paper 或者 RFC。我这里只是想讨论一下这个东西的应用前景。

    由于对背景并没有做深入了解，我相信已经有很多人尝试去做过类似的工作，但我想类似的工作应该没有得到过大规模的应用。对于已经成型很久很久的 TCP 协议，让人很难有修改它的欲望，因为改那么底层的东西意味着很多很多的麻烦。

    但是是否愿意付出代价，有一个前提是有没有足够的好处。TFO 给出的好处是：在 RTT (Round Trip Time) 比较低时，客户端页面加载时间优化大约在 4%~5%；RTT 越长，好处越大，平均大约在 25%。

Google TCP Fast Open Evaluation

    除了页面加载变快改善了用户体验之外，TFO 给服务器端也带来了一些好处。由于每个请求都节省了一个 RTT，相应地也减少了服务器端的 CPU 消耗。paper 中给出的数据是每秒事务数由 2876.4 上升到 3548.7。

    虽然 paper 中大部分时间在强调 TFO 对 web 页面加载的显著加速作用，但我认为即使 TFO 能成为互联网标准，它目前的状态离成为标准还有很长一段距离，因而在短期内它是无法影响到主流互联网世界的。但这并不意味着它没有机会，依小弟的愚见，目前它的推广应用可能有两个方向：

    1. 移动互联网。移动互联网的 RTT 目前远大于传统互联网(常理推测，需数据支撑)，因而一个 RTT 节省的效果无法被忽视；另外移动互联网终端操作系统多样化，不像桌面终端系统那么单一。 Google 自己就掌握着其中一个很重要的 android，百度也计划推出自己的“易平台”。这些互联网公司有动力去改善移动用户访问自身网站的用户体验。

    2. 互联网企业数据中心。虽然数据中心内部访问时延很低，但对于典型的请求/响应的服务而言，减少一次 RTT 带来的好处还是有吸引力的，最起码能减少计算能力浪费和增加吞吐吧。再加上很多企业内部使用的都是定制的开源操作系统和定制的网络库，升级的代价并不是那么高。如果我是企业基础设施的负责人，我想我会很慎重地考虑这个方案的。...

建议继续学习：

1. TCP 的那些事儿（上）    (阅读：21562)
2. 浅谈TCP优化    (阅读：9789)
3. 查看 Apache并发请求数及其TCP连接状态    (阅读：8494)
4. 计算机网络协议包头赏析-TCP    (阅读：6458)
5. TCP链接主动关闭不发fin包奇怪行为分析    (阅读：5545)
6. 有关TCP Flag    (阅读：5441)
7. TCP 的那些事儿（下）    (阅读：5438)
8. TCP之close_wait    (阅读：5120)
9. TCP keep-alive & connection pool    (阅读：4833)
10. TCP洪水攻击（SYN Flood）的诊断和处理    (阅读：4438)