V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
cnbatch
V2EX  ›  宽带症候群

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

  •  
  •   cnbatch · 249 天前 · 4538 次点击
    这是一个创建于 249 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

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

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

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

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


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

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

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

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


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

    27 条回复    2024-06-19 20:07:12 +08:00
    AlphaTauriHonda
        1
    AlphaTauriHonda  
       249 天前 via iPhone
    WireGuard 是不是也有同样的问题?
    0o0O0o0O0o
        2
    0o0O0o0O0o  
       249 天前
    @AlphaTauriHonda #1 国内 WireGuard 我用起来一直没有太大问题,但很多人都说会有 QoS ,可能我不够快。翻墙用 WireGuard 的应该不多?
    canyue7897
        3
    canyue7897  
       249 天前 via iPhone
    OP 测试下,是就这么多端口阻断?还是过一段时间就会变?如果会变,可能是 QOS ? hysteria2 我用一直断流,cn2 都会断,感觉应该是协议的问题?
    canyue7897
        4
    canyue7897  
       249 天前 via iPhone
    现在用 vmess ,除了经常封端口,感觉问题不大。也能跑满宽带。
    vcn8yjOogEL
        5
    vcn8yjOogEL  
       249 天前
    @AlphaTauriHonda #1 WireGuard 没有那么激进, 默认连域名都只会解析一次, 应该不会触发这种程度的干扰
    cnbatch
        6
    cnbatch  
    OP
       249 天前
    @AlphaTauriHonda 我还没试过长时间 WireGuard 跨大墙裸连,不清楚会不会遭到阻断
    因为运营商主动 QoS 、出口节点给家宽丢包弄得我心累,只好放弃 WG 裸连
    cnbatch
        7
    cnbatch  
    OP
       249 天前
    @canyue7897 在半个小时内测了差不多 10 次,测试结果实在很诡异,有时端口全通,有时仅有个位数端口阻断,有时几十个、几百个,最多的一次竟然有一千多个!
    我的测试程序设定了 30 秒无响应就判断为阻断。如果仅仅是 QoS 的话,端口变化应该不至于这么大的,最起码数据能够流通,顶多速率高了上去时就遇到运营商的 QoS 丢包。
    像这样的阻断实在很奇怪,端口不定、时间不定,我都判断不出这种到底属于运营商的强力 QoS 还是某设备给运营商发出的干扰指令
    tril
        8
    tril  
       249 天前
    @AlphaTauriHonda wg 跨境也会被临时阻断端口,哪怕只是打游戏的小流量。不过只开了一个端口,所以并不清楚有没有其他不连续的端口被阻断。
    canyue7897
        9
    canyue7897  
       249 天前 via Android
    @cnbatch 这就是 qos 随机阻断。在阻断的时间段内,应该是任何端口都不通。这个时间段根据你的流量,连接 ip 地址而变化。
    canyue7897
        10
    canyue7897  
       249 天前 via Android
    这玩意儿就是黑盒,没有人只知道确切的方式
    diangongnan
        11
    diangongnan  
       249 天前 via iPhone
    大佬,上面那个帖子我发的,我遇到的问题是,一段时间他会阻断我本地宽带的 udp 入站,我在韩国 美国 日本 德国搭建了四个 hy2 ,例如我用韩国的 hy2 看 4k 视频,跑一段时间被阻断的时候,美国 日本 德国的 hy2 也是不通的,我重启本地的 clash ,试图重连也无效,我看了下 hy2 的日志,断开的时候,服务端能收到客户端请求,但是我本地应该是收不到服务端响应了。
    cnbatch
        12
    cnbatch  
    OP
       249 天前
    @canyue7897 还好暂时没遇到过所有端口阻断(除非是开着 BT ,连接太多触发反向墙),这个 QoS 有时实在很怪,比如我 2 分钟内连续 3 次测试,见到的端口阻断数会越来越多(但未必重叠),过 5 分钟再测,又全通了

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

    然而如果

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

    不过这背后的实现确实是个黑盒,我猜也未必猜得对
    cnbatch
        13
    cnbatch  
    OP
       249 天前
    @diangongnan 4K 视频 + 10 秒换端口,在运营商那边来看的话,很可能就是短时间内大流量+出现大量连接,触发的不仅仅是 QoS ,而是反向墙。
    BT 下载就很容易触发反向墙,特点正好是大量连接+大量流量。

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

    可能流量大的情况下过于频繁跳跃端口,会遭遇像 BT 下载那样的反向墙
    canyue7897
        14
    canyue7897  
       249 天前 via Android
    其实我还更怀疑 hysteria2 这个协议有问题。用过 cn2 ,9929 这样的优质线路,流量不大的情况下,一样会断流。没有开端口跳跃,但是游戏和会议这种 udp 应用都没任何问题,最终无奈放弃,还是使用 xray ,这种便秘似的断流最影响体验。
    hello2023
        15
    hello2023  
       248 天前   ❤️ 1
    @cnbatch 大佬 gh 上 kcptube 20240316 版本的 windows x64 包运行显示还是 20240310 的,有空看一看吗
    YGBlvcAK
        16
    YGBlvcAK  
       248 天前 via Android
    天津移动云主机会阻断 hy2 ,每个省的墙的策略都不一样,北京移动家宽就不会
    cnbatch
        17
    cnbatch  
    OP
       248 天前
    @hello2023 真是抱歉,上传错版本了,现在已经把正确的文件传到了 Github
    hello2023
        18
    hello2023  
       248 天前
    @cnbatch 可以了 感谢~~
    wangyucn
        19
    wangyucn  
       248 天前
    这个功能跟心跳检测的区别是什么?

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

    感觉你说的现象,像是中间负责 UDP NAT 的设备 allocate 新端口处理不过来,或者是负责审查的设备跟不上新 udp session 建立。不像是故意这么搞你。
    cnbatch
        20
    cnbatch  
    OP
       248 天前
    @wangyucn 本质上没什么区别,如果说有区别,那就是心跳检测提前做
    普通的心跳检测:只负责当前链路。
    跳跃前事先检查:利用心跳检测提前测试下一个链路(端口)。
    换个说法就是,跳跃前来一个 handshake ,成功了再转移。

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

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

    这个黑盒子实在猜不透,以往不少人的研究认为,中间那堆设备是旁路机器,但能够实施 UDP 阻断(或时间段丢包)的只能是直连设备。再结合其他人对于 UDP 的 QoS 帖子,实在搞不清楚到底是运营商主动而为还是某设备给直连设施发指令
    basncy
        21
    basncy  
       247 天前
    难道 OP 就认为跨国 udp 不会丢包?hysteria2 就一定发送了冗余包?
    hy2 共享一条底层 udp 链路, 一丢包, quic session 也许只有等超时.
    kcp 是每条 tcp session 独享一条 udp 连接, 所以即使某条 udp 连接超时或发生重传, 整体感知也不大.
    cnbatch
        22
    cnbatch  
    OP
       247 天前
    @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
        23
    basncy  
       247 天前
    @cnbatch 虽然, 也许,大概, 但只看结果,它用 iptables 给 udp 双倍发包后, 确实管用, 很多 udp app 就不容易抽筋了.
    kcp 和 udp 连接, 是用 iftop 肉眼看出来的, 每开一个视频, 就新建了一条 udp 连接(不排除多对一),speedtest 多线程也一样.
    cnbatch
        24
    cnbatch  
    OP
       247 天前
    @basncy
    双倍发包有效,那就可以庆幸当地运营商做的并不是很长时间的阻断,而是几秒钟的阻断,或者几秒内的超高丢包。双倍发包在这种情况下才能够起效,使得重传机制能够回到可接受的等待时间。

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


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

    这就是大家说的“冗余包耗费额外流量”的来由,奇怪的是各个 KCP 代码使用者其实是可以观察到这一点的,但没人讲出来,依然还在笼统地用着“浪费 10%-20%”这种模糊的说法,以及“狂发冗余包”这样的印象。其实极端起来 KCP 是可以浪费 25%-40%的(大多数转发工具制作者不至于用到这么极端的配置参数),也可以把浪费降低到 10%以内(抗丢包能力相对没那么好)
    basncy
        25
    basncy  
       247 天前 via Android
    quic decouple 了҄应用层 session 与传输层 session, ip:port 就可҄以҄随意套娃找替҃补҃了҄, 铁打的包裹流水的快递员.
    halen1021
        26
    halen1021  
       154 天前
    op 现在有解决方案吗?或者用的是什么?
    halen1021
        27
    halen1021  
       154 天前
    我最近换了一个好点的线路,反而感觉体验更差了
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5361 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 08:54 · PVG 16:54 · LAX 00:54 · JFK 03:54
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.