面向低尾延迟的多中转路径传输：一种不追求带宽聚合的多路径方案

免责声明：本文内容完全由 AI 生成，文中所有内容均为 A\ 的幻觉，不代表任何事实或建议。请勿将本文任何内容用于违反任何国家或地区法律法规及公序良俗的用途。

摘要

在带宽普遍过剩的今天，代理网络的主要体验瓶颈已从吞吐转向尾延迟：单个中转节点的间歇性排队与假死，会直接表现为交互卡顿。现有代理客户端的选路机制均工作在连接粒度，依赖周期性探测，无法在毫秒到秒级掩盖单路径故障；学术界与商业界的低尾延迟多路径系统则普遍依赖 UDP 或内核 MPTCP ，无法用于只有 TCP 中转可用的环境。本文提出一种思路：经由多个相互独立的中转节点同时维持长连接，在其上运行轻量的传输层，以"晚绑定、对冲重发、慢路径隔离"为调度原则，将多路径用于压低尾延迟而非叠加带宽。配合两家中转机场与一台自建落地机（独享出口 IP ，避免机场共享 IP 被污染），月成本约 ¥70 ，可由 2–3 人分摊；如需使用 AI 工具，可再叠加家宽出口。

1 引言

主流中转机场的带宽已足以覆盖日常需求，用户感知到的问题主要是偶发卡顿：SSH 回显停顿、LLM 流式输出中断、视频缓冲。其共同来源是单条路径的瞬时劣化，例如高峰期排队，或连接未断但数据停止流动的假死。这类故障持续时间短（数百毫秒到数秒）且难以预测，任何"发现故障再切换"的方案都注定慢一步。

中文社区对此已有相当一致的经验：测速不准、切换有害、叠加无效。 测速表上的低延迟节点用起来照样卡；频繁切换节点会打断正在进行的连接；多条线路做负载均衡，单条连接的速度并不会叠加。主流做法因此退化为"多机场冷备 + 手动分流"。

本文的目标是：任意单条路径的劣化，不应被用户感知。

2 背景与相关工作

2.1 代理客户端的选路机制

主流代理内核提供的选路机制如下：

内核	机制	探测方式
mihomo	url-test （最低延迟 + 容差防抖）、fallback （顺序取第一个存活）、load-balance （按目的地哈希 / 轮询 / 粘性会话）	HTTP 探测，默认 300 s 一轮，默认惰性探测
sing-box	urltest （容差默认 50 ms ），切换时默认不中断已有连接	默认 3 min 一轮，空闲 30 min 后停止探测
Xray	balancer：random / roundRobin / leastPing / leastLoad （按 RTT 标准差加权）	Observatory 周期探测
gost	round / rand / fifo / hash / parallel （同时向所有节点拨号，取第一个成功者）	被动失败计数 + 主动探测

它们存在三个共同局限：

连接粒度。 选路只决定"下一条新连接走哪个节点"；已建立的连接始终绑定在原节点上，切换只影响后续连接。gost 的 parallel 是其中最接近竞速的设计，但只作用于建连阶段，数据传输仍是单路径。
探测通道不等于数据通道。 探测测量的是一次 HTTP 请求的延迟，而非用户数据的实际传输状况；部分机场甚至会对测速流量做针对性处理。近期出现的"根据节点历史表现打分"的智能选路内核，承认了单点测速的不可靠，但仍停留在连接粒度。
时间尺度不匹配。 探测周期为分钟级，而卡顿是秒级。为避免节点来回跳动，机场往往还会主动调大探测间隔。故障恢复后切回原节点（ failback ）的能力，在主流客户端中也普遍缺位。

2.2 社区的多路径尝试

社区中不乏想要"一条连接的数据分多条线走、远端重组"的讨论 [8][9]，但结论多是现成方案全部基于连接、TCP 乱序难以处理。也有人真正实现了"每个包随机走多条 TCP 流、上层负责重传"，结果可靠性没问题，带宽却低于单条线路，症结在于各路径延迟不同。双宽带聚合中"慢线会拖累快线"同样是社区的朴素共识。

