Facebook 创新之 BigPipe：优化页面加载时间

近日，Facebook 的研究科学家 Changhao Jiang 介绍了一个名为 BigPipe 的技术，这项技术可使 Facebook 站点的访问速度提升一倍。BigPipe 是 Facebook 的创新研究之一，同时也是 Facebook 的“秘密武器”，它能够极大提升站点的性能：在大多数浏览器中，BigPipe 都能将用户感受到的延迟时间降低一半，除了 Firefox 3.6，BigPipe 可以将 Firefox 3.6 的延迟时间降低 50ms 左右，大约降低了 22% 左右。

BigPipe 及相关创新的驱动力是：

相比于 10 年前，现代 Web 站点的动态性与交互性都迈上了一个新台阶，传统的页面处理模型已经无法满足当今 Internet 速度上的需求了。

受到硬件的启发（管道与标量微处理器），Facebook 团队使用 PHP 和 JavaScript（并不需要改变现有的 Web 服务器和浏览器）“重新设计了现有的 Web 服务处理过程”。重新设计的内容包括：将页面处理过程分解为 8 个不同的步骤（每个步骤叫做一个“pagelet”），其中一些步骤可以并行处理。通过返回如下内容来响应最初的页面请求：

一个未闭合的 HTML 文档，包含了 HTML head 标签和 body 标签的第一部分内容。head 标签包含了 BigPipe 的 JavaScript 库，用于解释稍后收到的 pagelet 响应内容。在 body 标签中，有个模板指定了页面的逻辑结构和 pagelets 的占位符。

然后创建 JSON 编码的对象（即 pagelets），里面包含了“pagelet 需要的所有 CSS、JavaScript 资源、HTML 内容以及一些元数据”。

复杂网页不断攀升的加载时间延迟问题已经不是什么新话题了，也有不少人提出使用某种管道技术来提升性能。Aaron Hopkins 在 Die.net 上讨论过如何优化页面加载时间，除了传统的页面请求生命周期外，还有不少影响因素可以影响到页面加载的延迟时间。Aaron 提到的有趣儿的一点是：

IE、Firefox 与 Safari 默认情况下是禁用管道的；Opera 是我所知道的唯一一个启用了管道的浏览器。禁用管道意味着需要应答每个请求，在下一个请求发出前需要释放掉上一个请求所建立的连接。这样就增加了用户等待的延迟时间，平均延迟时间为双向的 ping 时间除以允许的连接数。如果服务器禁用了 HTTP 持续连接（keepalives），那么还需要再进行一次 TCP 三次握手，这又导致一次双向连接，造成延迟时间加倍的后果。

Jiang 并没有说 BigPipe 利用了浏览器所固有的管道功能，实际上却暗示了 BigPipe 并没有这么做，因为他说不需要对现有的服务器与浏览器进行任何改变。一旦浏览器发生了变化（比如 HTML 5 的广泛实现），BigPipe 创新的用途是否还会这么大，我们不得而知。

Kensaku Komatsu 创建了一个示例（ The Zinger 谈到了该示例）：

… 对 HTML5 Web Sockets 中的数据流与 XML HTTP Request 进行了对比。运行结果令人震惊：565 毫秒对 31444 毫秒，天哪！Web Sockets 快了 55 倍，这是因为 Web Sockets 减少了大量不必要的 header 信息。

该示例使用了 HTTP Pipelining，但通常人们认为这么做有些“危险”：

这并非 HTTP Pipelining。网络传输是由 WebSocket frames 构成的，而非 HTTP 请求与响应。显然，这是由应用作者控制的，并不会遇到 HTTP/1.1 管道的问题。由于 WebSockets 可以在任何时间发送与接收，可以由程序员直接控制，因此它并不会遇到代理干扰（proxy interference）的问题，管道功能是安全的，不应该禁用。

Komatsu 的示例将 Facebook 的创新、HTTP 管道问题以及 HTML 5 的未来有机联系在了一起，尤其是 WebSockets 以及他们最终该如何交互以提升 Web 站点的性能并最大限度地降低用户等待的延迟时间。

查看英文原文： BigPipe at Facebook: Optimizing Page Load Time