search

cnbatch / kcptube

同时支持传送TCP与UDP的KCP通道，附带端口跳跃的功能，以及FEC，自带中继服务器支持
BSD 3-Clause "New" or "Revised" License
95 stars 10 forks source link

KCPTube对UDP流量的转发是可靠传输还是非可靠传输？ #18

Closed reF1nd closed 4 months ago

reF1nd commented 4 months ago

如题，KCP对TCP是可靠传输，通常KCP也不支持转发UDP，所以好奇KCPTube对UDP是可靠转发还是非可靠转发。

cnbatch commented 4 months ago

KCP只是个ARQ，一套传输用的算法，它并不关心承载在它上面的数据是什么协议。 实际上，只要使用KCP的人愿意，也可以用KCP来转发SCTP。传输私有协议都可以。用KCP来转发UDP更加可以。

确实有不少人拿KCP制作转发工具时只用来转发TCP数据。我觉得这种做法不是很好，于是就有了KCPTube。

KCPTube是真的会把收到的UDP数据交给KCP做收发处理，只要UDP流量不要太大就行。在带宽允许的范围内，可以做到可靠转发。

“UDP流量不要太大”，除了指带宽允许，还包括突然爆发的流量。毕竟UDP本身不是可靠协议，操作系统是真的会在流量过大时丢掉UDP包的，这种情况下KCPTube也无能为力，能够做的也就只有内置缓存队列缓解下局面。如果流量大到缓存爆满、操作系统丢包，那KCPTube就没办法可靠转发全部UDP数据了。

reF1nd commented 4 months ago

如果我想转发QUIC流量，由于QUIC本来就带流控，KCP也有流控，这样是不是不太好。 看来UDP Hop工具更适合这种情景？

cnbatch commented 4 months ago

QUIC↔KCP↔QUIC 这样？

如果这里的QUIC是指类似于KCPTube或KCPTun，又或者类似于Hysteria这样的工具，那么套上UDPHop确实会更好，可以发挥QUIC的优势。 如果是指HTTP/3应用，比如网页浏览器看视频，那反而无所谓，不会糟糕到哪里去。

reF1nd commented 4 months ago

明白了 多谢解答 另外UDP Hop在端口跳跃的时候对上层应用是无感的吗？会不会出现在跳跃时连接断开/丢包等

cnbatch commented 4 months ago

对于上层是无感的，端口跳跃时不会导致连接断掉。

除非遇到了端口封禁。比如指定了使用61000—61999这段范围，假设61500端口受到莫名阻断，如果跳跃时恰好跳到了这个端口，那么上层应用就会感知到连接受阻。

KCPTube对于这种阻断倒是有办法规避，跳跃前先检测下是否通畅即可（这个做法我正在测试，暂未推送出来）。 UDPHop我还没想到可靠的做法，毕竟UDP自身不负责丢包重传，而检测包在传送过程中有丢包的可能（不同于KCPTube可以依靠KCP解决丢包问题）。

把端口范围设置得宽一点应该可以降低端口封禁的几率。

reF1nd commented 4 months ago

明白了 再次感谢