我们用QUIC代替了互联网已经使用了数十年的事实上的协议，QUIC是我们为优化网络协议而采取的最新，最彻底的步骤，旨在为使用我们服务的人们创造更好的体验。今天，我们超过75％的互联网流量使用QUIC和HTTP / 3（我们将QUIC和HTTP / 3统称为QUIC）。QUIC已在多个指标上显示了重大改进，包括请求错误，尾部延迟，响应头大小以及许多其他有意义地影响使用我们应用程序的人们的体验的指标。
互联网工程任务组（IETF）目前正在开发QUIC和HTTP / 3进行标准化。
 

什么是QUIC和HTTP / 3？从广义上讲，QUIC替代了传输控制协议（TCP），后者是Internet通信的主要协议之一。QUIC最初由Google内部开发，称为Google QUIC或gQUIC，并于2015年提交给IETF。此后，IETF社区对其进行了重新设计和改进，形成了我们现在称为QUIC的新协议。HTTP / 3是 HTTP的下一个迭代，HTTP是基于Web的应用程序和服务器的标准协议。QUIC和HTTP / 3共同代表了以互联网为中心的协议中最新，最先进的技术，并结合了我们，Google和IETF社区通过在互联网上运行协议而学到的数十年的最佳实践和经验教训。QUIC和HTTP / 3通常胜过TCP和HTTP / 2，而后者又胜过TCP和HTTP / 1.1。TCP和HTTP / 2首先引入了在称为流多路复用的过程中允许单个网络连接支持多个数据流的概念。QUIC和HTTP / 3进一步迈出了这一步，它通过避免TCP可怕的行阻塞（使丢失的数据包阻塞并使连接上的所有流变慢）而使流真正独立，从而使流真正独立。QUIC采用最先进的丢失恢复功能，因此在恶劣的网络条件下，它的性能比大多数TCP实现要好。TCP也容易僵化，协议难以升级，因为防火墙等网络中间盒对数据包的格式进行了假设。QUIC通过完全加密来避免此问题，使协议可扩展性成为头等公民，并保证将来可以进行改进。QUIC还允许通过QLOG（一种专门为QUIC设计的基于JSON的跟踪格式）来检测，观察和可视化传输行为的新方法。

以经验为中心的协议开发我们开发了自己的称为mvfst的QUIC实现，以便在我们自己的系统上快速测试和部署QUIC。我们拥有编写和部署自己的协议实现的历史，首先使用我们的HTTP客户端/服务器库Proxygen，然后使用Zero协议，然后使用TLS 1.3实现Fizz。Facebook应用程序利用Fizz和Proxygen通过Proxygen Mobile与我们的服务器进行通信。我们还为TLS开发了两种安全解决方案，即称为委托凭据的扩展，用于保护TLS上的证书和DNS，以通过TLS加密和认证网络流量。

从头开始开发和部署新的传输协议我们希望新协议能够与现有软件无缝集成，并允许我们的开发人员快速工作。作为一个试验场，我们决定将QUIC部署在Facebook网络流量的很大一部分上，特别是内部网络流量，其中包括到Facebook的代理公共流量。如果QUIC对于内部流量来说效果不佳，我们知道在较大的互联网上也可能效果不佳。除了消除错误和其他有问题的行为外，该策略还让我们设计了一种方法，该方法可使我们的网络负载平衡器对QUIC有深刻的了解，并保持负载平衡器的零停机时间释放保证。有了这个坚实的基础，我们便开始向互联网上的人们部署QUIC。由于mvfst的设计，我们能够将QUIC支持平稳地集成到Proxygen Mobile中。

Facebook应用Facebook应用程序是我们在互联网上使用QUIC的第一个目标。Facebook拥有成熟的基础架构，使我们能够以有限的方式安全地发布对应用程序的更改，然后再将其发布给数十亿人。我们从一个实验开始，在该实验中，我们为Facebook应用程序中的动态GraphQL请求启用了QUIC 。这些请求在响应中没有静态内容，例如图像和视频。我们的测试表明，QUIC在几个指标上提供了改进。与HTTP / 2相比，Facebook上的人们的请求错误减少了6％，尾部等待时间减少了20％，响应头大小减少了5％。这也对其他指标产生了级联影响，表明QUIC大大提高了人们的体验。但是，存在回归。最令人困惑的是，尽管仅对动态请求启用了QUIC，但我们发现使用TCP下载的静态内容的错误率有所增加。根本原因是当我们将流量转换为QUIC时遇到的一个常见主题：应用程序逻辑正在根据对其他类型内容的请求的速度和可靠性来更改对某些类型内容的请求的类型和数量。因此，改进一种请求可能会对其他请求产生不利影响。例如，一种启发式方法可以适应应用程序向服务器请求新静态内容的积极程度，从而以QUIC产生问题的方式进行调整。当应用发出请求（例如，加载新闻订阅源的文本内容）时，它会等待查看该请求花费的时间，然后确定从那里发出多少图像/视频请求。我们发现启发式方法已使用任意阈值进行了调整，这对于TCP来说可能效果很好。但是，当我们切换到QUIC时，这些阈值是不准确的，并且该应用尝试一次请求太多，最终导致新闻Feed的加载时间更长。

