其他人用 hysteria2 的相关帖子:hysteria2 有什么伪装 TCP 的方案么? 现在跑个几十分钟就随机阻断几分钟 UDP
这个现象其实已经存在很长时间了,去年年中开始,我自己的 kcptube 经常见到这种情况,困扰了我好几个月。
我观察到的阻断是这样的:
刚开始的几天、十几天都畅通无阻,但慢慢地,端口临时阻断会越来越多,并且端口阻断并不是一段连续的端口范围,而是分散的不连续端口。
更换成新的端口范围,可以暂时“解决”,然后又重复同样的阻断过程。
后来实在受不了,毕竟一旦跳跃到受阻断的端口等于临时断网。于是趁上个月过年期间,我给自己的 kcptube 加了个小改进:跳跃端口前检查下新端口是否已经阻断,如果是阻断端口就找另一个端口号,找到真正畅通的才跳过去。
有了这个小改进,整个连接就重新畅通了。
不过我也很好奇,这种阻断到底阻隔了多少端口,我猜测范围一定不小。
接着我想起来,我的这个工具有现成的--try
命令行参数用于测试连接通断,只不过每次只测 1 个随机端口。
于是,又做了个新改进,改成测试整个端口范围。
测试结果实在“壮观”,3000 个端口,有一百多个是阻断的,剩下都是通畅的。
而这一百多个阻断端口并不是连续的一片,都是分散的。尽管也有极个别的连续端口,但不多,也就三四个而已。
按理来说,其实 hysteria2 是可以做到跳跃前先检查下通断的,发起个探测连接即可。
(需要有人给 hysteria2 提个 issue 或者 patch)
至少我的 kcptube 就是这样做的。依靠 KCP ,确定性有保障。而 hysteria2 有 QUIC ,理论上来讲其实也是有确定性的。
至于我的另一个工具,UDPHop ,完全就是 raw udp ,我实在想不到有什么好办法能够可靠地做到这种检测。
还好的是,流量很小的情况下不会出现这种阻断。无论多久都还是很顺畅。比如单纯只用来做游戏线路,只用来听电台、Podcast 。
备注:以上情况都特指公网跨大墙,并非指省间、省内、市内的情况。省市内部的连接没那么夸张。
1
AlphaTauriHonda 263 天前 via iPhone
WireGuard 是不是也有同样的问题?
|
2
0o0O0o0O0o 263 天前
@AlphaTauriHonda #1 国内 WireGuard 我用起来一直没有太大问题,但很多人都说会有 QoS ,可能我不够快。翻墙用 WireGuard 的应该不多?
|
3
canyue7897 263 天前 via iPhone
OP 测试下,是就这么多端口阻断?还是过一段时间就会变?如果会变,可能是 QOS ? hysteria2 我用一直断流,cn2 都会断,感觉应该是协议的问题?
|
4
canyue7897 263 天前 via iPhone
现在用 vmess ,除了经常封端口,感觉问题不大。也能跑满宽带。
|
5
vcn8yjOogEL 263 天前
@AlphaTauriHonda #1 WireGuard 没有那么激进, 默认连域名都只会解析一次, 应该不会触发这种程度的干扰
|
6
cnbatch OP @AlphaTauriHonda 我还没试过长时间 WireGuard 跨大墙裸连,不清楚会不会遭到阻断
因为运营商主动 QoS 、出口节点给家宽丢包弄得我心累,只好放弃 WG 裸连 |
7
cnbatch OP @canyue7897 在半个小时内测了差不多 10 次,测试结果实在很诡异,有时端口全通,有时仅有个位数端口阻断,有时几十个、几百个,最多的一次竟然有一千多个!
我的测试程序设定了 30 秒无响应就判断为阻断。如果仅仅是 QoS 的话,端口变化应该不至于这么大的,最起码数据能够流通,顶多速率高了上去时就遇到运营商的 QoS 丢包。 像这样的阻断实在很奇怪,端口不定、时间不定,我都判断不出这种到底属于运营商的强力 QoS 还是某设备给运营商发出的干扰指令 |
8
tril 263 天前
@AlphaTauriHonda wg 跨境也会被临时阻断端口,哪怕只是打游戏的小流量。不过只开了一个端口,所以并不清楚有没有其他不连续的端口被阻断。
|
9
canyue7897 263 天前 via Android
@cnbatch 这就是 qos 随机阻断。在阻断的时间段内,应该是任何端口都不通。这个时间段根据你的流量,连接 ip 地址而变化。
|
10
canyue7897 263 天前 via Android
这玩意儿就是黑盒,没有人只知道确切的方式
|
11
diangongnan 263 天前 via iPhone
大佬,上面那个帖子我发的,我遇到的问题是,一段时间他会阻断我本地宽带的 udp 入站,我在韩国 美国 日本 德国搭建了四个 hy2 ,例如我用韩国的 hy2 看 4k 视频,跑一段时间被阻断的时候,美国 日本 德国的 hy2 也是不通的,我重启本地的 clash ,试图重连也无效,我看了下 hy2 的日志,断开的时候,服务端能收到客户端请求,但是我本地应该是收不到服务端响应了。
|
12
cnbatch OP @canyue7897 还好暂时没遇到过所有端口阻断(除非是开着 BT ,连接太多触发反向墙),这个 QoS 有时实在很怪,比如我 2 分钟内连续 3 次测试,见到的端口阻断数会越来越多(但未必重叠),过 5 分钟再测,又全通了
而这段期间,同 IP 地址其他端口的 UDP 服务没受到影响,并且其它 IP 地址依旧保持畅通 然而如果 个人猜测,可能一段时间内少量 UDP 端口大流量就会先触发普通的 QoS ,如果是一段范围的 UDP 流量过多可能就触发范围级 QoS ,要是 UDP 流量大且端口过多就触发反向墙(就像开着 BT 那样) 不过这背后的实现确实是个黑盒,我猜也未必猜得对 |
13
cnbatch OP @diangongnan 4K 视频 + 10 秒换端口,在运营商那边来看的话,很可能就是短时间内大流量+出现大量连接,触发的不仅仅是 QoS ,而是反向墙。
BT 下载就很容易触发反向墙,特点正好是大量连接+大量流量。 反向墙的特点就是凡是境外地址的连接全都阻断,国内连接没影响。 可能流量大的情况下过于频繁跳跃端口,会遭遇像 BT 下载那样的反向墙 |
14
canyue7897 262 天前 via Android
其实我还更怀疑 hysteria2 这个协议有问题。用过 cn2 ,9929 这样的优质线路,流量不大的情况下,一样会断流。没有开端口跳跃,但是游戏和会议这种 udp 应用都没任何问题,最终无奈放弃,还是使用 xray ,这种便秘似的断流最影响体验。
|
16
YGBlvcAK 262 天前 via Android
天津移动云主机会阻断 hy2 ,每个省的墙的策略都不一样,北京移动家宽就不会
|
19
wangyucn 262 天前
这个功能跟心跳检测的区别是什么?
>在半个小时内测了差不多 10 次,测试结果实在很诡异,有时端口全通,有时仅有个位数端口阻断,有时几十个、几百个,最多的一次竟然有一千多个! 感觉你说的现象,像是中间负责 UDP NAT 的设备 allocate 新端口处理不过来,或者是负责审查的设备跟不上新 udp session 建立。不像是故意这么搞你。 |
20
cnbatch OP @wangyucn 本质上没什么区别,如果说有区别,那就是心跳检测提前做
普通的心跳检测:只负责当前链路。 跳跃前事先检查:利用心跳检测提前测试下一个链路(端口)。 换个说法就是,跳跃前来一个 handshake ,成功了再转移。 至于“中间负责 UDP NAT 的设备 allocate 新端口处理不过来”,在我的家宽应该不是这样,我家软路由已经获取到双栈公网 IP ,发起测试的机器就是软路由本身,不需要 NAT 。而且,无论 IPv4 还是 IPv6 都有同样的现象。 中间某设备或许跟不上,也有可能是“反向墙”的轻微版,因为最重要的一点是,国内连接完全不受影响。 这个黑盒子实在猜不透,以往不少人的研究认为,中间那堆设备是旁路机器,但能够实施 UDP 阻断(或时间段丢包)的只能是直连设备。再结合其他人对于 UDP 的 QoS 帖子,实在搞不清楚到底是运营商主动而为还是某设备给直连设施发指令 |
21
basncy 261 天前
难道 OP 就认为跨国 udp 不会丢包?hysteria2 就一定发送了冗余包?
hy2 共享一条底层 udp 链路, 一丢包, quic session 也许只有等超时. kcp 是每条 tcp session 独享一条 udp 连接, 所以即使某条 udp 连接超时或发生重传, 整体感知也不大. |
22
cnbatch OP @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 连接,我并未限定必须一对一。 |
23
basncy 261 天前
@cnbatch 虽然, 也许,大概, 但只看结果,它用 iptables 给 udp 双倍发包后, 确实管用, 很多 udp app 就不容易抽筋了.
kcp 和 udp 连接, 是用 iftop 肉眼看出来的, 每开一个视频, 就新建了一条 udp 连接(不排除多对一),speedtest 多线程也一样. |
24
cnbatch OP @basncy
双倍发包有效,那就可以庆幸当地运营商做的并不是很长时间的阻断,而是几秒钟的阻断,或者几秒内的超高丢包。双倍发包在这种情况下才能够起效,使得重传机制能够回到可接受的等待时间。 至于 KCPTube ,像这种立马就新建连接的情况,应该就是没配置 mux_tunnel 参数的缘故。使用了 mux_tunnel 后就会自动建立多条 UDP 连接,共享使用,这样就不会再观察到每接受一个连接就自动建立一个新连接。好处是,可以降低延迟;坏处就是一条路受阻,同路承载的各个 session 就会感知到受阻(这就是去年困扰我情况) 顺便多说一个有关 KCP 的“冗余”发包。 所有的可靠 UDP 拥有重传机制,KCP 也不例外。KCP 特别之处在于,它会在规定时间内收不到确认号的情况下就直接发送重传包,而这个规定时间非常短,短到只有“去程+回程”的总时间,若收不到,那就在(去程+回程)×1.5 的时间后重新来一次。而网络抖动总会造成去程、回程的时间有所浮动,于是就造成第一个重传包经常“过早”就发了出去,第二个重传包也很容易就发了出去。但 KCP 并不会主动地在去程+回程总时间未到的情况下就事先发包 这就是大家说的“冗余包耗费额外流量”的来由,奇怪的是各个 KCP 代码使用者其实是可以观察到这一点的,但没人讲出来,依然还在笼统地用着“浪费 10%-20%”这种模糊的说法,以及“狂发冗余包”这样的印象。其实极端起来 KCP 是可以浪费 25%-40%的(大多数转发工具制作者不至于用到这么极端的配置参数),也可以把浪费降低到 10%以内(抗丢包能力相对没那么好) |
25
basncy 261 天前 via Android
quic decouple 了҄应用层 session 与传输层 session, ip:port 就可҄以҄随意套娃找替҃补҃了҄, 铁打的包裹流水的快递员.
|
26
halen1021 168 天前
op 现在有解决方案吗?或者用的是什么?
|
27
halen1021 168 天前
我最近换了一个好点的线路,反而感觉体验更差了
|