摘要

互联网审查方常依赖连接最初几个数据包中的信息来封锁其不希望出现的流量。随着 QUIC 传输协议的兴起，既有研究提出利用 QUIC 连接迁移，通过另一条网络路径（如加密代理通道）隐藏最初的若干握手数据包。然而，以连接迁移规避审查的可行性和性能尚未得到探索或验证。

我们通过对这一方法开展严谨的量化评估来填补上述空白，并将其命名为 QUICstep。我们开发了一个轻量、与应用无关的 QUICstep 原型，并证明 QUICstep 能够规避现实中的 QUIC SNI 审查系统。研究发现，在多种环境下，QUICstep 不仅优于全程加密通道，还能显著降低加密通道提供方承载的流量。

我们还提出将 QUICstep 用作测量现实网络中 QUIC 连接迁移支持情况的工具，并表明连接迁移的支持率正在上升。尽管当前 QUIC 和连接迁移的支持仍然有限，但我们认为，在 QUIC 成为互联网事实标准的未来，QUICstep 将成为一种实用工具。

1. 引言

随着互联网成为生活中不可或缺的工具，各国政府也竞相扩大审查计划，试图控制人们获取信息的渠道。Access Now 的 2024 年数据显示，网络中断不仅发生得愈发频繁，涉及的国家也越来越多［47］。能够执行深度包检测（DPI）的通用网络设备不断普及，使更多政府和互联网服务提供商能够开展可扩展的网络审查［55］。中国防火长城（GFW）和俄罗斯 TSPU 等成熟的审查体系，仍在不断强化封锁网络连接和识别审查规避技术的方法［28， 29， 74］。

对现实审查系统的既有研究表明，绝大多数连接（包括完全加密的连接）都依据握手数据包中的信息被过滤。例如，基于 SNI 的检测对审查至关重要［15］，以至于审查方早在 2020 年就开始预先封锁使用加密 SNI 扩展的连接［10］。同样，GFW 在判断是否豁免某个连接时，只重点检查该连接最初的几个数据包［70］。OONI 和 Censored Planet 等审查测量平台也利用这一特点，主要通过发送握手探测包在全球范围测量审查［1， 54］。归根结底，握手为审查方提供了足够的连接元数据，使其能够判断是否封锁连接的其余部分。

在实践中，要规避依赖握手信息的审查，关键是向审查方隐藏握手，或通过另一条通道引导连接建立。沿着这一思路，Wang 等人提出，可将握手数据包和非握手数据包分散到不同网络路径上，借助连接迁移规避针对 QUIC 的无状态审查［64］。连接迁移是 QUIC 的一项重要功能：即使端点的 IP 地址或端口发生变化，也能维持连接。若仅通过抗审查通道（如 VPN）传输握手数据包，用户既可获得规避审查的好处，又能尽量降低抗审查通道带来的性能开销和负载。

然而，既有工作只是简略提出这一审查规避方案，尚未回答其设计、实现、实用性以及量化性能收益等关键问题。

研究贡献。 我们将这一方法命名为 QUICstep，并尝试理解其可行性与性能：第一，Web 服务器是否 兼容 QUICstep？第二，QUICstep 能否有效 规避已部署的审查系统？第三，使用 QUICstep 会产生怎样的量化 性能影响？为回答这些问题，我们首先定义清晰的威胁模型（第 3.1 节），重点研究已部署审查系统的行为：这类系统倾向使用简单、轻量的机制（如无状态处理），而非全面却复杂的机制。随后，我们开发了一个轻量、开源的 QUICstep 原型（第 3.2 节），使现实 Web 浏览场景中的高效路径迁移成为可能。我们的实现见 https://github.com/inspire-group/QUICstep。我们使用该实现开展全面评估，以展示 QUICstep 的有效性和性能。我们成功利用 QUICstep 规避了现实中正在运行的 QUIC-SNI 审查，证明它对采用无状态检测技术的现实审查系统确实有效（第 4.3 节）。更复杂的审查方或许会使用有状态流量分析来检测 QUICstep，但这可能提高其成本；我们在对 QUICstep 更全面的安全性分析中讨论了这种可能性及其权衡（第 5 节）。

我们通过广泛的实验展示 QUICstep 的性能优势。我们用术语 握手通道指代 QUICstep 客户端执行握手时所使用的安全隧道（第 3.1.1 节）。与所有流量都完全依赖握手通道相比，QUICstep 最多可将页面加载时间缩短 84%，并使握手通道提供方的负载中位数降低 93%。当握手通道受到带宽限制等现实约束时，QUICstep 的性能收益更加明显。QUICstep 可用于减轻 VPN 或其他审查规避工具等握手通道提供方的负载。

QUICstep 要在实践中发挥作用，网站必须同时支持 QUIC 和连接迁移；目前，这正是此类技术大规模应用的瓶颈。我们借助 QUICstep，在三个月内对现实网络中的连接迁移支持情况开展大规模测量，识别出数量虽少但不可忽视的 QUIC 网站能够兼容 QUICstep。尽管 QUIC 与连接迁移目前的支持率仍然有限，但支持正在增长：在三个月的测量期间，部分支持连接迁移的网站数量增加了 20%。这表明 QUICstep 有望在未来成为实用工具。

2. 背景与相关工作

QUIC 是一种基于 UDP 的传输层协议，支持对应用层数据流进行多路复用［32］。QUIC 旨在相较 TCP+TLS 提升 Web 应用性能，也是 HTTP/3 的基础。随着 HTTP/3 被标准化为 RFC，QUIC 的迅速普及很可能继续［8］。根据我们近期的测量，目前所有主流浏览器以及排名前一百万的网站中约 22% 已支持 QUIC（第 4.2 节）。

QUIC 提供多种网络性能功能。例如，将 QUIC 与 TLS 握手合并后，它可省去一次握手往返［57］。与本研究密切相关的一项关键性能功能是 连接迁移，它使 QUIC 连接能够跨越多个网络层会话而持续存在。

连接迁移。 QUIC 使用一组连接标识符，而非 IP 地址与端口组成的元组来唯一标识连接。QUIC 连接与 IP 地址、端口相解耦，因此即使客户端在不同网络之间移动，连接仍可维持。这一能力称为 连接迁移［8，第 9 节］。当端点检测到网络变化时，会执行一次往返的 路径验证，确认对端仍然可达，随后才恢复连接，如 图 1 ［8，第 8.2 节］所示。连接迁移只能在客户端与服务器通过 QUIC-TLS 握手完整建立会话后发生。QUIC 连接迁移可显著提升移动用户的性能，因为即使设备在移动网络与本地 Wi-Fi 等不同网络之间切换，连接仍可保持。QUICstep 利用这一性能功能，以极低的额外延迟规避审查。

QUIC-TLS 握手。 QUIC 被设计为默认安全的协议，要求传输中的数据必须加密。为此，QUIC 与 TLS 加密相集成。值得注意的是，QUIC-TLS 使用由公开盐值派生的密钥来加密 Initial 数据包［57，第 5.2 节］。尽管 QUIC Initial 数据包的加密并不能保证机密性——因为任何观察到连接的人都可以派生密钥——但它仍使 DPI 中间盒开展基于 SNI 的审查更加困难，因为解密需要额外的计算资源，跟踪 UDP 流也需要更多工作。

2.1. QUIC 流量审查。

网络层对手可以分析 QUIC-TLS 握手数据包，并依据 TLS SNI 字段审查连接，使 HTTP/3 连接容易遭到封锁。具体而言，审查方可先根据客户端的目标连接 ID 和公开盐值，计算用于加密 QUIC 客户端 Initial 数据包的密钥［57，第 5.2 节］。随后，审查方解密客户端的 Initial 数据包，并从其 TLS ClientHello 消息中提取 SNI 字段。如果该 SNI 字段与审查方的封锁名单匹配，审查方就会封锁正在进行的 QUIC 连接。QUIC 协议的开发与采用曾造成一个短暂的 QUIC 审查空档期，因为审查方需要时间开发能够检查和封锁 QUIC 流量的 DPI 软件与设备。例如，2023 年土耳其政府因某社交媒体网站批评其处理土耳其—叙利亚地震后续工作的方式而决定封锁该网站；网站开发者报告称，用户可通过强制与其服务器建立 QUIC 连接来规避基于 TLS-SNI 的审查［35］。

然而，随着 QUIC 流量增加，各审查体系持续设计检测与封锁 QUIC 流量的方法。研究人员报告了全球多地封锁 QUIC 的案例，包括中国［76］、乌干达［21］、伊朗［22］和俄罗斯［21］。早期 QUIC 审查尝试包括笼统封锁全部 QUIC 流量。例如，Xue 等人在 2022 年报告称，俄罗斯 TSPU 会识别具有特定指纹的数据包，再丢弃该流中的所有数据包，从而审查 QUIC 流量［74］。这种策略旨在封锁所有 QUIC 流量，无法选择性封锁前往特定网站的流量。随着 QUIC 流量预计不断增加，广泛封锁 QUIC 可能造成越来越严重的附带损害。

