近日,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 站点的性能并最大限度地降低用户等待的延迟时间。
评论