本篇将具体介绍 http2 协定的方方面面，知识点如下：

HTTP 2 连贯的建设
HTTP 2 中帧和流的关系
HTTP 2 中流量节俭的神秘：HPACK 算法
HTTP 2 协定中 Server Push 的能力
HTTP 2 为什么要实现流量管制？
HTTP 2 协定遇到的问题

一、HTTP 2 连贯的建设

和许多人的固有印象不同的是 HTTP 2协定自身并没有规定必须建设在TLS/SSL之上，其实用一般的TCP连贯也能够实现HTTP 2连贯的建设。只不过当初为了平安市面上所有的浏览器都仅默认反对基于TLS/SSL的 HTTP 2协定。简略来说咱们能够把构建在TCP连贯之上的 HTTP 2 协定称之为H2C，而构建在TLS/SSL协定之上的就能够了解为是H2了。

输出命令：

tcpdump -i eth0 port 80 and host nghttp2.org -w h2c.pcap &

而后用curl拜访基于TCP连贯，也就是port 80端口的 HTTP 2站点（这里是没方法用浏览器拜访的，因为浏览器不容许）

curl http://nghttp2.org --http2 -v

其实看日志也能够大抵理解一下这个连贯建设的过程：

咱们将TCPDump进去的pcap文件拷贝到本地，而后用Wireshark关上当前还原一下整个HTTP 2连贯建设的报文：

首先是 HTTP 1.1 降级到 HTTP 2 协定

而后客户端还须要发送一个“魔法帧”：

最初还须要发送一个设置帧：

之后，咱们来看一下，基于TLS的 HTTP 2连贯是如何建设的，思考到加密等因素，咱们须要提前做一些筹备工作。能够在Chrome中下载这个插件。

而后关上任意一个网页只有看到这个闪电的图标为蓝色就代表这个站点反对HTTP 2；否则不反对。如下图：

将Chrome浏览器的TLS/SSL之类的信息输入到一个日志文件中，须要额定配置零碎变量，如图所示：

而后将咱们的Wireshark中SSL相干的设置也进行配置。

这样浏览器在进行TLS协定交互的时候，相干的加密解密信息都会写入到这个log文件中，咱们的Wireshark就会用这个log文件中的信息来解密出咱们的TLS报文。

有了上述的根底，咱们就能够着手剖析基于TLS连贯的HTTP 2协定了。比方咱们拜访tmall的站点 https://www.tmall.com/ 而后关上咱们的Wireshark。

看一下标注的中央能够看进去，是TLS连贯建设当前而后持续发送魔法帧和设置帧，才代表HTTP 2的连贯真正建设结束。咱们看一下TLS报文的client hello 这个信息：

其中这个alpn协定的信息就代表客户端能够承受哪两种协定。server hello 这个音讯就明确的告知咱们要应用H2协定。

这也是HTTP 2相比spdy协定最重要的一个长处：spdy协定强依赖TLS/SSL，服务器没有任何抉择。而HTTP 2协定则会在客户端发动申请的时候携带alpn这个扩大，也就是说客户端发申请的时候会通知服务端我反对哪些协定。从而能够让服务端来抉择，我是否须要走TLS/SSL。

二、HTTP 2 中帧和流的关系

简略来说，HTTP 2就是在应用层上模仿了一下传输层TCP中“流”的概念，从而解决了HTTP 1.x协定中的队头拥塞的问题，在1.x协定中，HTTP 协定是一个个音讯组成的，同一条TCP连贯上，后面一个音讯的响应没有回来，后续的音讯是不能够发送的。在HTTP 2中，勾销了这个限度，将所谓的“音讯”定义成“流”，流跟流之间的程序能够是错乱的，然而流外面的帧的程序是不能够错乱的。如图：

也就是说在同一条TCP连贯上，能够同时存在多个stream流，这些流由一个个frame帧组成，流跟流之间没有程序关系，然而每一个流外部的帧是有先后顺序的。留神看这张图中的 135 等数字其实就是stream id，WebSocket中尽管也有帧的概念，然而因为WebSocket中没有stream id，所以Websocket是没有多路复用的性能的。HTTP 2 因为有了stream id所以就有了多路复用的能力。能够在一条TCP连贯上存在n个流，就意味着服务端能够同时并发解决n个申请而后同时将这些申请都响应到同一条TCP连贯上。当然这种在同一条TCP连贯上传送n个stream的能力也是有限度的，在 HTTP 2 连贯建设的时候，setting帧中会蕴含这个设置信息。例如下图在拜访天猫的站点的时候，浏览器携带的setting帧的音讯外面就标识了浏览器这个HTTP 2的客户端能够反对并发最大的流为1000。

当天猫服务器返回这个setting帧的响应的时候，就告知了浏览器，我能反对的最大并发stream为128。

同时咱们也要晓得，HTTP 2协定中流id为复数就代表是客户端发动的流，偶数代表服务端被动发动的流（能够了解为服务端被动推送）。

三、 HTTP 2 中流量节俭的神秘：HPACK 算法

相比与HTTP 1.x协定，HTTP 2协定还在流量耗费上做了极大改良。次要分为三块：动态字典，动静字典，和哈夫曼编码. 能够装置如下工具探测一下对流量节俭的作用：

apt-get install nghttp2-client

而后能够探测一下一些曾经开启 HTTP 2的站点，基本上节约的流量都是百分之25起，如果频繁拜访的话会更多：

对于流量耗费来说，其实HTTP 2相比HTTP 1.x协定最大的改良就是在HTTP 2中咱们能够对HTTP 的头部进行压缩了，而在以往HTTP 1.x协定中，gzip等是无奈对header进行压缩的，尤其对于绝大多数的申请来说，其实header的占比是最大的。

咱们首先来理解一下动态字典，如图所示：

这个其实不难理解，无非就是将咱们那些罕用的HTTP 头部，用固定的数字来示意，那当然能够起到节约流量的作用.这里要留神的是有些value 状况比较复杂的header，他们的value 是没有做动态字典的。比方cache-control这个缓存管制字段，这前面的值因为太多了就无奈用动态字典来解决，而只能靠霍夫曼编码。下图能够示意 HPACK这种压缩算法起到的节约流量的作用：

例如，咱们看下62这个头部，user-agent 代指浏览器，个别咱们申请的时候这个头部信息都是不会变的，所以最终通过hpack算法优化当前后续再传输的时候就只须要传输62这个数字就能够代表其含意了。

又例如下图：

也是一样的，多个申请间断发送的时候，少数状况下变动的只有path，其余头部信息是不变的，那么基于此场景，最终传输的时候也就只有path这一个头部信息了。

最初咱们来看看hpack算法中的外围:哈夫曼编码。哈弗曼编码核心思想就是呈现频率较高的用较短的编码，呈现频率较低的用较长的编码（HTTP 2协定的前身spdy协定采纳的是动静的哈夫曼编码，而HTTP 2协定则抉择了动态的哈夫曼编码）。

来看几个例子：

例如这个header帧，留神看这个method:get的头部信息。因为method:get 在动态索引表中的索引值为2.对于这种key和value都在索引表中的值，咱们用一个字节也就是8个bit来标识，其中第一个bit固定为1，剩下7位就用来示意索引表中的值，这里method:get 索引表的值为2，所以这个值就是1000 0010，换算成16进制就是0x82.

再看一组，key在索引表中，value 不在索引表中的header例子。

对于key在索引表中，value 不在索引表中的状况，固定是01结尾的字节，前面6个bit（111010 换算成十进制就是58）就是动态索引的值， user-agent在索引中index的值是58 再加上01结尾的2个bit 换算成二进制就是01111010,16进制就7a了。而后接着看第二个字节，0xd4,0xd4换算成二进制就是 1 101 0100，其中第一个bit 代表前面采纳的是哈夫曼编码，前面的7个bit 这个key-value的value 须要几个字节来示意，这里是101 0100 换算成10进制就是84，也就是说这个user-agent前面的value须要84个字节来示意，咱们数一下图中的字节数 16*5+第一排d4前面的4个字节，刚好等于84个字节。

最初再看一个key和value 都不在索引表中的例子。

四、HTTP 2 协定中 Server Push 的能力

前文咱们提到过，H2相比H1.x协定晋升最大的就是H2能够在单条TCP连贯的根底上同时传输n个stream。从而防止H1.x协定中队头拥塞的问题。实际上在大部分前端的页面中，咱们还能够应用H2协定的Server Push能力进一步提高页面的加载速度。例如通常咱们用浏览器拜访一个Html页面时，只有当html页面返回到浏览器，浏览器内核解析到这个Html页面中有CSS或者JS之类的资源时，浏览器才会发送对应的CSS或者JS申请，当CSS和JS回来当前浏览器才会进一步渲染，这样的流程通常会导致浏览器处于一段时间内的白屏从而升高用户体验。有了H2协定当前，当浏览器拜访一个Html页面到服务器时，服务器就能够被动推送相应的CSS和JS的内容到浏览器，这样就能够省略浏览器之后从新发送CSS和JS申请的步骤。

有些人对Server Push存在肯定水平上的误会，认为这种技术可能让服务器向浏览器发送“告诉”，甚至将其与WebSocket进行比拟。事实并非如此，Server Push只是省去了浏览器发送申请的过程。只有当“如果不推送这个资源，浏览器就会申请这个资源”的时候，浏览器才会应用推送过去的内容。否则如果浏览器自身就不会申请某个资源，那么推送这个资源只会白白耗费带宽。当然如果与服务器通信的是客户端而不是浏览器，那么HTTP 2协定天然就能够实现 push推送的性能了。所以都应用HTTP 2协定的状况下，与服务器通信的是客户端还是浏览器在性能上还是有肯定区别的。

上面为了演示这个过程，咱们写一段代码。思考到浏览器拜访HTTP 2站点必须要建设在TLS连贯之上，咱们首先要生成对应的证书和秘钥。

而后开启HTTP 2，在接管到Html申请的时候被动push Html中援用的CSS文件。