如文献［76］所述，自 2024 年 4 月起，GFW 开始审查 QUIC 流量：它先解密 QUIC 客户端的 Initial 数据包，再检查 TLS ClientHello 消息中的 SNI 字段是否匹配封锁名单。

2.2. 用于隐私保护的 QUIC 连接迁移。

2.2.1. CoMPS。

CoMPS 是 Wang 等人提出的一种基于连接迁移的流量拆分框架，旨在增强抵抗网站指纹识别的稳健性［64］。CoMPS 使用路径调度器将流量拆分到多条网络路径，以限制对手能够观察到的流量；其假设是对手只能观察单条路径上的数据包。客户端利用连接迁移在不同路径之间路由流量。这项工作还首次给出了 QUICstep 的高层构想：通过 VPN 路径发送握手数据包，CoMPS 可以规避基于 SNI 的审查。不过，审查规避只是作为 CoMPS 的潜在用途被简略提及，作者并未针对部署、可行性或性能加以实现或评估。因此，我们研究以下开放问题：基于连接迁移的规避方法在实践中是否有效？与通过握手通道隧道传输所有流量相比，它能带来怎样的性能收益？

2.2.2. MIMIQ。

MIMIQ 利用 QUIC 连接迁移，在可信网络内频繁更换客户端 IP 地址，以抵御用户跟踪和某些类型的流量分析攻击［27］。MIMIQ 需要客户端网络配合，因为该网络必须部署修改过的 DHCP 和边缘交换机。因此，它不适用于客户端网络本身可能就是对手的审查规避场景。

2.3. 相关工作。

2.3.1. TLS 会话恢复。

已有研究提出用 TLS 会话恢复规避 SNI 审查。会话恢复在 TLS 1.2 中引入，可减少客户端为每个 TLS 连接执行握手的需要。首次建立 TLS 会话时，服务器会向客户端发送一个唯一票据，客户端可用它恢复与服务器的 TLS 会话。MultiFlow 和 REDACT 提出利用会话恢复实现诱饵路由［18， 39］。较新的 BlindTLS 提出，先通过 VPN 代理与受审查域名建立连接，再使用 TLS 会话恢复，以不同的 SNI 在审查方眼前恢复该会话［50］。然而，BlindTLS 侧重 TLS 1.2 中的会话恢复，无法用于 TLS 1.3，因为 TLS 1.3 要求恢复握手中发送的 SNI 必须与该会话关联的 SNI 一致［44］。与 BlindTLS 不同，QUICstep 兼容 TLS 1.3，并且其设计不依赖具体的 TLS 版本。我们是首个全面研究如何利用 QUIC 作为传输协议的多项属性来规避握手审查的工作，而不是依赖 TLS 的应用层功能。以往的 SNI 审查规避研究主要聚焦传统 TCP 场景，因为现实中的审查大多出现在该场景［15， 28］。

2.3.2. 加密 ClientHello。

加密 ClientHello（ECH）是 TLS 1.3 的一项扩展，它对包含服务器名称在内的 ClientHello 消息进行加密，以保护用户隐私［45］。由于 SNI 对观察者不可见，ECH 可用于规避基于 SNI 封锁名单的审查。然而，既有研究发现服务器对 ECH 的支持有限，而且俄罗斯、中国和伊朗的审查方目前会封锁 ECH 流量，削弱了 ECH 在审查规避中的实用性［42］。

2.3.3. QUIC 连接迁移支持情况测量。

连接迁移的可用性与普及程度与本研究直接相关。2024 年，Buchet 和 Pelsser 调查了 Web 上对 QUIC 连接迁移的支持情况［13］。该工作通过向服务器发送带有新连接 ID 的数据包来测试连接迁移，但并未启动迁移，也未测试迁移后能否成功加载资源。我们发现，这种方法无法完整测量切换到不同端口或 IP 地址后，连接在实践中迁移成功的比例。例如，QUIC 服务器对基于端口的连接迁移（如将 QUIC 连接迁移到新的 UDP 端口）与基于 IP 的连接迁移（将 QUIC 连接迁移到新的 IP 地址）通常有不同的支持方式。我们利用 QUICstep 提供了迄今最完整的互联网范围连接迁移支持情况测量，还依据这些结果向标准组织提出建议，以提升连接迁移对所有 QUIC 客户端的实用性。

2.3.4. 其他审查规避系统。

审查规避领域已有大量工作假设对手比 QUICstep 威胁模型中的对手更强。这些工作使用复杂的流量整形、流量模仿及其他混淆技术来隧道传输加密流量，所面对的对手往往能够运用成本更高的技术（如强大的机器学习分类器），依据加密流的元数据识别被封锁内容［24， 30， 33， 40， 46］。尽管我们在 第 5 节中简要讨论了更强的对手，但本研究聚焦的是资源更有限、也更贴近现实的对手。QUICstep 聚焦“轻量”审查方，这一点与 Geneva、域前置、域名影子和 Snowflake 相似；这些技术中有许多已在实践中部署，并被数百万用户用于规避网络审查［9， 11， 23， 67］。

2.3.5. 现实审查方偏好简单、高效的检测方法。

GFW 往往是全球审查生态中的先行者，因此我们预计其他审查体系很快也会效仿，实施 QUIC SNI 审查［76］。本研究旨在抢先于审查方：广泛、全球性的 QUIC SNI 审查在实践中会是什么样子？对现实审查设备的实证测量显示，审查方更偏好相对简单、高效的检测机制，而非全面却复杂或昂贵的检测机制［3］。例如，Wu 等人发现，GFW 在检测 TCP 连接是否完全加密时，只检查客户端发送的第一个 TCP 载荷［70］。这与以下观点一致：即使经过加密，握手数据包仍是连接中信息最丰富的部分，审查方会利用它高效作出封锁决定。同样，Zohaib 等人发现，GFW 在开展基于 QUIC SNI 的审查时，会假设第一个 UDP 载荷是一个完整的 QUIC 客户端 Initial 数据包［76］。基于这些观察，我们聚焦执行无状态、轻量审查的审查方。我们承认，未来可能出现执行有状态审查、侵入性更强且能力更强的审查方。但鉴于 GFW 是现实中部署的主要 QUIC-SNI 审查系统，我们聚焦 GFW 一类的审查方，并将有状态审查方视为本研究范围之外。我们的威胁模型详见 第 3.1 节。

3. 将 QUICstep 从理论变为实践

QUICstep 的首要目标是在规避 QUIC SNI 审查的同时，尽量降低总体额外延迟，并避免修改服务器端软件或 QUIC 协议。本节说明我们如何将 QUICstep 从理论变为实践：首先阐明威胁模型和实现目标，随后深入讨论相关挑战与实现细节。

3.1. 威胁模型。

我们的威胁模型遵循域前置［23］和 Geneva［9］等审查规避技术的既有研究。在该威胁模型中，客户端位于受审查网络内，希望访问托管在受审查网络之外、IP 地址未被封锁的受审查域名。审查方使用 DNS 和 SNI 过滤等 DPI 技术识别并阻止此类访问。我们考虑的是 第 2.3.5 节所述的现实审查方，其采用轻量方法实现大规模实时检测。具体而言，审查方利用可逐包执行的无状态检测技术，不会记录所有网络流来开展流级流量分析。匿名性并非客户端的首要考虑，这与既有工作的假设一致（如 MassBrowser［41］）。实践中，受审查国家的用户常用公共 VPN 或代理绕过审查，即使这些工具并不保证匿名。用户调查也表明，审查体系下的用户往往更看重内容访问和网速，而非安全性或匿名性［14， 72］。

3.1.1. 客户端模型与握手通道。

客户端希望以较低的性能开销访问受审查域名。我们假设，对于每个连接，客户端已经能够访问一条安全、抗封锁但可能高延迟的握手通道（如 DNS 隧道或公共 VPN）。大量抗审查研究致力于开发这种高安全、低带宽通道，例如 Tor 网桥和可插拔传输、Tor Snowflake 使用的会合通道［11］，以及用于 Tor 网桥分发的信令通道［60］。客户端可以将任何这类同步、高安全通道用作握手通道。Hysteria［31］、V2Ray［59］、Xray［71］、Sing-box［52］以及 Meek（域前置）等 Tor 可插拔传输［43］也都可以作为握手通道。

不过，让客户端的所有流量都依赖这条通道并不理想。握手通道资源有限（且与其他用户共享），因此可能向个人用户收费，或施加带宽、流量限制。例如，Lantern 免费版每月有 500 MB 的流量上限［36］。

我们还假设，审查方无法破坏 QUIC 或握手通道的安全保证，也不会为避免附带损害而攻击某些 Web 流量类别的可用性（如封锁所有 QUIC 流量）。关于封锁全部或特定类型 QUIC 流量的进一步讨论见 第 5 节。 图 2(a) 展示了代表本威胁模型的受审查网络。

