HTTP2基本概念学习笔记

HTTP2 规范在2015年5月正式发布，至今大多数浏览器和服务器已经对此协议提供了支持：

(2018-04-09)

做为一个对 HTTP1.x 进行了增强、补充和完善的更好的协议，值得咱们好好的去了解它，而后使用它作出更美妙的事情。

1 过去和如今

HTTP1.1 自从1997年发布1999年最后一次修改以来，咱们已经使用 HTTP1.x 至关长一段时间了，可是随着近十年互联网的爆炸式发展，当时协议规定的某些特性，已经没法知足现代网络的需求了。

HTTP1.x 有如下几点致命缺陷：（以浏览器至服务器为例）

• 协议规定客户端对同一域的并发链接最多只能2个（浏览器实现通常是2~8个），可是现代网页平均一个页面须要加载 40个资源
• 线头阻塞（Head of line blocking）问题：同一个链接中的请求，须要一个接一个串行发送和接收
• 基于文本协议，请求和响应的头信息很是大，而且没法压缩。
• 不能控制响应优先级，必须按照请求顺序响应。
• 只能单向请求，也就是客户端请求什么，服务器只能返回什么。

就是以上问题严重影响了现代互联网信息交互的效率和灵活性，此时更现代更高效的通信协议 HTTP2 应运而生。

HTTP2 使用了多路复用、HPACK头压缩、流 + 二进制帧和流优先级等技术手段解决上述问题。

2 HTTP2

HTTP2 的前身是 SPDY协议（一个 Google 主导推行的应用层协议，做为对 HTTP1 的加强），初版草稿就是基于 SPDY3 规范修改制定而来。HTTP2必须在维持原来 HTTP 的范式（不改动 HTTP/1.x 的语义、方法、状态码、URI 以及首部字段等等）前提下，实现突破性能限制，改进传输性能，实现低延迟和高吞吐量。

HTTP2 的特性包括：

1. 传输内容使用二进制协议
2. 使用帧做为最小传输单位
3. 多路复用
4. 头压缩
5. 服务器推送
6. 优先级与依赖性
7. 可重置
8. 流量控制
9. HTTPS rfc 规范并无要求 HTTP2 强制使用 TLS，可是目前世界全部浏览器和服务器实现都基于 HTTPS 来实现 HTTP2

2.1 二进制

在 HTTP1.x 时代，不管是传输内容仍是头信息，都是文本/ASCII编码的，虽然这有利于直接从请求从观察出内容，可是却使得想要实现并发传输异常困难（存在空格或其余字符，很难判断消息的起始和结束）。使用二进制传输能够避免这个问题，由于传输内容只有1和0，经过下面第二点的“帧”规范规定格式，便可轻易识别出不一样类型内容。同时使用二进制有一个显而易见的好处是：更小的传输体积。

2.2 二进制分帧

HTTP2 在维持原有 HTTP 范式的前提下，实现突破性能限制，改进传输性能，实现低延迟和高吞吐量的其中一个关键是：在应用层（HTTP2）和传输层（TCP or UDP）之间增长了二进制分帧层。

帧（Frame）是 HTTP2 通信中的最小传输单位，全部帧以固定的 9 个八位字节头部开头，随后是一个可变长度的有效载荷

帧结构图
 +-----------------------------------------------+
 |                 长度Length (24)                |
 +---------------+---------------+---------------+
 |   类型Type (8)    |   标志Flags (8)   |
 +-+-------------+---------------+-------------------------------+
 |R|                 流标识符Stream Identifier (31)               |
 +=+=============================================================+
 |                   帧载荷Frame Payload (0...)                 ...
 +---------------------------------------------------------------+
复制代码

规范中一共定义了 10 种不一样的帧，其中最基础的两种分别对应于 HTTP1.x 的 DATA 和 HEADERS。

一个真正的 HTTP2 请求相似下图：

2.3 多路复用（Multiplexing）和流

上一节提到的 Stream Identifier 将 HTTP2 链接上传输的每一个帧都关联到一个“流”。流是一个独立的，双向的帧序列，能够经过一个 HTTP2 的链接在服务端与客户端之间不断的交换数据。
每一个单独的 HTTP2 链接均可以包含多个并发的流，这些流中交错的包含着来自两端的帧。流既能够被客户端/服务器端单方面的创建和使用，也能够被双方共享，或者被任意一边关闭。在流里面，每一帧发送的顺序很是关键。接收方会按照收到帧的顺序来进行处理。

