关于javascript:Http-vs-Http2-详细细节

http1的毛病

• 线头阻塞：形式为，若干个申请排队串行化单线程解决，前面的申请期待后面申请的返回能力取得执行机会，一旦有某申请超时等，后续申请只能被阻塞，毫无办法，也就是人们常说的线头阻塞；
• 没有充沛的利用TCP链接： HTTP 1.x 中，如果想并发多个申请，必须应用多个 TCP 链接，且浏览器为了管制资源，还会对单个域名有 6-8个的TCP链接申请限度

http2长处

• 多路复用：最有价值的长处，解决了线头阻塞的问题，容许繁多的http2连贯能够发送多重的申请和响应，充沛的利用TCP。 使得 资源分域名、雪碧图、内联款式等不再实用。
• header压缩：HTTP2.0能够在客户端和服务器端保护动态字典和动静字典用来压缩和差量更新HTTP头部，大大降低因头部传输产生的流量。非两个字典内的header能够实用哈夫曼压缩形式进行压缩。
• 新的二进制格局：http1.x 是文本格式传输，http2是二进制格局传输。
• 服务端推送：服务器端能够被动向客户端推送资源。

二进制分帧

先来了解几个概念：

帧：HTTP/2 数据通信的最小单位音讯：指 HTTP/2 中逻辑上的 HTTP 音讯。例如申请和响应等，音讯由一个或多个帧组成。

流：存在于连贯中的一个虚构通道。流能够承载双向音讯，每个流都有一个惟一的整数ID。

HTTP/2 采纳二进制格局传输数据，而非 HTTP 1.x 的文本格式，二进制协定解析起来更高效。 HTTP / 1 的申请和响应报文，都是由起始行，首部和实体注释（可选）组成，各局部之间以文本换行符分隔。HTTP/2 将申请和响应数据宰割为更小的帧，并且它们采纳二进制编码。

HTTP/2 中，同域名下所有通信都在单个连贯上实现，该连贯能够承载任意数量的双向数据流。每个数据流都以音讯的模式发送，而音讯又由一个或多个帧组成。多个帧之间能够乱序发送，依据帧首部的流标识能够从新组装。

多路复用

多路复用，代替原来的序列和阻塞机制。所有就是申请的都是通过一个 TCP连贯并发实现。 HTTP 1.x 中，如果想并发多个申请，必须应用多个 TCP 链接，且浏览器为了管制资源，还会对单个域名有 6-8个的TCP链接申请限度，如下图，红色圈进去的申请就因域名链接数已超过限度，而被挂起期待了一段时间：

在 HTTP/2 中，有了二进制分帧之后，HTTP /2 不再依赖 TCP 链接去实现多流并行了，在 HTTP/2中：

• 同域名下所有通信都在单个连贯上实现。
• 单个连贯能够承载任意数量的双向数据流。
• 数据流以音讯的模式发送，而音讯又由一个或多个帧组成，多个帧之间能够乱序发送，因为依据帧首部的流标识能够从新组装。

这一个性，使性能有了极大晋升：

• 同个域名只须要占用一个 TCP 连贯，打消了因多个 TCP 连贯而带来的延时和内存耗费。
• 单个连贯上能够并行交织的申请和响应，之间互不烦扰。
• 在HTTP/2中，每个申请都能够带一个31bit的优先值，0示意最高优先级， 数值越大优先级越低。有了这个优先值，客户端和服务器就能够在解决不同的流时采取不同的策略，以最优的形式发送流、音讯和帧。

服务器推送

服务端能够在发送页面HTML时被动推送其它资源，而不必等到浏览器解析到相应地位，发动申请再响应。例如服务端能够被动把JS和CSS文件推送给客户端，而不须要客户端解析HTML时再发送这些申请。

服务端能够被动推送，客户端也有权力抉择是否接管。如果服务端推送的资源曾经被浏览器缓存过，浏览器能够通过发送RST_STREAM帧来拒收。被动推送也恪守同源策略，服务器不会轻易推送第三方资源给客户端。

头部压缩

HTTP 1.1申请的大小变得越来越大，有时甚至会大于TCP窗口的初始大小，因为它们须要期待带着ACK的响应回来当前能力持续被发送。HTTP/2对音讯头采纳HPACK（专为http/2头部设计的压缩格局）进行压缩传输，可能节俭音讯头占用的网络的流量。而HTTP/1.x每次申请，都会携带大量冗余头信息，节约了很多带宽资源。

HTTP每一次通信都会携带一组头部，用于形容这次通信的的资源、浏览器属性、cookie等，例如

为了缩小这块的资源耗费并晋升性能，HTTP/2对这些首部采取了压缩策略：

• HTTP/2在客户端和服务器端应用“字典表”来跟踪和存储之前发送的键－值对，对于雷同的数据，不再通过每次申请和响应发送；
• 字典表在HTTP/2的连贯存续期内始终存在，由客户端和服务器独特渐进地更新;
• 每个新的首部键－值对要么被追加到以后表的开端，要么替换表中之前的值。
• 字典表包含动静字典表和动态字典表

例如：下图中的两个申请， 申请一发送了所有的头部字段，第二个申请则只须要发送差别数据，这样能够缩小冗余数据，升高开销。

咱们来看一个理论的例子，上面是用WireShark抓取的拜访google首页的包：

上图是是拜访https://www.google.com/抓到的…，能够看到头部的内容，总共占用了437 bytes，咱们选中头部的cookie，能够看到cookie总共占用了118 bytes。接下来咱们看看第二个申请的头部：

从上图能够看到，得益于头部压缩，第二个申请中cookie只占用了1个字节，咱们来看看变动了的Accept字段：

因为Accept字段与申请一中的内容不同，须要发送给服务器，所以占用了29 bytes。

结语

• HTTP/2的通过反对申请与响应的多路复用来缩小提早
• 通过压缩HTTP首部字段将协定开销降至最低
• 减少对申请优先级和服务器端推送的反对。

在进行 HTTP/2 网站性能优化时很重要一点是「应用尽可能少的连接数」，本文提到的头部压缩是其中一个很重要的起因：同一个连贯上产生的申请和响应越多，动静字典积攒得越全，头部压缩成果也就越好。所以，针对 HTTP/2 网站，最佳实际是不要合并资源，不要散列域名(因为每一个不同的域名下，须要单开一个TCP链接，并且保护一份header字典值)

默认状况下，浏览器会针对这些状况应用同一个连贯：

• 同一域名下的资源；
• 不同域名下的资源，然而满足两个条件：1、解析到同一个 IP；2、应用同一个证书