3.2. 实现。

图 2(b) 展示了 QUICstep 的高层架构。客户端首先通过安全握手通道完成 QUIC-TLS 握手，并与服务器建立 QUIC 会话。随后，客户端立即切换到原生网络路径，使其余数据包能够以极低延迟直接发送到服务器。

QUICstep 需要建立握手通道。握手通道可以是任何安全且抗封锁的通道（如 VPN）。在原型中，我们使用 WireGuard 通道。尽管 Tor 提供更强的安全与匿名保证，我们并未使用它，因为 Tor 目前不支持 UDP 隧道。此外，使用由我们控制的 WireGuard 代理可以构建更可控的实验，便于改变代理位置或吞吐量。受审查地区的许多用户会主动使用此类自建代理来规避审查［31， 48， 51， 52， 59， 71］。只要握手通道提供虚拟网络接口，我们的 QUICstep 实现就不依赖具体的握手通道类型。

3.2.1. 实现目标。

实现 QUICstep 时，我们的首要目标是开发一种易于实现、与应用无关的方案。我们希望 QUICstep 能兼容客户端和服务器可能运行的广泛技术环境，例如无需修改客户端应用、上层协议、操作系统或浏览器。除要求客户端和服务器支持 QUIC 与连接迁移外，我们的 QUICstep 实现无需任何其他改动。

3.2.2. 实现选择与挑战。

通过握手通道完成握手后，挑战在于识别握手已得到确认，并据此路由数据包（无论数据包由何种应用传输）。根据 QUIC 标准，连接迁移应在对端确认握手后发生［32］。服务器确认握手时，会在一个 1-RTT 数据包中向客户端发送 HANDSHAKE_DONE 帧；但该帧经过加密，很难从应用外部识别。如果不能准确识别握手确认，服务器就会通过握手通道发送额外数据包来完成握手，从而产生额外延迟。为准确识别握手确认，我们考虑过两种方案：(1) 使用 eBPF［20］，根据载荷未加密部分启发式判断哪些连接已完成握手确认；(2) 修改 QUIC 客户端以跟踪该帧。然而，第一种方案需要管理多个连接的状态，并要求在客户端以特权方式部署；第二种方案则要求修改 QUIC 客户端，实践部署困难。这两种方案都无法满足我们对灵活性和未来易部署性的要求。

因此，我们转而选择近似估计握手确认时间，做法只是让握手数据包与数据包走不同路由。关键洞见在于：QUIC 握手数据包使用 QUIC“长首部”格式，而数据包使用 QUIC“短首部”格式；两种格式可由 QUIC 首部中未加密的第一个比特区分。因此，仅使用线路上暴露的信息，就能区分握手数据包与数据包。

3.2.3. 概念验证实现说明。

QUICstep 的概念验证版本使用 iptables 防火墙规则，将特定数据包经 WireGuard 接口路由。规则会将 DNS 数据包（发往 53 端口的 UDP 数据包）、TCP 数据包以及 QUIC 长首部数据包（发往 443 端口且载荷以 1 开头的 UDP 数据包）经 WireGuard 接口路由，从而确保所有包含服务器名称的数据包都安全传输。此外，除能访问 WireGuard 代理（或其他握手通道）外，QUICstep 对客户端没有其他要求，也不会给客户端带来显著的额外延迟。若服务器不支持 QUIC 或连接迁移，客户端将回退到 TCP，全部流量均通过握手通道传输；用户不会遇到明显故障。我们的实现与评估代码见 https://github.com/inspire-group/QUICstep。

4. 评估

本节评估 QUICstep 规避现实审查的能力及其性能。

4.1. 研究问题与概览。

我们概述为回答各项研究问题而设计的评估（问题见 第 1 节）。

4.1.1. QUICstep 兼容性：测量现实网络中的兼容网站。

我们使用 QUICstep 执行 HTTP/3 GET 请求，识别热门网站当前对 QUIC 和连接迁移的支持情况（第 4.2 节）。结果显示，排名前一百万的域名中有 22%（约 22 万）支持 QUIC，其中 12.8%（约 2.8 万）兼容 QUICstep。研究结果还表明，服务提供商对连接迁移的支持起着关键作用。

4.1.2. 有效性：使用 QUICstep 在实践中规避审查。

我们评估 QUICstep 规避现实中基于 SNI 审查 TLS 和 QUIC 流量的审查系统的能力（第 4.3 节）。由于 QUICstep 通过握手通道传输握手数据包，审查方更难判断是否应封锁某个连接。我们发现，QUICstep 确实能成功规避现实中的 SNI 审查，包括 GFW 最近实施的 QUIC SNI 审查。

4.1.3. 性能评估。

我们针对不同设置下所有流量经原生通道或握手通道发送的场景，对 QUICstep 的延迟开展量化分析（第 4.4 节）。QUIC 连接迁移保证直连路径与隧道路径之间切换时只引入一个 RTT 的延迟（即路径验证），且不会中断客户端与服务器之间正在进行的会话。与原生 QUIC 连接相比，QUICstep 确实会因通过握手通道执行握手、并在路径切换时验证路径而产生一些额外延迟。然而，这些延迟会分摊到整个请求中；与所有流量均使用握手通道相比，QUICstep 最多可将页面加载时间缩短 84%。我们还表明，在 100 个不同网站上，QUICstep 可使握手通道提供方的负载中位数降低 93%（第 4.4.3 节）。运行高延迟通道会产生托管成本，需要由会合主机运营者、Tor 网桥志愿者或抗审查 VPN 提供商等承担。带宽可能因传输方式而受到明确限制，也可能被提供商封顶，或因通道经常过载而在实践中下降。QUICstep 通过择机将连接迁移到设备的原生网络，尽量减少带宽用量并降低高延迟通道的负载。

4.2. QUICstep 支持情况：测量现实网络中的兼容网站。

为确定 QUICstep 的潜在影响规模，我们测量支持 QUIC、完全兼容 QUICstep 或仅部分支持连接迁移的网站（域名）数量。完全兼容的网站可以直接使用 QUICstep；随着 QUIC 库不断成熟，目前不支持或仅部分支持连接迁移的 QUIC 网站未来也将受益于 QUICstep。

4.2.1. 实验设置与方法。

我们首先识别现实网络中支持 QUIC 的网站。为确定服务器端对 QUIC 的支持，我们通过 QUIC 向 Tranco 排名前一百万的域名发送 HTTP/3 GET 请求［37］；若客户端成功连接服务器，则记为支持 QUIC。我们使用 Chromium 的 quic_client 执行这些测试［26］。随后，我们在支持 QUIC 的网站中寻找兼容 QUICstep 的网站。为测量 QUICstep 兼容性，我们启用 QUICstep 执行 HTTP/3 GET 请求；若获取过程无错误完成，则记为成功。对于部分成功的 QUICstep 获取请求，我们检查了连接期间的数据包捕获，验证连接迁移后仍正常工作。我们分别向主域名和 www 子域名重复发送请求；二者任一成功即记为成功。我们排除通过 QUIC 提供的 404 错误页面，但纳入重定向页面。QUICstep 的客户端和握手通道提供方分别位于北弗吉尼亚和俄亥俄。

4.2.2. 相当一部分 QUIC 网站兼容 QUICstep。

截至 2024 年 10 月 25 日，我们发现排名前一百万的网站中有 219,729 个（22%）支持 QUIC；其中 28,104 个（12.8%）兼容 QUICstep。尽管 QUIC 尚未普及，我们预计未来 QUIC 将更加广泛（更多实体支持 QUIC）且更加完整（QUIC 实现完全遵循标准）。我们进一步分析了这些兼容域名所属的网络提供商。 表 1 列出了排名前一百万域名中前十名 QUIC 提供商，以及各提供商内 QUICstep 的兼容情况。可以看到，74.6% 的支持 QUIC 的域名使用 Cloudflare；但其中只有很小一部分（0.2%）兼容 QUICstep。进一步调查发现，这一低兼容率源于 Cloudflare CDN 的一项具体限制：它尚未完整支持连接迁移。根据 QUIC RFC，QUIC 实现理应支持连接迁移［32］，这说明即使被广泛使用的 QUIC 实现，也仍落后于完整规范的预期。我们还测试了 Cloudflare 的开源 QUIC 实现 quiche，确认它目前缺乏对连接迁移的正确支持。

在 Hetzner 所服务的支持 QUIC 的域名中，连接迁移支持率尤其高。Hetzner 所服务的大多数支持连接迁移的域名（很可能使用其托管服务）采用提供连接迁移功能的 Litespeed 服务器。这表明，大型云服务／托管提供商在连接迁移的推广中发挥关键作用；一次简单的服务更新就可能显著增加能够受益于连接迁移的网站数量。

