从起源到发展 详说HTTP从1到3的演变

HTTP/1.1 自从 1997 年发布以来，我们已经使用 HTTP/1.x 相当长一段时间了。但随着互联网近十年爆炸式的发展，从当初网页内容以文本为主，到现在以富媒体（如图片、声音、视频）为主，而且对页面内容实时性高要求的应用越来越多（比如聊天、视频直播），所以当时协议规定的某些特性，已经逐渐无法满足现代网络的需求了。

如果你有仔细观察，那些最流行的网站首页所需要下载资源的话，会发现一个非常明显的趋势。近年来加载网站首页需要下载的数据量在逐渐增加，并已经超过了 2100K。但在这里我们更关心的是：平均每个页面为了完成显示与渲染所需要下载的资源数也已经超过了 100 个。

基于此，在 2010 年到 2015 年，谷歌通过实践一个实验性的 SPDY 协议，证明了一个在客户端和服务器端交换数据的另类方式。其收集了浏览器和服务器端的开发者的焦点问题，明确了响应数量的增加和解决复杂的数据传输。在启动 SPDY 这个项目时预设的目标是：

• 页面加载时间 （PLT） 减少 50%。

• 无需网站作者修改任何内容。

• 将部署复杂性降至最低，无需变更网络基础设施。

• 与开源社区合作开发这个新协议。

• 收集真实性能数据，验证这个实验性协议是否有效。为了达到降低目标，减少页面加载时间的目标，SPDY 引入了一个新的二进制分帧数据层，以实现多向请求和响应、优先次序、最小化及消除不必要的网络延迟，目的是更有效地利用底层 TCP 连接。

**HTTP/1.1 有两个主要的缺点：安全不足和性能不高，**由于背负着 HTTP/1.x 庞大的历史包袱，所以协议的修改，兼容性是首要考虑的目标，否则就会破坏互联网上无数现有的资产。

而如上图所示，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 连接还可以正常传输数据。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!