facebook客户端_QUIC 在 Facebook 是如何部署的？

作者 | Matt Joras, Yang Chi 策划 | 万佳 今天，Facebook 超过 75% 的网络流量使用 QUIC 和 HTTP/3。

Facebook 正用 QUIC 取代互联网几十年来一直使用的事实上的协议，这是我们采取的最新的也是最激进的一步，目的是优化我们的网络协议，为使用我们服务的用户提供更好的体验。

今天，Facebook 超过 75% 的网络流量使用 QUIC 和 HTTP/3(我们将 QUIC 和 HTTP/3 一起称为 QUIC)。显然，QUIC 在几个指标展现出了显著的改善，包括请求错误数、尾部延迟、响应头大小以及对使用我们应用程序的用户的体验有重要影响的其它很多指标。

因特网工程任务组(IETF)正开发 QUIC 和 HTTP/3 使其标准化。

https://quicwg.org/

1 什么是 QUIC 和 HTTP/3？

广义来讲，QUIC 是传输控制协议(Transmission Control Protocol，TCP，用于互联网通信的主要协议之一)的一个取代物。它最初是由谷歌内部开发的，称作 Google QUIC 或 gQUIC，并在 2015 年提交给 IETF。从那时起，它被更广泛的 IETF 社区重新设计和改进，形成一个新的协议，我们现在称之为 QUIC。HTTP 是基于 Web 的应用程序和服务器的标准协议，HTTP/3 是 HTTP 的下一个迭代。

https://github.com/bagder/http3-explained

QUIC 和 HTTP/3 一起代表了互联网协议中最新和最伟大的协议，结合了数十年的最佳实践和经验教训，这些都是由 Facebook、谷歌和 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 的跟踪格式)来检测、观察和可视化传输行为。

https://github.com/quiclog

2 以体验为中心的协议开发

我们开发了自己的 QUIC 实现，称作 mvfst，以便在我们自己的系统上快速测试和部署 QUIC。我们有编写和部署自己的协议实现的历史，最先是我们的 HTTP 客户端 / 服务器库——Proxygen，接着是 Zero protocol，然后是我们的 TLS 1.3 实现——Fizz。

https://github.com/facebookincubator/mvfst

Facebook 应用程序使用 Fizz 和 Proxygen 通过 Proxygen Mobile 来与我们的服务器通信。我们还为 TLS 开发了两种安全解决方案，一个名为 delegated credentials 的用来保护证书的扩展，和 DNS over TLS，用来加密和验证 TLS 上的 Web 流量。

3 从头开发部署一个新的传输协议

我们想要新协议无缝集成到现有的软件，并允许开发人员能快速上手。作为一个试验场，我们决定在 Facebook 网络流量的很大一部分上部署 QUIC，特别是内部网络流量，其中包括访问 Facebook 的代理公共流量。如果 QUIC 对内部流量表现得不好，我们就知道它在更大的互联网上很可能也表现得不好。

除了摆脱 bugs 和其它有问题的行为外，这个策略还使我们能够设计一种方法来让我们的网络负载均衡器能够深入感知 QUIC 并维护我们的负载均衡器的零停机时间发布保证。

有了这个坚实的基础，我们开始向互联网上的人们部署 QUIC。由于 mvfst 的设计，我们能够平滑地将 QUIC 支持集成到 Proxygen Mobile。

4 Facebook 应用程序

Facebook 应用程序是我们在互联网上使用 QUIC 的第一个目标。Facebook 有一个成熟的基础设施，允许我们在向数十亿人发布应用程序更新之前，以有限的方式安全地推广应用程序的更新。

我们从一个实验开始，其中我们为 Facebook 应用程序中的动态 GraphQL 请求启用了 QUIC。这些请求在响应中没有静态内容，例如图像和视频。

测试显示，QUIC 在多个指标上提供了改进。Facebook 的用户体验到，请求错误减少了 6%，尾延迟减少了 20%，相比于 HTTP/2 的响应头大小减少了 5%。这对其它指标也有级联影响，表明 QUIC 极大地提高了人们的体验。

然而，也有倒退。最令人困惑的是，尽管 QUIC 只针对动态请求启用，我们观察到 TCP 下载的静态内容的错误率有所增加。当我们将流量转换到 QUIC 时，这一点的根本原因将会是我们深入研究的一个常见主题：应用程序逻辑会根据其它类型内容的请求的速度和可靠性，改变特定类型内容的请求的类型和数量。因此，提升一种类型的请求可能会对其它类型的请求产生有害的副作用。

例如，调整应用程序从服务器请求新的静态内容的积极度与使用 QUIC 产生的问题协调。当一个应用程序发起一个请求来加载新闻流的文本内容，它会等等看这个请求需要多长时间，然后决定发起多少个图像 / 视频请求。我们发现这可以用任意阈值进行协调，而且可能对 TCP 有效。但是，当我们切换到 QUIC，这些阈值是不准确的，而且应用程序一次性尝试请求太多内容，最终导致新闻流花费更长时间来加载。

