面向低尾延迟的多中转路径传输：一种不追求带宽聚合的多路径方案 免责声明 ：本文内容完全由 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 ─┘ └─

  • 情报分类：服务器与云资源
  • 分类依据：内容涉及服务器、云资源或网络线路
  • 信息来源：服务器 / V2EX
  • 发布时间：2026/10/4 09:36:50