2.3 MPTCP 及其批评

MPTCP [1][2] 在一条连接内使用多个子流。知乎「浙江温州皮鞋湿」的系列文章 [3–6] 对其做了深入分析，主要结论包括：

数据一旦分配给某个子流，就只能由该子流发送；路径阻塞时数据被困，其他空闲路径无法代劳。合理的模型是所有路径共享一个发送队列，由接收端重排 [3]。
带宽聚合需要在发送端积压数据以填满异构路径，以延迟为代价换取多数应用并不需要的吞吐；多路径的主要价值在于主备切换 [4][5]。

此外，在代理场景下，中转节点会终结 TCP 连接，端到端的 MPTCP 无法穿越机场节点。

2.4 低尾延迟多路径系统

另一类系统直接以尾延迟为目标，其中最接近本文思路的商业实现是 Speedify [15]。它把用户的多条上网链路（ Wi-Fi 、蜂窝、有线）绑定到自家服务器，数据按包分发到各条链路，丢包时在表现最好的链路重传；另提供冗余模式（每个包在所有链路上复制，先到者有效）和面向音视频的自适应模式（检测到链路劣化时自动转为冗余）。可以说，"多条路径同时在线、按包调度、用冗余换延迟"这一方向，Speedify 已经在商业上验证过。

但 Speedify 解决的是另一个问题：它的路径是用户本地的多个网络接口，终点是它自己的服务器，无法把第三方中转节点当作路径；其冗余模式是无条件复制，开销恒定翻倍；算法闭源。在本文的场景中，用户只有一条本地网络，可用的"多路径"恰恰是多个机场节点，而 Speedify 的服务器本身在国内也难以直连。

开源方面，多路径 QUIC VPN 中已有"未确认时间超过最小 RTT 的一定倍数即在另一条链路重发"的设计； Linux MPTCP 的冗余调度器对每个包无条件复制；多路径 QUIC 草案 [7] 也允许将滞留数据在其他路径重发。

这些系统各自覆盖了问题的一部分，但存在两点共性：要么是无条件全量复制，带宽开销恒定翻倍；要么依赖 UDP 或内核 MPTCP。前者不适合按流量计费的机场，后者在 UDP 普遍受 QoS 限制、中转节点只转发 TCP 的环境中无法部署。

2.5 对冲请求（ Hedged Request ）

Dean 与 Barroso 在《 The Tail at Scale 》[10] 中提出对冲请求：请求超过其延迟分布的高分位仍未返回时，向另一个副本再发一份，取先返回者。文中报告，在 BigTable 上仅增加约 2% 的请求，即可将 p95 延迟降低约 40%。该思想已广泛用于应用层，例如 gRPC 的 hedging 策略 [11]、分布式存储的 hedged read ；何时触发对冲也已有理论分析 [12]。但应用层对冲要求操作幂等，因此多只用于读请求。

3 设计

3.1 架构

客户端与自建落地机之间，经由每个中转节点各维持一条长连接，所有连接常驻、预先完成握手。在这些连接之上运行一层传输协议：每条应用连接被切分为带序号的数据块，可经任意路径发送，接收端按序重组并去重。应用连接因此与具体路径解耦，任意路径的中断都不会导致应用连接中断。

             ┌─ 机场 A 节点 1 ─┐
             ├─ 机场 A 节点 2 ─┤
本地客户端 ──┼─ 机场 B 节点 1 ─┼──► 落地机 ──┬──► 目标站点
             └─ 机场 B 节点 2 ─┘             └──► 家宽出口 ──► AI 服务（可选）

3.2 对冲重发

对冲是本方案的核心。以一次按键为例：数据块从当前最快的路径 A 发出。A 的历史表现是通常 40 ms 内收到确认，偶尔 60 ms ，极少数情况超过 150 ms 。系统据此为该数据块设定一个贴合 A 自身分布的时限；时限已到而确认未回，说明它很可能落入了尾部，于是立即在次优路径 B 上补发一份，以先到者为准。