上面是《HTTP2 讲解》对流的解释，下面接着是一个小火车的例子，可是我的以为这个例子有必定的误差，而且并不能让人直观的理解 帧-流-链接 之间的关系，如下是我的理解：

A "stream" is an independent, bidirectional sequence of frames exchanged between the client and server within an HTTP/2 connection. --rfc7540 StreamsLayer

“流”是一个逻辑上的概念（没有真正传输流这么个东西），是 HTTP2 链接中在客户端和服务器之间交换的独立双向帧序列，这就是为何在规范中的 stream 也是用双引号括起来的缘由。从上一节咱们能够知道，HTTP2 的传输单位是帧，流其实就是一个帧的分组集合的概念，为何须要这个逻辑集合呢？答案就在多路复用。

多路复用是解决 HTTP1.x 缺陷第一点（并发问题）和第二点（HOLB线头问题）的核心技术点。这里须要举个🌰来讲明：

假设已经创建了 TCP 链接，如今须要客户端发起了两个请求，从流的角度看是这样的：

可是实际 TCP 链接只有一个，两个帧是不可能真的“同时”到达服务器的，多路复用更像是 CPU 处理任务概念中的 并发，而不是并行，从规范中使用术语 Stream Concurrency 而不是 Stream Parallelism 也可得出此结论，因此实际传输时是下图：

上图须要注意三点：

1. 同一个流中的帧是交错传输的！
2. Header 帧必须在 data 帧前面，由于不管是客户端仍是服务端，都依赖 header 帧的信息解析 data 帧的数据！
3. 先到的帧不必定先返回，快的能够先返回！

正是因为上述第一点特性，解释了为何须要“流”这个逻辑集合。同时，经过这种 帧-流-链接 的组合，解决了请求并发（一次链接多个请求）和HOLB线头问题（并发发送，异步响应）。

进入 HTTP/2: the Future of the Internet 由 Akamai 公司创建的官方 Demo，能够看出 HTTP2 相比于以前的 HTTP1.1 在性能上的大幅度提高。

HTTP1.1

HTTP2

在过去，咱们发现 HTTP 性能优化的关键不在于高宽带，而是低延迟。

从上图可见，当带宽到达必定的速度以后，对页面加载速度的提高已经不多了，可是随着延迟的减小，页面加载时间会对应持续的减小。因为 TCP 链接存在一种称为「调谐」的慢启动（slow start）特性，让本来就具备突发性和短时性的 HTTP 链接变的十分低效。而 HTTP2 经过让全部数据流共用同一个链接，能够更有效地使用 TCP 链接，让高带宽也能真正的服务于 HTTP 的性能提高。

以上纯属我的理解，若有不对请不吝指出共同讨论，感谢！

2.4 头压缩

咱们都知道 HTTP协议自己是无状态（stateless） 的：每一个请求之间互不关联，每一个请求都须要携带服务器所须要的全部细节信息。好比说请求1发送给服务器信息“我是用户A”，而后请求二发送信息“修改个人用户名为XX”，这时若是请求二没有携带“我是用户A”的信息，那么服务器是不知道要修改哪一个用户的用户名的。

这显然是不符合当前 web 应用系统架构的，由于通常系统都须要进行鉴权，日志记录，安全校验等限制，因此须要获取当前操做用户的信息，出于安全和性能考虑咱们不能在消息体中明文包含这些信息，HTTP2 以前的解决方案通常是使用 Cookies 头、服务器session 等方式模拟出“状态”。而使用 Cookies 头的缺点就是每一个请求都须要携带庞大的重复的信息而且没法压缩，假设一个请求的 header 是2kb，那么一百个请求就是重复的 200Kb 信息，这是一个巨大的带宽浪费。

HTTP2 增长了两个特性解决上述问题：

• HPACK，专门为头部压缩设计的算法，还被指定成单独的草案中。

  

• 首部表，HTTP2 在户端和服务器端使用“首部表”来跟踪和存储以前发送的键-值对，对于相同的数据，再也不经过每次请求和响应发送；通讯期间几乎不会改变的通用键-值对（用户代理、可接受的媒体类型，等等）只需发送一次。

  

2.5 服务器推送

这个功能一般被称做“缓存推送（cache push）”。主要的思想是：当一个客户端请求资源X，而服务器知道它极可能也须要资源Z的状况下，服务器能够在客户端发送请求Z前，主动将资源Z推送给客户端。这个功能帮助客户端将Z放进缓存以备未来之需。

服务器推送须要客户端显式的容许服务器提供该功能。但即便如此，客户端依然能自主选择是否须要中断该推送的流。若是不须要的话，客户端能够经过发送一个 RST_STREAM 帧来停止推送。

