通往HTTP/3漫漫长路

原创

mariolu

发布于 2020-10-28 11:01:55

7110

发布于 2020-10-28 11:01:55

HTTP/3在TCP断开频繁的无线连接中带来好处。QUIC处理连接标识，因此频繁的TCP断开连接甚至更改IP都会对HTTP / 3连接造成的影响小得多。越来越多移动设备，5G等，HTTP/3在这种情况下大放异彩。在理想的有线网络中，考虑到优化TCP过去的成果，HTTP/3不会带来任何改善甚至可能导致更差的性能。

这两次升级都有其存在的理由，但这并不意味着它们会取代所有用例的HTTP/1.1。如果不关心性能改进或需要全双工，则无需使用HTTP/2；如果不针对移动网络，则不需要HTTP/3。

虽然HTTP/3规范仍处于起草阶段，但默认情况下，最新版本的Chrome浏览器已经支持它。Chrome拥有约70％的浏览器市场份额，可以说HTTP / 3已经成为主流。

HTTP协议的新修订版旨在使Web更加高效，安全并缩短内容交付延迟。在某些方面，这是对HTTP2的明智运用：通过用新的，专门构建的协议QUIC代替基本的TCP协议来解决类似的问题。解释QUIC优点的最好方法是，说明TCP作为HTTP请求的传输方式不足之处。为此，我们将从头开始。

最早的HTTP

1991年，当蒂姆·伯纳斯·李爵士正式设计一个简单的单行超文本交换协议时，TCP已经是一个古老而可靠的协议。后来被称为HTTP 0.9的原始定义文档特别提到了TCP，尽管不是排他性的，还是首选的传输协议：

注意：HTTP当前在TCP上运行，但是可以在任何面向连接的服务上运行。

当然，这个概念验证的HTTP版本与我们现在所知道和喜欢的HTTP几乎没有相似之处。没有标题，也没有状态代码。典型的要求很简单GET /path。响应仅包含HTML，并以TCP连接关闭而结束。由于那时候还没有浏览器什么事，因此用户应该直接阅读HTML。可以链接到其他资源，但是在此早期HTML版本中存在的所有标签都不异步请求其他资源。单个HTTP请求传递了一个完整的，自给自足的页面。

HTTP / 1.0的出现

在随后的几年中，互联网迅猛发展，尽管传输HTML仍然是其主要专长，但HTTP逐渐发展成为一种可扩展且灵活的通用协议。HTTP的三个重要更新使这一演变成为可能：

方法的引入使客户能够确定其想要执行的操作的类型。例如，创建POST是为了允许客户端将数据发送到服务器以进行处理和存储
状态码为客户端提供了一种确认服务器已成功处理请求的方法，如果不能，则可以了解发生了哪种错误
增加了http头，结构化元数据，可以修改客户端或服务器行为的请求和响应。例如，编码和内容类型头使HTTP不仅可以传输HTML，还可以传输任何类型的有效负载。“压缩”标头允许客户端和服务器协商支持的压缩格式，从而减少了通过连接传输的数据量。

同时，HTML进阶以支持图像，样式css和其他链接资源。现在，浏览器被迫执行多个请求以显示单个网页，而原始的“每个请求连接”体系结构并不是设计来处理的。建立和结束TCP连接涉及大量的来回数据包交换，因此在等待时间开销方面相对昂贵。网页由单个文本文件组成并不重要，但是随着每页请求数量的增加，延迟也随之增加。

下图说明了每个请求建立新的TCP连接涉及多少开销。

创建了一个“连接”header来解决此问题。客户端发送带有“ connection:keep-alive”标头的请求，以表明意图为后续请求保持TCP连接的打开状态。如果服务器理解此标头并同意遵守该标头，则其响应还将包含“connection:keep-alive”标头。这样，双方都保持TCP通道打开并使用它进行后续通信，直到任何一方决定关闭它为止。随着SSL / TLS加密的普及，这一点变得更加重要，因为协商加密算法和交换加密密钥需要在每个连接上增加一个请求/响应周期。

当时，许多HTTP改进都是自发出现的。当流行的浏览器或服务器应用程序需要新的HTTP功能时，他们会自己实现该功能，并希望其他各方也能效仿。讽刺的是，分散的网络需要一个集中的管理机构来避免碎片成不兼容的碎片。该协议的最初创建者蒂姆·伯纳斯·李（Tim Berners-Lee）意识到了这种危险，并于1994年成立了万维网联盟（W3C），该联盟与互联网工程任务组（IETF）一起致力于规范互联网技术的堆栈。作为为现有环境带来更多结构的第一步，他们记录了当时HTTP中最常用的功能，并将其命名为协议HTTP/1.0。但是，由于描述的“规范”各不相同，通常看到不一致的技术，但它从未获得过标准的地位。相反，有关HTTP协议新版本的工作已经开始。

HTTP/1.1的标准化