我们认为，一些域名所有者可能并未意识到，由于其网站依赖项（CDN、负载均衡器等）与标准 QUIC 不兼容，他们错失了 QUIC 的性能收益。某些依赖项虽宣称支持 QUIC，却没有完整支持 RFC 标准所定义的连接迁移等关键 QUIC 功能。

另一个例子是 AWS CloudFront。CloudFront 声称支持连接迁移，但实践中的支持往往不一致。我们将在 第 4.2.3 节进一步讨论这一问题。

4.2.3. 部分支持连接迁移的网站数量正在增长。

测量中，我们发现一些网站不支持 IP 地址迁移，却支持端口迁移。这很可能是因为 Web 服务器或其依赖项使用的 QUIC 库没有正确实现连接迁移功能。随着 QUIC 库持续成熟，我们预计，这些仅部分支持连接迁移的网站未来可能兼容 QUICstep。

我们开展了一项长期测量，以跟踪这些未来可能兼容 QUICstep 的网站。为测量端口迁移支持，我们使用 quic_client 提供的临时端口迁移选项。该选项先执行一次 HTTP/3 GET 请求，随后迁移到一个临时端口，并在同一连接上执行第二次 HTTP/3 GET 请求。需要说明的是，其中一些支持端口迁移的网站可能已经支持 IP 地址迁移，因而完全兼容 QUICstep；尽管如此，我们仍将其计入未来可能兼容 QUICstep 的网站。2024 年 8 月 3 日至 11 月 13 日，我们每天扫描排名前一百万的域名。 图 3 显示，尽管支持 QUIC 的网站数量有所波动，未来可能兼容 QUICstep 的网站数量却显著增加。测量开始时（2024 年 8 月 3 日），有 26,234 个域名支持端口迁移；9 月 26 日增至 28,060 个，9 月 29 日又增至 31,262 个，此后一直保持在 31,000 个以上。

未来可能兼容 QUICstep 的网站数量增长，或许源于 QUIC 库升级。例如，测量开始时 Varnish CDN 不支持连接迁移，但我们近期的检查确认，它现在已经完整支持端口迁移，部分服务器也支持 IP 地址迁移。

还有一些特殊情形只支持 IP 地址迁移而不支持端口迁移。我们将其排除在测量之外，因为这些域名几乎都与 CloudFront CDN 相关。此外，我们发现，托管 amazon 域名的不同服务器（以 IP 地址区分）对 IP 地址迁移的响应各不相同。即使是同一域名，部分服务器支持 IP 地址迁移，另一些却不支持。我们推测，部署问题导致这些服务器使用了不同版本的 QUIC 实现或不同配置（例如，我们从某些服务器收到“服务器已禁用连接迁移”的错误消息，而其他服务器没有）。我们预计，稳健且一致的迁移支持将在不久的将来扩展到所有服务器。

4.2.4. 通往连接迁移之路。

测量表明，尽管连接迁移的采用率正在上升，仍有两项主要的现实挑战可能阻碍进一步部署和使用：(1) QUIC 实现不符合 RFC 标准，完全不支持或仅部分支持连接迁移；(2) 现代网站复杂的依赖关系要求关键基础设施节点稳健支持连接迁移。解决这些挑战需要 QUIC 开发者、应用提供商和服务提供商等不同利益相关方协作。尤其考虑到互联网的中心化，服务提供商在这一过程中起着关键作用；其是否愿意采用更新后的实现、配置基础设施以支持连接迁移，将直接影响该功能能否成功。例如，如果 Cloudflare 正确支持连接迁移，支持 QUIC 的域名中将有 87.2% 能利用连接迁移。

我们认为，推进连接迁移普及的关键一步，是开发一种可靠工具，用于在 QUIC 库开发和支持 QUIC 的服务部署中测试连接迁移。QUICstep 可作为这一进程的基石。如前所述，连接迁移涉及一些经常被忽略、只有在实际迁移事件中才能发现的复杂情形，例如支持端口迁移却不支持 IP 地址迁移。可以将 QUICstep 视为一种向网络引入人为移动事件、从而激活原生 QUIC 迁移功能的系统。使用 QUICstep 后，无需再像既有工作那样，依据间接信息推断服务器是否支持连接迁移［13］；相反，QUICstep 会根据迁移是否真正成功，明确确认服务器是否支持迁移。

4.3. 有效性：使用 QUICstep 在实践中规避审查。

我们测试 QUICstep 规避现实中基于 SNI 的审查系统的能力，确认 QUICstep 能够访问被封锁的网站。

4.3.1. 现实中的 TCP+TLS SNI 审查。

我们的第一项评估针对本地［匿名机构］内执行 TLS SNI 审查的 Palo Alto Networks 防火墙。我们访问了一个由我们控制、被该防火墙通过 SNI 审查封锁的域名。我们无法控制防火墙；由于域名名称与加密货币有关，Palo Alto 的自动系统将其加入了防火墙封锁名单。测试证实该域名确实通过 SNI 审查被封锁：该域名的 DNS 请求返回正确 IP 地址，与该 IP 地址的 TCP SYN → SYN+ACK 握手成功完成，直接连接 IP 地址而不使用域名也能成功。然而，我们观察到客户端发送 TLS ClientHello （SNI 字段中包含该域名）后，中间盒立即向连接注入 RST 数据包。

我们通过 QUICstep 成功与该域名建立了 QUIC 会话。使用原生 QUIC 连接访问 Web 服务器同样成功，这说明该防火墙执行的 SNI 审查并未对 QUIC 流量进行基于 SNI 的封锁。不过，这并不削弱 QUICstep 的成功：我们的结果确认 QUICstep 同样适用于传统 TCP SNI 审查。

4.3.2. 现实中的 QUIC SNI 审查。

我们尤其关注 GFW。作为主要审查系统之一，GFW 自 2024 年 4 月起开始使用 QUIC SNI 选择性审查 QUIC 流量［76］。我们针对中国现实中的 QUIC SNI 审查测试 QUICstep，发现 QUICstep 能够有效绕过 QUIC SNI 审查。原生连接无法访问的网站，通过 QUICstep 可以稳定访问。我们使用中国大陆的一台阿里云虚拟机作为客户端，并运行 quic_client 获取网站（指定 SNI）。我们向文献［76］的作者咨询了中国 QUIC SNI 审查的性质与范围，并获得一份遭 QUIC SNI 审查的域名列表。实验期间，我们在不同 AWS 区域之间变换握手通道提供方的位置，以避免留下固定痕迹。

第一项实验使用一台由我们控制的 QUIC 服务器，它运行在位于北弗吉尼亚的 AWS EC2 实例上。我们为该服务器分别设置一个未受审查的主机名和一个受审查的主机名（youtube.com）。将 QUIC SNI 设为未受审查的主机名时，原生客户端与 QUICstep 客户端在多轮重复试验中均能访问服务器；将 youtube.com 设为 QUIC SNI 主机名时，原生 QUIC 客户端在重复获取数次后被封锁。封锁不会立即发生，因为审查方以概率方式检查流量，并在检测到不希望放行的流量后封锁前往目标的连接。然而，QUICstep 客户端在连续 50 次获取中始终成功访问服务器。

我们还识别并测试了第 4.3.3 节所述在现实网络中可由 QUICstep 解封的域名。我们选取少量真实网站测试 QUICstep 的可行性。我们测试了 tiktokcdn.com 的 7 个子域名：它们遭到 QUIC SNI 封锁，但可通过 QUICstep 访问。反复测试表明，原生连接在获取数次后失败，而 QUICstep 始终能成功访问这些域名。

4.3.3. 中国目前遭 QUIC SNI 审查的网站中，有三分之一可能受益于 QUICstep。

我们测量了中国遭 QUIC SNI 审查的网站对 QUIC 迁移的支持情况。结果显示，在特定审查体系下被封锁的网站中，连接迁移支持率很高。一项同期工作［76］测试了 2024 年 10 月 2 日获得的完整 Tranco 列表（约 700 万个网站）¹，发现 GFW 的 QUIC SNI 封锁名单中有 28,458 个域名：如果 QUIC Initial 数据包以其中任一域名为 SNI，连接就会被丢弃。不过，由于其中许多域名不支持 QUIC，这更像是一种预防措施。我们发现，这些网站中有 2,404 个（8.45%）支持 QUIC，其中 828 个（34.4%）兼容 QUICstep。如果客户端能够识别与这些域名关联的某个未被封锁 IP 地址，QUICstep 就能解封这些网站。我们还测试了遭 TCP SNI 审查的网站与 QUICstep 的兼容性，因为这些网站未来可能逐步加入 GFW 的 QUIC SNI 封锁名单。我们采用文献［15］的方法，测试包含 65,153,600 个域名的列表²，识别出中国有 5,700,928 个网站遭 TCP SNI 审查。其中 3,524,808 个（61.8%）支持 QUIC，而其中 3,516,979 个（99.8%）兼容 QUICstep。这是因为封锁名单中有很大一部分是 blogspot.com 和 wixsite.com 子域名（占支持 QUIC 域名的 99.2%），二者都支持 QUICstep。