package mainimport (    "fmt"    "net/http"    "github.com/labstack/echo")func main() {    e := echo.New()    e.Static("/", "html")    //次要用来验证是否胜利开启http2环境    e.GET("/request", func(c echo.Context) error {        req := c.Request()        format := `          <code>            Protocol: %s<br>            Host: %s<br>            Remote Address: %s<br>            Method: %s<br>            Path: %s<br>          </code>        `        return c.HTML(http.StatusOK, fmt.Sprintf(format, req.Proto, req.Host, req.RemoteAddr, req.Method, req.URL.Path))    })    //在收到html申请的时候 同时被动push html中援用的css文件，不须要期待浏览器发动申请    e.GET("/h2.html", func(c echo.Context) (err error) {        pusher, ok := c.Response().Writer.(http.Pusher)        if ok {            if err = pusher.Push("/app.css", nil); err != nil {                println("error push")                return            }        }        return c.File("html/h2.html")    })    //     e.StartTLS(":1323", "cert.pem", "key.pem")}

而后Chrome拜访这个网页的时候，看下NetWork面板：

能够看进去这个CSS文件就是咱们被动push过去的。再看下Wireshark。

能够看进去 stream id为13的是客户端发动的申请，因为id是复数的，在这个stream中，还存在着push_promise帧，这个帧就是由服务器发送给浏览器的，看一下他的具体内容。

能够看进去这个帧就是用来通知浏览器，我被动push给你的是哪个资源，这个资源的stream-id 是6.图中咱们也看到了有一个stream-id 为6的 data在传输了，这个就是服务器被动push进去的CSS文件。到这里，一次残缺的Server Push就交互结束了。

但在理论线上利用Server Push的时候挑战远远比咱们这个demo中来的简单。首先就是大部分cdn供应商(除非自建cdn)对Server Push的反对比拟无限。咱们不可能让每一次资源的申请都间接打到咱们的源服务器上，大部分动态资源都是前置在CDN中。其次，对于动态资源来说，咱们还要思考缓存的影响，如果是浏览器本人收回去的动态资源申请，浏览器是能够依据缓存状态来决定这个资源我是否真的须要去申请，而Server Push 是服务器被动发动的，服务器少数状况下是不晓得这个资源的缓存是否过期的。当然能够在浏览器接管到push Promise帧当前，查问本身的缓存状态而后发动RST\_STREAM帧，告知服务器这个资源我有缓存，不须要持续发送了，然而你没方法保障这个RST\_STREAM在达到服务器的时候，服务器被动push进来的data帧还没收回去。所以还是会存在肯定的带宽节约的景象。总体来说，Server Push 还是一个进步前端用户体验相当无效的伎俩，应用了Server Push当前浏览器的性能指标 idle指标个别能够进步3-5倍（毕竟浏览器不必期待解析Html当前再去申请CSS和JS了）。

五、HTTP 2 为什么要实现流量管制？

很多人不了解，为什么TCP传输层曾经实现了流量管制，咱们的应用层 HTTP 2 还要实现流量管制。上面咱们看一张图。

在HTTP 2协定中，因为咱们反对多路复用，也就是说咱们能够同时发送多个stream 在同一条TCP连贯中，上图中，每一种色彩就代表一个stream，能够看到咱们总共有4种stream，每一个stream又有n个frame，这个就很危险了，假如在应用层中咱们应用了多路复用，就会呈现n个frame同时不停的发送到指标服务器中，此时流量达到高峰就会触发TCP的拥塞管制，从而将后续的frame全副阻塞住，造成服务器响应过慢了。HTTP 1.x 中因为不反对多路复用天然就不存在这个问题。且咱们之前屡次提到过，一个申请从客户端达到服务器端要通过很多的代理服务器，这些代理服务器内存大小以及网络状况都可能不一样，所以在应用层上做一次流量管制尽量避开触发TCP的流控是非常有必要的。在HTTP 2协定中的流量控制策略，遵循以下几个准则：

客户端和服务端都有流量控制能力。
发送端和接收端能够独立设置流控能力。
只有data帧才须要流控，其余header帧或者push promise帧等都不须要。
流控能力只针对TCP连贯的两端，两头即便有代理服务器，也不会透传到源服务器上。

拜访知乎的站点看一下抓包。

这些标识window_update帧的就是所谓的流控帧了。咱们随便点开一个看一下，就能够看到这个流量管制帧通知咱们的帧大小。

聪慧如你肯定能想到，既然HTTP 2都能做到流控了，那肯定也能够来做优先级。比方说在HTTP 1.x协定中，咱们拜访一个Html页面，外面会有JS和CSS还有图片等资源，咱们同时发送这些申请，然而这些申请并没有优先级的概念，谁先进来谁先回来都是未知的(因为你也不晓得这些CSS和JS申请是不是在同一条TCP连贯上，既然是扩散在不同的TCP中，那么哪个快哪个慢是不确定的)，然而从用户体验的角度来说，必定CSS的优先级最高，而后是JS，最初才是图片，这样就能够大大放大浏览器白屏的工夫。在HTTP 2中实现了这样的能力。比方咱们拜访sina的站点，而后抓包就能够看到：

能够看下这个CSS 帧的的优先级：

JS的优先级

最初是gif图片的优先级，能够看进去这个优先级是最低的。

有了weight这个关键字来标识优先级，服务器就晓得哪些申请须要优先被响应优先被发送response，哪些申请能够后一点被发送。这样浏览器在整体上提供给用户的体验就会变的更好。

六、HTTP 2 协定遇到的问题

基于TCP或者TCP+TLS的 HTTP 2协定还是遇到了很多问题，比方：握手工夫过长问题，如果是基于TCP的HTTP 2协定，那么至多要三次握手，如果是TCP+TLS的HTTP 2协定，除了TCP的握手还要经验TLS的屡次握手（TLS1.3曾经能够做到只有1次握手）。每一次握手都须要发送一个报文而后接管到这个报文的ack才能够进行下一次握手，在弱网环境下能够设想的到这个连贯建设的效率是极低的。此外，TCP协定天生的队头拥塞问题也始终在困扰着HTTP 21.x协定和HTTP 2协定。咱们看一下谷歌spdy的宣传图,能够更加精准的了解这个拥塞的实质：

图一很好了解，咱们多路复用反对下同时发了3个stream，而后通过TCP/IP协定发送到服务器端，而后TCP协定把这些数据包再传给咱们的应用层，留神这里有个条件是，发送包的程序要和接管包的程序统一。上图中能够看到那些方块的图的程序是统一的，然而如果碰到下图中的状况，比如说这些数据包恰好第一个红色的数据包传丢了，那么后续的数据包即便曾经到了服务器的机器里，也无奈立即将数据传递给咱们的应用层协定，因为TCP协定规定好了接管的程序要和发送的程序保持一致，既然红色的数据包失落了，那么后续的数据包就只能阻塞在服务器里，始终等到红色的数据包通过从新发送当前胜利达到服务器了，再将这些数据包传递给应用层协定。

TCP协定除了有上述的一些缺点以外，还有一个问题就是TCP协定的实现者是在操作系统层面，咱们任何语言，包含 Java，C，C++，Go等等对外裸露的所谓Socket编程接口最终实现者其实都是操作系统本人。要让操作系统本人降级TCP协定的实现是十分十分艰难的，况且整个互联网中那么多设施想要整体实现TCP协定的降级是一件不事实的事件（IPV6协定降级的过慢也有这方面的起因）。基于上述问题，谷歌就基于udp协定封装了一层quic协定（其实很多基于udp协定的应用层协定，都是在应用层上局部实现了TCP协定的若干性能），来代替HTTP 21.x-HTTP 2中的TCP协定。

咱们关上Chrome中的quic协定开关：

而后拜访一下youtube（国内的b站其实也反对）。

能够看进去曾经反对quic协定了。为什么这个选项在Chrome浏览器中默认是敞开的，其实也很好了解，这个quic协定实际上是谷歌本人搞进去的，还没有被正式纳入到HTTP 3协定中，所有都还在草案中。所以这个选项默认是敞开的。看下quic协定相比于原来的TCP协定次要做了哪些改良？其实就是将原来队列传输报文改成了无需队列传输，那天然也就不存在队头拥塞的问题了。

此外在HTTP 3中还提供了变更端口号或者ip地址也能够复用之前连贯的能力，集体了解这个协定反对的个性可能更多是为了物联网思考的。物联网中很多设施的ip都可能是始终变动的。能复用之前的连贯将会大大提高网络传输的效率。这样就能够防止目前存在的断网当前从新连贯到网络须要至多通过1-3个rtt才能够持续传输数据的弊病。

最初要提一下，在极其弱网环境中，HTTP 2 的体现有可能不如HTTP 1.x，因为HTTP 2上面只有一条TCP连贯，弱网下，如果丢包率极高，那么会一直的触发TCP层面的超时重传，造成TCP报文的积压，迟迟无奈将报文传递给下面的应用层，然而HTTP 1.x中，因为能够应用多条TCP连贯，所以在肯定水平上，报文积压的状况不会像HTTP 2那么重大，这也是我认为的HTTP 2协定惟一不如HTTP 1.x的中央，当然这个锅是TCP的，并不是HTTP 2自身的。

更多浏览：

深刻了解web协定(二)：DNS、WebSocket
深刻了解 web 协定(一)：http 包体传输

作者：vivo 互联网-WuYue