在之前的课程帖子中，我们讨论了网络技术。这也是网络技术的一部分内容，通常被称为HTTP/2。

HTTP 当前状态

HTTP 1.1 已经成为互联网上几乎用于一切事物的协议。在协议和基础设施上的大量投资已经使这一点变得可能，以至于现在基于 HTTP 构建新事物通常比创建全新的东西更容易。

HTTP 1.1 的请求密集度

当 HTTP 最初被创建并发布时，它可能被认为是一个简单直接的协议。然而，事实证明最初的看法错了。RFC 1945 定义的 HTTP 1.0 于 1996 年发布，是一份长达 60 页的规范。仅三年后，在 1999 年，描述 HTTP 1.1 的 RFC 2616 发布，已显著增加到 176 页。随后由 IETF 开发的更新将规范拆分成了六个文档，总页数显著增加（RFC 7230 及其系列规范）。无论从哪个角度看，HTTP 1.1 都是相当详尽的，包括了许多细节、微妙之处，还有大量的可选组件。

有很多选择

HTTP 1.1 的性质，具有众多复杂细节及为未来扩展预留的选项，培育了一个软件生态系统，在其中几乎没有实现能够完全实现协议的所有方面。确实，确切地定义“所有内容”本身就相当困难。这导致了那些最初未充分利用的功能得到的支持很少，而实现这些功能的则发现其实用场景很少。

随后，这导致了互操作性问题的产生，当客户端和服务器开始更多地使用这些不太常见的功能时。HTTP 管道便是个典型例子。

TCP 使用不充分

HTTP 1.1 很难完全利用 TCP 提供的强大性能，所以浏览器和 HTTP 客户端必须采取创新措施来缩短页面加载时间。

多年来不断的努力增加了替换TCP的难度，这激励了人们继续改进TCP本身及其上层协议的工作。

本质上，TCP 的能力可以更好地利用，以减少暂停和未被使用的间隔，这些间隔原本可以用于数据传输和接收。接下来的部分将详细讨论其中的一些不足之处。

转储大小和对象数目:

对热门网站及其首页加载所需资源的分析表明了一个明显的趋势。随着时间的推移，所需的数据量稳步增长，达到了1.9 MB以上。更值得注意的是，平均而言，显示一个页面需要超过100个单独的资源。

如附图所示，这一趋势已经持续了一段时间，并没有显示出任何即将的变化。该图显示了全球访问量最大的网站在过去四年中所需的总传输量（绿色显示）和总请求数量（红色显示）的增长。

低时延敏感性

HTTP 1.1 显示出对延迟的高度敏感性，部分原因是 HTTP 管道传输仍然存在很多问题，导致很多用户禁用了它。

尽管近年来许多用户的可用带宽大幅增加，但在减少延迟方面却没有观察到类似的改进。高延迟连接在许多当前移动技术中都很常见，即使有高带宽连接，也会阻碍满意的快速上网体验。

此外，对于实时视频应用来说，低延迟时间至关重要，例如视频会议和在线游戏，其中实时传输是主要内容传输方式。

队首阻塞

HTTP管线传输允许发送后续请求，即使还在等待先前请求的响应。这种机制与在银行或超市排队的情况非常相似。在这种情况下，无法预料前一位顾客会迅速完成还是会有长时间的等待。这种固有局限性被称为“首部阻塞”。

尽管一个人可能会试图选择最有前途的队伍，甚至可能创建一个新的队伍，但最终，必须做出决定。一旦选择了队伍，就不能再换了。

创建一个新的队列也会带来性能和资源开销，因此，当队列数量超过一定限度时，扩展就不切实际了。因此，这个问题就没有理想的解决方案了。

作为对这些情况的证明，当前大多数桌面网络浏览器默认禁用了这项技术，这项技术指的是 HTTP 连接复用功能。

应对延迟问题

遇到问题时，人们常常一起合作找到变通方法。虽然其中一些方法既聪明又实用，但另一些则显得不靠谱且构思拙劣。

做角色

"Spriting" 是一个常用术语，用来描述将多个小图片拼合成一个大图片的做法。随后，通过 JavaScript 或 CSS 技术，从这个大图片中提取特定区域并显示为单独的小图片。

网站常常使用这种技术来提升性能。在HTTP 1.1协议下，获取一张较大的图片比获取多张较小的独立图片更快。

然而，这种技术也带来了一些缺点。网站上只需要少量小图的页面加载较大的合并图像时会遭受性能损失。此外，一旦缓存被清除，所有精灵图会一起被删除，而不是允许保留常用的图片。

内联函数

"Inlining"代表了一种替代技术，用于避免单独传输图像文件，这种方法是直接在CSS文件中嵌入数据URL。这种方法与之前提到的图像拼合方法有类似的优点和缺点。

/* 下面的 CSS 代码用于设置 .icon1 和 .icon2 的背景图像 */

    .icon1 {
       background: url(data:image/png;base64,<data>) no-repeat;
    }

    .icon2 {
       background: url(data:image/png;base64,<data>) no-repeat;
    }

全屏模式 退出全屏

JavaScript 字符串拼接

大型网站常常会积累许多不同的JavaScript文件。为了缓解这种状况，开发人员可以使用前端工具将多个脚本合并为一个，从而让浏览器只需加载一个较大的文件，而不是多个较小的文件。然而，这种方法会在仅需要部分脚本时传输不必要的大量数据，并且在进行小的修改后需要重新加载大量不必要的数据。

这种做法主要给参与其中的开发者带来了一些麻烦。

资源分区

要讨论的最终一种技术通常被称为“分片技术”。这涉及将服务的不同部分尽可能地分散到不同的主机上。乍一看可能有些反直觉，但实际上这种方法背后有着合理的逻辑。

最初的 HTTP 1.1 规范规定每个客户端对每个主机最多只能有两个 TCP 连接。为了规避这一限制以便在不违反规范的情况下，一些大网站使用了多个不同的域名，从而实现了更多并发连接，减少了页面加载时间。

尽管这一限制已被取消，现代客户端依然受到连接数的限制，通常为每个主机名使用六到八个连接。因此，网站继续采用资源分片的方式来进一步增加并发连接的数量。随着通过HTTP请求的对象数量继续增加（如前所述），增加的连接数被用来提高HTTP性能并加快页面加载速度，从而更好地服务用户。现在，一些网站通过这种方法使用超过50甚至多达100个并发连接来加载单个网站的情况并不罕见。来自httparchive.org的最新数据显示，全球前30万个URL平均需要40个TCP连接来显示网站，而这一数字随着时间的推移正逐渐增加。

另一个将资源分片的动机是将图片和类似资源托管在不传输 cookies 的单独域名上，因为 cookie 的大小可能相当可观。通过使用不传输 cookie 的图片服务器，可以显著减少 HTTP 请求的大小，从而提高网站性能。

下面的图显示了浏览一个流行的瑞典网站时的数据包跟踪情况，展示了请求如何分发到多个主机名上。

HTTP 协议更新

开发一个更优的协议将会有利。

• 降低了延迟敏感性
• 解决了流水线问题以及队首阻塞问题
• 减少了与每个主机连接数量的不断增加的需求
• 保留了原有的接口、内容、URI格式和方案
• 由IETF的HTTPbis工作组开发

互联网工程任务组 (IETF) 和 HTTP 版本二

互联网工程任务组（IETF）是一家负责制定和推广互联网标准的组织，主要在协议层面。他们因发布一系列RFC文档（如TCP、DNS、FTP、HTTP等）而广受认可，这些文档详细描述了各种协议和最佳实践，其中一些协议变体并未得到广泛采用。

在IETF中，会建立专门的“工作小组”，每个小组都有特定的范围和目标。这些小组定义一份“章程书”，概述其交付成果的指导原则和限制条件。讨论和开发对所有人都是开放的，每个人的意见和贡献都会被平等看待，无论所属公司的背景。

HTTPbis工作组（这个名字稍后会解释）成立于2007年夏天，目的是更新HTTP 1.1规范。这个小组在2012年末真正开始了下一代HTTP协议的相关讨论。HTTP 1.1的更新在2014年初完成，最终形成了RFC 7230系列。

HTTPbis工作组（HTTPbis Working Group）的最终的互操作性会议于2014年6月初在纽约市举行。随后的讨论以及按照IETF的程序以最终确定官方RFC一直持续到次年。