4.4. 性能评估。

本节旨在理解不同设置下影响 QUICstep 性能的因素，并将其与完全依赖代理的情形比较。我们考察代理带宽、客户端位置和代理位置等不同配置对页面加载时间和首字节时间的影响。结果表明，与完整 VPN 连接相比，QUICstep 显著降低 VPN 代理的负载，并在带宽受限环境中带来更大的性能收益。优化代理位置和 DNS 解析还可进一步提升 QUICstep 的性能。

4.4.1. 方法。

在默认设置中，客户端位于伦敦（AWS 区域），握手通道提供方位于俄亥俄，最大吞吐量限为 5 Mbps。我们用 Selenium 控制 Chrome，通过原生连接、完整 VPN 连接（即所有流量都经握手通道提供方隧道传输）和 QUICstep 三种方式各访问支持连接迁移的网站 100 次。每轮中，我们在三种连接类型之间交替，以减轻网络波动的影响。我们通过 Selenium 记录两项性能指标：首字节时间（responseStart-navigationStart）以及页面加载时间（domComplete-responseStart）。首字节时间（TTFB）包含握手带来的延迟，而握手通过加密 VPN 通道进行。因此，我们预计 QUICstep 的 TTFB 与 VPN 相近。但握手后，QUICstep 通过原生连接获取网站内容，故其页面加载时间应比 VPN 更短。评估中，我们改变客户端位置、握手通道提供方位置和握手通道带宽，以了解它们对 QUICstep 性能的影响。测量使用三个客户端位置（伦敦、新泽西和大阪）以及七个代理位置（法兰克福、爱尔兰、蒙特利尔、俄亥俄、俄勒冈、首尔和东京），共得到 21 种位置组合。此外，我们为握手通道提供方设置不同限速，以模拟现实用户会遇到的带宽受限安全通道。测试的最大吞吐量分别为 1 Mbps、5 Mbps、10 Mbps 和不限速。这些数值与热门代理服务的吞吐量规模相当：Tor 的吞吐量中位数约为 10 Mbps［56］，Psiphon 免费版将吞吐量限制为 2 Mbps［66， 68］。

除非特别说明，我们在不同设置下的观察总体一致。为清晰简洁起见，我们只报告默认设置（客户端：伦敦；握手通道提供方：俄亥俄；速率：5 Mbps）的结果。性能数值为 100 轮测量的中位数。

4.4.2. 与完整 VPN 相比，QUICstep 通常性能更佳。

测量量化了 QUICstep 相对完整 VPN 连接的性能收益。 图 4 展示了 100 个兼容 QUICstep 的不同域名上，VPN 与 QUICstep 页面加载时间中位数（20 轮）的分布；这些域名来自 2024 年 10 月 25 日 Tranco 前一千名列表³。对于大多数受测域名，QUICstep 的页面加载时间短于 VPN，最多可缩短 84%。如 第 3.2.2 节所述，我们的实现只是近似判断握手完成；若能更准确地迁移，缩短幅度可能更大。测量也证实了我们在 第 4.4.1 节中关于 TTFB 和页面加载时间的假设。对于 www.youtube.com 的不同客户端／代理位置组合，我们分别用 图 5 和 图 6展示 TTFB 与页面加载时间。我们选择 www.youtube.com 作为目标网站，因为它是能够稳定支持连接迁移的最大网站。可以清楚看到，尽管 QUICstep 的 TTFB 与完整 VPN 相当，但其页面加载时间显著优于完整 VPN。

4.4.3. QUICstep 显著降低代理（握手通道提供方）负载。

⁴ 性能提升背后的直觉很简单：QUICstep 可以显著减少必须经过代理的流量（QUICstep 只传输握手数据包，而传统 VPN 传输整个连接）。为量化理解 QUICstep 的减负优势，我们在每次使用 QUICstep 和 VPN 访问网站时于代理处捕获数据包，并计算流量比。“流量比”指 QUICstep 连接经代理的流量大小与完整 VPN 连接经代理的流量大小之比；“负载降低”指 1 − 流量比。如 图 7 所示，相较完整 VPN 连接，QUICstep 使 VPN 代理的 负载降幅中位数达到 93%。以 www.youtube.com 为例，完整 VPN 连接有 3.634 MB 流量经过代理，而 QUICstep 配置仅有 96 KB，负载降低 97.4%。这种减负效果可以帮助用户降低按用量付费代理服务器的成本，或更充分地利用带有流量上限的代理服务。

4.4.4. 通过优化代理位置，QUICstep 可达到与原生 QUIC 相当的性能。

不出所料，代理（握手通道提供方）的位置会影响 QUICstep 性能。代理在地理上离客户端越远，相比原生连接，QUICstep 增加的页面加载时间越多（图 6）。性能下降的一个明显原因是，代理离客户端越远，客户端与代理之间的往返时间就越长。不过，另一个值得注意的方面是，改变代理位置也会改变服务器位置，因为许多网站通过 CDN 提供服务。在 QUICstep（以及 VPN）中，DNS 请求通过代理执行，因此客户端连接的是靠近代理的 Web 服务器；原生连接中，客户端则连接靠近自身的服务器。

我们认为，服务器位置对性能的影响可能大于代理往返时间，因为 QUICstep 中大部分流量都通过原生连接直接发往服务器。事实上，我们确实观察到，在某些情况下 QUICstep 的性能可与原生 QUIC 相当（如 图 6(b)、(f) 和 (g)）。我们推测，这些情况下请求恰好由同一地理区域内的服务器提供服务。这也表明，客户端可有策略地选择位于审查体系之外、 且在地理上尽可能靠近自身的代理 位置，从而获得 最佳性能，特别是在连接 www.youtube.com 这类由遍布不同地理区域的 CDN 服务器提供服务的网站时。

4.4.5. 在带宽受限环境中，QUICstep 可带来更大的性能收益。

前文提到，现实中的代理可能只能提供有限带宽；在需求旺盛时，握手通道提供方还可能因资源限制而进一步降低服务质量［72］。为理解 QUICstep 在带宽受限环境中的性能优势，我们改变代理最大吞吐量和客户端／代理位置，在获取 www.youtube.com 时考察 QUICstep 页面加载时间与 VPN 页面加载时间之比。比值越小，表示相对 VPN 的性能收益越大。 表 2 （完整结果见 表 4）给出了结果。我们观察到， 代理带宽越低，QUICstep 的性能收益 越明显。具体而言，代理吞吐量为 1 Mbps 或 5 Mbps 时，QUICstep 始终优于 VPN；带宽为 10 Mbps 时，某些情况下 VPN 的性能优于 QUICstep。这可能是因为基于 AWS 的代理连接质量良好，使代理路径可能比客户端与服务器之间的直连路径更高效。即使不限速，我们也至少能找到一个代理位置，使 QUICstep 的页面加载时间与 VPN 相当或更佳，且相较原生连接引入的额外延迟不足 5%。TTFB 呈现与 第 4.4.2 节相似的规律，为节省篇幅不再列出结果。总体而言，代理吞吐量有限时，QUICstep 可带来更大性能收益。这对现实用户尤其有吸引力，因为公共 VPN 服务或志愿者代理经常受到限速。QUICstep 减少必须经过限速通道的流量，从而有效缓解潜在的性能瓶颈。

4.4.6. QUICstep 为大型网站带来更大的性能收益。

另一个可能影响浏览性能的常见因素是网站大小。然而，在现实环境中评估网站大小对 QUICstep 的影响并不容易，因为第三方服务器依赖等各种“噪声”因素可能影响性能估计。因此，我们开展受控实验来消除噪声。我们使用 Google QUICHE 搭建自己的 QUIC 服务器，托管不同大小的文件，再使用 Chromium quic_client 在不同代理吞吐量限制下获取这些文件。QUICstep 与 VPN 文件下载时间之比如 图 8所示，更详细的数据见 表 5。不出所料，文件越大，QUICstep 相对 VPN 的性能收益越高。观察 QUICstep 相对原生延迟的额外开销时，这一规律更加明显（表 5）。QUICstep 连接在握手后不会引入额外延迟，因此无论文件大小如何，其额外延迟都保持稳定。

我们预计，对于大型网站，QUICstep 相对 VPN 能带来更大的性能收益，因为有更高比例的流量经原生通道传输。

4.4.7. 优化 DNS 解析可进一步提升 QUICstep 性能。

如 第 4.4.4 节所述，执行 DNS 查询的位置对 QUICstep 性能有不可忽视的影响，因为它可能进而影响客户端所连接服务器的位置。理想情况下，我们希望客户端自行执行 DNS 查询，以确保选择最优服务器。但这在实践中不可行，因为 DNS 审查是最基本、最普遍的审查形式。审查方常读取明文 DNS 查询，并通过封锁查询或注入包含审查方自有 IP 地址的响应加以干扰［29， 34］。