咱们来看一下实际场景：如今咱们访问一个网站，第一个请求通常是获取 Document 页面，而后浏览器解析这个页面，在遇到须要资源获取的时候（css、js、图片等），再去发起资源获取请求，以下图：

【传统作法】

为了加速这个过程，减小白屏时间，传统的作法是把首页须要的资源都内联到 Document 中，还有合并资源好比 CSS sprites，js 压缩合并等。以下图：

【HTTP2】

在 HTTP2 的场景下，客户端在请求 Document 的时候，服务器若是知道页面须要的资源有哪些，就能够把那些资源也一同返回了：

注意：主动推送的资源是能被浏览器缓存的！

那么问题来了，若是客户端已经缓存了资源，此时服务器每次都还推送一样的资源给客户端，这不是很大的浪费吗？

答：原来确实会存在这种状况，因此 IETF 小组正在拟定一个名为 cache-digest的技术规范，用于帮助客户端主动告诉服务端哪些资源已经缓存了，不须要重复发送。

关于服务端推送对网页性能的影响，和对于 CDN 的使用的比较，能够参考下面两篇文章：

1. measuring-server-push-performance
2. http://www.ruanyifeng.com/blog/2018/03/http2_server_push.html

结论：使用 HTTP2 的多路复用和服务器推送功能，并不意味着能够减小甚至抛弃使用 CDN，由于 CDN 带来的现实地理位置上延迟减小是 HTTP2 所不能解决的，反而咱们应该思考的是如何把 HTTP2 和 CDN 结合起来，进一步提高网络服务的效率和稳定性，减小延迟。

2.6 优先级与依赖性

每一个流都包含一个优先级（也就是“权重”），它被用来告诉对端哪一个流更重要。当资源有限的时候，服务器会根据优先级来选择应该先发送哪些流。

借助于PRIORITY帧，客户端一样能够告知服务器当前的流依赖于其余哪一个流。该功能让客户端能创建一个优先级“树”，全部“子流”会依赖于“父流”的传输完成状况。

优先级和依赖关系能够在传输过程当中被动态的改变。这样当用户滚动一个全是图片的页面的时候，浏览器就可以指定哪一个图片拥有更高的优先级。或者是在你切换标签页的时候，浏览器能够提高新切换到页面所包含流的优先级。

2.7 可重置

HTTP1.x 的有一个缺点是：当一个含有确切值的 Content-Length 的 HTTP 消息被送出以后，你就很难中断它了。固然，一般你能够断开整个 TCP 连接（但也不老是能够这样），但这样致使的代价就是须要经过三次握手来从新创建一个新的TCP链接。

一个更好的方案是只终止当前传输的消息并从新发送一个新的。在http2里面，咱们能够经过发送 RST_STREAM 帧来实现这种需求，从而避免浪费带宽和中断已有的链接。

2.8 流量控制

每一个http2流都拥有本身的公示的流量窗口，它能够限制另外一端发送数据。若是你正好知道SSH的工做原理的话，这二者很是类似。

对于每一个流来讲，两端都必须告诉对方本身还有足够的空间来处理新的数据，而在该窗口被扩大前，另外一端只被容许发送这么多数据。

只有数据帧会受到流量控制。

总结

咱们来概括一下使用 HTTP2 能带来的好处：

• 更小的传输体积，更小或者省略重复的头消息
• 突破原有的 TCP 链接并发限制，使用一个 TCP 链接便可实现多请求并发，单连接也能减轻服务端的压力（更少的内存和 CPU 使用）
• 解决 HOLB 线头问题，慢的请求或者先发送的请求不会阻塞其余请求的返回
• 结合 CDN 提供实时性更高，延迟更低的内容分发代理服务，大大减小白屏时间
• 数据传输优先级可控，使网站能够实现更灵活和强大的页面控制
• 能在不中断 TCP 链接的状况下中止（重置）数据的发送

---

本文主要是学习笔记和我的理解，首发于 xlaoyu.info， 部分图片和文字引用网络，侵删。

参考文章：

1. Ideal HTTP Performance 做者是 Mark Nottingham，IETF HTTP Working Group 的主席，Akamai 公司的首席架构师。
2. TCP那些事
3. HTTP2概述
4. HTTP2讲解
5. HTTP/2 is here, let’s optimize! Ilya Grigorik, Velocity SC 2015
6. rfc7540
7. HTTP2的总结
8. HTTP2.0 的奇妙平常 -- alloyteam