5 使它规模化

下一步是为 Facebook 应用程序中的静态内容(例如图片和视频)部署 QUIC。然而，在这样做之前，我们必须解决两个主要问题：mvfst 的 CPU 效率和我们主要的拥塞控制实现(BBR)的有效性。

到目前为止，mvfst 的设计初衷是帮助开发人员快速上手并跟进不断变化的 QUIC 草案。动态请求，与那些静态请求相比，它们的响应比较小，不需要占用大量的 CPU，也不需要拥塞控制器来控制其速度。

为解决这些问题，我们开发了性能测试工具，让我们能评估 CPU 使用率以及拥塞控制器如何有效地利用网络资源。我们在负载均衡器中使用这些工具和 QUIC 的综合加载测试来进行一些改进。例如，一个重要的领域是优化我们如何调整 UDP 数据包的速度来实现更平滑的数据传输。

为了提高 CPU 使用率，我们采用了许多技术，包括使用通用分段卸载(generic segmentation offload，GSO)来一次性高效地批量发送 UDP 数据包。我们还优化了处理未确认的 QUIC 数据的数据结构和算法。

https://lwn.net/Articles/752956/

6 针对所有内容的 QUIC

在为 Facebook 应用程序中的所有内容开启 QUIC 前，我们与一些利益相关者合作，包括我们的视频工程师。他们对重要的产品指标有着深刻的理解，并当我们启用 QUIC 时帮助我们分析在 Facebook 应用程序中的实验结果。

实验表明，QUIC 对于 Facebook 应用程序中的视频指标有着革命性的影响。重缓冲平均时间(MTBR)，缓冲时间之间的时间度量，根据平台的不同，总体提升了 22%。视频请求的总体错误数降低了 8%。视频卡顿率降低了 20%。其它一些指标，包括元指标，考虑到各种因素以及离散条件，也得到了显著的提升。QUIC 改善了视频观看体验，对条件相对来说，比较差的网络，尤其是新兴市场的网络，产生了巨大的影响。

但是通往这些结果的道路上也有自己的障碍。与我们对动态内容的体验类似，我们遇到了在应用程序中针对 TCP 的行为进行调整的问题。例如，在 iOS 和 Android 上的应用程序有不同的机制来估计可用的下载带宽。当使用 QUIC 时，这些估算器有时高估了可用带宽，导致应用程序播放了一个超过网络能够支持的比较高质量的视频，并导致了卡顿。

我们还必须调整和迭代流控制参数。流控制限制了接收方从发送方缓冲的数据量。Facebook 应用程序针对 HTTP/2 有一个静态定义的流控制限制，其针对 TCP 进行了隐式调整，使用 QUIC 时表现得并不好。这需要我们进行一些实验性的迭代来发现新的最佳流控制值。

QUIC 和 TCP 的视频加载时间的个体百分比差异

7 Instagram 及其它

QUIC 在 Facebook 应用程序上的表现，已经成为提升互联网用户体验的证据。在将来，我们计划继续利用 QUIC 更多已有的功能，例如连接迁移和真正的 0-RTT 连接建立，并投入对拥塞控制和丢包恢复的改进。

我们也在 Instagram 应用程序上部署了 QUIC，使用与 Facebook 部署相同的策略——先在 Instagram 的一小部分流量上测试，然后进行推广。如今，QUIC 已经被部署到 Instagram iOS 版本和 Instagram Android 版本上。Instagram 两个版本的指标都与 Facebook 应用程序上的指标相当或更好。Facebook 和 Instagram 在 Web 上也启用了 QUIC，因此随着越来越多 Web 浏览器启动对 QUIC 的支持，例如谷歌最近对 Chrome 的支持和苹果公司对 Safari beta 的支持，越来越多的人会从这些改进中受益。

https://blog.chromium.org/2020/10/chrome-is-deploying-http3-and-ietf-quic.html

https://developer.apple.com/videos/play/wwdc2020/10111/

除了 Instagram，我们相信可以将 QUIC 的好处带到我们应用程序家族中的每一个体验中，QUIC 最终将不仅代表 Facebook 的互联网流量的大部分，而是代表全部。

IETF 将在 2021 年的某个时候将 QUIC 协议作为征求意见稿(request for comments，RFC)定稿。一旦这样，更多网站、应用程序和网络库都会开始提供 QUIC 通用支持。在不久的将来，像 QUIC 这样的新协议将是解锁创新型互联网应用程序的关键。对我们而言，QUIC 是一个起点，我们会继续提升人们在 Facebook 上的体验。

原文链接：

https://engineering.fb.com/networking-traffic/how-facebook-is-bringing-quic-to-billions/

今日文章推荐：

快手自研 kQUIC：千万级 QPS 集群是如何实现的？

点个在看少个 bug ?