[分享]应对运营商 udp 屏蔽和 qos 的解决方案，几乎支持任何 udp 程序，适合 kcptun 和 finalspeed

wangyucn

2017-08-11 21:25:11 +08:00

@s82kd92l 我觉得运营商有时候都不是故意 UDPQos 你，只是他们设备对 udp 支持不好，或者 udp NAT 的设备压力太大导致不稳定。我这边的移动 tcp 多线程（单线程当然不行）连国外基本都满速。但是 udp 连有一些方向的线路总是时断时续，有的时候 nat pipe 都打不通。既然 tcp 都满速，udp 故意 Qos 你有什么用呢。

所以我觉得这个项目某种程度上也是在帮运营商，解决 udp nat 支持不好带来的用户抱怨 = = 。

wangyucn

2017-08-11 21:25:42 +08:00

当然，这纯属不负责任猜测。

s82kd92l

2017-08-11 21:28:04 +08:00

@wangyucn

运营商绝对是故意 udp-qos 的，主要限制 p2p, 不然 bt/emule 会把他们整疯的。

FishTorres

2017-08-11 21:29:54 +08:00

QUIC 跟着倒霉

wangyucn

2017-08-11 21:30:44 +08:00

@s82kd92l 我这边到美国西海岸 udp 基本满速，到日本经常连都连不上，但是多线程 tcp 到日本和美国西海岸又都满速。有点费解。

terrytw

2017-08-11 21:32:32 +08:00

有意思，非常支持！

1423

2017-08-11 23:27:20 +08:00

测了下 kcptun + udp2raw-tunnel 一起用，带宽利用率相当低。。不知道怎么分析原因？

wangyucn

2017-08-11 23:43:06 +08:00

@1423，性能问题去项目里提 issue，贴出配置吧。

有可能你使用的是路由器版，用了 aes128cbc 加密，导致 cpu 被打满。路由器建议用 --cipher xor --auth simple

wangyucn

2017-08-11 23:49:45 +08:00

我这边移动 20m 宽带，测试出的性能：
./iperf3 -c 10.222.2.1 -P40 -t30
[SUM] 0.00-30.00 sec 68.3 MBytes 19.1 Mbits/sec 3391 sender
[SUM] 0.00-30.00 sec 64.6 MBytes 18.1 Mbits/sec receiver

./iperf3 -c 10.222.2.1 -P40 -t30 -R
[SUM] 0.00-30.00 sec 71.3 MBytes 19.9 Mbits/sec 10046 sender
[SUM] 0.00-30.00 sec 56.6 MBytes 15.8 Mbits/sec receiver

客户端在 linux 虚拟机上，如果是路由器的话，因为 cpu 速度的原因，只有 8Mbits/sec.

wangyucn

2017-08-12 00:10:10 +08:00

server 在 vultr 日本。

Damaidaner

2017-08-12 09:28:50 +08:00

收藏！！

hjc4869

2017-08-12 10:14:52 +08:00

Windows 没必要用虚拟机，装 Windows Server 就能用 raw socket 艹 tcp 了。

或者用 pcap 之类的也行

johnlui

2017-08-12 10:34:00 +08:00

kcptun 和 BBR 有实测数据嘛？

wangyucn

2017-08-12 11:02:05 +08:00

@johnlui
window raw socket 没有 linux 的功能强大。pcap 的话得移植一下。winpcap 也要单独装得，干脆装虚拟机吧。如果嫌麻烦可以去网上找做好的 vmware 镜像。

@johnlui
kcptun 的数据暂时没有。finalspeed 移动 20M 宽带从日本下载，1.6MB/s （ Byte ）的下载速度。

wangyucn

2017-08-12 11:03:51 +08:00

BBR 感觉跟这个项目不搭边吧。也许你想到了什么特殊用法？比如用 openvpn+udp2raw 再测开启了 bbr 的 tcp 性能？

linhua

2017-08-12 12:15:14 +08:00

@wangyucn
厉害

@kuretru
如果丢包率不高的话(<15%)，可以使用 BBR
github.com/linhua55/lkl_study 搬瓦工 64M 也是可以使用的，只是 CPU 占用有点高

wangyucn

2017-08-12 12:36:32 +08:00

不敢不敢
@linhua 是最早实现了用 raw_socket 中转 udp 这个点子的人:
https://github.com/linhua55/some_kcptun_tools/tree/master/relayRawSocket

Chion82 在他的基础上加上了 tcp 握手功能，集成到了 kcptun 里:
https://github.com/Chion82/kcptun-raw

我这个项目，把 kcptun-raw 的功能做成通用的了，再加了点小功能。如果没有 relayRawSocket，可能也就没有 kcptun-raw 了，也没有我这个项目了。

palxex

2017-08-12 12:54:46 +08:00

建议还是考虑一下 pcap。这样 win/mac 上应该都能原生跑了（虚拟机感觉还是太重），final speed 的 tcp 模式印象中就是这么做到跨平台的，尽管可能是实现略 naive 始终没做到 udp 模式的稳定程度，但原理上跟这个项目应该一样是用 raw socket 发包。

wangyucn

2017-08-12 13:09:28 +08:00

finalspeed 用的就是 pcap。而且他也不愿意同时支持 pcap 和 raw socket，所以他的版本不能在 openvz 上运行。

支持 windows 理论上没问题，问题是开发成本= =。 raw socket 要改成 pcap,epoll 要改成 libevent，暂时不想增加开发负担。

虚拟机很稳定，而且性能很好，如果爱折腾还是装个备用吧。

wangyucn

2017-08-12 13:12:40 +08:00

可以考虑后续发布装了 udp2raw 的 vmware image。用 openwrt x86 版的，容量可以控制在几 MB。