HTTP/2 与 WEB 性能优化(二)

  • 时间:
  • 浏览:1
  • 来源:大发5分排列5_极速5分排列3

HTTP/1 的连接

只是,亲戚亲戚朋友提出了 HTTP 管道(HTTP Pipelining)的概念,试图把本地的 FIFO 队列挪到服务端。它的原理是事先的:浏览器一股脑把请求都发给服务端,有只是等着就时要了。事先服务端就时要在正确处理完另有另一个 请求后,马上正确处理下另有另一个 ,时会有空闲了。甚至服务端时要利用多系统应用应用程序并行正确处理多个请求。可惜,机会 HTTP/1 不支持多路复用,你本身方案几条棘手的问题报告 :

HTTP/2 的连接

CSS、JS 合并(Concatenation);

流(Stream):所处于连接中的另有另一个 虚拟通道。流时要承载双向消息,每个流都不 另有另一个 唯一的整数 ID;

亲戚亲戚朋友知道,HTTP/2 并这样 改动 HTTP/1 的语义每项,这个请求妙招、响应情况报告码、URI 以及头部字段等核心概念依旧所处。HTTP/2 最大的变化是重新定义了格式化和传输数据的妙招,这是通过在高层 HTTP API 和低层 TCP 连接中引入二进制分帧层来实现。事先改动的好处是事先的 WEB 应用删改时会修改,就能享受到协议升级带来的收益。

机会亲戚亲戚朋友这样 无限制开源,你本身你本身节流也很糙要。除了砍掉页面内容,第二次访问时利用 HTTP 缓存之外,通常能做的就这样 合并请求了。根据合并的内容不同,一般又分为以下几种:

消息(Message):指 HTTP/2 中逻辑上的 HTTP 消息。这个请求和响应等,消息由另有另一个 或多个帧组成;

异步接口合并:批量接口返回的时间受木桶效应影响,最慢的那个接口失去了你本身接口。

更多的并发连接 + Keep-Alive 机制,会显著增加服务端和客户端的负担;

这里稍微吐槽下:本地 TCP 连接和本地端口也是有本身资源,为了做 WEB 性能优化,开更多的域名让浏览器创建更多的并发连接,是很霸道和不公平的做法。

在 HTTP/2 中,同域名下所有通信都不 单个连接上完成,你本身连接时要承载任意数量的双向数据流。每个数据流都以消息的形式发送,而消息又由另有另一个 或多个帧组成。多个帧之间时要乱序发送,机会根据帧首部的流标识时要重新组装。下面有一幅图说明帧、消息、流和连接的关系:

图片、音频内联:除了都不 中间另有另一个 问题报告 之外,二进制文件以 Data URI 妙招内联,时要进行 Base64 编码,体积会变大 1/3。

服务端收到多个管道请求后,时要按接收顺序逐个响应。机会恰好第另有另一个 请求很糙慢,后续所有响应时会 跟着被阻塞。你本身情况报告通常被称之为「队首阻塞(Head-of-Line Blocking)」;

有只是,现在蕴含几四个 CSS、JSS,几百张图片的页面大有所在。为了进一步榨干浏览器,开更多的源,往往亲戚亲戚朋友时会 对静态资源做域名散列,将页面静态资源分散在多个子域下加载。多域名能提高并发连接数,也会带来你本身你本身问题报告 ,这个:

来源:51CTO

节流

异步接口合并(Batch Ajax Request);

图片合并:首先,为了显示一张小图,而不得不加载合并后的整张大图,一是机会浪费流量;二是占用更多内存。其次,合并图片中任何一处修改,时会 愿因整张大图缓存失效。那先 问题报告 时要根据不同场景,选取 Data URI、Icon Font、SVG 等技术来改造。另外,雪碧图的生成和维护都比较繁琐,最好使用工具自动管理。

另外,HTTP/1 协议头部使用纯文本格式,这样 任何压缩,且蕴含你本身你本身冗余信息(这个 Cookie、UserAgent 每次时会 携带),你本身你本身另有另一个 页面的请求数太多,头部带来的额外开销就越大。亲戚亲戚朋友一般会用短小且独立的域名来托管静态资源,只是 为了减小你本身开销(域名越短请求头起始行的 URI 就越短,独立域名时会共享主域的 Cookie,时要有效减小请求头大小,你本身策略一般称之为 Cookie-Free Domain)。

哦对了,据官方预测,HTTP/1 合适还时要 10 年可不可否 彻底退出历史舞台,另外尽管 HTTP/2 协议允许脱离 TSL 部署,但 Chrome 和 Firefox 都表示不支持非 TLS 的 HTTP/2,事先很机会另有另一个 网站会一起去提供 HTTP/1.1、HTTP/1.1 over TLS、HTTP/2 over TLS 有本身服务。怎样才能在每项情况报告下,都能给用户提供最好的体验,时要更加深入的优化研究和更加精细的优化策略。由此可见,在很长一段时间内,WEB 性能优化非但时会落幕,反而会更加重要。

另外,服务端和浏览器之间的中间代理设备只是 一定支持 HTTP 管道,这给管道技术的普及引入了更多繁杂性;