值得注意的是，HTTP领域的一些著名实体并未参与工作组的讨论和会议。虽然我不会提及具体的公司或产品名称，显然，当前互联网生态中的某些利益相关方确信，IETF可以在没有他们直接参与的情况下取得成功。

HTTPbis 中 'bis' 的由来

工作组被叫做HTTPbis，后缀“bis”来自拉丁语“两次”。在IETF中，“bis”通常用作后缀或名称的一部分，表示规范的更新或第二次版本。在这种特定情况下，它表示对HTTP 1.1的更新。

HTTP/2 的起源与 SPDY 密切相关

SPDY 是一种由谷歌开发和倡导的协议（Protocol）。尽管其开发过程公开并邀请了社区参与，但很明显，谷歌从控制一个流行浏览器版本和一个支持广泛使用的服务的强大服务器基础设施中获益。

当HTTPbis小组开始着手开发HTTP/2时，SPDY已经证明是一个可行的概念，并证明了其在互联网上的可部署性。此外，公开展示的数据验证了其性能。HTTP/2的开发始于SPDY/3草案文件，并通过相对简单的查找和替换过程，SPDY/3草案被转换成了HTTP/2草案00版本。

HTTP/2 的主要概念

那么，HTTP/2 的主要成就有哪些？HTTPbis 组在开发过程中设定了哪些范围？

实际上，规定的限制实际上非常严格，极大限制了团队的创新空间。具体来说：

• HTTP/2 必须维持已确立的 HTTP 原则。它仍然是一种客户端通过 TCP 向服务器发送请求的协议。
• http:// 和 https:// URL 必须保持不变，无法修改，不允许有新的方案。大量的现有内容使用了这些 URL，无法进行修改。
• 预计 HTTP/1.1 服务器和客户端将使用几十年；因此，将它们代理到 HTTP/2 服务器是基本需求。
• 因此，代理必须能够对 HTTP/2 特性和 HTTP/1.1 客户端之间进行一对一的对应。
• 移除或减少可选协议组件受到强烈鼓励。这不是一个严格要求，而是一个从 SPDY 和 Google 团队中得出的指导原则，确保所有功能的强制实施可以避免由于部分或选择性实现而导致的未来兼容性问题。
• 明确禁止了小版本的更新。确定客户端和服务器将要么完全兼容 HTTP/2，要么完全不兼容。如果有需要扩展或修改协议，则将启动 HTTP/3 协议。HTTP/2 不会包含小版本更新。

HTTP/2 的与现有 URI 方案的兼容性

如前所述，现有的URI方案不能被更改；因此，HTTP/2必须使用这些现有方案。由于它们目前用于HTTP 1.x，需要一种机制将协议升级到HTTP/2版本，或者明确要求服务器使用HTTP/2而不是旧协议。

HTTP/1.1 定义了 Upgrade: 标头，以实现此目的，这使得服务器可以在收到旧协议请求时使用新协议响应。不过，这样做会增加一次额外的通信往返。

SPDY团队认为这种往返带来的额外开销是不可接受的，他们专门在TLS上实现SPDY，因此开发了一个新颖的TLS扩展，以显著加快协商过程的速度。这个扩展称为Next Protocol Negotiation（NPN，协议名称协商），允许服务器告知客户端支持的协议，从而让客户端能够根据支持的协议选择其偏好协议。

HTTP/2 与 TLS，你知道吗？

在 HTTP/2 的开发中，一个重要关注点是确保其在 TLS 上的正确运作。虽然 SPDY 强制要求使用 TLS，并且有很多人提倡将 TLS 作为 HTTP/2 的强制要求，但最终未能达成一致意见，HTTP/2 最终将 TLS 作为可选组件发布。然而，两个主要的网络浏览器——Mozilla Firefox 和 Google Chrome 的主要开发者明确表示，他们打算仅通过 TLS 来实现 HTTP/2。

选择只使用TLS实现的原因包括对用户隐私的重视以及早期数据显示这些新协议的成功率在使用TLS时更高。这归因于普遍认为端口80上的流量仅包含HTTP/1.1，导致一些中间网络设备在该端口上使用其他协议时会干扰或阻断流量。

强制 TLS 的主题在邮件列表和会议中引发了激烈的辩论和不同的意见，人们对它的利弊各有利弊的看法。这是一个高度争议的话题，在与 HTTPbis 参与者讨论这一主题时，讨论时务必小心。

类似的，长期以来一直存在争论，即在使用TLS时，是否应该强制采用特定的一组密码套件，或者是否应该禁止某些密码套件，或者是否应该避免对TLS“层”提出任何要求，而是将这些要求交由TLS工作组处理。最终的规范规定，TLS版本必须至少为1.2，并且会对密码套件进行限制。

HTTP/2 的 TLS 协议协商过程：

NPN（Next Protocol Negotiation）最初用于与TLS服务器协商SPDY连接。鉴于NPN作为非标准协议的局限性，它被提交给IETF，这最终促成了应用层协议谈判（ALPN）的开发。现在ALPN被推荐用于HTTP/2，而SPDY客户端和服务器依旧使用NPN。

NPN 的初始流行以及 ALPN 标准化过程的延长导致许多早期的 HTTP/2 客户端和服务器在协商 HTTP/2 协议时同时实现了这两种扩展。此外，由于 NPN 用于 SPDY，而许多服务器支持 SPDY 和 HTTP/2，因此，在这些服务器上同时实现 NPN 和 ALPN 是合乎逻辑的。

ALPN 和 NPN 的主要区别在于选择协议的方式。在 ALPN 中，客户端给出一个它偏好的协议列表，按优先级排序，由服务器从中挑选一个它支持的协议；而在 NPN 中，客户端最后决定使用哪个协议。

HTTP/2 通过明文 HTTP 进行协商

正如前面提到的，在使用纯文本 HTTP/1.1 时，通过使用 Upgrade: 标头与服务器协商 HTTP/2。如果服务器支持 HTTP/2，它将返回 "101 协议升级" 的响应代码，然后连接将使用 HTTP/2。虽然这个升级过程需要额外的网络交互，但通过保持持久的 HTTP/2 连接，可以实现比典型的 HTTP/1.1 连接更高的重用。

尽管一些浏览器开发者已经表明他们不会采用这种HTTP/2协商方式，微软的Internet Explorer团队曾表达过支持这种方法的意愿，但最终并未实现。curl工具及其他非浏览器客户端确实支持纯文本的HTTP/2。

目前，没有任何主要的浏览器不使用 TLS 就不支持 HTTP/2。

HTTP/2 协议详解

在具备了足够的背景知识，包括历史背景，以及导致现状的政治因素之后，我们现在将开始对HTTP/2协议进行详细探讨。接下来，我们将探讨构成其框架的具体技术和概念。

HTTP/2 的二进制分帧

HTTP/2 就是一个二进制传输协议。

这一决定值得花一点时间考虑。那些对互联网协议有经验的人可能会本能地对这个选择感到不满，他们可能会引用支持文本协议的论点，特别是这种可读性，这使得人们可以手动创建请求，比如使用Telnet这样的工具。

然而，HTTP/2 使用二进制格式来简化帧的结构。确定帧的开始和结束在 HTTP/1.1 和其他基于文本的协议中颇具挑战性。通过去除可选的空格和表示相同数据的多种方式，这样可以大大降低实现的复杂度。

此外，这种二元结构使得协议的核心组件和数据帧更容易区分开来，相比之下，HTTP/1.1 中这两者是混在一起的。

HTTP/2 内建的压缩功能及其频繁使用 TLS，降低了文本协议的实用性，因为数据通常不会以明文形式传输。因此，我们需要使用像 Wireshark 这样的工具来分析 HTTP/2 协议，进行准确的协议级分析。

这可能需要使用专门的工具，例如 curl，或者使用 Wireshark 的 HTTP/2 解析器来分析网络流。

二进制帧格式

HTTP/2 使用二进制帧来传输数据。定义了各种类型的帧，每种帧都有相同的结构：长度、类型、标志、流标识符和帧负载。

HTTP/2 规范定义了十种不同的帧类型，这些帧类型中，DATA 和 HEADERS 帧是最基本的，它们映射到 HTTP/1.1 的特性。我们将在后续部分提供更多关于这些帧类型的细节。

在 HTTP/2 中的多路复用流