只有确实迟到的少数数据块多付出一次发送，而它们本应承受的尾部延迟被 B 的正常延迟取代。与其他手段相比：

手段	触发时机	用户感知	带宽开销
重传	确认失败（超时）之后	先经历一次完整超时	低，但太晚
全量冗余	每个包立即复制	无	恒定 k 倍
对冲	尚未失败，但已晚于该路径的常态	无	仅迟到部分

将对冲从应用层下移到传输层有一个关键优势：副本带有相同序号，接收端去重后只交付一次，因此不要求应用幂等。SSH 这样的字节流也可以安全地对冲。

对冲只是最轻的一级响应。证据越确凿，反应越强：

时限到期：补发单个数据块；
接收端报告缺口（后续数据均已到达，唯独缺这一块）：不等时限，立即补发；
路径判定为卡死（其他路径确认正常推进，唯独它无响应，数个往返时间内即可判定）：将其上全部未确认数据迁移至其他路径；
路径断开：全部未确认数据立即重发。

按键等小包则直接双发，相当于《 The Tail at Scale 》中的 tied request：成本可以忽略，换取最稳定的交互手感。

3.3 晚绑定与慢路径隔离

晚绑定。 数据块在即将写出时才选择路径，系统发送缓冲中只保留极少量待发数据。这是 [3] 中"共享队列"模型的直接实现：没有数据被预先分配给某条路径，路径阻塞时被困的数据量也因此最小。

慢路径隔离。 大流量（如视频）不做对冲，否则开销翻倍。它的问题是另一个：平均分摊时，最慢的路径决定整体完成时间。因此每条路径只分配其可在预期时间内送达的数据量，在途数据不超过约一个带宽时延积；一旦出现排队迹象即减少分配。分配依据是"哪条路径能最早送达"，而非"哪条路径还有余量"，与 MPTCP 调度器研究中的 ECF [13]、BLEST [14] 思路一致。这也印证了 [4] 的论断：引入一条更慢的路径只会劣化体验，调度必须主动规避它。

3.4 线路选择

本方案的效果取决于两个前提：单条线路的质量，以及线路之间故障的独立性。

质量：选用 IEPL 、IPLC 、CNIX 等专线中转，基础延迟低、高峰期稳定。
独立性：同一机场的节点常共享入口，故障高度相关。选用两家机场，入口、中转与出口均不相同，才能真正互为备份。同理，对冲副本应优先发往另一个中转节点：共享瓶颈的两条路径一起卡顿，对冲没有意义。
落地机：一方面，多路径协议需要两端配合，中转节点仅作为通道。更重要的是，机场的出口 IP 由大量用户共享，难免有人滥用（批量注册、爬虫、刷流量等），导致出口 IP 被目标网站标记：频繁弹出验证码、触发风控，甚至被直接拒绝访问。这类劣化与线路质量无关，多路径也无法规避。自建落地机让流量从一个独享、干净且固定的 IP 出去，机场只承担"运输"，不承担"出口"，出口信誉不再受其他用户行为的影响。
AI 工具：ChatGPT 、Claude 等服务对 IP 类型更敏感，机房 IP （包括自建落地机的 IP ）也可能被限制或降级。如需稳定使用，可在落地机之后再接一层家宽（住宅 IP ）出口，仅将 AI 相关流量分流过去，其余流量仍由落地机直接出站。

4 对比

方案	单路径卡顿能否被掩盖	已建连接受故障影响	额外流量	可在纯 TCP 中转上部署
url-test / fallback	否（分钟级探测）	是	无	是
按连接负载均衡	否	是	无	是
历史打分的智能选路	否（仍为连接级）	是	无	是
多 TCP 隧道 + 哈希	否（单流绑定单路径）	是	无	是
MPTCP	部分（受子流队列阻塞）	部分	低	否
Speedify	是	否	冗余模式下 k 倍	否（路径为本地网络接口，不能使用第三方中转）
多路径 QUIC VPN	是	否	低至 k 倍	否（依赖 UDP ）
全量冗余	是	否	k 倍	视实现
本文方案	是	否	低（仅补发迟到数据）	是