这里说的开源,当然都不 「Open Source」那个开源。既然另有另一个 TCP 连接一起去这样 正确处理另有另一个 HTTP 消息,那多开几条 TCP 连接不就正确处理你本身问题报告 了。是的,浏览器嘴笨 是这样 做的,HTTP/1.1 初始版本中允许浏览器针对同另有另一个 域名一起去创建另有另一个 连接,在修订版(rfc7230)中更是去掉 了你本身限制。实际上,现代浏览器一般允许同域名并发 6~8 个连接。你本身数字为那先 这样 更大呢?实际上这是出于公平性的考虑,每个连接对于服务端来说时会 带来一定开销,机会浏览器不加以限制,另有另一个 性能好传输速率足的终端就机会耗尽服务端所有资源,造成另一方无法使用。

基于那先 愿因,HTTP 管道技术无法大规模使用,亲戚亲戚朋友时要寻找你本身方案。实际上,在 HTTP/1 时代,连接数优化不外乎另有另一个 方面:开源和节流。

TCP 协议有本身更适合用来长时间传输大数据,事先它的稳定和可靠性可不可否 显露出来。HTTP/1 时代太多短而小的 TCP 连接,反而更多地将 TCP 的缺点给暴露出来了。

CSS、JS 合并:合并后的资源时要整体加载完才开使英语 解析、执行。事先加载完另有另一个 文件就时要解析并执行另有另一个 ,将你本身你这本人文件合并成另有另一个 巨无霸,会整体推后可用时间。为此,Chrome 新版引入了 Script Streaming 技术,能边加载边解析 JS 文件。Gmail 为了正确处理你本身问题报告 ,将多个 JS 文件合并为另有另一个 由多个 inline script 片段组成的 html,用 iframe 引入,以达到边加载变解析执行的效果。另外,与图片合并这个,CSS、JS 合并也会遇到「无论多小的改动,时会 愿因整个合并文件缓存失效」的问题报告 。

作者:何妍 

浏览器连续发送多个请求后,听候响应这段时间内机会遇上网络异常愿因连接被断开,无法得知服务端正确处理情况报告,机会删改重试机会会造成服务端重复正确处理;

图片、音频内联(Data URI);

结论

开源

每个域名的第另有另一个 连接都不 经历 DNS 解析的过程,这在移动端机会时要耗费几百毫秒;

机会同一资源在不同页面被散列到不同子域下,会愿因无法利用事先的 HTTP 缓存;

CSS、JS 内联:上篇文章我删改分析过内联的优点和弊端。主要另有另一个 问题报告 :1)无法利用缓存;2)多页面无法共享。

图片合并,雪碧图(CSS Sprite);

中间这份列表无须删改,我也没打算列全,那先 就足以说明 HTTP/1 时代亲戚亲戚朋友在性能上所做过的不懈努力了。可惜,亲戚亲戚朋友无须完美,分别列举一下亲戚亲戚朋友的缺点:

在 HTTP/1 中,每另有另一个 请求和响应都不 占用另有另一个 TCP 连接,尽管有 Keep-Alive 机制时要复用,但在每个连接上一起去这样 有另有另一个 请求 / 响应,这愿因完成响应事先,你本身连接这样 用于你本身请求(为社 会么会判断响应不是开使英语 ,时要看这里)。机会浏览器时要向同另有另一个 域名发送多个请求,时要在本地维护另有另一个 FIFO 队列,完成另有另一个 再发送下另有另一个 。事先,从服务端完成请求开使英语 回传,到收到下另有另一个 请求之间的这段时间,服务端所处空闲情况报告。

先来看看这几条概念:

HTTP/1 时代,亲戚亲戚朋友为了节省昂贵的 HTTP 连接(TCP 连接),采用了各种优化手段,那先 方案你本身会引入你本身问题报告 ,有只是相比收益来说还是值得做,也应该做。有只是,有了 HTTP/2 的多路复用和头部压缩,HTTP 连接变得时要随心所欲了,本文提到的那先 连接数优化手段嘴笨 时要退休了。

帧(Frame):HTTP/2 数据通信的最小单位。帧用来承载特定类型的数据,如 HTTP 首部、负荷;机会用来实现特定功能,这个打开、关闭流。每个帧都蕴含帧首部,其中会标识出当前帧所属的流;

在「HTTP/2 与 WEB 性能优化(一)」这篇博客中,我主要写了 HTTP/2 中的 Server Push 给 WEB 性能优化带来的便利,今天继续来聊一聊 HTTP/2 你本身方面的改变。

服务端为了保证按顺序回传,通常时要缓存多个响应,从而占用更多的服务端资源,也更容易被人攻击;

CSS、JS 内联(Inline);

连接(Connection):与 HTTP/1 相同,都不 指对应的 TCP 连接;

HTTP/1 的请求和响应报文,都不 由起始行、首部和实体正文(可选)组成,各每项之间以文本换行符分隔。而 HTTP/2 将请求和响应数据分割为更小的帧,并对它们采用二进制编码。下面这幅图中的 Binary Framing 只是 新增的二进制分帧层: