QUIC 协议本意通过融合 TLS 1.3 实现 1-RTT 握手，但实测 27.2 万 QUIC 服务中，绝大多数首轮往返即触发反射放大限制，导致多轮握手成为常态。核心瓶颈在于非叶子证书体积过大，挤占服务端首包预算。
反射放大限制与首包预算：
RFC 9000 规定服务端首包不得超过客户端 Initial 包的 3 倍，直到客户端地址验证通过。Chromium 发 1250 字节，Firefox 发 1350 字节，服务端可回 3750~4050 字节。实测 Tranco 1M 域名中 27.2 万 QUIC 可达服务，按 1352 字节初始包计算，61% 首轮即超限，38% 需多 RTT，理想 1-RTT 几乎不存在。RETRY 机制虽能验证地址，但额外增加一轮往返。
非叶子证书链挤占握手预算：
研究发现 TLS 证书链中非叶子证书体积庞大是主因。统计部署最多的前 10 条证书链，非叶子证书（白色方块）中位数与最大值（黄/橙色方块）均显著大于叶子证书。服务端需在首包预算内塞入完整证书链，非叶子证书占比过高直接导致超限。原文未给出具体证书字节数，但证实其对 TLS 数据量贡献 "substantial"。
部署现状与取舍：
当前部署中，服务端常因证书链过大被迫触发 RETRY 或分片，牺牲 QUIC 低延迟设计初衷。若精简中间 CA 证书、采用更短的证书链或压缩证书（如 RFC 8879），可在首包预算内完成握手。但证书链变更涉及 PKI 信任链兼容性，运维需在安全合规与握手性能间权衡。原文未给出具体优化后的成功率数据。
对网络工程师而言，排查 QUIC 高延迟应先抓包确认首包大小与证书链体积，而非盲目调整拥塞控制。若证书链非叶子证书超 3KB，必触发多 RTT；精简证书链是唯一不引入额外往返的根治路径。
原文: APNIC Blog（2023-01-16）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog