bigpipe 实现原理

一、什么是 bigPipe？

bigPipe 是由 facebook 提出来的一种动态网页加载技术。它将网页分解成称为 pagelets 的小块，然后分块传输到浏览器端，进行渲染。它可以有效地提升首屏渲染时间。

为了说清楚什么是 bigPipe，我先需要介绍下目前的常规渲染方式，以及可以进行优化的方向。

二、网页首屏加载方案

（1）HTTP 协议的底层是 TCP/IP，而 TCP/IP 规定三次握手才建立一次连接。每一个新增的请求都要重新建立 TCP/IP 连接，从而消耗服务器的资源，而对于几种不同的服务器程序——Apache、Nginx、Node.js——所消耗的资源也不太一样。

现有的阻塞模型

（2）如上图，现有的阻塞模型中，服务器生成页面需要时间（page generation），网络传输需要时间（network latency），页面在浏览器中渲染需要时间（page rendering），三者是阻塞式的，整个页面作为一个大块，需要完整地经历三个阶段，才能出现在浏览器中。

三、关键技术和原理

想要实现以上优化方案，可以利用现成的技术，有比较好的兼容性。

1.分段传输

bigPipe 依赖于分段传输 html 页面，所以这是实现 bigPipe 的一个基础。

http1.1

如果在 http1.1 版本上实现，那需要设置 Transfer-Encoding 为 chunked,也就是分块传输编码。

关于分块传输编码：

分块传输编码允许服务器为动态生成的内容维护 HTTP 持久连接。在这种情况下，不能使用 HTTP Content-Length 头来分隔内容和下一个 HTTP 请求/响应，因为内容大小未知。

分块编码的好处是，在返回客户端前不必生成完整的内容，因为它允许将内容作为分块进行流式处理，并明确地发出内容结尾的信号，从而使连接可用于下一个 HTTP 请求/响应。

在头部加入 Transfer-Encoding: chunked 之后，就代表这个报文采用了分块编码。这时，报文中的实体需要改为用一系列分块来传输。

每个分块包含十六进制的长度值和数据，长度值独占一行，长度不包括它结尾的 CRLF(\r\n)，也不包括分块数据结尾的 CRLF。

最后一个分块长度值必须为 0，对应的分块数据没有内容，表示实体结束。

http 2

如果你使用的是 http2，那则无需设置 Transfer-Encoding 为 chunked，因为 http2 本身就是支持这种分块传输的协议。

 

那么 BigPipe 适合什么样的场景呢？BigPipe 比较适用于页面具有明显的分块内容，且各个分块内容在后端的获取相对独立，且服务端的运算时间大于300~500ms。但具体的应用还是要根据业务以及进度来划分。