聚合多路 TCP 流（延迟不同），有比 kcptun 更适合的方案吗？

[PhaSelEza]

在做个项目，要求聚合多路 TCP 流，实现极高可靠性的数据流传输。

目前实现了 tcp over kcptun over udp(s) over tcp(s)，即将 kcptun 的每个数据包通过随机 TCP 流发送，若丢包则用 kcp 的机制自动重传。

以上方法保障了可靠性，长期测试通过。然而，带宽限制在了 10Mbps 左右，甚至低于单路 TCP 流的带宽，推测是由于各路 TCP 流的延迟不同造成的(50ms 至 300ms)。

我不是科班出身，检索了相关文献也没找到相关算法/实现。请教下各位，在延迟随机场景下，有什么更适合的实现吗？

[tool2dx]

你把 kcp 底层从 udp 改成了 tcp ，那么自然会受到掉包 rtt 的影响。
我看有方法提到，可以在 linux 上把 tcp window size 窗口完全关闭，可以改善响应速度。
用默认 udp 不是挺好的。tcp 多流复用还挺复杂，至少要抓包，才能知道卡顿的具体原因。

[mhycy]

首先去看看 mptcp ，这是 mptcp 在做的事情，但不够灵活

一般来说直接利用 tcp 进行聚合在你没法对数据包本身进行监控且依赖底层的拥塞控制的时候通常会有十分差的结果
而且对于延迟差距巨大的链路，如果不补偿数据包顺序的话结果就是乱序到达
大多数拥塞控制算法对此都只能理解为丢包这一结论，然后就是重传……
如果可以接受数据延迟，但在意可靠性的话，可以使用一个巨大的缓冲区抹平链路间的延迟差异
这也是 sd-wan 领域会用到的抖动控制方法（具体看 vmware sd-wan 相关的技术介绍）
但不管如何都需要在数据包等级对于每一个数据包都有精确的控制，插入各种附加的头以进行排序，计时，FEC 等操作

[shoaly]

是不是在把多个 4g 随身 wifu 聚合成一个 千兆网络开直播?

[geekvcn]

想不通你这套的应用场景，疯狂套娃的意义呢？

[Immunize]

多路径一个是要解决每条路径的带宽预测，另一个就是要解决可能出现由于时延差距导致的队头阻塞问题。解决队头阻塞的相关算法有 BLEST 、ECF 等等。