伯阳的网络笔记（三）：HTTP/2

由于疫情期间在外当志愿者，晚上回家无聊翻翻网络知识，权当记录了。
初始动笔：2019-02-06
修改时间：2019-03-27
GitHub Repo：BoyangBlog

1. HTTP/1.x 的问题

不得不说， HTTP/1.1 是一个伟大的协议，如今仍然有很是多的网站使用它，充分说明了它的健壮、巧妙。可是，它毕竟是一个建立于互联网时代前的协议，虽然已经颇有预见性了，可是仍然有些过期了。主要有如下几个问题：

1. HTTP 只容许每一个 TCP 链接有一个未完成的请求，会有队首阻塞的问题；
2. 对于同一个域名，浏览器最多能够同时建立 6~8 个 TCP 链接；
3. Header 有点过大了；
4. 为了尽量减小请求数，须要作合并文件、减小图像等优化工做，可是这无疑形成了单个请求内容变大延迟变高的问题；
5. 明文传输。

因此，随着求变的声音愈来愈多，HTTP/2 应声而出。

2. SPDY

等一下，正式讲到 HTTP/2 以前，咱们须要先提一下 SPDY。

由于迟迟没有 HTTP/1.1 的优化出线，谷歌本身推出了一个新的网络协议，叫作 SPDY，它的不少设计，被采用到了 HTTP/2 当中，好比说多路复用、二进制分帧、头部压缩、服务器推送等等。

3. HTTP/2 简介

在2012年，W3C向社会征求 HTTP/2 的建议，而后决定将 SPDY 当作制定标准的基础。目标上， HTTP/2 致力于突破上一代协议众所周知的性能限制，对 HTTP/1.x 进行扩展，而非替代，核心概念不会改变。下图展现了 HTTP/1 和 HTTP/2 的区别。

它作了不少改变，下面细讲。 不过在讲以前，要先解释 HTTP/2 中的几个概念：

• 流
  已创建的链接上的双向字节流
• 消息
  与逻辑消息对应的完整的一系列数据帧
• 帧
  HTTP/2 通讯的最小单位

全部的 HTTP/2 通讯都是在一个 TCP 链接上完成，这个链接能够承载任意数量的双向数据流。相应的，每一个数据流以消息的形式发送，而消息由一个或多个帧组成，这些帧能够乱序发送，而后再根据每一个帧首部的流表示符从新组装。

二进制分帧

HTTP/2 性能加强的核心，全在于新增的二进制分帧层，它定义了如何封装 HTTP 消息并在客户端与服务器之间传输。

这里的”层”，指的是位于会话层和应用层之间的一个新的机制：HTTP 的语义不受影响，不一样的是传输期间对它们的编码方式改变了。HTTP/1.x 以换行符做为纯文本的分隔符，而 HTTP/2 将全部传输的信息分割为更小的消息和帧，并对他们采用了二进制格式的编码。

多向请求和响应

在 HTTP/1.x 中，若是客户端想要发送多个并行的请求以改进性能，那么必须使用多个 TCP 链接；每一个链接每次只交付一个响应，多个响应必需要排队。更糟糕的在于，这样很是容易发生队首堵塞，从而形成 TCP 链接效率低下。

HTTP/2 中的二进制分帧，突破了这种限制，客户端和服务器能够把 HTTP 消息分解为互不依赖的帧，而后乱序发送，而后在另外一端把他们从新组合起来。以下如所示。

将 HTTP 消息分解为独立的帧，交错发送，而后在另一端从新组装是 HTTP/2 最重要的一项加强。它带来了如下几个优势：

• 能够并行交错的发送请求，请求之间互不影响；
• 能够并行交错的发送响应，响应之间互不干扰；
• 只使用一个链接便可并行发送多个请求和响应（多路复用）；
• 消除没必要要的延迟；
• 没必要再继续在为了绕过 HTTP/1.x 的限制作不少工做；
• ......

总之，这个技术解决了 HTTP/1.1 中存在的队首阻塞问题，也消除了并行处理和发送请求及响应时对多个链接的依赖。

流量控制

在同一个 TCP 上传输多个数据流，就意味着要共享带宽。标定数据流的优先级有助于按序交付，但只有优先级还不足以肯定多个数据流或多个链接之间的资源分配。因此，HTTP/2 提供了一个简单的机制：

• 流量控制基于每一跳进行，而非端到端的控制；
• 流量控制基于窗口更新帧进行，即接收方广播本身准备接受某个数据流的多少字节，以及对整个链接要接收多少字节；
• 流量控制窗口大小经过 WINDOW_UPDATE 帧更新；

咱们能够发现，它和 TCP 流量控制很是相似，事实上这两个机制是同样的。

这个由程序员手动控制。

服务器推送

服务器能够对一个客户端请求发送多个响应。换句话说，除了对最初请求的响应外，服务器还能够额外向客户端推送资源，而无需客户端明确地请求。

由于有些资源，好比去线上阅读说一本书，就能够预测到下一步可能的阅读的页面，进而提早进行缓存。

首部压缩

HTTP 的每一次通讯都会带一组完整的首部，用于描述传输的资源及其属性。在 HTTP/1.1 中，这些数据都是以纯文本的形式发送的，一般会给每一个请求增长 500~800 字节的负荷；若是再算上 cookie ，增长的负荷可能会加大到上千字节。为了减小这些开销，HTTP/2 会压缩首部数据。

HTTP/2 链接的两端都知道已经发送了哪些首部，这些首部是什么，从而能够针对以前的数据只编码发送差别数据。

4. 加密

虽然一直有加入 TLS 的提议，可是最后 HTTP/2 并未强制加入 TLS。只是有些网站会加上。

5. HTTP/2 和 HTTP/3

HTTP/2 依然是以 TCP 做为基础的，可是 TCP 依然会有三次握手消耗时间，为了优化它，谷歌专门搞了一个基于 UDP 协议的 QUIC 协议。这个协议正在被一些大厂使用，可是由于源于 UDP 协议，有可能被运营商破坏，前景依然须要观察。

QUIC的相关原理能够查看科普：QUIC协议原理分析这篇文章。

总结

总的来讲，HTTP/2 是基于 HTTP/1.1 进行的拓展，有效的优化了速度和数据量。在多路复用、二进制分帧、头部压缩、服务器推送上的优化很是的精妙和让人陶醉。

引用

RFC7540:Hypertext Transfer Protocol Version 2 (HTTP/2)

SPDY Wiki

《Web性能权威指南》