Kcptun: v20160820 可能有断流现象

[wansenlyt]

你好：
首先感谢你的付出！
使用搬瓦工VPS，Centos 6 x86_64系统，架设Shadowsocks Python版和Kcptunv20160820版，VPS上供电脑用参数为：server_linux_amd64 -l :** -t 127.0.0.1:* -key ** -crypt salsa20 -mtu 1400 -sndwnd 2048 -rcvwnd 2048 -mode fast2 -nocomp；供手机用参数为：server_linux_amd64 -l :** -t 127.0.0.1:* -key ** -crypt none -mtu 1400 -sndwnd 2048 -rcvwnd 2048 -mode fast2 -nocomp，电脑和手机上均正常使用。

在使用过程中，发现可能存在一点小问题，向你反馈一下：
通过本代理链接WinSCP时，不定时会自动退出，要求重新登录；Android通过代理在Google Play更新软件时，也会经常断开链接。

  请帮助看看，究竟是我配置参数问题，还是新版本存在断流现象，谢谢！

[qiumzh]

断流是有的，我也试了很多种配置参数，但还是会出现断流。。。

[shutup]

也有可能是防火墙的原因，我自己的使用感觉，在一些ISP中，会对发往国外的UDP进行限制，导致使用了KCPTUN反而速度变慢的问题。

[wxyzh]

建议用iperf去测试下，客户端运行iperf3 -s -f M，服务端运行iperf3 -c xxxxx -u -b 20M -f M -t 60
其中-b 20M 为测试带宽(Mpbs)，-t 60 为测试60秒，-u为udp模式，默认端口为5201 如需修改端口，要在两端用-p指定端口。
然后在两端看运行结果，尽可能的长时间做测试，我这边用的移动宽带，测试发现当带宽超过20Mbps后非常容易丢包。
最后根据测试的带宽和丢包情况去调整wnd和前向纠错

[wang20150419]

我今天专门测试断流，日本vps， 上午用 socks5 + kcptun 看youtube，开始很快，10多分钟后，就很慢了，感觉是断流了，此时 ping vps, 100ms左右的响应，丢包1% 。后来切换成 shadowsocks + kcp，看youtube 一个小时，基本正常。

[xtaci]

@wxyzh 这才是真实的丢包，完全不是ping能反应出来的。

[sosmygirl]

是有断流的情况，我换回以前的版本就没出现过

[qiumzh]

具体哪个版本呢

[GangZhuo]

@xtaci 下载大文件的时候，看起来像是先通过 UDP 把文件都传输到客户端后，一起送出去的。我在本机上测试，版本是 20160823，步骤如下：

服务端： server_windows_amd64.exe -l ":4435" -t "127.0.0.1:80" --mode manual --nodelay 0 --resend 0 --nc 1 --interval 40 --dscp 46 --nocomp --mtu 1200 --crypt none --datashard 20 --parityshard 5

客户端：client_windows_amd64.exe -l ":12948" -r "127.0.0.1:4435" --crypt none --mode manual --conn 1 --mtu 1200 --sndwnd 128 --rcvwnd 1024 --nocomp --datashard 20 --parityshard 5 --dscp 46 --nodelay 0 --resend 0 --nc 1 --interval 40

然后，浏览器打开 http://localhost:12948/download/，并下载一个 569M 的文件，客户端统计图如下。棕红色的线条是 client_windows_amd64.exe 接收 server_windows_amd64.exe 的速度，绿色线条是 client_windows_amd64.exe 送给浏览器的速度。从图上看 client_windows_amd64.exe 一直以 7M/s - 8M/s的速度从服务器接收数据，同时以不到 1M/s 的速度送数据给浏览器，期间也有一个14M/s的突出速度，最后突然以 174M/s 的速度把数据全部返回给浏览器了，这是否是断流的原因呢。

[xtaci]

@GangZhuo 这个问题涉及到多核多线程的调度均衡性，极有可能是调度不平衡导致的,即kcp先把CPU吃光了。

[xtaci]

@GangZhuo GOMAXPROCS＝1再运行，并观察

The GOMAXPROCS variable limits the number of operating system threads that can execute user-level Go code simultaneously. There is no limit to the number of threads that can be blocked in system calls on behalf of Go code; those do not count against the GOMAXPROCS limit. This package's GOMAXPROCS function queries and changes the limit.

https://golang.org/pkg/runtime/

[GangZhuo]

@xtaci CPU 的核心线程图，看起来 CPU 调度还是比较均衡的，不过客户端内存占用很高：

好的，我试试 GOMAXPROCS =1

[GangZhuo]

一样的结果，设置好环境变量后，已经重启服务端和客户端。

Edit: remove screenshot.

[xtaci]

我只有慢慢查原因， 可能的问题是

1. kcp-go中的mutex抢占不平衡
2. yamux的读取和发送不平衡

[GangZhuo]

嗯，作者辛苦了，我不懂 golang。

[GangZhuo]

@xtaci 20160826 版好像修好了这个问题。

[xtaci]

就是yamux 的窗口控制算法有问题。

[GangZhuo]

曲线看起来不够平滑，方差较大，不过应该可以了。感谢!!!