bigpipe实现理论背景篇

分享请标明来自:https://www.css3.io/bigpipe.html

bigpipe vs 静态页面

要想网页响应速度快,其实最简单可行的方法是将它生成静态页面就好了。但是有些页面不适合生成静态页面:比如首页,或者列表页,以及那些数据在实时变化的页面。像某个产品的详情页这种就适合生成静态页面,因为数据更新不频繁。所以对于那种不适合用生成静态页面来解决的场景我们怎么办呢?maybe bigpipe能派上用场。

bigpipe 解决了什么问题

衡量一个页面的性能,其中一个重要指标,是这个页面“白屏”时间。这与yahoo的优化建议Flush the Buffer Early有相似之处。其实我们用传统的web技术就能实现这个优化,只需要让webserver先输出一部分内容,让client先渲染一部分,耗时的部分后输出。

例如:

echo "a";
sleep(1);
echo "b";

当server向client传递数据时,我们很容易让server先传字符“a”,client渲染字符“a”,过一秒后,传递“b”时,再渲染“b”。并不需要server把字符“a”、“b”都收集完后才整个传递给client端,要知道等所有数据都收集完成,这个时间是很漫长的,client会一直处于白屏,client也从来没这样要求过。在于开发者怎么优化了。

那为何还要bigpipe呢?虽然传统技术能优化这样的“白屏”时间问题。但是server能先传递字符“b”,再传递字符“a”么?显然不行。这样的话client渲染时数据“b”就在数据”a”前面了,渲染顺序就与逻辑期望的不一致了。bigpipe实现需要前后端结合,它能够灵活解决渲染顺序问题,甚至是优先级问题。

http0.9 vs http1.0 vs http1.1

0.9只支持get请求,1.0相比0.9多了post请求,1.1相比1.0没太多本质上的改变。http最开始是不支持长连接的。从1.0开始,加入了

Connection: keep-alive

所以各位兄弟姐妹,请记住了这个头不是1.1提出的。现在使用的基本都是http1.1协议。除非显示加上

Connection: close

http1.1默认是长连接。

http 长连接

不是长连接时,只要server端或者client端close,两端都会知道这个连接已经断开了,需要数据通信时,再重新建立连接。但是长连接就不一样了,不能close。那两端总不能傻等着吧?要知道,如果不再需要数据传递,就应该把连接标示为空闲,因为长连接,这个连接要被其它需要数据通信的程序复用,传递其它数据。于是乎长连接下,增加了两个头

Content-Length 和 Transfer-Encoding: chunked

这两种方式都可以标识不再需要数据传递,这个连接可以放到空闲池,以备它用。

http1.0 在长连接时,必须要加

Content-Length

非长连接,直接close掉就行了。

http1.1长连接时,可以用

Content-Length 或 Transfer-Encoding: chunked

其中一个。两个同时使用时,Transfer-Encoding: chunked 优先级高。

Content-Length vs Transfer-Encoding: chunked

当传递数据大小固定时,比如静态资源,一般使用Content-Length,因为静态资源大小很容易获得。

当数据是动态,又急需要将部分数据返回给客户端时,举个例子:

比如ui层需要返回一个页面数据,这个页面数据由三块构成,每块数据源都是call远程服务而获得。这个时候可以等三块数据都ready了,然后计算个总的大小用content-length。但这种白屏时间就比较久,不是一个很好的方案。此时就可以用Transfer-Encoding: chunked。每当有一块ready了,就传输给client端,让它渲染(假设渲染效果没有顺序要求)。

现在基本所有文档类型为text\/html的资源在http1.1下都是使用Transfer-Encoding: chunked。可以看看百度首页,任意其它页面。

这两种方式具体使用可以参考:

https:\/\/imququ.com\/post\/transfer-encoding-header-in-http.html

bigpipe 与 Transfer-Encoding: chunked 什么关系,http0.9能实现bigpipe吗?

现在使用http协议基本都是长连接。那么在长连接下只能使用

Content-Length 或 Transfer-Encoding: chunked


Content-Length 显然不适合使用。因为server不能一开始就知道整个需要传递的页面的总大小。所以只能是使用

Transfer-Encoding: chunked

但是如果不考虑长连接,bigpipe是照样可以在http1.0甚至是http0.9使用的。假设我们把content-length设置为一个非常大的值,我们就可以做到webserver分段输出,到webserver不需要传递数据时,直接关闭连接就好了。

var a = "xxxxxxxx" // 多点数据,因为浏览器有buffer,多于1024个字符。
var c = "123456789";
require('net').createServer(function(sock) {            
    sock.on('data', function(data) { 
        sock.write('HTTP/1.1 200 OK\r\n'); 
        sock.write('Content-Length: 999999999999999\r\n');
        sock.write('\r\n'); 
        sock.write(a); 
        setInterval(function (){ 
            sock.write(c); 
        }, 3000);
    });
}).listen(9090, '127.0.0.1');

然后ctrl+c结束webserver进程,表示close流。
结论:bigpipe只依赖于webserver和client是否有处理分段输出内容的能力,而两种消息头都可以实现。

注意

bigpipe测试时有很多缓存控制。比如nginx,或者webserver的,浏览器也有1024字符。比如你有两个字符片段,想通过两次数据传递,或者想看到的效果是paint两次显示出来,但是各个环节有作优化,先buffer起来,再一起传递或渲染。

参考

yahoo:Best Practices for Speeding Up Your Web Site
https:\/\/developer.yahoo.com\/performance\/rules.html

http:\/\/www.cnblogs.com\/xpress\/archive\/2011\/07\/21\/2112382.html

http:\/\/www.cnblogs.com\/CareySon\/archive\/2012\/04\/27\/HTTP-Protocol.html

http:\/\/www.kafsemo.org\/2015\/01\/03_talking-HTTP-0.9,1.0,1.1.html

http:\/\/stackoverflow.com\/questions\/10723812\/if-a-http-1-0-client-requests-connection-keep-alive-will-it-understand-chunked

https:\/\/www.byvoid.com\/blog\/http-keep-alive-header 翻墙打开

https:\/\/tools.ietf.org\/html\/rfc2068#section-19.7.1

https:\/\/www.w3.org\/Protocols\/HTTP\/1.0\/spec.html#Augmented-BNF

https:\/\/www.w3.org\/Protocols\/rfc2616\/rfc2616.html#Augmented-BNF

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值