客户端和代理可通过以下几种方法选择最优服务器 IP 地址：

(1) 客户端可以使用基于 TLS 的 DNS（DoT）或基于 HTTPS 的 DNS（DoH）等方式发送加密 DNS 请求。使用加密 DNS 的最大挑战在于客户端能否访问加密 DNS 解析器，尤其是已有一些国家封锁这类解析器［34］。使用加密 DNS 规避审查还有其他一些注意事项和限制。若解析器位于审查体系内，审查方可以操纵解析器与权威名称服务器之间未加密的流量［34］。此外，DoH 在实践中降级为明文 DNS 的情况并不少见［38］。(2) 代理可以利用 EDNS 客户端子网（ECS），向权威 DNS 服务器透露客户端的网络前缀。正如 第 3.1 节所述，匿名性并非客户端的主要考虑。如果目标域名的权威 DNS 服务器支持 ECS，客户端就会收到更靠近 DNS 查询中指定客户端网络的 IP 地址。需要指出，递归解析器（如 Cloudflare［17］）和权威服务器并非普遍支持 ECS。代理可以使用修改过的 DNS 客户端，或运行本地递归解析器来执行 DNS 解析，因为标准 DNS 客户端原生不支持 ECS。(3) 客户端可以直接连接通过带外通道获得的最优服务器（或前端）IP 地址，例如类似 Lox［58］和 rBridge［65］）。

我们在客户端能够以某种方式安全获得地理位置靠近自身的最优服务器 IP 地址时，评估了 QUICstep 的性能。原生、VPN 与 QUICstep 连接都使用客户端获得的 IP 地址，从而消除了客户端连接远端服务器导致的额外延迟。 图 9 表明，相较 VPN，QUICstep 甚至小幅降低了 TTFB；这不同于 图 5 中 QUICstep 与 VPN 的 TTFB 延迟相当的情形。 表 3 展示了不同代理位置下，QUICstep 的页面加载时间与 VPN 和原生连接的比较。对于远离客户端的代理，QUICstep 与 VPN 的页面加载时间比显著降低。例如，伦敦客户端访问东京附近的服务器、代理位于东京时，QUICstep 相比 VPN 将延迟降低 32%；而当客户端访问自身附近的服务器时，延迟最多降低 70%，收益幅度达到前者的 2.65 倍。

再次强调，虽然 DNS 解析过程本身的开销可控，主要影响因素却是 DNS 查询位置所决定的服务器位置。优化 DNS 解析可显著提升 QUICstep 性能。

性能评估总结。 QUICstep 显著减少经握手通道传输的流量，使客户端能够更高效、更充分地利用性能受限的安全握手通道。当握手通道相较原生通道导致页面加载时间增加得更多时，QUICstep 的性能优势尤为明显：例如握手通道带宽较低或网站较大时。QUICstep 的性能与代理和服务器的位置高度相关。选择靠近客户端的代理，并通过 ECS 或带外通道连接靠近客户端的服务器，可进一步提升 QUICstep 性能。

5. 针对 QUICstep 的潜在攻击

本节探讨针对 QUICstep 的潜在攻击及其可行性，从简单的协议封锁逐步讨论到更复杂的流量分析。我们主要关注现实审查方已经或可能采用的实用攻击；既有研究表明，这类攻击通常是无状态的［3， 70， 76］。我们将无状态攻击定义为无需来自两个或更多数据包的信息、可逐包执行的攻击。例如，如果审查方遵循 Google 提供的参考实现，QUIC SNI 审查就可以是无状态的［25］。

DNS 封锁与 SNI 审查。 DNS 封锁［4， 29］和 SNI 审查是审查方封锁网站的两项主要技术。QUICstep 能够避开 DNS 封锁和 QUIC-SNI 封锁，因为 DNS 请求和 QUIC Handshake 数据包都通过不受审查的安全加密隧道传输。

IP 地址封锁。 一些审查方可能采用 IP 地址封锁［15］。按照既有工作并如 第 3.1 节所述，QUICstep 适用于目标 IP 地址未被封锁的情形。受审查域名可以利用未被封锁的 CDN 或云服务来规避 IP 地址封锁。需要指出的是，QUICstep 有时也能帮助规避基于 IP 地址的封锁：在 QUICstep 中，DNS 请求通过审查体系之外的代理执行，可能解析到另一个不在审查方 IP 地址封锁名单上的地址［15］。审查方也可能试图封锁握手通道提供方的 IP 地址。握手通道提供方可以像 Tor 网桥一样不公开 IP 地址，或像 Snowflake 一样频繁轮换 IP 地址［11］。与所有通信都依赖 VPN 相比，QUICstep 的设计也有助于降低握手通道提供方 IP 地址被识别的风险。识别 VPN 使用情况的一种方式，是判断客户端是否主要与单个 IP 地址通信；QUICstep 不会出现这种特征，因为客户端还会直接与目标服务器通信。

封锁所有 QUIC 流量。 对抗 QUICstep 的一种攻击策略是封锁所有 QUIC 流量。我们认为，鉴于 QUIC/HTTP3 部署迅速增加，这种激进策略会造成严重附带损害，可能并不符合审查方的利益。例如，中国的主要云服务提供商（阿里、腾讯、华为等）都提供基于 QUIC 的服务，因此封锁 QUIC 可能损害这些中国公司的收入。我们注意到，在 QUIC 部署早期的 2022 年，俄罗斯曾被怀疑封锁 QUIC 流量［74］。这可能是因为当时 DPI 无法解密加密 QUIC 载荷中的 SNI。不过，随着 QUIC SNI 检测技术成熟并集成到商业 DPI 系统中（如 Cisco［16］），国家级审查方会更有动力采用 QUIC SNI 检测，以尽量减少附带损害。事实上，近期证据表明，俄罗斯已经转向使用 QUIC SNI 检测［69］。如前所述，QUICstep 是绕过 QUIC SNI 审查的有效方法。

封锁所有发生连接迁移的 QUIC 流量。 理论上，审查方可以尝试识别 QUIC 连接迁移事件，并封锁所有已迁移的 QUIC 连接。缺少 Handshake 或 Initial 数据包可能是连接已经迁移的一个指标。然而，这种攻击面临重大挑战：从流量特征看，QUICstep 迁移与典型客户端移动事件触发的迁移无法区分。可以将 QUICstep 视为使用人为移动事件来触发原生 QUIC 迁移的系统。没有可靠方法能逐连接区分“正常”迁移与 QUICstep 迁移。连接迁移很可能在未来的移动网络和车联网中普及，这也是 QUIC 设计连接迁移功能时的关键考虑。因此，简单封锁所有已迁移连接可能造成严重附带损害。为评估审查方丢弃不含 Handshake 或 Initial 数据包的 QUIC 连接是否可行，我们分析了 2022 年 11 月 6 日从某校园网络采集的 24 小时 QUIC 流量。⁵ 在 3,786,050 个独立 QUIC 连接中，有 1,100,439 个（29.1%） 既不包含 QUIC Initial ，也不包含 QUIC Handshake 数据包。 它们很可能是正常连接迁移活动产生的流。

假设情形：有状态流量分析。 作为一种轻量方法，QUICstep 不考虑有状态流量分析，也不声称能够抵御此类攻击（例如，根据异常的连接迁移事件频率检测 QUICstep）。多种已部署的审查规避工具也存在类似局限，例如，一些 Tor 可插拔传输和 VPN 可通过流量分析被识别［2， 62， 63， 73， 75］。我们承认，针对能够抵御有状态流量分析的审查规避技术，已有大量研究［5， 6， 12， 19， 24， 33， 46， 53］。不过，这类攻击耗费资源，因为审查方必须存储显著更多的状态信息。现实中的实时 DPI 仍偏好关键词匹配等轻量检测机制（第 2.3.5 节）。高级流量分析攻击能否以已部署审查系统实时封锁目标所需的效率检测 QUICstep，仍是一个开放问题。

6. 讨论与结论

总而言之，QUICstep 为 QUIC 优先的未来世界提供了一条很有前景的审查规避路径。QUICstep 成功规避了现实审查系统；与所有通信都依赖安全但资源受限的通道相比，它能带来显著性能收益。QUICstep 的性能收益在以下情形尤为显著：用户每个连接获取更多数据（例如访问大型网站； 第 4.4.6 节），或用户资源有限（例如握手通道带宽较低； 第 4.4.5 节）。

QUICstep 与应用无关，因此可集成到现有审查规避工具中。将 QUICstep 集成到现有代理服务也能使提供商受益，因为 QUICstep 大幅减少每个客户端的资源消耗。本研究还展示了现实网络中 QUIC 和连接迁移支持的现状；QUICstep 同样可用作评估连接迁移支持情况的工具。