流标识符，如前所述，将每个通过 HTTP/2 传输的数据帧与特定的“流”相关联。流被定义为一个在客户端和服务器之间的单一 HTTP/2 连接中双向独立的数据帧序列。

一个 HTTP/2 连接可以同时支持多个并发流，允许任一端点交错来自不同流的帧以实现并发处理。流可以由任一端点单独发起和使用，也可以被客户端和服务器共享，并且可以由任一方终止。流中帧的传输顺序至关重要，因为接收方会按照接收到的顺序来处理帧。

多路复用数据包涉及将来自多个数据流的数据包混合到单个连接中。两个或更多的独立数据流被组合成一个单一的流，并在接收端被分开。

流优先级与依赖项

每个 HTTP2 流都分配了一个优先级，也称为“权重”，这传达给对等方该流的相对重要性。这样服务器在资源不足时就可以按优先级顺序传输流。

通过使用PRIORITY帧，客户端可以声明一个流与其他流之间的依赖关系。此机制允许构建一个分层优先级结构，在该结构中，多个“子流（child streams）”可以依赖于“父流（parent streams）”的完成。

这些优先级权重和依赖关系可以在运行时进行动态调整。这允许浏览器指定资源的相对重要性，例如，当用户滚动一个包含许多图片的页面时。在这种情况下，浏览器可以优先下载当前在屏幕上的图片，或者在切换标签页时，浏览器可以将重点放在一组新的流上。

HTTP/2 首部压缩

HTTP本质上是无状态的。这意味着每个请求必须包含处理该请求所需的所有必要信息，不能依赖于之前的请求信息。在这种情况下，每个请求依然需要提供所有必要的信息，同样适用于HTTP/2。

这种无状态的特性导致了一定的冗余。当客户端从同一个服务器请求多个资源，例如网页中的图片时，会产生一系列几乎一模一样的请求。这种重复表明压缩可能有助于优化。

网页中对象数量的增加导致了HTTP请求的大小也随之增加，这主要是由于cookie的使用等。每次请求时都必须传输这些cookie，进一步加剧了这种冗余问题。

HTTP/1.1请求的大小已经变得非常大，以至于它们现在经常超过初始TCP窗口，导致传输速度变慢，因为在发送完整请求前需要完成一个完整的往返。这进一步说明了实施头部压缩的必要性。

压缩中的复杂之处

HTTPS和SPDY的压缩已被发现容易受到BREACH和CRIME这类攻击。通过将已知文本注入到数据流中并分析输出变化，攻击者可能推断出加密数据的内容。

在协议中对动态内容进行压缩的实现——而不易受到此类攻击的影响——需要周密的规划和细致的执行。这一直是HTTPbis团队的核心关注点。

他们设计的解决方案是 HPACK，即 HTTP/2 头部压缩，顾名思义，这是一种专门针对 HTTP/2 头部设计的压缩格式。HPACK 正在另一份 Internet-Draft 中定义。这种新格式结合了其他几种对策（例如一个位禁止中介节点压缩特定头部，以及可选的帧填充功能），旨在减少利用压缩漏洞的容易程度。

HTTP/2 流重置

HTTP/1.1的一个显著的限制是在传输一个HTTP消息之后，使用指定的Content-Length很难终止这个HTTP消息。虽然通常可以通过终止底层的TCP连接来实现，但这将导致重新建立TCP连接，增加额外的开销。

更高效的解决方案是直接结束当前消息并发起新的传输。这一功能通过HTTP/2的RST_STREAM帧实现，有助于节省带宽资源，并避免拆卸和重新建立连接的麻烦，从而避免了拆卸和重新建立连接的麻烦。

服务器推送机制

该功能也被称为“缓存推送”，使服务器能够主动将可能会被请求的资源推送给客户端。当客户端请求资源X时，服务器可能会预判它接下来会请求资源Z，然后在未被明确请求的情况下提前发送资源Z给客户端。这通过将资源Z提前放入客户端缓存中来加快客户端的性能，确保在需要时资源Z随时可用。

服务器推送是一种需要客户端明确授权的机制。即使有了这样的授权，客户端仍然保留了使用RST_STREAM帧终止任何不需要的推送流的能力，如果他们不再需要某个特定资源。

