一文领略 HTTP 的前世今生( 三 ) _HTTP

新增缓存的控制和管理。

加入了 Host 头，用在你一台机子部署了多个主机，然后多个域名解析又是同一个 IP，此时加入了 Host 头就可以判断你到底是要访问哪个主机。

文章插图

可以看到浏览器大战推进了 Web 的发展，也暴露出 HTTP/1.0 的不足之处，毕竟网络带宽等等都在进步，总不能让协议限制了硬件的发展。
因此提出了 HTTP/1.1，主要是为了解决性能的问题，包括支持持久连接、pipeline、缓存管理等等，也添加了一些特性。
再后来到 2014 年对 HTTP/1.1 又做了一次修订，因为其太过庞大和复杂，因此进行了拆分，弄成了六份小文档 RFC7230 - RFC7235
这时候 HTTP/1.1 已经成了标准，其实标准往往是在各大强力竞争对手相对稳定之后建立的，因为标准意味着统一，统一就不用费劲心思去兼容各种玩意。
只有强大的势力才能定标准，当你足够强大的时候你也可以定标准，去挑战老标准。
HTTP 2 时代随着 HTTP/1.1 的发布，互联网也开始了爆发式的增长，这种增长暴露出 HTTP 的不足，主要还是性能问题，而 HTTP/1.1 无动于衷。
这就是人的惰性，也符合平日里我们对产品的演进，当你足够强大又安逸的时候，任何的改动你是不想理会的。
别用咯。
这时候 google 看不下去了，你不搞是吧？我自己搞我的，我自己和我自己玩，我用户群体大，我有 Chrome，我服务多了去了。
Google 推出了 SPDY 协议，凭借着它全球的占有率超过了 60% 的底气，2012年7月，开发 SPDY 的小组公开表示，它正在努力实现标准化。
HTTP 坐不住了，之后互联网标准化组织以 SPDY 为基础开始制定新版本的 HTTP 协议，最终在 2015 年发布了 HTTP/2 。
HTTP/2 版本主要增加以下几点：

是二进制协议，不再是纯文本。
支持一个 TCP 连接发起多请求，移除了 pipeline 。
利用 HPACK 压缩头部，减少数据传输量。
允许服务端主动推送数据。

从文本到二进制其实简化了整齐的复杂性，解析数据的开销更小，数据更加紧凑，减少了网络的延迟，提升了整体的吞吐量。

文章插图

支持一个 TCP 连接发起多请求，即支持多路复用，像 HTTP/1.1 pipeline 还是有阻塞的情况，需要等前面的一个响应返回了后面的才能返回。
而多路复用就是完全异步化，这减少了整体的往返时间（RTT），解决了 HTTP 队头阻塞问题，也规避了 TCP 慢启动带来的影响。
HPACK 压缩头部，采用了静态表、动态表和哈夫曼编码，在客户端和服务器都维护请求头的列表，所以只需要增量和压缩过的头部信息，服务端拿到之后组装一下就能得到完整的头部信息。
形象一点就是如下图所示：

文章插图

再具体一点就是下图这样：

文章插图

服务端主动推送数据，这个其实就是减少了请求的次数，比如客户端请求 1.html，我把 1.html 需要的 js 和 css 也一块送过去，省的之后客户端再请求我要 js，我要这个 css 。
可以看到 HTTP/2 的整体演进都是往性能优化的角度发展，因为此时的性能就是痛点，任何东西的演进都是哪里痛医哪里。
当然有一些例外，比如一些意外，或者就是“闲的蛋疼”的那种捯饬。
这次推进属于用户揭竿而起为之，你再不给我升级我自己搞了，我有着资本，你自己掂量。
最终结果是好的，Google 后来放弃了 SPDY，拥抱标准，而 HTTP/1.1 这个历史包袱太重了，所以 HTTP/2 到现在也只有大致一半的网站使用它。

文章插图

HTTP 3 时代这 HTTP/2 还没捂热，HTTP/3 怎么就来了？
这次又是 Google，它自己突破自己，主要也是源自于痛点，这次的痛点来自于 HTTP 依赖的 TCP 。
TCP 是面向可靠的、有序的传输协议，因此会有失败重传和按序机制，而 HTTP/2 是所有流共享一个 TCP 连接，所以会有 TCP 层面的队头阻塞，当发生重传时会影响多个请求响应。
并且 TCP 是基于四元组（源IP，源端口，目标IP，目标端口）来确定连接的，而在移动网络的情况下 IP 地址会频繁的换，这会导致反复的建连。