本节讨论大规模部署 QUICstep 的路径；当前互联网对 QUIC 和连接迁移的支持有限，是其主要瓶颈。

提升 QUIC 的支持与采用。 Rüth 等人报告，2017 年 10 月 Alexa 前一百万列表中有 1.2% 支持 QUIC［49］；我们的结果则发现，2024 年 11 月 Tranco 前一百万列表中支持 QUIC 的比例超过 22%。⁶ 随着 HTTP/3 标准化以及 QUIC 部署持续增长，我们预计 QUIC 将成为互联网流量的事实标准［7， 61］。

提升连接迁移的支持与采用。 我们在 第 4.2 节 中的结果表明，连接迁移支持率正在上升，但仍未覆盖大多数支持 QUIC 的网站。测试发现，QUICstep 不仅可用于审查规避，还能帮助了解网站是否以及如何支持 QUIC 连接迁移。本研究给出了迄今最全面的 QUIC 连接迁移部署测量，并区分不同类型的支持。我们希望本研究能推动连接迁移支持增长，也希望 Cloudflare 等服务提供商认识到连接迁移的价值。

标准化连接迁移支持的通告机制。 我们的测量揭示了 QUIC 支持与 QUIC 连接迁移支持之间的差距。因此，客户端必须先发现主机是否支持连接迁移，才能利用其性能优势。目前，客户端没有用于发现连接迁移支持情况的标准方法。我们及既有工作的测量均表明，要可靠判断网站是否支持连接迁移并不容易；此外，许多网站只支持端口迁移或 IP 迁移之一。若能将发现连接迁移支持的方法标准化（或许在已建立的 QUIC 通道中实现），所有 QUIC 客户端都可从连接迁移的性能优势中受益。目前，由于客户端很难识别连接迁移支持情况，仍需维护一份支持连接迁移的端点列表。

将 QUICstep 集成到实用部署中。 本研究证明，QUICstep 核心功能的实现十分轻量，可以简化为若干基于数据包的路由规则。我们认为，如果具备择机发现 QUIC 和连接迁移支持情况的机制，QUICstep 可以作为独立工具部署（如封装为 Android VPN），更理想的方式则是与现有审查规避工具一同部署。QUICstep 的性能优势还可推广到减少高安全握手通道的带宽用量；现有规避软件可利用这一点，降低志愿者提供方（或其他资源有限的提供方）的负载。

7. 伦理考量

审查规避实验。 我们在 第 4.3 节 中的审查规避实验不涉及任何人类受试者。在 GFW 测量中，我们使用由自己控制、托管在大型商业 VPS 提供商处且拥有专用 IP 地址的客户端主机。为避免客户端主机本身遭封锁，我们只访问了少量真实域名。我们还运行一台由自己控制的 QUIC 服务器，并用不同域名开展进一步测试。需要说明的是，该服务器运行于 localhost，只有知道其 IP 地址的客户端主机能够访问。

网络流量轨迹分析。 为评估 第 5 节中封锁所有发生 QUIC 连接迁移的流量会造成多大附带损害，我们分析了从校园网络收集的匿名化流量轨迹。校园网络运营方管理采集点并捕获 443 端口的 UDP 流量；他们清洗流量轨迹、匿名化 IP 地址和源端口，并在将数据交给我们前移除所有受保护载荷。流量轨迹所用的网络存储系统也由校园网络运营方管理，并通过访问限制加以保护。这些流量轨迹同样供校园内其他项目使用，我们无法控制数据的保存期限。我们获得了所属机构 IRB 对研究这些数据的批准，除论文给出的汇总统计外未进行任何其他分析。

致谢

感谢匿名审稿人提出的宝贵意见。本材料所述工作获得美国国防高级研究计划局（DARPA）合同 HR00112590081 的支持。本文表达的任何观点、发现、结论或建议均属于作者本人，不一定代表资助方的观点。

参考文献