HTTP/2 流量控制

在 HTTP/2 中，每个单独的流都有其自己的宣告的流量控制窗口，该窗口规定了对等方可以传输的数据量。这种机制的风格和功能类似于 SSH 中的流量控制。

对于每个流，两端都需要告知对方可用于接收的数据缓冲区大小。对方只能发送不超过通告窗口大小的数据，直到接收方扩大流量控制窗口。需要注意的是，流量控制仅适用于DATA帧。

设想一个HTTP/2的环境场景

随着HTTP/2的采用越来越多，这对它会有什么影响？毕竟，它能否真正普及？

HTTP/2 如何影响用户感受

HTTP/2目前还没有被广泛部署，因此其具体实施效果还不得而知。然而，通过我们对SPDY的观察以及从过去和当前的实验推断，我们可以合理推测它可能带来的影响。

HTTP/2 设计旨在减少必要的网络往返，并通过多路复用和快速流终止，完全解决了队首阻塞问题（即队首阻塞）。

它能够处理大量的并行处理流，甚至超过了当前分片程度最激进的网站的能力。

通过正确地应用流优先级，客户端更有可能先接收到关键数据，而不是不太重要的数据。因此，预计这将加快页面加载速度并使网站更加响应迅速，最终为用户带来更好的网络体验。

尽管这些改进的程度仍然不确定，但重要的是要注意，HTTP/2仍然是一个新兴技术。此外，我们还没有看到经过优化的客户端和服务器能够充分利用这个新协议带来的好处。

HTTP/2对网页开发意味着什么

随着时间的流逝，网页开发者以及开发环境积累了大量的技术和工具，旨在解决HTTP/1.1的限制问题。正如之前所提到的，其中一些解决方案实际上为开发HTTP/2提供了依据。

现在常用的很多变通方法，人们往往不假思索地使用，要么会降低HTTP/2的性能，要么至少无法充分利用其高级功能。具体来说，像图片拼合和内嵌这样的技术可能会在HTTP/2中适得其反，而域名分片可能会带来负面影响，因为HTTP/2的设计是希望从更少但更高效的连接中获益。

一个显著的挑战是，网页开发者必须在短期内创建和部署能够同时服务于 HTTP/1.1 和 HTTP/2 客户端的网站，而不用维护两个独立的前端实现，这使性能优化变得困难。

因此，可能要过一段时间才能完全发挥HTTP/2的潜力。

HTTP/2 实现

试图在这种文本中记录特定的实现细节本质上是不切实际的，并且很快就会变得过时。因此，我不会详细描述特定的实现，而是提供一个总体概述，并引导读者查看实现列表，以获取HTTP/2网站上维护的实现列表。

在过程的早期开发了大量的实现，这一数量在整个HTTP/2开发过程中持续增加。撰写本文时，已有超过40个实现被列出，其中大多数都符合最终规范。

HTTP/2 在 Web 浏览器中的支持

Firefox 一直走在支持 HTTP/2（超文本传输协议第二版）早期草案的前沿。Twitter 也积极采用了 HTTP/2 协议，通过该协议提供服务。Google 于 2014 年 4 月在少量测试服务器上启用了 HTTP/2 支持，并于 2014 年 5 月将其集成到了 Chrome 的开发版本中。Microsoft 展示了下一代 Internet Explorer 的 HTTP/2 支持的技术预览。Safari（包括 iOS 9 和 Mac OS X El Capitan）以及 Opera 也宣布支持 HTTP/2。

Web 服务器中的 HTTP/2 支持

已经有相当多的 HTTP/2 服务器实现可用。

从 2015 年 9 月 22 日发布的 1.9.5 版本开始，流行的 Nginx 服务器开始支持 HTTP/2。这个实现取代了 SPDY 模块，这意味着在同一服务器实例中无法同时使用这两种模块。

自2015年10月9日发布的2.4.17版本开始，Apache的httpd服务通过mod_http2模块支持HTTP/2协议。

此外，H2O、Apache Traffic Server、nghttp2、Caddy 和 LiteSpeed 都已推出支持 HTTP/2 的服务器。

其他 HTTP/2 的实现与工具

curl 和 libcurl 支持不安全连接和基于 TLS 的 HTTP/2 连接，并使用多种不同的 TLS 库。

