Quic握手是否需要快速压缩？

您会接受我们的饼干保单吗？我们使用Cookie为您提供更好、更个性化的体验，并为我们提供重要的性能和分析数据，以保持平稳运行。

这些Cookie对于您浏览Fastly.com和利用网站的功能至关重要。

功能和性能Cookie用于记住您在我们网站上输入的信息或所做的选择(如您的用户名、语言或您所在的地区)。功能和性能Cookie还用于收集有关您和其他访问者如何使用我们的网站并与其互动的信息。

这些cookie跟踪您在fast ly.com上的在线活动，帮助您在浏览其他网站时快速向您投放有针对性的广告。Fastly不使用营销cookie向其他广告商提供信息。

IETF最近批准了TLS证书压缩扩展，这一优化承诺通过压缩TLS握手的最大部分来减小TLS握手的大小。同时，Quic'；的主要特点是其内置的低延迟握手，比人们普遍理解的更依赖于小的握手尺寸。QUIC实现现在面临这样一个决定：是否迫切需要更新其嵌入式TLS代码以支持证书压缩。

在这篇文章中，我将使用来自FAST网络的真实(匿名和聚合)数据来说明压缩在实践中对于实现Quic承诺的快速启动性能是多么重要。

Quic的低延迟握手是其主要功能。它通过将TCP和TLS的功能重叠到一个交换中而不是串行进行来实现其速度。因此，它有望在TCP和TLS相互堆叠的一半时间内完成。

但是，由于安全考虑，这些优化握手传输的数据量受到限制。在许多情况下，该限制可能太小，无法在快速部分容纳所有完整的握手。过大的握手不会比它们的TCP前身更快完成。保持握手的轻柔对于兑现奎克的承诺至关重要。

如果您不熟悉格式，像这样的图表可能会意外地暗示有一个数据包从服务器流向客户端，其初始名称为“Hello”、“Cert”和“Fin”。在现实中，它显示的是这个方向的一系列数据。根据数据量的不同，该飞行可以由背靠背的多个IP数据报组成。下面讨论的安全规则限制了Quic服务器可以在不增加往返延迟的情况下在该航班中发送的数据量。TLS证书链相当大，如果超过此限制，将破坏快速握手的承诺。

在发送第一次TLS握手数据时，Quic不可能依赖客户端地址验证的结果(TCP中的SYN握手提供的属性)，因为这两件事是集成在一起的，并且是同时完成的。为了减轻放大攻击的威胁，在完成地址验证之前，QUIC服务器被限制为传输从客户端接收的数据的3倍。不合适的握手必须等待额外的往返行程才能完成地址验证，然后才能继续，因此丧失了Quic的主要性能优势。握手性能通常受延迟的限制，因此关于它们完成的速度唯一可控的因素是握手中的往返次数。增加额外的往返行程(或“航班”)是一件大事。

放大攻击旨在诱使服务器将大量数据发送给不知情的第三方受害者。简而言之，攻击者在他们发送到服务器的第一个数据报上假装是受害者，然后服务器直接以更大的回复响应受害者。该攻击之所以称为放大攻击，是因为回复数据被设计为比攻击者的原始数据大得多，因此允许攻击者通过此反射使用比直接向受害者发送数据更多的带宽。3倍因子的Quic限制使放大威胁保持适度。TCP上的TLS握手没有此限制，因为TLS握手仅在TCP设置完成后发生。地址验证可防止反射到第三方。

Quic握手的大多数部分都很小，并且只在很小的范围内大小不同，具体取决于所使用的功能。Quic成帧、TLS服务器Hello、加密扩展和Finish构成了这些类型的大部分字节。在握手的大小变化不大的部分中，它们通常在200字节左右。

在Quic握手中，有一个大小可变的内容的大型来源控制着字节计数：TLS证书链。证书链可能只有几百个字节，也可能超过10千字节。所包含证书的大小在很大程度上决定了是否可以在一次飞行中发送握手。

证书压缩有可能通过将握手的大小减小到与安全限制兼容的大小来改善超过3倍放大系数的问题。事实上，最初的(即标准化前)Google Quic包含了类似的机制，为TLS引入基于标准的握手压缩就是为了恢复这一属性。

简单地减少握手中的字节数是不够的；很明显，证书压缩可以做到这一点。我们需要看看压缩是否通常会影响握手是否符合3倍放大预算。这提出了两个具体的问题，我希望我们的快速数据集能够回答：

问：带有未压缩证书链的握手多久会太大，无法容纳在第一次Quic航班中？

问：带压缩证书链的握手多久会太大而无法适应第一次Quic飞行？

TLS证书链的内容在TCP和QUIC上是相同的。这使我能够从我们广泛部署的基于TCP的HTTP堆栈中获取样本，以确定在现实世界中看到的证书链大小的分布。重要的是要调查实际使用情况，以便根据对最终用户的影响对数据进行加权。此数据集中不使用任何机密或受保护的数据。

为了确保数据代表不同的地理使用模式，来自6大洲9个城市的约12万5千次握手样本被分成两批收集，间隔12小时。这些样本完全是完全握手，因为恢复的握手不包含证书链，因此不容易受到正在考虑的问题的影响。

Quic规范草案定义了如何在握手中编码证书链。如果我们对握手中变化较小的部分的内容做出一些合理的假设，那么我们就可以确定每个收集的样本用quic表示的大小。

准备数据集的最后一步是压缩每个样本的证书链，并将结果编码为QUIC格式。这显示了通过压缩节省的字节数。TLS证书压缩规范允许使用DEFLATE、BROTLI或ZSTD格式进行压缩。据传闻，与压缩和未压缩表示之间的差异相比，它们之间的差异非常小。我的数据集在级别7使用了放气压缩。

回想一下，放大抑制规则将第一次握手数据限制为从客户端接收的字节数的3倍。有许多因素使对我们的数据集中哪些样本符合该规则的准确分析变得复杂，因为它是以相对于客户端可能发送的可变数据量的字节数据来表示的。然而，大致的原则是直观的：您收到一个数据报，因此您可以发送三个或更少的数据报作为响应。

让我们使用这种简化的数据报计数方法来查看数据的外观。我首先使用1280的悲观数据报大小运行它，因为所有支持IPv6的网络都必须支持至少1280的MTU(最大传输单元)，并且出于同样的原因，QUIC规范要求将其作为最小值。这些图表显示了数据集中每次握手(无论是否压缩)所需的UDP数据报数的直方图。

对于MTU为1280的情况，随便扫一眼该图表就会发现，未压缩(蓝色)证书链集中超过三个数据报预算的样本比压缩(红色)数据集中的样本多得多。在分解确切数字之前，让我们先看一下组织成1500字节数据报的同一数据集。1500是互联网上最常见的MTU。

与未压缩的数据报相比，使用压缩时的数据报长度的总体分布明显趋向于更少的数据报。显然，使用具有1500字节MTU的较大数据报意味着您需要发送的数据报比MTU 1280少，但是握手部分更改为符合放大规则时，添加压缩对于两个MTU是相似的。

在这个调查阶段，我们可以得出几个关键结论。首先，观察到的40%到43%(取决于MTU)的未压缩证书链太大，无法容纳3个数据报的单个Quic传输。这是握手中非常大的一部分，因为它们的大小将导致性能损失。

其次，对证书链应用压缩后，只有1%到8%的证书链(同样取决于MTU)太大，无法容纳在3个数据报预算内。通过这个镜头，压缩显示了一个令人印象深刻的有意义的改善。

这是非常有希望的，但我们仍然应该基于以字节表示的放大限制来查看数据，而不是按照规范的要求查看数据报。这一次，我们可以专门关注应用程序因子所隐含的关键阈值，而不是整个大小分布。

不幸的是，这引入了一个服务器实现无法控制的变量：初始客户端数据报中的字节数。虽然客户端只可靠地发送一个数据报，但其确切大小取决于客户端的实现。

客户端的初始数据报的最小大小可以是1200字节(在UDP/IP之上)，实际上，最大值将基于客户端的MTU。因此，让我们使用1452作为基于完整1500字节IPv6数据报的最高端。谷歌的Chrome一直在使用1350字节的中间MTU。我使用这些数据报大小和前面使用的相同200字节的非证书握手数据加上Quic帧字节来布局Quic数据包。结果是有效握手的证书链预算在3333到4356字节之间，具体取决于初始客户端数据包大小是在范围的低端还是高端。

根据这些阈值，我将每个样本归入三个类别之一：即使没有压缩也符合预算，需要压缩才能符合预算，或者永远不符合预算。对于没有压缩而不符合阈值的样本，压缩节省的中位数是34%，这通常足以将样本的状态更改为“需要压缩以符合预算”。

使用1452字节初始数据包的客户端将能够高效地完成更高比例的握手，因为它们最多允许4356个证书链信息。

现在是基于这个精炼的基于字节大小的数据最后一次回顾我们最初的问题的时候了。幸运的是，它们讲述的故事与基于简化数据报的分析非常相似。

观察到的未压缩证书链的40%到44%之间(取决于客户端初始数据包的大小)太大，无法容纳在符合3x放大规则的单个Quic握手过程中。这是握手中非常大的一部分，因为它们的大小将导致性能损失。

其次，对证书链应用压缩后，只有1%到9%的证书链(同样取决于客户端发起连接的字节数)太大，无法容纳在3倍的放大预算内。压缩不仅减少了字节数，而且以一种与安全规则交互非常有利的方式实现了这一点。

通过使用更激进的压缩算法(如Brotli)而不是放气，这些结果可能会得到进一步的改善。适当的平衡将取决于执行环境。Brotli通常有更好的压缩比，但创建成本更高。可以预先计算证书链的服务器可能会发现这是一个有吸引力的选择，尽管我们似乎正在到达回报递减的地步。

首先，TLS证书压缩扩展对Quic性能有非常大的影响。尽管该扩展是新的，与整个Quic部署计划相比，在此过程中引入的时间较晚，但对于客户端和服务器而言，实现新的扩展似乎非常重要，这样Quic握手才能对得起它的账单。如果没有一些帮助，40%的Quic完全握手不会比TCP更好，但是压缩可以修复大部分问题。我听说过其他减少证书链大小的非标准化方法，它们似乎是合理的，但这是一个值得使用现有压缩扩展立即解决的问题。

其次，客户端应该使用较大的初始握手数据包，以便最大限度地增加允许服务器回复的字节数，从而最大限度地增加在一个往返行程中可以完成的握手次数。这确实需要客户端在本地MTU大于服务器的路径上支持的情况下实施路径MTU发现机制，但投资回报很高。客户端初始中额外的200字节填充将使这里考虑的数据集中7%的连接的握手时间减半。

最后，来自真实世界的数据再次被证明比直觉更有洞察力，在协议设计和实施决策中具有无价的价值。当我开始这项工作时，我希望压缩的影响是积极的，但只关注一些边缘情况。数据显示，此优化正好位于将配置和Quic规范捆绑在一起并影响很大一部分Quic握手的最佳位置。我要感谢压缩扩展的作者。