1. OONI: Open Observatory of Network Interference. In 2nd USENIX Workshop on Free and Open Communications on the Internet (FOCI 12), Bellevue, WA, August 2012. USENIX Association.
2. Sultan Almutairi, Yogev Neumann, and Khaled Harfoush. Fingerprinting vpns with custom router firmware: A new censorship threat model. In 2024 IEEE 21st Consumer Communications & Networking Conference (CCNC), pages 976–981. IEEE, 2024.
3. Anonymous and Amonymous. Sharing a modified Shadowsocks as well as our thoughts on the cat-and-mouse game, October 2022.
4. Anonymous, Arian Akhavan Niaki, Nguyen Phong Hoang, Phillipa Gill, and Amir Houmansadr. Triplet censors: Demystifying Great Firewall’s DNS censorship behavior. In Free and Open Communications on the Internet. USENIX, 2020.
5. Diogo Barradas, Nuno Santos, and Luís Rodrigues. DeltaShaper: Enabling unobservable censorship-resistant TCP tunneling over videoconferencing streams. Proceedings on Privacy Enhancing Technologies, 2017(4):5–22, 2017.
6. Diogo Barradas, Nuno Santos, Luís Rodrigues, and Vítor Nunes. Poking a hole in the wall: Efficient censorship-resistant Internet communications by parasitizing on WebRTC. In Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security, pages 35–48, 2020.
7. David Belson and Lucas Pardue. Examining HTTP/3 usage one year on, June 2023.
8. M Bishop. RFC 9114: HTTP/3, 2022.
9. Kevin Bock, George Hughey, Xiao Qiang, and Dave Levin. Geneva: Evolving Censorship Evasion Strategies. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, CCS ’19, page 2199–2214, New York, NY, USA, 2019. Association for Computing Machinery.
10. Kevin Bock, iyouport, Anonymous, Louis-Henri Merino, David Fifield, Amir Houmansadr, and Dave Levin. Exposing and circumventing china’s censorship of esni. Technical report, GFW Report, August 2020.
11. Cecylia Bocovich, Arlo Breault, David Fifield, Serene, and Xiaokang Wang. Snowflake, a censorship circumvention system using temporary WebRTC proxies. In 33rd USENIX Security Symposium (USENIX Security 24), pages 2635–2652, Philadelphia, PA, August 2024. USENIX Association.
12. Chad Brubaker, Amir Houmansadr, and Vitaly Shmatikov. Cloudtransport: Using cloud storage for censorship-resistant networking. In International Symposium on Privacy Enhancing Technologies Symposium, pages 1–20. Springer, 2014.
13. Aurélien Buchet and Cristel Pelsser. An analysis of QUIC connection migration in the wild, 2024.
14. Cormac Callanan, Hein Dries-Ziekenheiner, Alberto Escudero-Pascual, and Robert Guerra. Leaping over the firewall: A review of censorship circumvention tools. Report by Freedom House, 2011.
15. Zimo Chai, Amirhossein Ghafari, and Amir Houmansadr. On the importance of encrypted-SNI (ESNI) to censorship circumvention. In Free and Open Communications on the Internet. USENIX, 2019.
16. Cisco. Support for SNI Detection, unknown.
17. Cloudflare. 1.1.1.1 (DNS Resolver) FAQ, 2024.
18. Arjun Devraj, Liang Wang, and Jennifer Rexford. Redact: refraction networking from the data center. ACM SIGCOMM Computer Communication Review, 51(4):15–22, 2021.
19. Kevin P Dyer, Scott E Coull, and Thomas Shrimpton. Marionette: A programmable network traffic obfuscation system. In 24th {USENIX}Security Symposium ({USENIX}Security 15), pages 367–382, 2015.
20. The eBPF Foundation. eBPF Documentation, 2024.
21. Kathrin Elmenhorst. A Quick Look at QUIC Censorship, Apr 2022.
22. Kathrin Elmenhorst, Bertram Schütz, Nils Aschenbruck, and Simone Basso. Web censorship measurements of HTTP/3 over QUIC. In Proceedings of the 21st ACM Internet Measurement Conference, pages 276–282, 2021.
23. David Fifield, Chang Lan, Rod Hynes, Percy Wegmann, and Vern Paxson. Blocking-resistant communication through domain fronting. Proceedings on Privacy Enhancing Technologies, 2015.
24. Gabriel Figueira, Diogo Barradas, and Nuno Santos. Stegozoa: Enhancing WebRTC Covert Channels with Video Steganography for Internet Censorship Circumvention. In Proceedings of the 2022 ACM on Asia Conference on Computer and Communications Security, pages 1154–1167, 2022.
25. Google. Parsing QUIC Client Hellos, 2021.
26. Google. QUICHE. https://quiche.googlesource.com/quiche/, 2022.
27. Yashodhar Govil, Liang Wang, and Jennifer Rexford. MIMIQ: Masking IPs with migration in QUIC. In 10th USENIX Workshop on Free and Open Communications on the Internet (FOCI), 2020.
28. Nguyen Phong Hoang, Jakub Dalek, Masashi Crete-Nishihata, Nicolas Christin, Vinod Yegneswaran, Michalis Polychronakis, and Nick Feamster. GFWeb: Measuring the Great Firewall’s Web censorship at scale. In USENIX Security Symposium. USENIX, 2024.
29. Nguyen Phong Hoang, Arian Akhavan Niaki, Jakub Dalek, Jeffrey Knockel, Pellaeon Lin, Bill Marczak, Masashi Crete-Nishihata, Phillipa Gill, and Michalis Polychronakis. How great is the Great Firewall? Measuring China’s DNS censorship. In USENIX Security Symposium. USENIX, 2021.
30. Amir Houmansadr, Thomas J Riedl, Nikita Borisov, and Andrew C Singer. I want my voice to be heard: IP over Voice-over-IP for unobservable censorship circumvention. In NDSS, 2013.
31. Hysteria developers. Hysteria.
32. Jana Iyengar and Martin Thomson. RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport. Omtermet Emgomeeromg Task Force, 2021.
33. Watson Jia, Joseph Eichenhofer, Liang Wang, and Prateek Mittal. Voiceover: Censorship-circumventing protocol tunnels with generative modeling. Free and Open Communications on the Internet, 2023.
34. Lin Jin, Shuai Hao, Haining Wang, and Chase Cotton. Understanding the impact of encrypted DNS on internet censorship. In Proceedings of the Web Conference 2021, pages 484–495, 2021.
35. Sedat Kappanoğlu. turkish ISPs use two methods for blocking access... https://twitter.com/esesci/status/1630024112071491586.
36. Lantern. Lantern - Frequently Asked Questions.
37. Victor Le Pochat, Tom Van Goethem, Samaneh Tajalizadehkhoob, Maciej Korczyński, and Wouter Joosen. Tranco: A research-oriented top sites ranking hardened against manipulation. In Proceedings of the 26th Annual Network and Distributed System Security Symposium, NDSS 2019, February 2019.
38. Jinseo Lee, David Mohaisen, and Min Suk Kang. Measuring dns-over-https downgrades: Prevalence, techniques, and bypass strategies. Proceedings of the ACM on Networking, 2(CoNEXT4):1–22, 2024.
39. Victoria Manfredi and Pi Songkuntham. MultiFlow: Cross-Connection decoy routing using TLS 1.3 session resumption. In 8th USENIX Workshop on Free and Open Communications on the Internet (FOCI 18), Baltimore, MD, August 2018. USENIX Association.
40. Hooman Mohajeri Moghaddam, Baiyu Li, Mohammad Derakhshani, and Ian Goldberg. Skypemorph: Protocol obfuscation for tor bridges. In Proceedings of the 2012 ACM conference on Computer and communications security, pages 97–108, 2012.
41. Milad Nasr, Hadi Zolfaghari, Amir Houmansadr, and Amirhossein Ghafari. Massbrowser: Unblocking the censored web for the masses, by the masses. In NDSS, 2020.
42. Niklas Niere, Felix Lange, Nico Heitmann, and Juraj Somorovsky. Encrypted client hello (ech) in censorship circumvention. Free and Open Communications on the Internet, 2025.
43. Tor Project. meek, 2020.
44. Eric Rescorla. The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446, August 2018.
45. Eric Rescorla, Kazuho Oku, Nick Sullivan, and Christopher A. Wood. TLS Encrypted Client Hello. Internet-Draft draft-ietf-tls-esni-25, Internet Engineering Task Force, June 2025. Work in Progress.
46. Marc B Rosen, James Parker, and Alex J Malozemoff. Balboa: Bobbing and weaving around network censorship. In 30th USENIX Security Symposium (USENIX Security 21), pages 3399–3413, 2021.
47. Zach Rosson, Felicia, Carolyn Tackett, and Meabh Maguire. Lives on hold: internet shutdowns in 2024, February 2025.
48. Shadowsocks rust developers. Shadowsocks-rust.
49. Jan Rüth, Ingmar Poese, Christoph Dietzel, and Oliver Hohlfeld. A first look at quic in the wild. In Passive and Active Measurement: 19th International Conference, PAM 2018, Berlin, Germany, March 26–27, 2018, Proceedings 19, pages 255–268. Springer, 2018.
50. Sambhav Satija and Rahul Chatterjee. BlindTLS: Circumventing TLS-based HTTPS censorship. In Free and Open Communications on the Internet. ACM, 2021.
51. Shadowsocks developers. Shadowsocks.
52. Sing-box developers. Sing-box.
53. Zhen Sun and Vitaly Shmatikov. Telepath: A minecraft-based covert communication system. In 2023 IEEE Symposium on Security and Privacy (SP), pages 2223–2237. IEEE, 2023.
54. Ram Sundara Raman, Prerana Shenoy, Katharina Kohls, and Roya Ensafi. Censored Planet: An Internet-Wide, Longitudinal Censorship Observatory. In Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security, CCS ’20, page 49–66, New York, NY, USA, 2020. Association for Computing Machinery.
55. Ram Sundara Raman, Adrian Stoll, Jakub Dalek, Reethika Ramesh, Will Scott, and Roya Ensafi. Measuring the Deployment of Network Censorship Filters at Global Scale. In NDSS, 2020.
56. The Tor Project. Tor metrics - performance, 2024.
57. Martin Thomson and Sean Turner. Using TLS to Secure QUIC. RFC 9001, May 2021.
58. Lindsey Tulloch. Lox: Protecting the social graph in bridge distribution. Master’s thesis, University of Waterloo, 2022.
59. V2Ray developers. V2Ray.
60. Paul Vines, Samuel McKay, Jesse Jenter, and Suresh Krishnaswamy. Communication breakdown: Modularizing application tunneling for signaling around censorship. Privacy Enhancing Technologies, 2024(1), 2024.
61. W3Techs. Usage statistics of http/3 for websites, May 2025.
62. Ryan Wails, George Arnold Sullivan, Micah Sherr, and Rob Jansen. On precisely detecting censorship circumvention in real-world networks. In Network and Distributed System Security, 2024.
63. Liang Wang, Kevin P Dyer, Aditya Akella, Thomas Ristenpart, and Thomas Shrimpton. Seeing through network-protocol obfuscation. In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, pages 57–69, 2015.
64. Mona Wang, Anunay Kulshrestha, Liang Wang, and Prateek Mittal. Leveraging strategic connection migration-powered traffic splitting for privacy. In Proceedings on Privacy Enhancing Technologies, page 498–515, 2022.
65. Qiyan Wang, Zi Lin, Nikita Borisov, and Nicholas Hopper. rbridge: User reputation based tor bridge distribution with privacy preservation. In NDSS, 2013.
66. Jon Watson. How to Use Psiphon The Censorship-Circumvention Tool, 2021.
67. Mingkui Wei. Domain shadowing: Leveraging content delivery networks for robust Blocking-Resistant communications. In 30th USENIX Security Symposium (USENIX Security 21), pages 3327–3343. USENIX Association, August 2021.
68. Mike Williams. Pshiphon review, 2020.
69. wkrp. Throttling→blocking of YouTube in Russia, 2024-07-12, 2024.
70. Mingshi Wu, Jackson Sippe, Danesh Sivakumar, Jack Burg, Peter Anderson, Xiaokang Wang, Kevin Bock, Amir Houmansadr, Dave Levin, and Eric Wustrow. How the Great Firewall of China detects and blocks fully encrypted traffic. In USENIX Security Symposium. USENIX, 2023.
71. XRay developers. XRay.
72. Diwen Xue, Anna Ablove, Reethika Ramesh, Grace Kwak Danciu, and Roya Ensafi. Bridging barriers: A survey of challenges and priorities in the censorship circumvention landscape. In 33rd USENIX Security Symposium (USENIX Security 24), pages 2671–2688, Philadelphia, PA, August 2024. USENIX Association.
73. Diwen Xue, Michalis Kallitsis, Amir Houmansadr, and Roya Ensafi. Fingerprinting obfuscated proxy traffic with encapsulated {TLS} handshakes. In 33rd USENIX Security Symposium (USENIX Security 24), pages 2689–2706, 2024.
74. Diwen Xue, Benjamin Mixon-Baca, ValdikSS, Anna Ablove, Beau Kujath, Jedidiah R Crandall, and Roya Ensafi. Tspu: Russia’s decentralized censorship system. In Proceedings of the 22nd ACM Internet Measurement Conference, pages 179–194, 2022.
75. Diwen Xue, Reethika Ramesh, Arham Jain, Michaelis Kallitsis, J Alex Halderman, Jedidiah R Crandall, and Roya Ensafi. OpenVPN is open to VPN fingerprinting. Communications of the ACM, 2022.
76. Ali Zohaib, Qiang Zao, Jackson Sippe, Abdulrahman Alaraj, Amir Houmansadr, Zakir Durumeric, and Eric Wustrow. Exposing and circumventing SNI-based QUIC censorship of the Great Firewall of China. In USENIX Security Symposium. USENIX, 2025.