UDP 端口跳跃，不连续的端口阻断

这个现象其实已经存在很长时间了，去年年中开始，我自己的 kcptube 经常见到这种情况，困扰了我好几个月。

我观察到的阻断是这样的：
刚开始的几天、十几天都畅通无阻，但慢慢地，端口临时阻断会越来越多，并且端口阻断并不是一段连续的端口范围，而是分散的不连续端口。
更换成新的端口范围，可以暂时“解决”，然后又重复同样的阻断过程。

后来实在受不了，毕竟一旦跳跃到受阻断的端口等于临时断网。于是趁上个月过年期间，我给自己的 kcptube 加了个小改进：跳跃端口前检查下新端口是否已经阻断，如果是阻断端口就找另一个端口号，找到真正畅通的才跳过去。

有了这个小改进，整个连接就重新畅通了。

不过我也很好奇，这种阻断到底阻隔了多少端口，我猜测范围一定不小。

接着我想起来，我的这个工具有现成的--try命令行参数用于测试连接通断，只不过每次只测 1 个随机端口。
于是，又做了个新改进，改成测试整个端口范围。

测试结果实在“壮观”，3000 个端口，有一百多个是阻断的，剩下都是通畅的。
而这一百多个阻断端口并不是连续的一片，都是分散的。尽管也有极个别的连续端口，但不多，也就三四个而已。

按理来说，其实 hysteria2 是可以做到跳跃前先检查下通断的，发起个探测连接即可。
（需要有人给 hysteria2 提个 issue 或者 patch）

至少我的 kcptube 就是这样做的。依靠 KCP ，确定性有保障。而 hysteria2 有 QUIC ，理论上来讲其实也是有确定性的。

至于我的另一个工具，UDPHop ，完全就是 raw udp ，我实在想不到有什么好办法能够可靠地做到这种检测。

还好的是，流量很小的情况下不会出现这种阻断。无论多久都还是很顺畅。比如单纯只用来做游戏线路，只用来听电台、Podcast 。

备注：以上情况都特指公网跨大墙，并非指省间、省内、市内的情况。省市内部的连接没那么夸张。

cnbatch

77 天前

@basncy
请先搞清楚这两件事：丢包、阻断
这两个的程度区别很大的

UDP 出现丢包很正常，所以才会有那么多协议和算法给 UDP 做可靠传输，也因此你认为我”认为跨国 udp 不会丢包“完全不成立。如果我认为跨国 UDP 不会丢包，直接用 raw UDP 就行了，根本不可能使用、制作兜底工具。

阻断（某段时间内 100%丢包）就严重得多，连都连不上。

这不是发不发冗余包的问题，而是重传机制也无能为力的问题。划重点，重传机制，发生丢包了就必须重传，阻断的情况下无论怎么重传都没用。能够做的要么继续等，要么跳跃前事先探测，免得选中受阻端口。

然后是谁跟你说的“kcp 是每条 tcp session 独享一条 udp 连接”？
须知道，是否每条 TCP session 独享一条 UDP 连接，那是 kcp 代码使用者说了算。KCP 代码本身并没有限死必须一条 TCP 对应一条 UDP 。
在本例当中，我是多条 TCP session 共享个位数的 UDP 连接，并不是一对一独享。
KCPTube 既可以每条 TCP session 独享一条 UDP 连接，也可以多条 TCP session 共享同一条 UDP 连接，我并未限定必须一对一。

cnbatch

76 天前

@basncy
双倍发包有效，那就可以庆幸当地运营商做的并不是很长时间的阻断，而是几秒钟的阻断，或者几秒内的超高丢包。双倍发包在这种情况下才能够起效，使得重传机制能够回到可接受的等待时间。

至于 KCPTube ，像这种立马就新建连接的情况，应该就是没配置 mux_tunnel 参数的缘故。使用了 mux_tunnel 后就会自动建立多条 UDP 连接，共享使用，这样就不会再观察到每接受一个连接就自动建立一个新连接。好处是，可以降低延迟；坏处就是一条路受阻，同路承载的各个 session 就会感知到受阻（这就是去年困扰我情况）

顺便多说一个有关 KCP 的“冗余”发包。
所有的可靠 UDP 拥有重传机制，KCP 也不例外。KCP 特别之处在于，它会在规定时间内收不到确认号的情况下就直接发送重传包，而这个规定时间非常短，短到只有“去程+回程”的总时间，若收不到，那就在（去程+回程）×1.5 的时间后重新来一次。而网络抖动总会造成去程、回程的时间有所浮动，于是就造成第一个重传包经常“过早”就发了出去，第二个重传包也很容易就发了出去。但 KCP 并不会主动地在去程+回程总时间未到的情况下就事先发包

这就是大家说的“冗余包耗费额外流量”的来由，奇怪的是各个 KCP 代码使用者其实是可以观察到这一点的，但没人讲出来，依然还在笼统地用着“浪费 10%-20%”这种模糊的说法，以及“狂发冗余包”这样的印象。其实极端起来 KCP 是可以浪费 25%-40%的（大多数转发工具制作者不至于用到这么极端的配置参数），也可以把浪费降低到 10%以内（抗丢包能力相对没那么好）