关于http:深入理解-Web-协议-三HTTP-2

3次阅读

共计 8120 个字符，预计需要花费 21 分钟才能阅读完成。

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

HTTP 2 连贯的建设
HTTP 2 中帧和流的关系
HTTP 2 中流量节俭的神秘：HPACK 算法
HTTP 2 协定中 Server Push 的能力
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 就是在应用层上模仿了一下传输层 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 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 都不在索引表中的例子。

前文咱们提到过，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 main

import (
    "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 了）。

很多人不了解，为什么 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，哪些申请能够后一点被发送。这样浏览器在整体上提供给用户的体验就会变的更好。

基于 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 自身的。

更多浏览：