HTTP/1.1修复了HTTP/1.0的不一致之处，并将协议调整为在新的Web生态系统中更具性能。引入的两个最关键的更改是默认情况下使用持久性TCP连接（保持活动状态）和HTTP流水线。

HTTP流水线仅表示客户端无需在发送后续HTTP请求之前等待服务器响应请求。此功能可以更有效地利用带宽并减少延迟，但是可以还有改进空间。HTTP流水线仍然要求服务器按接收到的请求顺序响应，因此，如果流水线中的单个请求执行得很慢，则对客户端的所有后续响应都将相应地延迟。这个问题被称为线头阻塞。

在这个时间点上，网络正在获得越来越多的交互功能。Web 2.0指日可待，一些网页包含数十个甚至数百个外部资源。为解决行首阻塞，并降低页面加载速度，客户端在每个主机上建立多个TCP连接。当然，连接开销从来没有到过任何地方。实际上，情况变得更糟，因为越来越多的应用程序使用SSL/TLS加密HTTP通信。因此，大多数浏览器都设置了最大可能同时连接数的限制，以寻求微妙的平衡。

许多较大的Web服务已经意识到，现有的限制对于其异常繁重的交互式Web应用程序来说太过严格，因此他们通过通过多个域名分发其应用程序来“糊弄系统”。一切都以某种方式起作用，但是解决方案远非优雅。

尽管存在一些缺点，但是HTTP / 1.0和HTTP / 1.1的简单性使它们获得了广泛的成功，并且十多年来，没有人进行过认真的尝试来更改它们。

SPDY和HTTP / 2

Google在2008年发布了Chrome浏览器，该浏览器因其快速和创新而迅速流行。它使Google在互联网技术问题上获得了强烈的投票。在2010年代初期，Google在Chrome中增加了对其网络协议SPDY的支持。

HTTP/2标准基于SPDY，并进行了一些改进。HTTP / 2通过在单个打开的TCP连接上多路复用HTTP请求，解决了行首阻塞问题。这允许服务器以任何顺序回答请求，然后客户端可以在接收到响应时重新组合响应，从而在单个连接中加快整个交换的速度。

实际上，使用HTTP / 2服务器甚至可以在请求之前就将资源提供给客户端！举个例子，如果服务器知道客户端很可能需要样式表来显示HTML页面，它可以将CSS“推”到客户端，而无需等待相应的请求。虽然从理论上讲是有益的，但此功能在实践中很少见，因为它需要服务器了解其服务的HTML的结构，这种情况很少发生。

除了请求正文以外，HTTP/2还允许压缩http头，这进一步减少了通过网络传输的数据量。

HTTP/2解决了Web上的许多问题，但不是全部。在TCP协议级别上仍然存在类似类型的线头问题，它仍然是Web的基础构建模块。当TCP数据包在传输过程中丢失时，在服务器重新发送丢失的数据包之前，接收方无法确认传入的数据包。由于TCP是设计使得不能使用HTTP等高级协议的，因此单个丢失的数据包将阻塞所有进行中的HTTP请求的流，直到重新发送丢失的数据为止。这个问题在不可靠的连接上尤为突出，这在无处不在的移动设备时代并不罕见。

HTTP / 3革命

由于HTTP / 2的问题不能仅在应用程序层上解决，因此协议的新迭代必须更新传输层。但是，创建新的传输层协议并非易事。传输协议需要硬件供应商的支持，并且需要大多数网络运营商的部署，由于涉及的成本和工作量，它们不愿进行更新。以IPv6为例：它是24年前推出的，距离普遍支持还很远。

幸运的是，还有另一种选择。UDP协议与TCP一样得到广泛支持，但是它足够简单，可以作为在其之上运行的自定义协议的基础。UDP数据包是一劳永逸的：没有握手，持久连接或错误校正。HTTP3背后的主要思想是放弃TCP，转而使用基于UDP的QUIC协议。QUIC以对Web环境有意义的方式添加了必要的功能（以前由TCP提供的功能，以及更多功能）。

与HTTP2在技术上允许未经加密的通信不同，QUIC严格要求加密才能建立连接。此外，加密不仅适用于HTTP有效负载，还适用于流经连接的所有数据，从而避免了整个安全问题。建立持久连接，协商加密协议，甚至发送第一批数据都被合并到QUIC中的单个请求/响应周期中，从而大大减少了连接等待时间。如果客户端具有本地缓存的密码参数，则可以通过简化的握手（0-RTT）重新建立与已知主机的连接。

为了解决传输级别的线路前端阻塞问题，通过QUIC连接传输的数据被分为流。流是持久性QUIC连接中的短暂，独立的“子连接”。每个流都处理自己的错误纠正和传递保证，但使用连接全局压缩和加密属性。每个客户端发起的HTTP请求都在单独的流上运行，因此丢失数据包不会影响其他流/请求的数据传输。