通信技术|从起源到发展详说HTTP从1到3的演变( 四 ) 从起源到发展|详

文章图片

而如上图所示，SPDY 位于 HTTP 之下，TCP 和 SSL 之上，这样可以轻松兼容老版本的 HTTP 协议同时可以使用已有的 SSL 功能。
SPDY 协议在 Chrome 浏览器上证明可行以后，就被当作 HTTP/2 的基础，主要特性都在 HTTP/2 之中得到继承。
于是时间来到 2015 年，HTTP/2.0 问世。
HTTP/2 相比 HTTP/1.1 的修改并不会破坏现有程序的工作，但是新的程序可以借由新特性得到更好的速度。
HTTP/2 保留了 HTTP/1.1 的大部分语义，例如请求方法、状态码、乃至 URI 和绝大多数 HTTP 头部字段一致。而 HTTP/2 采用了新的方法来编码、传输客户端和服务器间的数据。
来看看 HTTP/2 的具体特点：

二进制分帧层：在应用层与传输层之间增加一个二进制分帧层，以此达到在不改动 HTTP 的语义，HTTP 方法、状态码、URI 及首部字段的情况下，突破 HTTP/1.1 的性能限制，改进传输性能，实现低延迟和高吞吐量。在二进制分帧层上，HTTP/2.0 会将所有传输的信息分割为更小的消息和帧，并对它们采用二进制格式的编码，其中 HTTP1.x 的首部信息会被封装到 Headers 帧，而我们的 request body 则封装到 Data 帧里面。
多路复用：对于 HTTP/1.x，即使开启了长连接，请求的发送也是串行发送的，在带宽足够的情况下，对带宽的利用率不够，HTTP/2.0 采用了多路复用的方式，可以并行发送多个请求，提高对带宽的利用率。
数据流优先级：由于请求可以并发发送了，那么如果出现了浏览器在等待关键的 CSS 或者 JS 文件完成对页面的渲染时，服务器却在专注的发送图片资源的情况怎么办呢？HTTP/2.0 对数据流可以设置优先值，这个优先值决定了客户端和服务端处理不同的流采用不同的优先级策略。
服务端推送：在 HTTP/2.0 中，服务器可以向客户发送请求之外的内容，比如正在请求一个页面时，服务器会把页面相关的 logo，CSS 等文件直接推送到客户端，而不会等到请求来的时候再发送，因为服务器认为客户端会用到这些东西。这相当于在一个 HTML 文档内集合了所有的资源。
头部压缩：使用首部表来跟踪和存储之前发送的键值对，对于相同的内容，不会再每次请求和响应时发送。
HTTP/2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS 。
HTTP/2.0 消息头的压缩算法采用 HPACK，而非 SPDY 采用的 DEFLATE 。

QUIC 和 HTTP3
虽然 HTTP/2 提高了网页的性能，但是并不代表它已经是完美的了，HTTP/3 就是为了解决 HTTP/2 所存在的一些问题而被推出来的。随着时间的演进，越来越多的流量都往手机端移动，手机的网络环境会遇到的问题像是封包丢失机率较高、较长的 Round Trip Time (RTT)和连接迁移等问题，都让主要是为了有线网路设计的HTTP/TCP协议遇到贫颈。
我们可以看两个典型的问题。
第一握手带来的消耗。HTTP/2 使用 TCP 协议来传输的，而如果使用 HTTPS 的话，还需要使用 TLS 协议进行安全传输，而使用 TLS 也需要一个握手过程，这样就需要有两个握手延迟过程：

在建立 TCP 连接的时候，需要和服务器进行三次握手来确认连接成功，也就是说需要在消耗完 1.5 个 RTT 之后才能进行数据传输。
进行 TLS 连接，TLS 有两个版本——TLS 1.2 和 TLS 1.3，每个版本建立连接所花的时间不同，大致是需要1~2个 RTT 。

总之，在传输数据之前，我们需要花掉 3～4 个 RTT 。
第二，TCP 的队头阻塞并没有得到彻底解决。我们知道，为了实现多路复用，在 HTTP/2 中多个请求是跑在一个 TCP 管道中的。但当出现了丢包时，HTTP/2 的表现反倒不如 HTTP/1.X 了。因为 TCP 为了保证可靠传输，有个特别的丢包重传机制，丢失的包必须要等待重新传输确认，HTTP/2 出现丢包时，整个 TCP 都要开始等待重传，那么就会阻塞该 TCP 连接中的所有请求。而对于 HTTP/1.1 来说，可以开启多个 TCP 连接，出现这种情况反到只会影响其中一个连接，剩余的 TCP 连接还可以正常传输数据。
至此，我们很容易就会想到，为什么不直接去修改 TCP 协议？其实这已经是一件不可能完成的任务了。因为 TCP 存在的时间实在太长，已经充斥在各种设备中，并且这个协议是由操作系统实现的，更新起来非常麻烦，不具备显示操作性。
HTTP/3 乘着 QUIC 来了。

文章图片

HTTP3 是基于 QUIC 的协议，如上图。先说 QUIC，QUIC 协议是 Google 提出的一套开源协议，它基于 UDP 来实现，直接竞争对手是 TCP 协议。QUIC 协议的性能非常好，甚至在某些场景下可以实现 0-RTT 的加密通信。
在 Google 关于 QUIC [http://techimg88.guangdonglong.com/img.php?https://docs.google.com/document/d/1gY9-YNDNAB1eip-RTPbqphgySwSNSDHLq9D5Bty4FSU/edit] 的文件中提到，与 HTTP/2 相比，QUIC 主要具有下列优势：