Chrome QUIC协议优化：HTTP/3性能提升与新技术实现

让Chrome更高效地使用QUIC

2020年10月，Chrome默认启用了HTTP/3。HTTP/3（RFC 9114）运行在IETF QUIC（RFC9000）之上。在Chrome中默认启用HTTP/3不仅比HTTP/1和HTTP/2性能更好，也比Google QUIC有所改进。带来的好处包括降低了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那样绑定到单个4元组，但这是RFC9000中唯一一种服务器可以更改其地址的迁移类型。

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