为什么Fastly喜欢QUIC和HTTP/3

在Fastly （一个网络服务提供商），我们对资源的配置非常有目的性和选择性。这意味着我们更关心我们所承担的项目种类和它们所产生的影响，而不是项目的数量。这就是为什么我们对QUIC如此感兴趣的原因。QUIC是一种新的互联网传输协议，它比现在使用的互联网更灵敏、更安全、更灵活。

QUIC正在被互联网工程工作组(IETF)标准化，我们的工程团队包括IETFQUIC工作组的主席和一位核心文档的编辑。我们也在致力于quicly项目，这是我们自己对这种新协议的实现。让我们更详细地探讨一下QUIC是什么，以及为什么我们如此兴奋地投入我们的资源支持它。

定义QUIC(和HTTP/3)

备注：QUIC：Quick UDP Internet Connection 快速UDP互联网连接

QUIC(不是缩写)是一种全新的互联网传输协议，它正在取代目前最常用的传输协议TCP。TCP为客户端和服务器提供了一种方法，使它们能够在数据包丢失时可靠地通信，在应用程序之间优雅地共享资源，并确保数据按照发送的顺序传输。

现代TCP是对1981年发布的RFC 793中定义的核心协议进行了数十年实验、体验和扩展的结果。当HTTP工作组在2013年开始制定HTTP/2时，他们的主要关注点是优化HTTP使用TCP的方式。该小组的目标是消除排头阻塞(head-of-line blocking)，即未完成的HTTP请求有效地阻止连接的使用，直到收到响应为止。为了解决这个问题，HTTP/2引入了请求的多路复用，使得使用单个TCP连接变得更加有效。

然而，优化HTTP的工作暴露了另一个问题:TCP中也存在排头阻塞，因为TCP按顺序向接收应用程序传输数据。如果一个包丢失了，TCP接收器将保留该连接上随后接收到的所有包，直到接收到丢失包的重新传输。这样一来，应用程序将不得不等待这个重新传输被接收，即使它可以使用随后接收到的包(就像HTTP/2这样的协议一样，其中同时发生多个传输，但只使用一个TCP连接)。

TCP中的这种排头阻塞问题在HTTP/2中以几种不同的方式表现出来。虽然HTTP/2在大多数情况下都比HTTP/1表现的好，但是当连接不好时效果就不那么好了——比如高损耗的连接，或者有少量损耗和大量延迟的连接。

QUIC通过将HTTP/2的流层移动到通用传输中来解决这个问题，以避免应用程序层和传输层的排头阻塞。它通过在UDP之上构建一组类似于TCP的新的服务来实现这一点.UDP没有内置TCP的顺序保证，可靠的传输和拥塞控制特性;QUIC将它们构建到UDP顶端的一个新的层上。

此外，QUIC集成了一种加密方案，该方案重用了TLS 1.3的机制，以确保应用程序的连接是机密的、经过身份验证的和完整性保护的。TLS是保护HTTPS数据的相同技术，但在QUIC中它同时保护数据和传输协议本身。这种方法允许QUIC更早地开始数据传输，从而使它比TCP响应更快。

这个新传输协议的第一个应用是HTTP/3。这是HTTP的版本，旨在利用QUIC的特性。重要的是，HTTP/3不会改变HTTP/2的HTTP语义(URL和HTTP头部定义)。通过使用QUIC, HTTP/3应该可以解决HTTP/2的性能问题，同时避免更改应用程序(使用HTTP的实体)代码。这本身就是一个令人兴奋的改进，因为HTTP/3是HTTP/2的临时替代品。

但这仅仅是个开始。对于互联网用户来说，QUIC还有什么令人兴奋的地方呢?

为最后一英里所做的对延迟敏感的web服务正在增长，这对服务基础设施提出了前所未有的要求。与此同时，网络连接不良的用户数量显著——随着全球范围内更多的用户加入互联网，这一数字可能还会增加，尽管互联网基础设施多年来已显著改善。

QUIC旨在通过减少最后一英里的丢失和延迟问题来提高性能，特别是对连接不良的用户的好处要大于那些已经连接良好的用户。如果它实现了自己的承诺，大多数网站和用户，尤其是那些服务质量较差的地区的用户——无论是在澳大利亚内陆、印度农村还是南太平洋岛屿——将会看到更好的表现。我们相信，随着全球互联网普及率的提高，QUIC的价值很可能会上升。

