八、弱网优化之完全 0-RTT 握手与金融级前向安全

如下是 GQUIC 的握手流程，原生实现里，应用发生冷启动时，首先会进行 1RTT 握手，拿到服务端的证书和 ServerConfig（简称 SCFG），随后 SCFG 会被作为随机数用于生成非前向安全的密钥。

因此在下一次发送数据包时，便可用非前向安全的密钥进行加密。直到收到了服务端发来的 Server Hello 后，通过类似 DHE 算法生成前向安全秘钥，自此开始发送前向安全的数据包。

在原生实现中，SCFG 会被临时存储在进程内存堆区，下次发起新连接或者热启动时，直接就能进入 0-RTT 流程，但冷启动则永远是 1-RTT。基于原生的实现情况，我们针对握手流程做了两个方向的优化。

1. 实现 100% 0-RTT 成功率，用于在握手时延极其敏感的业务上，例如广告请求、API 调用、短连接下载等。

2. 强制前向安全，针对安全敏感型业务，例如金融业务，0-RTT 中发送的非前向安全数据包风险远高于前向安全数据包，因此对于金融型业务，可以强制 1-RTT 握手生产前向安全密钥后，再发送数据包。

改进后的两种握手流程如下图：

九、弱网优化之实时传输

实时传输是 QUIC 的一个拓展功能，目前在 IETF 草稿阶段。实时传输适用于对数据可靠性要求不高，但非常注重数据实时性的业务。例如音视频传输、互动游戏等。实时传输在 QUIC 中的定位，以及与可靠传输的区别如下：

相同点：

1. 在 QUIC 连接建立、创建 QUIC 数据包、数据加解密这些基础功能，不可靠数据与可靠数据都是共用的。

2. 不可靠传输也有拥塞控制、ACK 机制，与可靠传输一致。

不同点：

1. 不可靠数据不受滑动窗口限制，滑窗窗口满只限制可靠数据传输。

2. 发生丢包重传时，只重传可靠数据帧，不可靠数据帧不进行重传。

不可靠数据没有 quic stream 概念，只是 frame 粒度。这其中，一个关键点在于数据是否重传，IETF 草稿的定义对这块比较开放，可以完全不重传，也可以选择性重传。

为此，TQUIC 在实现实时传输时，做了灵活的改造，对于实时传输的数据，提供多种重传策略供使用者选择，可以完全不重传，也可以选择性重传某个重要的数据（比如关键帧），我们也在尝试做动态重传控制，依托我们的弱网判断模型，动态调整重传策略。

十、总结

经过腾讯 sTGW 团队持续投入。TQUIC 在腾讯多个重要业务落地，覆盖业务包括实时通信、音视频、在线游戏、在线广告等。在登录成功率、登录耗时、握手时延、下载速度等性能指标上均取得了明显收益。腾讯云客户通过 CLB 使用 HTTP3 后，延迟降低了超过 20 个点，也欢迎大家接入使用。

附部分业务效果总结如下：

参考列表：

• https://datatracker.ietf.org/doc/html/rfc9000
• https://datatracker.ietf.org/doc/draft-ietf-quic-datagram/?include_text=1
• https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit
• https://dl.acm.org/doi/abs/10.1145/3098822.3098842