为什么是Queqiao？
许多传输协议会让每个连接自行学习和响应。对于一般的互联网来说，这是一个合理的默认设置，但当许多应用程序流共享同一段复杂的客户端到网关链路时，性能就会受到影响。
Queqiao 的研究路径使问题变得具体化：即使在路径容量拐点以下，我们也测量到大约 42%–45% 的下行数据包丢失，而当总流量超过该拐点时，则会出现集群式丢包。这两种情况需要不同的应对措施。退避并不能消除独立丢包；忽略过载只会使情况更糟。请参阅完整的 路径特征描述。
鹊桥的建立基于以下几个实际观察：
- 共享同一瓶颈的流量应共享同一模型。 发往不同最终目的地的流量可以共享同一条客户端到网关的路径，因此 Queqiao 会在这些流量之间共享交付、丢包、往返时间 (RTT)、传输节奏和延迟预留状态。
- 并非所有丢包都意味着拥塞。 控制器会将测得的丢包阈值与过载瓶颈导致的丢包区分开来，而不是将每个丢失的数据包都视为拥塞。
- 选择合适的恢复方式。 在长往返时间 (RTT) 路径上，前向纠错可以比再次往返更快地恢复数据缺口；随着数据量的增长，重传可能成为更高效的选择。
- 保护交互式流量免受批量传输的影响。 控制和新的交互式工作不应滞后于批量传输，因此，聚合速率控制、优先级和反应式隔离可在管道使用期间保护延迟。
- 上游和下游是不同的。 上游和下游的容量和损耗特性可能差异很大，因此需要分别进行测量和控制。
这些是运行原则，并非普遍适用的性能保证。当客户端和网关是已知且可信的端点，并且它们共享的广域网段是主要瓶颈时，鹊桥方案非常适用。如果真正的瓶颈在其他地方，请在依赖优化结果之前重新进行测量。
工作原理
Queqiao 提供了一个普通的本地 SOCKS5 代理，包括 UDP ASSOCIATE。客户端和提供商网关形成一个经过认证的传输会话。在该会话中，每个数据流都使用相同的逻辑帧结构、字节偏移恢复、确认范围和调度机制。QUIC 流和数据报在可用时使用，对于受限网络则回退到经过认证的 TLS/TCP。
鹊桥的比较
| 系统 | 共享路径模型 | 恢复策略 | 总体中位数 | SSH p99 在大负载下 |
|---|---|---|---|---|
| queqiao | 共享端点对 | 可擦除的 FEC + 重传 | 143.1 Mbit/s | 940毫秒 |
| TUIC v5 | 通常每个连接 | QUIC恢复 | 76.8 Mbit/s | 662毫秒 |
| hy2 | 通常每个连接 | 协议特定的UDP/QUIC恢复 | 90.2 Mbit/s | 526毫秒 |
这些是六轮实际路径测试的代表性结果。它们展示了阙桥共享路径模型的优势所在，而交互式尾部则说明了我们为何不声称该模型能取得全面胜利。结果取决于路径和工作量；请参阅完整的对比和方法论。
应用程序无需选择“短流”、“交互式”或“批量”协议。Queqiao 会观察数据流的行为，并在同一架构内调整策略。HTTPS 保持端到端传输；网关会查看目标地址和流量形状，但 Queqiao 不会检查应用程序内容。