谷歌对其专有的、预先标准化的QUIC版本的经验表明，在这些情况下(具有高损耗和/或延迟的网络)，其性能得到了显著改善。具体来说，谷歌发现，对于延迟最大的桌面连接，端到端搜索延迟降低了16.7%，对于延迟最大的移动连接，端到端搜索延迟降低了14.3%。考虑到他们的搜索页面是一些高度优化的URL，这是一个令人印象深刻的改进。在视频方面，他们发现那些最麻烦的手机连接被拒绝的次数减少了8.7%。这些好处来自于QUIC的延迟优化握手、更好的损失恢复，更重要的是，来自于它绕过了TCP和围绕TCP构建的互联网生态系统中的bug和低效。

对敏捷性的新承诺

如果我们使用的传输协议要继续充当要求越来越高的应用程序和混乱的底层互联网之间的有效粘合剂，那么它需要进行调整和改进。现在使用TCP并不容易，原因有二。

首先，TCP通常在客户机和服务器的操作系统(OS)内核中实现，更改TCP需要更改或升级内核。内核更改具有系统范围的影响，并且系统通常是谨慎而缓慢地部署在服务器上的。

客户端——即使是在升级周期更快的移动操作系统上——也存在问题，因为有相当多的用户最终都落后于最新的操作系统/内核版本好几年，而且许多用户根本不升级他们的操作系统。因此，即使是简单的传输级别更改，也要花费数年的时间才能部署在今天的互联网上。

QUIC更适合快速发展，因为它构建在UDP之上，通常在用户空间中运行，因此可以在服务器和客户机上部署快速更改。

第二，互联网生态系统不再允许TCP改变。在过去20年的互联网增长中，服务器和客户机之间路径上的网络元素数量出现了惊人的增长，例如检查或修改TCP报头的TCP“优化”框。这些被称为中间件的插入网络元素常常会不知不觉地阻止对TCP头部和行为的更改，即使服务器和客户机都愿意这样做。因此，互联网生态系统已经僵化了TCP，这意味着即使对TCP进行很小的更改，现在也不可能在不产生意外后果的情况下进行部署。TCP Fast Open就是对TCP进行此类修改的一个典型例子:在首次提出TCP Fast Open 8年后，它仍然没有得到广泛的部署，这主要是由于中间件。

这也是QUIC设计的亮点。QUIC对传输数据和协议本身进行加密和加密身份验证，防止中间件检查或修改协议头部，并在此过程中对协议进行未来验证。QUIC还内置了版本控制(是的，TCP中没有版本控制)，这让我们可以根据未来的需要自由地考虑深入和广泛的更改。版本控制还允许我们考虑替代版本,我们可以使用它在POP中构建、调优和部署，我们现在来讨论这个问题。

遇见更智能的入网点(POP)

我们认为，QUIC可以通过两种关键方式改进连接处理和边缘的可伸缩性，同时管理Fastly的入网点(Points of Presence，POP或数据中心)内部的流量。

首先，我们热衷于试验各种传输修改，包括拥塞控制和损失恢复，以改进我们的POP中服务器之间的流量延迟和效率。QUIC处于用户空间中，它还可以更好、更深入地与我们的工具和日志基础设施集成，从而更容易运行和从实验中学习。

其次，QUIC将发送方的流量视图与接收方的流量视图分离，从而引入了显著的灵活性。在不深入讨论这些问题的情况下，将这两者分开，本质上意味着我们可以优化我们的服务，而不需要对接收者做更改。也就是说，我们可以塑造QUIC的使用，以有效地适应我们独特的CDN和POP架构，而不需要对终端用户进行任何更改，这可能会降低用户的延迟。我们正在探索这个领域的想法，也对我们在这里看到的潜力感到兴奋!

当然，无论CDN和其他服务器运营商的体系结构如何，QUIC中还有很多东西应该引起他们的兴趣:比如它是如何加密传输的，从而使用户更加安全。或者它如何实现无状态负载平衡，以及连接移动性，允许客户端在网络之间无缝移动——例如WiFi和蜂窝网络——而不丢失连接。

接下来是什么?

QUIC仍在标准化过程中，尽管目前有20多个IETF版本的实现(包括我们的)，但它们都在朝着互操作性和完整的HTTP功能而努力。工作组预计，核心草案将在今年最终定稿，我们预计，IETF风味的QUIC将在今年晚些时候在浏览器中也可用。

对于网站的多样性和谷歌的有限集合之外的使用实例来说，QUIC的优势仍然需要被证明。我们怀疑将会有一段很长的时间，服务器和浏览器的实现都需要优化、加强和操作经验。终点在望，但要实现这一目标还有很多工作要做。

那就太好了。我们相信，Fastly的优势——以及整个互联网的优势——都值得投资和期待。随着对HTTP/3的支持开始进入公开可用的客户端，我们期待着与客户一起测试、部署和创新这项令人兴奋的新技术。

英文原文：https://www.fastly.com/blog/why-fastly-loves-quic-http3

译者：好酒不上头