本方案在尾延迟上接近全量冗余，在流量开销上接近单路径，且完全运行于 TCP 之上，无需内核支持，可直接利用现有机场节点。

5 新颖性说明

本文的各项机制均有概念来源：对冲请求来自 [10][11][12]，共享队列模型来自 [3]，最早完成时间调度来自 [13][14]，按包调度与冗余换延迟已由 Speedify [15] 等商业产品验证，跨路径重发见于 [7] 与若干多路径 VPN 。本文的贡献不在于单个机制，而在于：此前的低尾延迟多路径系统均假设 UDP 或内核 MPTCP 可用；在"只有 TCP 中转"这一现实约束下，将按路径自身分布触发的对冲、带宽时延积约束下的慢路径隔离与跨中转的副本放置组合起来，是代理场景中尚未被覆盖的空白。

6 部署与成本

项目	月费
主力中转机场	≈ ¥30
备用中转机场	≈ ¥20
香港落地机	≈ ¥20
合计	≈ ¥70（ 2–3 人分摊后每人 ¥25–35 ）
家宽出口（可选，用于 AI 工具）	视地区与线路而定

"机场 + 自建落地"的混合模式与"双机场"本就是社区中常见的做法；本方案所做的，是把用户手动进行的冷备与分流自动化，并下沉到数据块粒度。机场价格近期有上涨趋势，上表仅供参考。

7 局限

不提升峰值带宽：本方案的目标是尾延迟，吞吐上限由落地机出口带宽决定。
少量额外流量：对冲与小包双发会产生一定的重复流量。
运维成本：需要自行部署与维护落地机。
依赖线路独立性：若所有线路共享同一故障点（如同一入口或落地机网络本身受限），副本与原数据会一起受阻，多路径无法提供保护。

8 结论

单条路径的抖动无法消除，但可以被多条独立路径掩盖。现有代理选路停留在连接粒度和分钟级探测，现有低尾延迟多路径系统依赖 UDP 或无条件复制。本文主张将多路径用于压低尾延迟而非叠加带宽：晚绑定避免数据被困，对冲重发以少量流量掩盖瞬时劣化，慢路径隔离防止短板拖累整体。配合优质且相互独立的中转线路，这是一种成本可控、体验接近"永不卡顿"的方案。

参考文献

[1] A. Ford et al. TCP Extensions for Multipath Operation with Multiple Addresses. RFC 8684, 2020.
[2] C. Raiciu, M. Handley, D. Wischik. Coupled Congestion Control for Multipath Transport Protocols. RFC 6356, 2011.
[3] 浙江温州皮鞋湿. Multipath TCP 的缺陷和优化. 知乎.
[4] 浙江温州皮鞋湿. 多路径传输(比如 MPTCP)对性能的意义. 知乎.
[5] 浙江温州皮鞋湿. 多路径可靠传输协议(比如 MPTCP)为什么低效. 知乎.
[6] 浙江温州皮鞋湿. 高速多路径传输之始末. 知乎.
[7] IETF QUIC WG. Multipath Extension for QUIC. draft-ietf-quic-multipath.
[8] V2EX. 讨论：流量负载均衡的现成方案.
[9] V2EX. 讨论：多路 TCP 流聚合.
[10] J. Dean, L. A. Barroso. The Tail at Scale. Communications of the ACM, 56(2), 2013.
[11] gRPC. A6: gRPC Retry Design（含 hedging 策略）. gRPC Proposals.
[12] M. Primorac, K. Argyraki, E. Bugnion. When to Hedge in Interactive Services. NSDI 2021.
[13] Y.-s. Lim et al. ECF: An MPTCP Path Scheduler to Manage Heterogeneous Paths. CoNEXT 2017.
[14] S. Ferlin et al. BLEST: Blocking Estimation-based MPTCP Scheduler for Heterogeneous Networks. IFIP Networking 2016.
[15] Connectify. Speedify: Channel Bonding and Redundant Mode. https://speedify.com

No Comments Yet

多路径延迟对冲