利用 QUIC 反向散射推断超大规模部署配置

# 利用 QUIC 反向散射推断超大规模服务商部署配置 | APNIC 博客 来源：https://blog.apnic.net/2026/04/21/using-quic-backscatter-to-infer-hypergiant-deployment-configurations/ QUIC（RFC 9000）是被大型内容提供商（或称“超大规模服务商”）广泛采用的传输层协议，兼具低延迟、加密与更强的隐私性。尽管 QUIC 强化了隐私保护，我们发现仅通过被动测量仍能还原其部署细节。 研究的起点很简单：仅靠监听 unsolicited QUIC 流量能知道什么？这一问题在 QUIC 刻意混淆元数据的背景下格外有趣。 我们借助网络望远镜与 QUIC 流记录开展实验。网络望远镜被动捕获互联网背景辐射——来自（恶意或良性）扫描器的流量，以及对伪造源地址的回应（反向散射）。值得注意的是，本研究善意利用了攻击者触发的回应流量。为评估完整性并验证结果，我们还进行了主动测量。 望远镜数据来自 UCSD 网络望远镜，覆盖一个 /9 与一个 /10 IPv4 前缀，选取 2021–2025 每年同一个月的 QUIC 包。 捷克国家科研网 CESNET 提供了 2024 与 2025 年相同月份的流数据（https://zenodo.org/records/17249078），用于交叉验证。本文所有结论均在流记录中得到复现。 我们重点分析了 Cloudflare、Google、Meta 服务器的 QUIC 包特性，更多细节见论文（https://dl.acm.org/doi/10.1145/3768988）。 ## 重传配置 图 1 —— 服务器重传配置在反向散射中的体现。当服务器向望远镜的伪造源 IP 回复时，可观察到重传间隔。Google 与 Meta 在整段观测期（示例为 2025 年）保持一致，且均使用指数退避。 图 1 展示了同一连接内首包与后续重传的时间差。QUIC 服务器在收到看似来自“无响应客户端”的伪造包时会重传。峰值揭示了常见的重传时机与频度。 2025 年，首次重传间隔：Meta 94% 为 0.1 s，Google 51% 为 0.3 s，Cloudflare 67% 为 1.0 s。除 Cloudflare 在 2022 年有 31% 为 0.3 s 外，其余年份稳定，只是最常用间隔占比略有波动。0.1 ms 处 Meta 的重传包甚至多于连接数，我们发现其在该时刻连续重传两次。 三家均呈现指数退避，但最大重传次数不同，反映维持连接状态所耗资源的差异。Meta 重传最频繁、超时最短，表明其对丢包更敏感，预期客户端 RTT 更短；Google 与 Cloudflare 则投入更少资源应对异常连接，降低 QUIC 泛洪攻击的暴露面。 ## Retry 包很少用于抗 DoS QUIC Retry 包可让服务器验证客户端地址，迫使客户端携带 Retry 令牌重新连接，能缓解 QUIC Flood，但会多一次 RTT。我们观测到该机制极少启用：Cloudflare 2025 年才引入 Retry，占比仅 3%，说明部署方优先保障低延迟而非 DoS 防御。 ## QUIC 连接 ID 泄露信息 图 2 —— 2024 年反向散射中服务器 CID 值相对频率。每列分布不均即表明编码信息（Google）。其余厂商亦存在类似 Meta、Google 的模式。 QUIC 用连接 ID（CID）而非 TCP/UDP 端口来标识连接。若超大规模服务商在服务器 CID 中编码信息，就会破坏随机性，从而泄露数据。 图 2 将服务器 CID 每 4 bit 的频率可视化。偏离理想随机分布（浅黄/绿色）处即为编码痕迹。 纯被动地，反向散射即可揭示所有厂商都在 CID 中编码信息，形成独特“指纹”，可用来发现自治域外的 off-net 部署。方法与精度详见论文。 2021–2022 年 Google 的服务器 CID 呈随机分布；2023–2024 年负载均衡配置变更：长包头中，服务器 CID 以 0b11 开头的占 99%（2023），以 0b111 开头的占 99.9%（2024）。 IETF 草案《可路由 QUIC 连接 ID 生成》指出，这说明 Google 并未借助 CID 辅助负载均衡；其 QUIC 实现虽跟进草案格式，却未把 CID 用于分流。 Meta 的 QUIC 实现 mvfst 则在服务器 CID 中编码主机、worker、进程及版本号（见图 4）。前 5 字节某些值密度更高，表明 Meta 正在用 CID 承载信息。 ## 观测负载均衡配置迁移 图 3 —— Meta 服务器 CID 版本编码在反向散射中的变化。2023 年 7 月 19–29 日，Meta 迁移至 CID 版本 2。 持续跟踪 Meta 的 QUIC 反向散射，我们目击了 2023 年 7 月的负载均衡升级（图 3），历时 10 天，后续主动测量验证无误。迁移前，host ID 对应单个负载均衡实例；迁移后，同一 host ID 可在不同集群复用。下一节将介绍如何推断集群结构。 ## 还原 Meta 的负载均衡器数量 图 4 —— 2025 年按经济体汇总的 Meta L7 负载均衡器数量。亚洲 PoP 使用更多负载均衡器，表现为 host ID 数量更多。 确认 CID 编码后，我们评估被动视角的完整性，并用主动测量补漏。具体做法：对 2025 年 Meta AS32934 内活跃的 7,355 个 QUIC IP 各完成 2 万次握手，客户端端口递减。 当同一 /24 内多个 IP 出现相同 host ID 时即归为一个集群。反向 DNS 验证：所有集群虚拟 IP 的 PTR 记录均含同一 IATA 机场代码，说明集群粒度为 /24。由此得出每集群负载均衡器数量，图 4 给出全球分布。更多集群结构与用法见论文。 对比发现：2023 年，2,366 条 QUIC 连接可覆盖某集群 93% 的 host ID；2025 年新结构下，仅 545 条连接即可 100% 覆盖。2023 年反向散射捕获的 Meta host ID 占比最高，为 29%。 ## 为何选择被动测量？ 我们的分析表明： 1. 极少量的反向散射即可暴露超大规模服务商的 QUIC 栈配置。 2. 不足 1,000 条伪造 QUIC 连接就能高精度枚举负载均衡实例。 主动测量可复现被动结论，但需要先掌握目标列表，产生额外流量且可能触发 IDS。望远镜测量能揭示真实 QUIC 行为，为主动测量提供指引。 ## 结构化 CID 会普及吗？方法适用于其他厂商吗？ 结构化 CID 可能成为特定超大规模服务商的“指纹”。我们发现 Google 2023 年已切换，且 Akamai、Amazon、Apple、Cloudflare、Fastly、Meta、Microsoft 的反向散射均呈现独特编码。随服务商对精细化路由的需求增长，结构化 CID 将愈发常见。 但标准化可能削弱其唯一性，降低我们与特定厂商的关联能力。高级 QUIC 特性（如客户端迁移）甚至要求更多状态信息嵌入 CID，以减少状态同步开销。 我们的 off-net 检测方法同样适用于其他厂商与测量手段（如无需开源实现先验知识的流记录）。L7 负载均衡器数量推断仅限 Meta，因只有 Meta 使用明文编码。 ### 知道负载均衡器数量有何影响？ 将目标负载均衡器编码进 CID 后，客户端可把流量导向特定实例。攻击者借此绕过单点失效缓解，集中打垮一台负载均衡器。 虽然数量不直接暴露容量，但掌握某区域分布或单集群规模，即可估算打瘫该 PoP 所需流量。 竞争对手也能利用这些信息预判商机与本地竞争、评估区域重要性并优化自身基础设施。 ## 为何网络运营商需要关心 off-net 检测 跨网流量预测困难，却是保障低延迟服务的必要前提。推断服务器角色等基础设施细节，有助于容量规划与异常流量发现。 QUIC CID 中嵌入的细粒度信息，可能揭露 off-net 部署间的缓存同步——这类流量通常被托管网络按中转计费。 欲了解 Akamai、Amazon、Apple、Fastly、Microsoft 等大型部署的更多细节，请阅读我们的论文《Waiting for QUIC: Passive Measurements to Understand QUIC Deployments》（CoNEXT 2025 年 12 月发表）。 若想深入分析 QUIC 流量，数据提供方 CESNET 已公开 2024 年 6 月至 2025 年 5 月一年的边缘 QUIC 流数据集（https://zenodo.org/records/17249078）。 *Jonas Mücke* 是德累斯顿工业大学分布式与网络系统组博士生兼研究助理，研究方向为主被动测量复杂 Web 基础设施，特别关注新兴传输协议 QUIC 带来的新视角。 --- 本文作者观点不代表 APNIC 立场。请注意，博客适用行为准则（https://blog.apnic.net/?p=395）。