Chromium博客：让Chrome更高效支持QUIC

HTTP/3的默认启用与性能提升

2020年10月，Chrome默认启用了HTTP/3。HTTP/3（RFC 9114）运行在IETF QUIC（RFC9000）之上。与HTTP/1、HTTP/2以及Google QUIC相比，在Chrome中默认启用HTTP/3带来了性能提升，包括降低了Google搜索延迟和减少了YouTube的重新缓冲。

持续的性能优化之旅

优化性能的旅程并未在HTTP/3默认启用时结束。最近的进展包括实现了HTTP/3 ORIGIN帧（RFC 9412）和服务器首选地址（RFC 9000第9.6节）。前者增强了连接合并，而后者减少了连接的往返时间（RTT）。这两项功能已在M131中默认启用，并于11月19日发布到稳定版。

ORIGIN帧技术解析

当为特定主机名建立连接时，服务器的证书通常包含许多其他主机名，服务器对这些主机名具有权威性。然而，客户端不能立即在该连接上发送这些其他主机名的请求，而必须首先对其他主机名执行DNS查找，并验证连接的IP地址是否与解析的地址匹配。这种额外的DNS解析会引入延迟，并由于潜在的IP不匹配而显著降低连接池化的可能性。Chrome的指标表明，如果不是因为这种IP不匹配，近20%的HTTP/3连接将是不必要的。

即使使用QUIC 0-RTT，建立新连接在延迟、内存和CPU使用方面也是昂贵的。这是因为：

• 除非在Chrome的DNS缓存中本地缓存，否则DNS解析会增加延迟。
• 客户端和服务器都必须发送多个数据包来完成QUIC握手。
• TLS需要在两端进行CPU密集型的非对称加密。
• 拥塞控制器从其默认状态开始，可能导致发送不足或过度。
• 0-RTT可能会失败。
• 非安全请求不会通过0-RTT发送。
• 更多连接会消耗更多内存。

此外，像HTTP优先级（RFC 9218）这样的功能只有在有多个同时响应要发送时才有效。

HTTP/3 ORIGIN帧（RFC 9412）使服务器能够指示希望将哪些域合并到一个连接上。此外，一旦接收到该帧，就表示其他域不应合并到该连接上，即使它们在证书中。

服务器首选地址技术实现

在某些情况下，客户端最初连接的服务器地址并不是最高效的路径。它可能位于L4负载均衡器后面，直接连接可能会提高稳定性。特别是在使用任播时，服务器可能远离流量进入网络的位置，形成三腿路径，从而增加了往返时间。

一旦握手确认，服务器首选地址允许服务器指示希望客户端迁移到不同的服务器IP。尽管QUIC连接不像TCP那样绑定到单个四元组，但这是RFC9000中唯一一种服务器可以更改其地址的迁移类型。

到目前为止，只有Google的媒体CDN广泛启用了广告替代地址，但我们预计更多服务器将很快采用它。测试表明，在Chrome中，这种迁移成功率超过99%，并将平均RTT降低了40-80%。

发布时间：2024年12月17日星期二
作者：Fan Yang和Ian Swett