使其规模化下一步是在Facebook应用程序中为静态内容（例如图像和视频）部署QUIC。但是，在执行此操作之前，我们必须解决两个主要问题：mvfst的CPU效率和主要的拥塞控制实现BBR的有效性。到目前为止，mvfst旨在帮助开发人员快速移动并跟上不断变化的QUIC草案。与静态请求相比，动态请求的响应相对较小，它们不需要大量的CPU使用，也不需要通过拥塞控制器来解决其问题。为了解决这些问题，我们开发了性能测试工具，使我们能够评估CPU使用率以及我们的拥塞控制器如何有效利用网络资源。我们在负载均衡器中使用了这些工具和QUIC的综合负载测试，以进行一些改进。例如，一个重要领域是优化我们如何调整UDP数据包的速度，以实现更流畅的数据传输。为了提高CPU使用率，我们采用了多种技术， 包括使用通用分段卸载（GSO）一次高效地发送一批UDP数据包。我们还优化了处理未确认的QUIC数据的数据结构和算法。

所有内容的QUIC在对Facebook应用程序中的所有内容启用QUIC之前，我们与包括视频工程师在内的多个利益相关方进行了合作。他们对重要的产品指标有深刻的理解，并在启用QUIC时帮助我们在Facebook应用中分析了实验结果。实验表明，QUIC对Facebook应用中的视频指标具有变革性的影响。重缓冲之间的平均时间（MTBR）（衡量缓冲事件之间的时间），根据平台的不同，合计最多可缩短22％。视频请求的总错误计数减少了8％。视频停顿率降低了20％。考虑到多种因素，特别是异常条件，其他一些指标（包括元指标）也得到了显着改善。QUIC改善了视频观看体验，对条件相对较差的网络（尤其是新兴市场的网络）产生了巨大影响。但是，取得这些成果的道路本身就有障碍。与我们对动态内容的体验相似，我们在应用程序中遇到了已针对TCP行为进行调整的启发式方法。例如，iOS和Android上的应用程序具有不同的机制来估计可用下载带宽。这些估算器有时会在使用QUIC时高估可用带宽，从而导致该应用播放比网络所能支持的更高质量的视频，并导致停顿。我们还必须调整和迭代流控制参数。流控制限制了接收者愿意从发送者那里缓冲的数据量。Facebook应用程序对HTTP / 2具有静态定义的流控制限制，该限制已针对TCP隐式调整，并且在QUIC上表现不佳。我们花了一些实验迭代才能找到新的最佳流量控制值。

InstagramQUIC在Facebook应用程序上的性能证明了其改善人们在互联网上的体验的能力，即使在像Facebook这样丰富而复杂的应用程序上也是如此。将来，我们计划继续利用QUIC的更多现有功能，例如连接迁移和真正的0-RTT连接建立，并投资改善拥塞控制和丢失恢复。我们也使用与Facebook部署相同的策略，将QUIC部署到Instagram应用程序上-对Instagram流量的一小部分进行测试，然后进行扩展。如今，QUIC已部署在iOS的Instagram和Android的Instagram上。Instagram的两个版本都具有与Facebook应用程序相当或更好的指标。网络上的Facebook和Instagram也启用了QUIC，因此，随着越来越多的网络浏览器启用对QUIC的支持，就像Google最近针对Chrome所做的和Apple针对Safari beta所做的那样，更多的人将从中受益。除Instagram外，我们相信我们可以将QUIC的优势带入我们应用程序系列的每一种体验中，而QUIC最终不仅代表了Facebook的互联网流量的绝大部分，而且还代表了整个互联网流量的全部。 IETF有望在2021年某个时候最终完成QUIC协议，作为征求意见（RFC）文件。一旦发生这种情况，更多的网站，应用程序和网络库将开始提供通用的QUIC。在不久的将来，像QUIC这样的新协议对于解锁创新的互联网应用将至关重要。对于我们来说，QUIC是一个起点，我们可以从此起点继续增强人们的Facebook体验。