随着近年来晚高峰互联网需求日渐膨胀，传统线路愈发拥挤/丢包，长程链路的性能出现了严重的两极分化：
高端线路：很贵 / 低带宽 / 延迟低 / 稳定
普通线路：平价 / 高带宽（理想情况）/ 延迟高 / 不稳定
尽管可以进行分流，但很覆盖容易不全、不够精细，长期维护成本不低。
因此设计并实验了一个PoC：singbox-multipath，选择了基于某个协议支持全面的开源L4正向代理程序而开发，增加了multipath逻辑节点，实现了类似mptcp的单tcp流聚合能力。但和mptcp的直接聚合不同，设计了如下的择优策略：每个新连接默认都会使用高端线路（leg0），此时其延迟表现与单独使用高端线路一致，而当这个流的下载量或者速率超过一定阈值，那就会无缝聚合进来普通线路（leg1），这种聚合能提高tcp单线程速度，同时由于普通线路一般口子更大，还会让普通线路承担多数流量。
同时，还设计了leg0流量节省选项，如果启用，则原本聚合时的行为变为切换，条件触发后仅使用leg1，leg0仅用于条件触发前的小流量行为，可进一步节省leg0的流量。
通过singbox-multipath无缝聚合，可以使链路延迟体验依旧保持高端线路的水平，但大文件下载能自动达到大带宽普通线路的速度，同时让普通线路承担更多流量。自动识别，无需任何手工分流
如上图所示，在一次speedtest单线程测速中，小口子的专线承担了20MB/s的速度，而大口子的直连线路承担了60MB/s的速度，其被聚合成了80MB/s的单tcp流。
这种方案需要在客户端和服务端都使用singbox-multipath，同时服务端需要作为最终唯一出站，以得到统一的出口。因此合理的拓扑为：统一由普通线路机侧出口，leg0为经过高端线路机L3/L4转发连接普通线路机上的节点，leg1为直连普通线路机上的节点，此时leg0和leg1实际的底层流量协议都是普通线路机上的同一个节点，只是leg0经过高端线路机的端口转发，路径更优，具体来说，此时：
- leg0：客户端 -> multipath逻辑节点 -> 下层节点（转发地址） —–高端线路—–> 高端VPS端口转发 –> 普通VPS下层节点服务端 -> multipath逻辑节点 -> 服务端
- leg1：multipath逻辑节点 -> 下层节点（直连地址） —–普通线路—–> 普通VPS下层节点服务端 -> multipath逻辑节点
使用同一个目标节点不是必须的，只要multipath逻辑节点能通过各leg最终连接到服务端的multipath逻辑节点的mp监听端口即可，例如可通过direct+wg0出口作为leg0，但要注意multipath节点本身无鉴权和二次加密，mp端口不应当暴露在公网，否则有被滥用风险。
请注意，本项目目前仅为网络实验PoC工作，仅作为思路分享和交流学习，无技术支持
PoC开源，共两部分：
- singbox-multipath本体：https://github.com/WuSiYu/singbox-multipath
可直接使用，配置文档见README - luci-app-homeproxy-multipath：https://github.com/WuSiYu/luci-app-homeproxy-multipath
可选的UI，用于软路由，homeproxy的改版，适配了sing-box 1.14.x和singbox-multipath，同时加入了直观的multipath状态页面
limitations：
使用场景高度针对“优质线路”+“高带宽一般线路”的组合，但如果你的普通线路本身跑不到大带宽，那就不会有聚合加速等效果，甚至会使性能降级
发表回复