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

[cnbatch]

其他人用 hysteria2 的相关帖子：hysteria2 有什么伪装 TCP 的方案么？ 现在跑个几十分钟就随机阻断几分钟 UDP

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

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

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

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

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

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

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

---

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

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

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

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

---

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

[AlphaTauriHonda]

WireGuard 是不是也有同样的问题？

[0o0O0o0O0o]

@AlphaTauriHonda #1 国内 WireGuard 我用起来一直没有太大问题，但很多人都说会有 QoS ，可能我不够快。翻墙用 WireGuard 的应该不多？

[canyue7897]

OP 测试下，是就这么多端口阻断？还是过一段时间就会变？如果会变，可能是 QOS ？ hysteria2 我用一直断流，cn2 都会断，感觉应该是协议的问题？

[canyue7897]

现在用 vmess ，除了经常封端口，感觉问题不大。也能跑满宽带。

[vcn8yjOogEL]

@AlphaTauriHonda #1 WireGuard 没有那么激进, 默认连域名都只会解析一次, 应该不会触发这种程度的干扰

[cnbatch]

@AlphaTauriHonda 我还没试过长时间 WireGuard 跨大墙裸连，不清楚会不会遭到阻断
因为运营商主动 QoS 、出口节点给家宽丢包弄得我心累，只好放弃 WG 裸连

[cnbatch]

@canyue7897 在半个小时内测了差不多 10 次，测试结果实在很诡异，有时端口全通，有时仅有个位数端口阻断，有时几十个、几百个，最多的一次竟然有一千多个！
我的测试程序设定了 30 秒无响应就判断为阻断。如果仅仅是 QoS 的话，端口变化应该不至于这么大的，最起码数据能够流通，顶多速率高了上去时就遇到运营商的 QoS 丢包。
像这样的阻断实在很奇怪，端口不定、时间不定，我都判断不出这种到底属于运营商的强力 QoS 还是某设备给运营商发出的干扰指令

[tril]

@AlphaTauriHonda wg 跨境也会被临时阻断端口，哪怕只是打游戏的小流量。不过只开了一个端口，所以并不清楚有没有其他不连续的端口被阻断。

[canyue7897]

@cnbatch 这就是 qos 随机阻断。在阻断的时间段内，应该是任何端口都不通。这个时间段根据你的流量，连接 ip 地址而变化。

[canyue7897]

这玩意儿就是黑盒，没有人只知道确切的方式

[diangongnan]

大佬，上面那个帖子我发的，我遇到的问题是，一段时间他会阻断我本地宽带的 udp 入站，我在韩国 美国 日本 德国搭建了四个 hy2 ，例如我用韩国的 hy2 看 4k 视频，跑一段时间被阻断的时候，美国 日本 德国的 hy2 也是不通的，我重启本地的 clash ，试图重连也无效，我看了下 hy2 的日志，断开的时候，服务端能收到客户端请求，但是我本地应该是收不到服务端响应了。

[cnbatch]

@canyue7897 还好暂时没遇到过所有端口阻断（除非是开着 BT ，连接太多触发反向墙），这个 QoS 有时实在很怪，比如我 2 分钟内连续 3 次测试，见到的端口阻断数会越来越多（但未必重叠），过 5 分钟再测，又全通了

而这段期间，同 IP 地址其他端口的 UDP 服务没受到影响，并且其它 IP 地址依旧保持畅通

然而如果

个人猜测，可能一段时间内少量 UDP 端口大流量就会先触发普通的 QoS ，如果是一段范围的 UDP 流量过多可能就触发范围级 QoS ，要是 UDP 流量大且端口过多就触发反向墙（就像开着 BT 那样）

不过这背后的实现确实是个黑盒，我猜也未必猜得对

[cnbatch]

@diangongnan 4K 视频 + 10 秒换端口，在运营商那边来看的话，很可能就是短时间内大流量+出现大量连接，触发的不仅仅是 QoS ，而是反向墙。
BT 下载就很容易触发反向墙，特点正好是大量连接+大量流量。

反向墙的特点就是凡是境外地址的连接全都阻断，国内连接没影响。

可能流量大的情况下过于频繁跳跃端口，会遭遇像 BT 下载那样的反向墙

[canyue7897]

其实我还更怀疑 hysteria2 这个协议有问题。用过 cn2 ，9929 这样的优质线路，流量不大的情况下，一样会断流。没有开端口跳跃，但是游戏和会议这种 udp 应用都没任何问题，最终无奈放弃，还是使用 xray ，这种便秘似的断流最影响体验。

[hello2023]

@cnbatch 大佬 gh 上 kcptube 20240316 版本的 windows x64 包运行显示还是 20240310 的，有空看一看吗

[YGBlvcAK]

天津移动云主机会阻断 hy2 ，每个省的墙的策略都不一样，北京移动家宽就不会

[cnbatch]

@hello2023 真是抱歉，上传错版本了，现在已经把正确的文件传到了 Github

[hello2023]

@cnbatch 可以了 感谢~~

[wangyucn]

这个功能跟心跳检测的区别是什么？

>在半个小时内测了差不多 10 次，测试结果实在很诡异，有时端口全通，有时仅有个位数端口阻断，有时几十个、几百个，最多的一次竟然有一千多个！

感觉你说的现象，像是中间负责 UDP NAT 的设备 allocate 新端口处理不过来，或者是负责审查的设备跟不上新 udp session 建立。不像是故意这么搞你。

[cnbatch]

@wangyucn 本质上没什么区别，如果说有区别，那就是心跳检测提前做
普通的心跳检测：只负责当前链路。
跳跃前事先检查：利用心跳检测提前测试下一个链路（端口）。
换个说法就是，跳跃前来一个 handshake ，成功了再转移。

至于“中间负责 UDP NAT 的设备 allocate 新端口处理不过来”，在我的家宽应该不是这样，我家软路由已经获取到双栈公网 IP ，发起测试的机器就是软路由本身，不需要 NAT 。而且，无论 IPv4 还是 IPv6 都有同样的现象。

中间某设备或许跟不上，也有可能是“反向墙”的轻微版，因为最重要的一点是，国内连接完全不受影响。

这个黑盒子实在猜不透，以往不少人的研究认为，中间那堆设备是旁路机器，但能够实施 UDP 阻断（或时间段丢包）的只能是直连设备。再结合其他人对于 UDP 的 QoS 帖子，实在搞不清楚到底是运营商主动而为还是某设备给直连设施发指令

[basncy]

难道 OP 就认为跨国 udp 不会丢包?hysteria2 就一定发送了冗余包?
hy2 共享一条底层 udp 链路, 一丢包, quic session 也许只有等超时.
kcp 是每条 tcp session 独享一条 udp 连接, 所以即使某条 udp 连接超时或发生重传, 整体感知也不大.

[cnbatch]

@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 连接，我并未限定必须一对一。

[basncy]

@cnbatch 虽然, 也许,大概, 但只看结果,它用 iptables 给 udp 双倍发包后, 确实管用, 很多 udp app 就不容易抽筋了.
kcp 和 udp 连接, 是用 iftop 肉眼看出来的, 每开一个视频, 就新建了一条 udp 连接(不排除多对一),speedtest 多线程也一样.

[cnbatch]

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

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


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

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

[basncy]

quic decouple 了҄应用层 session 与传输层 session, ip:port 就可҄以҄随意套娃找替҃补҃了҄, 铁打的包裹流水的快递员.

[halen1021]

op 现在有解决方案吗？或者用的是什么？

[halen1021]

我最近换了一个好点的线路，反而感觉体验更差了