Wireshark 还兼容 HTTP/2，因此是分析 HTTP/2 网络数据的理想工具。

关于 HTTP/2 的常见批评

在该协议的发展过程中，一直存在广泛的讨论，一些利益相关者认为最终规范有根本性的缺点。现在，我将提出一些常见的批评意见，以及对这些批评的反驳。

Google 在 HTTP/2 发展中的疑云

一个常见的批评是，HTTP/2是由谷歌设计或控制的，有些说法甚至认为该协议使互联网进一步依赖或受制于谷歌。这种说法并不准确。该协议是在IETF内开发的，遵循了已经使用了30多年的既定程序。谷歌通过SPDY做出了重大贡献，不仅展示了部署新协议的可能性，还提供了定量数据，证明了潜在的性能改进。

在一次公开声明中，Google 宣布将在 2016 年从 Chrome 中移除对 SPDY 和 NPN 的支持，并鼓励服务器迁移到 HTTP/2。2016 年 2 月，他们进一步宣布，SPDY 和 NPN 将在 Chrome 51 中被彻底移除。因此，自 2016 年 Chrome 51 版本以来，Chrome 版本不再支持 SPDY 和 NPN。

HTTP/2在浏览器之外的实用性有限

确实，有人认为HTTP/2的主要优势在于优化网页浏览器的表现。开发HTTP/2的一个关键动机是解决HTTP管线化中的问题。如果特定应用场景并不需要管线化，采用HTTP/2可能不会带来显著的改进。虽然管线化只是HTTP/2众多改进中的一项，但它确实是一个引人注目的改进。

不过，随着服务开始利用单一连接上的多路复用流的能力，我们可能会看到HTTP/2在浏览器之外的应用增多。

较小的 REST API 以及其他简单的 HTTP/1.x 编程用途可能并不会觉得过渡到 HTTP/2 有什么特别的好处，然而，对于大多数用户而言，实现 HTTP/2 一般不会带来什么明显的坏处。

HTTP/2 所谓的仅限大型网站说法

这个说法是不准确的。HTTP/2的多路复用功能旨在显著提升高延迟连接下的用户体验，这种情况在小型网站中较为常见，这些网站通常缺乏广泛的地理分布。相比之下，大型网站通常已经从更快的速度和更广泛的分布中获益，从而为用户带来了更快的响应时间。

HTTP/2 的这种二元特性让人无法接受

承认文本协议的可读性在调试和跟踪方面有优势。然而，文本协议也更容易出现错误，这给解析带来了更大的挑战，并可能导致解析问题。此外，二进制协议设计成可以在各种编程语言之间通用，而不仅仅局限于英语。

关于HTTP/2二进制特性的担忧在一定程度上被减轻，这是因为TLS和压缩技术在HTTP/1.x中已经使用了多年，从而掩盖了底层文本格式。

超越HTTP/2

HTTP/2的发展涉及了众多艰难的决策和妥协。随着HTTP/2的部署已经开始进行，一套正式的机制已经被建立，用于过渡到后续协议版本，为未来的协议修订奠定了基础。这也引入了处理多个版本同时存在的框架和基础设施，使之能够共存。或许在引入新版本时，不再需要完全淘汰旧版本了？这样可以更好地保持兼容性。

然而，HTTP/2 仍然保留了许多 HTTP/1 的旧特性，以便在 HTTP/1.1 和 HTTP/2 之间平滑地代理流量。这些旧特性可能会影响进一步的发展和创新。也许 HTTP/3 可以摆脱一些这些限制？

在您看来，HTTP 还缺少哪些关键特性？

HTTP/3 简介

QUIC 不再被视为首字母缩略词；它现已作为传输协议的名称固定下来，该协议在四个规范（RFC 8999 至 RFC 9002）中有所记录。HTTP/3 是正在开发的 HTTP 协议的下一版本，旨在运行在 QUIC 协议之上。

个人的看法

虽然大多数网站仍然使用HTTP/1.1，但HTTP/3的开发已经开始。同时，许多网站开发者并没有积极转向HTTP/2或HTTP/3。这也部分解释了为什么像Cloudflare这样的平台仍然很受欢迎的原因。