Kcptun: Simple Multiplexing(SMUX)

[xtaci]

https://github.com/xtaci/smux

yamux问题太多, 正在重新实现mux库, 希望感兴趣的同学提意见。

[openertech]

绝对正确的选择！

2016-08-31 20:11 GMT+08:00 xtaci [email protected]:

https://github.com/xtaci/smux

yamux问题太多, 正在重新实现mux库, 希望感兴趣的同学提意见。

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/xtaci/kcptun/issues/168, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIlFoVlgDgBray_4WpiEzt6hhsnKLGSks5qlW9_gaJpZM4Jxikt
.

[xtaci]

kcptun smux分支 有能力的可以尝试自己编译

[koolwiki]

不知道smux有哪方面的优势？

[xtaci]

没有优势，主要是消除yamux的一大堆bug，做一个正确的实现。

[xtaci]

SMUX传输曲线

[braveguywallce]

SMUX 似乎已经很好地解决了前面ymux下的CPU/MEM占用过高的问题，今天无论看1080p HD视频，还是全速下载大文件，树莓派上的kcptun占用MEM稳定在80-100M, 最大值100M, 再没有前面ymux版本的攀高到300-500M的夸张情形。 CPU效能也得到大幅提高，树莓派 3 arm7下， 及时满负载高速下载，CPU占用率最大在50.5%左右！

恭喜楼主，软件有了一个质的飞跃！！谢谢！

[xtaci]

嗯，alpha测试中。

[baggiogogo]

没有严谨的测试过，不过可以很直观的感受到y2b缓冲条比原来的更加快速。赞。
昨晚更新一直到现在稳定使用中。

[braveguywallce]

最大的看点是： CPU , MEM 占用率优化了很多很多，说明系统的效率大大地进步了，几乎是两代不同的产品。

已经在树莓派上跑了一个下午，迄今都很稳定，速度很快很平稳，传输曲线很平坦，比ymux版本的速度又进一步提升了大约80%，真得大赞！佩服啊！

[xtaci]

https://github.com/xtaci/kcptun/releases/tag/smuxalpha

刚放了个测试版，有兴趣的同学可以试试。

[neteroster]

稳定性大幅提升
以前Youtube经常在9000~12000Kbps浮动，现在基本稳定在14000Kbps

[xtaci]

很好，希望听到更多的声音。

[neteroster]

反映一个问题

proxychians+wget下载大文件时会出问题

~/test$ proxychains wget http://23.247.4.35/1GB.test
ProxyChains-3.1 (http://proxychains.sf.net)
--2016-09-01 21:17:10--  http://23.247.4.35/1GB.test
正在连接 23.247.4.35:80... |S-chain|-<>-127.0.0.1:1083-<><>-23.247.4.35:80-<><>-OK
已连接。
已发出 HTTP 请求，正在等待回应... 200 OK
长度： 1000000000 (954M) [application/octet-stream]
正在保存至: “1GB.test”

1GB.test              0%[                    ]   8.94M  1.43MB/s    in 6.3s    

2016-09-01 21:17:17 (1.43 MB/s) - 在 9378664 字节处连接关闭。 重试中。

以下是kcptun

2016/09/01 21:19:02 stream opened
2016/09/01 21:19:27 write udp 192.168.1.7:38200->x.x.x.x:998: use of closed network connection 0
2016/09/01 21:19:27 write udp 192.168.1.7:38200->x.x.x.x:998: use of closed network connection 0
2016/09/01 21:19:27 stream closed
2016/09/01 21:19:28 stream opened
2016/09/01 21:19:35 stream closed
2016/09/01 21:19:41 write udp 192.168.1.7:52014->x.x.x.x:998: use of closed network connection 0

但是wget自动重试了之后还是可以下载。

[xtaci]

@lizongzeshunshun 什么版本

[neteroster]

@xtaci smux

[choicky]

@xtaci
0901的测试版，在使用fast3的情况下，速度峰值比0830的好，平均速度好像也比0830的好。

但是，0901会偶尔出现
write udp 192.168.1.5:53867->x.x.x.x:xxxx: use of closed network connection 0
与 @@lizongzeshunshun 的测试反馈类似。

[xtaci]

嗯，已经观察到此问题

[xtaci]

https://github.com/xtaci/kcptun/releases/tag/smuxbeta beta测试

[braveguywallce]

Alpha 版本smux
session scavenged write udp 192.168.1.218:48287->116.xxx.xxx.xxx:21: use of closed network connection 0
看了一下log, 会不间断出现上述提示.

[neteroster]

@xtaci beta测试中问题已经得到解决。感谢！

[choicky]

@xtaci 真勤快，赞一个。

beta版本没出现之前的“use of closed network connection 0”了。

另，我发现，不管是alpha还是beta，还是之前的版本，YouTube 1080P下网速比 4K或1440P都快...
例如，4G/1440P下，平均网速只有7M左右，1080P反而能有8~9M

我用的是fast3模式。之前尝试manual，但一直没找到比fast3快的参数，所以就没有折腾了。

[braveguywallce]

@xtaci @lizongzeshunshun
Beta版本的server端确实不再有 “session scavenged write udp 192.168.1.218:48287->116.xxx.xxx.xxx:21: use of closed network connection 0” ，但是client端还是会不间断出现上述提示，看下log就知道。但是这个提示并不影响smux kcptun正常工作，未出现断流现象或者影响下载， wget也没有任何报错！只有client的log里会有这个提示。

其实alpha版本我在用wget下载1G文件时，本身wget并没有任何报错，只有sever/client的log里会有上述提示而已，但是我没有用proxychains.

另外，无论alpha还是beta版本， CPU / MEM 控制得相当好！目前Beta 版本，满负荷工作状态下，server端 MEM 在29M左右，client端MEM在60-68M, 系统也非常稳定。

[braveguywallce]

@choicky
和kcptun没有关系,网路和个体设备的正常波动而已.我这边1080p / 1440p 下的视频流曲线都很平稳,没有你说的那个情况.

[xtaci]

@braveguywallce 重新下载一下beta，刚上传。

[neteroster]

@braveguywallce 我测试过程中服务端/客户端均没有出现xxx.xxx.xxx.xxx:21: use of closed network connection 0的情况

[braveguywallce]

@xtaci 最新的beta 0902版本已经OK! client 和 server再无上述提示出现！Beta版本CPU/MEM在我的树莓派上的情况如下（smux kcptun full load)：

[xtaci]

很好，争取晚上发布release.

[braveguywallce]

@xtaci Highly appreciate your great work! Well done!

[xtaci]

第一个release放出： https://github.com/xtaci/kcptun/releases/tag/v20160902

[braveguywallce]

@xtaci 在使用smux kcptun 0902的时候遇到一个问题，我的部署是，树莓派运行kcptun + 路由器 SS, 目前在PC上无论做任何的操作，都没有遇到任何问题。但是在安卓手机端尝试下载文件的话，都会遇到下载中断失败，无法继续，手机要尝试好几次才能完成文件下载，如果是稍微大一点的文件，手机端就不能正常下载成功了。而在yamux kcptun上则没有这个问题，关闭smux kcptun 只开启SS也没有这个问题。我的手机是NEXUS 6P , android 6.0.1 ，本身不带kcptun。

查了下本地 kcptun client的log, 手机下载中断时提示 ：session scavenged 会话中断。

[dolphinpaopao]

@braveguywallce 估计是ssAndroid的kcp版本还是yamux的，未更新到最新的smux，抑或所有ss、kcptun均更新到最新版本试试。

[braveguywallce]

@dolphinpaopao 我手机端没有开启shadowsocks，也没有安装kcptun，是靠路由和树莓派工作的，和shadowsocks -android应该没有关系，等会换个手机平台继续测试。手机浏览视频时和PC一样的，非常快速平稳，只有下载文件时出现这个问题。

[longshaof]

服务器和window10 客户端都用了最新的 0902 X64 的版本 ，看视频没有问题，就是在看网页的时候，网页有没有完全刷出来的情况，切换到不用kcptun就正常，之前0830版本没有这种问题

[rivernofish]

@braveguywallce 表示也有相同的问题，NEXUS 6P 和 NEXUS 5都试过，在更新play应用时，下载到99%就停住

[xtaci]

好的，已经收到，目前暂不清楚原因。此处无法重现。

[xtaci]

@braveguywallce @longshaof @rivernofish 稍微调整了一下smux的实现，麻烦重新下载一下0902测试看是否有改善。

[braveguywallce]

@xtaci 已经更新了0902 smux 。在安卓手机端，google play里更新或者下载app, 假设app是20M大小，开始的时候都正常，下载到99%的时候会突然卡住，不能完成最后的1%，这时候手机系统会尝试再次建立连接继续下载，那么这时候要等上1-2分钟，最后会自动完成最后的1%的下载。不清楚为什么会这样突然卡在99%的地方？ 本地log里依然有session scavenged， 而在PC上则没有这个问题，全程下载都很正常。

我回头找台ios手机做个测试看看

[baggiogogo]

iPad，y2b观察很久，服务端报broken pipe客户端报session scavenged，容易发生在切换视频和拉进度条时，不过没有影响观看，也就随它去没报告。服务端Debian7 64，客户端树莓派arm7。902版及前两个都如此。

[monkeylab]

kcptun后接ss-libev，更新0902之后，浏览器接sock5的ss没问题，但是接privoxy转出来的http很大一部分链接都会报502，稳定重现。0830无此问题，ss不走kcptun无此问题。

[kisflying]

0902之前的版本, darwin_amd64在开启一段时间之后, 会CPU持续在30%, 也没有流量在跑, 重启KCPTUN就正常... 一会又开始, 不知道0902是否有修复啊

[chk970222]

我也有视频流畅，下载断流的问题，不是到99%，而是随机的断流，很艰难才能把googleplay里的软件下完。都是用的最新版。我已把我开的Issues关闭了。
复制下我的Issues：
在使用过程中有个问题，请教一下我用的0902服务端版本，win10也是同样版本号，网络环境是50M电信，VPS是搬瓦工现在碰到的问题：我正常连接后，YouTube的看1080P应该是比较稳定的，速率大概在3000kpbs-7000kpbs，当然大部分时候在3000多，这问题都不大。但是我手机端用GOOGLEPLAY下载软件时，经常性的断流，完全没有数据流量。我手机通过电脑端的shadowsocks共享给局域网使用的，请问我现在该如何修改，谢谢。
服务端参数：-key * -crypt aes-128 -mtu 1400 -sndwnd 2048 -rcvwnd 2048 -dscp 46 -datashard 70 -parityshard 30 -mode manual -nodelay 0 -resend 0 -nc 1 -interval 40 -nocomp
客户端参数：-key "*" -crypt aes-128 -nocomp -datashard 70 -parityshard 30 -conn 4 -mtu 1400 -sndwnd 256 -rcvwnd 1024 -dscp 46 -mode manual -nodelay 0 -interval 20 -resend 0 -nc 1

[wxyzh]

怎么感觉怪怪的，curl下载速度只有200KB/s 左右
日志如下：
client
2016/09/03 09:53:45 version: 20160902
2016/09/03 09:53:45 listening on: [::]:12948
2016/09/03 09:53:45 encryption: aes-128
2016/09/03 09:53:45 nodelay parameters: 0 40 0 1
2016/09/03 09:53:45 remote address: [server ip]:80
2016/09/03 09:53:45 sndwnd: 512 rcvwnd: 512
2016/09/03 09:53:45 compression: false
2016/09/03 09:53:45 mtu: 1400
2016/09/03 09:53:45 datashard: 90 parityshard: 10
2016/09/03 09:53:45 acknodelay: false
2016/09/03 09:53:45 dscp: 46
2016/09/03 09:53:45 sockbuf: 4194304
2016/09/03 09:53:45 keepalive: 10
2016/09/03 09:53:45 conn: 2
2016/09/03 09:53:45 autoexpire: 60
2016/09/03 09:53:50 stream opened
2016/09/03 09:54:03 stream opened
....
....
....
2016/09/03 09:59:56 KCP SNMP:&{BytesSent:214001 BytesReceived:4897579 MaxConn:4 ActiveOpens:12 PassiveOpens:0 CurrEstab:2 InErrs:0 InCsumErrors:68 InSegs:7374 OutSegs:1769 OutBytes:561816 RetransSegs:15 FastRetransSegs:0 EarlyRetransSegs:0 LostSegs:15 RepeatSegs:0 FECRecovered:10 FECErrs:0 FECSegs:670}

server
2016/09/03 09:53:43 version: 20160902
2016/09/03 09:53:43 listening on: [::]:80
2016/09/03 09:53:43 target: 127.0.0.1:[port]
2016/09/03 09:53:43 encryption: aes-128
2016/09/03 09:53:43 nodelay parameters: 0 40 0 1
2016/09/03 09:53:43 sndwnd: 512 rcvwnd: 1024
2016/09/03 09:53:43 compression: false
2016/09/03 09:53:43 mtu: 1400
2016/09/03 09:53:43 datashard: 90 parityshard: 10
2016/09/03 09:53:43 acknodelay: false
2016/09/03 09:53:43 dscp: 46
2016/09/03 09:53:43 sockbuf: 4194304
2016/09/03 09:53:43 keepalive: 10
2016/09/03 09:53:43 remote address: [client ip]:1949
2016/09/03 09:53:43 stream opened
2016/09/03 09:53:50 remote address: [clinet ip]:2166
.....
.....
.....
2016/09/03 09:59:51 stream opened
2016/09/03 09:59:54 KCP SNMP:&{BytesSent:7374890 BytesReceived:27016 MaxConn:4 ActiveOpens:0 PassiveOpens:13 CurrEstab:4 InErrs:0 InCsumErrors:63 InSegs:1782 OutSegs:9956 OutBytes:9062362 RetransSegs:3002 FastRetransSegs:0 EarlyRetransSegs:6 LostSegs:2996 RepeatSegs:0 FECRecovered:8 FECErrs:0 FECSegs:110}

[cnmade]

换salsa20加密试试。aes好慢的说

[wxyzh]

@netroby 客户端和服务端都是intel的cpu，有aes指令集，应该和加密算法没关系

[braveguywallce]

@wxyzh 修改端口到21试试看，PC端下载在我这边倒是非常流畅，我是50M下行，用kcptun一般都要达到2.3MB的稳定速度,无论是Windows还是Linux平台。这个和个体的网络环境也很有关系，如果ISP给你的国际出口带宽本来就限死了，那也没办法的。

[cnmade]

用443 udp端口超爽的。

Appreciate your time.

Netroby

2016-09-03 10:37 GMT+08:00 braveguywallce [email protected]:

@wxyzh https://github.com/wxyzh 修改端口到21试试看，PC端下载在我这边倒是非常流畅，
我是50M下行，用kcptun一般都要达到2.3MB的稳定速度,无论是Windows还是Linux平台。这个和个体的网络环境也很有关系，
如果ISP给你的国际出口带宽本来就限死了，那也没办法的。

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/xtaci/kcptun/issues/168#issuecomment-244521923, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAQ-iXB0lyWaz_pxufW1ARCB9OwT9wJCks5qmN1QgaJpZM4Jxikt
.

[chk970222]

@braveguywallce 特殊端口有加成？把你的告诉我可好？

[xtaci]

感谢各位的反馈，第一版肯定有不少问题，初步定位到一个问题，fix后通知大家。

[wxyzh]

443 和80 都试过 两端的BytesSent和 BytesReceived相差太多，油管能跑到10-20Mbps

[RoyLi-Pvt]

刚刚更新了0902E绅士图片几乎完全没法加载成功 服务端除了broken pipe没有其他报错 图片都是加载个一部分之后就变×了 看Twich则没有问题

[xtaci]

那么现在的问题是集中在文件下载？

[cnmade]

准确的说是断流.

[chk970222]

@xtaci 我的问题是手机在googleplay的下载，但是不知道是否是ss的影响，ss应该没影响，我只是通过局域网这么来的，电脑端没试下载。

[xtaci]

@netroby 什么情况下的断流，我这里无法重现。

[xtaci]

另外，如果客户端设置了autoexpire，服务器提示broken pipe是正常现象。

[xtaci]

高度怀疑是TCP HALF CLOSE的问题，你们觉得呢

[cnmade]

浏览,看视频看的好好的.过一会儿就掉了.死活连不上了.断掉重连也连不上了.

[xtaci]

我说下我这里的情况，联通，200M ADSL， 路由器是transocks + kcptun ---> vultr(usocksd) ，无论是浏览网页，看视频，还是下载文件，手机下载, apple store均未出现任何问题。

实在摸不到头绪。

[braveguywallce]

@xtaci 我也考虑过用苹果手机试试看下载文件，但是我的苹果手机要周一才能拿到，你也能用安卓机试试看吗？另外我后面要做的测试是停止shadowsocks+kcptun的方案，改用你的方案 transocks+kcptun，看情况是否改变。

[neteroster]

@xtaci 我也是。100M电信光纤，ss + kcptun (smux release)未出现上述任何问题(只是手机端没有实验过)。

[xtaci]

区别就是长链接还是短链接，短链接容易出问题。

[xtaci]

@braveguywallce @netroby 提交了一个小的修正， 需要重新下载0902版本，不确定是否是这个问题。

[rivernofish]

@xtaci 太厉害了！！！新版本没有卡在99%的问题了，无论是更新还是全新下载都没问题，大赞！

[xtaci]

希望能确定是此问题。

[cnmade]

很流畅. 暂时没有遇到问题.

[chk970222]

非常感谢，现在googleplay下载的问题已经极大的改善了，谢谢

[cnmade]

用了15分钟,比之前流畅一些.

[cnmade]

又观察到了断流.无论如何也连不上服务器. 不排除是网络问题.切换了另外一台服务器.再继续观察是否会继续出现断流现象.

[xtaci]

预期的传输曲线应该是比以前版本平稳的多。

[chk970222]

我这里的曲线反而没有小修改前，但是解决了下载的问题，我也帮不上忙，现在这样比较均衡了。但是现在居然有过万的时候，哈哈

[xtaci]

@chk970222 既然问题已经确认，剩下的就是优化。问题不大。

[rivernofish]

@chk970222 @xtaci 我这边也是同样的情况，传输曲线感觉还是之前的版本更平稳，但是下载问题似乎已经解决了。

[chk970222]

@xtaci 非常感谢你的付出

[xtaci]

重新上传了0902，正式的fix @chk970222 @rivernofish @TMily @braveguywallce 0902版本就这样了，没有重大问题就等收集意见到下个版本集中更新了。

[chk970222]

最新放出的fix怎么还不如之前那个小改呢？是不是fix错了啊？原来下的又删除了，咋办？

[xtaci]

@chk970222 具体是什么问题？

[xtaci]

[chk970222]

现在的速率只有不到3000kbps，大部分时候只有1000多，之前一个版本基本都在5000-6000多，有时候都会上万的，我觉得倒数第二个好很多。我也不晓得原因，但排除了网络的原因

[xtaci]

哦，如果是速度的原因，你可以贴一下你的参数，速度和参数关系最大。

[chk970222]

同样 的参数，同样的电信50M.搬瓦工vps
服务端参数：-key * -crypt aes-128 -mtu 1400 -sndwnd 2048 -rcvwnd 2048 -dscp 46 -datashard 70 -parityshard 30 -mode manual -nodelay 0 -resend 0 -nc 1 -interval 40 -nocomp
客户端参数：-key "*" -crypt aes-128 -nocomp -datashard 70 -parityshard 30 -conn 4 -mtu 1400 -sndwnd 256 -rcvwnd 1024 -dscp 46 -mode manual -nodelay 0 -interval 20 -resend 0 -nc 1

[xtaci]

嗯，你这个参数非常容易收到波动， 试试 -nodelay 1 -resend 2 -nc 1 -interval 20，其他不变， nodelay =0只有在线路质量非常稳定可靠的时候才可用， 所以fast2是一种在多种情况下最安全的参数。

[chk970222]

这样一改，速率更低1000kbps不到，我重启电脑试下

[cnmade]

断流,断流. 通过多台服务器测试,断流情况一直出现

ktc_1  | 2016/09/03 08:36:46 main.go:56: stream opened
ktc_1  | 2016/09/03 08:36:46 main.go:56: stream opened
ktc_1  | 2016/09/03 08:36:51 main.go:56: stream opened
ktc_1  | 2016/09/03 08:36:52 main.go:56: stream opened
ktc_1  | 2016/09/03 08:36:55 main.go:56: stream opened
ktc_1  | 2016/09/03 08:37:07 main.go:56: stream opened
ktc_1  | 2016/09/03 08:37:11 main.go:56: stream opened
ktc_1  | 2016/09/03 08:37:16 main.go:396: session scavenged
ktc_1  | 2016/09/03 08:37:16 main.go:79: stream closed
ktc_1  | 2016/09/03 08:37:16 main.go:79: stream closed
ktc_1  | 2016/09/03 08:37:16 main.go:79: stream closed
ktc_1  | 2016/09/03 08:37:16 main.go:79: stream closed
ktc_1  | 2016/09/03 08:37:16 main.go:79: stream closed
ktc_1  | 2016/09/03 08:37:16 main.go:79: stream closed
ktc_1  | 2016/09/03 08:37:16 main.go:79: stream closed
ktc_1  | 2016/09/03 08:37:16 main.go:79: stream closed
ktc_1  | 2016/09/03 08:37:16 main.go:56: stream opened
ktc_1  | 2016/09/03 08:37:16 main.go:56: stream opened
ktc_1  | 2016/09/03 08:37:19 main.go:56: stream opened

[xtaci]

@netroby 你vps挂了吧。

[chk970222]

确实这个最新版本我使用的情况不如前一版本的情况好

[xtaci]

@chk970222 我觉得不一定是这个原因，如果你是电信的网络，可以尝试重启下光猫。

[neteroster]

我觉得这一版速度提升很高
以前speedtest最多14Mbps，这次竟然飙到了20Mbps

[cnmade]

vps没挂.用着用着,链接就断了.ping vps是好的.ssh也可以正常链接.就是kcptun死活连不上

[cnmade]

而且我换了几台不同的服务器来测试. 都会出现中断的问题.不知道哪里不对

[neteroster]

@netroby 调低kcptun对外端口(1000以下)试试

[xtaci]

@netroby 更换密码，更换端口，更换-crypt

[chk970222]

好，我去重启光猫，你能不能把前一版给我个链接，万一重启美好，我就把它退回前一版。谢谢

[baggiogogo]

是不是加了autoexpire参数，如果加了相应的端口防火墙检查下。

[xtaci]

[RoyLi-Pvt]

刚回到家 现在我这边看加载大图片也没有问题了

[braveguywallce]

正在外地，随身带了一台笔记本，装ubuntu 14.04, 刚测试了修正后的0902版本，这边条件差，没有光纤线路，只有电缆到户，在电信10M下行的条件下，亚洲VPS，开启和不开启smux kcptun差大约7倍的速度，效果很理想，视频流输出曲线很平稳，没有发生断流的情况，回家后再测试下手机端的情况，如果已经恢复正常，那这个版本就很成功。非常感谢作者！

[chk970222]

@braveguywallce 你10M就是这种，让我50M的情何以堪，我还没你的快，我真不知道什么原因了。谢谢

[braveguywallce]

@chk970222 你可以换实际路由更友好的VPS,我从现在这个地方ping我的VPS也只有85ms，选择VPS的时候要事先看你实际的路由，有些节点虽然在亚洲，实际上ISP线路是先到美国再回到亚洲的，这样肯定好不起来。 另外你要优化你的kcptun的各种参数，这个要根据实际情况仔细调整的，你参考下这个项目里的说明和作者的相关专业解释，还是相当专业的。

[chk970222]

@braveguywallce 在0902最终版本之前一个版本，我youtube的速度基本在6000-7000kbps，有时候上万，现在这个速度基本下降一半，参数这些都是一样的东西，你有没有上一个版本的服务器端和客户端，传给我好吗？

[xtaci]

@chk970222 那个肯定不是版本的原因， 你别用y2b测试，用speedtest测试。
y2b是控制了流速的，根据我的经验，y2b控制在缓存60s～120s左右

[chk970222]

@xtaci 我确实不明白，但是这个版本的体验比上一个版本差很多。表现在一：我打开youtube时就要缓冲一会，上一版本基本秒开，二：速率下降得有点多，现在安静的时候基本少1000-2000kbps，三：googleplay下载的时候等待的时间稍微久一点，当然这是主观感受，还是比早期下载有问题的版本等待的时间短，但是比前一版本差些。四：曲线比前一版本起伏大。谢谢你们这么晚了还在关心我这个小白的不明所以。
另外我的搬瓦工刚才看了下路由追踪：本机-本地电信-上海骨干网-中国骨干网-美国 加利福尼亚州弗里蒙特市Hurricane Electric公司-美国 亚利桑那州凤凰城IT7Network公司-vps。当然这也是挂着ss走的，不知道是否有影响。
谢谢

[xtaci]

@chk970222 y2b是个错误的参考，因为google也会动态调整传输策略。 只要播放流畅，就是良好的传输方式。 我可以负责任的说，最新版本100%好于之前的临时fix. 针对你的问题，我怀疑如下：

1. dns解析出来的并不是离vps最近的地址
2. 曲线起伏大在于参数的，是否设置了 -nodelay 0
3. 如果是电信，QoS非常暴力，前一秒很好，后一秒就给你降下去，可以尝试重启光猫。
4. 家用的路由器，光猫上，是否有防火墙，QoS（电信光猫有防火墙控制）
5. 可以尝试VPS上的 net.ipv4.tcp_congestion_control=cubic 参数，改为htcp/vegas/hybla等是否有变化。

[chk970222]

嗯，我发现了y2b会动态调整，播放流畅就行，其实我不纠结这个，我现在感觉是不是我今天测试多了，qiang对我有干扰。另外听从你的一讲，已经参数改成你建议的-nodelay 1 -resend 2 -nc 1 -interval 20。
我慢慢折腾，这么晚了不打扰你，如果有发现，我会反馈到这里，供其他人参考。
谢谢，晚安

[baggiogogo]

@xtaci 经你这么一说，我请教个题外话，一般我都是sstunel转发8.8.8.8请求，那是否非美国的vps需要找下所在国的dns？

[xtaci]

@baggiogogo 最好的dns是vps上的 /etc/resolv.conf中的那个。

[baggiogogo]

@xtaci 好的，感谢。

[chk970222]

谁能给我0902最终版的前一版，不明原因的体验效果不好，现在已经没有其它人使用wifi了。

[geniusyjiang]

@netroby 我也有断流现象，不过刚才突然意识到是因为我的ISP限制了端口，只有常用端口才是通的，而autoexpire会变换端口导致断流。刚才把autoexpire设为0，不再断流了。

[chk970222]

我还是换回Pre-release这个版本了，我这里使用这个版本真比最终版体验好得不是点吧点，原因不明。实在抱歉，没有能力找出原因。

[xtaci]

有这种事！

[xtaci]

贴完整配置 启动日志

[chk970222]

@xtaci 抱歉，我不知道到哪里找配置启动日志。使用Pre-release就是有下载断流，其它还好。

[xtaci]

@chk970222 启动参数是什么 完整的。

[braveguywallce]

@xtaci 刚刚把我手机端的shadowsocks-android更新到了3.1.0，即支持smux kcptun。测试了下，运行很完美，从google play music下载了500M - 1G的音乐文件到手机，速度很快，再无下载中断而无法下载现象。视频也是秒开。另外观察了下PC端和Server端的MEM, PC端的MEM也就在60M 左右， Server端MEM只用了25M，比前面yamux版本要好很多。
此外，前面手机端下载文件中断的现象，是否因为TCP 长链接和短链接的原因，导致client和server握手中断而导致？

[chk970222]

@xtaci 你是说客户端配置工具的参数吗？ -key "*" -crypt aes-128 -nocomp -datashard 70 -parityshard 30 -conn 4 -mtu 1400 -sndwnd 256 -rcvwnd 1024 -dscp 46 -mode manual -nodelay 1 -interval 20 -resend 2 -nc 1

[xtaci]

你的机器配置是否很低

[xtaci]

唯一我能想到的差别是锁粒度 可能在板瓦工这种超卖vps上会明显。

[xtaci]

我下午单独给你个版本 调试一下

[chk970222]

好的，非常感谢，单独的版本就是倒数第二个比较适合我，哈哈。再次感谢，即使不好，我也不纠结了。我用的笔记本，跑这个应该没撒问题，我看cpu占用率很低，内存才3,652K。vps.搬瓦工的RAM:
48.5/1024 MB，也没多少啊。

[xtaci]

是cpu在锁操作上的严重阻塞 因为vps超卖了太多机器

[cnmade]

可否无锁设计？

获取 Outlook for Android

On Sun, Sep 4, 2016 at 12:17 PM +0800, "xtaci" [email protected] wrote:

是cpu在锁操作上的严重阻塞 因为vps超卖了太多机器

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[xtaci]

@netroby 这种情况应该是noisy neighbour问题，可以google，应该说是严重超卖才会出现。当然，这是我的推测 。 需要 @chk970222 先验证下这个版本。

PS. 我对这个版本不满意，曲线锯齿严重。

[chk970222]

谢谢，我现在外面，用电脑不方便，一会测试后反馈。谢谢

[GangZhuo]

测试下载一个本地文件，不像之前版本了，换了 SMUX 后，曲线比较匹配了。

[chk970222]

@xtaci 我觉得真的很怪，这个特供版本，速率也不高（2000-3000），波动也大，但是体验要好很多，它基本不缓冲，点开就开始播放了，googleplay下载也不断流了，速度虽然慢点，但都在我接受的范围。太奇怪了。不纠结了，谢谢

[xtaci]

@chk970222 高度怀疑vps极慢。CPU被同一台机器上的其它vps抢占了完, 这个问题不会做为正式fix，太极端了。当然在以后的优化过程中，会考虑这种极端情况。

[chk970222]

@xtaci 好的，谢谢，不用考虑我这种极端情况。现在我看了将近一个小时y2b，居然能上万了，但是确实波动大。再次对你的付出表示感谢。

[braveguywallce]

@chk970222 换稍微好点的vps，一个月出个10美刀也没啥，一年才120美刀，这种小钱就别省了。

[chk970222]

@xtaci 你一看我就是拿个渣渣来试手，我完全是外行，慢慢稍微熟悉点了来，这点钱倒没事，主要是不会就浪费了。

[c1024]

20160904版本还会有session scavenged出现

[xtaci]

各位，试一下0904。 若干小修正。
@c1024 正常输出。

[xiocode]

@xtaci 我的配置

./client_linux_amd64 -r "xxxxx" -l "xxxxx" -key xxxxx -crypt salsa20 -sndwnd 256 -rcvwnd 1024 -autoexpire 600 -mode manual -conn 2 -nodelay 1 -resend 2 -nc 1 -interval 20 -nocomp -dscp 46 -mtu 1400 -datashard 70 -parityshard 30

./server_linux_amd64 -t "xxxxxx" -l "xxxxx" -key xxxx -crypt salsa20 -sndwnd 2048 -rcvwnd 2048 -mode manual -nodelay 1 -resend 2 -nc 1 -interval 20 -nocomp -dscp 46  -mtu 1400 -datashard 70 -parityshard 30

未使用KT加速情况下，Y2B可以跑到1W~2W
使用后只能到7K~8K

Client: KCP SNMP:&{BytesSent:298890 BytesReceived:35680920 MaxConn:2 ActiveOpens:2 PassiveOpens:0 CurrEstab:2 InErrs:0 InCsumErrors:13 InSegs:96872 OutSegs:4848 OutBytes:3946948 RetransSegs:100 FastRetransSegs:0 EarlyRetransSegs:1 LostSegs:99 RepeatSegs:14046 FECRecovered:1537 FECErrs:0 FECSegs:28530}

Server: KCP SNMP:&{BytesSent:74732880 BytesReceived:31151 MaxConn:2 ActiveOpens:0 PassiveOpens:2 CurrEstab:2 InErrs:0 InCsumErrors:21 InSegs:6017 OutSegs:447195 OutBytes:593886977 RetransSegs:256024 FastRetransSegs:136843 EarlyRetransSegs:76874 LostSegs:42307 RepeatSegs:0 FECRecovered:54 FECErrs:0 FECSegs:1792}

是否参数有误，需要调整

[braveguywallce]

@xiocode 建议在不是很精通网络通信技术的情况下还是不要采用manual模式。可以尝试默认的几种模式，选择适合自己网络环境的。manual模式下，不同参数的组合，对速度的影响差别明显。
另外，kcptun不是对所有的网络环境都起到加速作用的，比如移动，它本身国际出口部分线路的状况就比较好，TCP通信也很畅通，这时候再开启kcptun其实是画蛇添足，反而会降低速度的，还白白浪费了流量和带宽。

[braveguywallce]

@xtaci 0904 正式版已经测试，没有问题！手机端下载文件的问题也解决了，其它各方面都不错！曲线输出也很漂亮平稳。采用fast模式下，有效流量/消耗流量 >= 1 : 3 , 和某些VPS供应商做的测试结果一致。

[xtaci]

0904的曲线是这样的。

[Cye3s]

0904应该也解决了Openwrt x64上客户端占用大量内存的问题，跑了20多个小时，目前还是25M左右，以前早暴到300M以上了，很好

[xtaci]

@Cye3s 还是自己造的轮子更好用。。。哈

[braveguywallce]

@xtaci 目前0904版本在稳定使用中，现在考虑的也是怎么尽量优化。有关根据SNMP的输出值来精细调整优化manual项下各项参数的专业知识，能否再进一步介绍？谢谢！

[xtaci]

@braveguywallce https://github.com/xtaci/kcptun/issues/137 参数调整在这里讨论，你可以先看下我之前的发言，了解基本困难在何处。
另外0906刚发布，做了些清理工作。

[baggiogogo]

@xtaci 又来请教题外了，实在不好意思，自己实在搞不定，闲时麻烦指点下，谢谢。
树莓派，同时启用adbyby和ss，不成功，走了redsocks就不走adbyby，走了adbyby就不走redsocks。
以下是redsocks，10811端口，监听sslocal1080端口。
:REDSOCKS - [0:0]
-A PREROUTING -p tcp -j REDSOCKS
-A REDSOCKS -d 0.0.0.0/8 -j RETURN
-A REDSOCKS -d 10.0.0.0/8 -j RETURN
-A REDSOCKS -d 127.0.0.0/8 -j RETURN
-A REDSOCKS -d 169.254.0.0/16 -j RETURN
-A REDSOCKS -d 172.16.0.0/12 -j RETURN
-A REDSOCKS -d 192.168.0.0/16 -j RETURN
-A REDSOCKS -d 224.0.0.0/4 -j RETURN
-A REDSOCKS -d 240.0.0.0/4 -j RETURN
-A REDSOCKS -p tcp -j REDIRECT --to-ports 10811
adbyby默认监听80端口，自身在8118端口。
官方给出的iptable为：
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8118
请教下是否就无法共存，或者这个情况下iptable到底该怎么写，谢谢。

[RoyLi-Pvt]

怀疑SMUX后的版本存在流量过度浪费问题 刚刚更新0906版本的时候看了下vultr控制台 本月入站只有47.83GB 出站居然有553.62 GB十倍还多 这个VPS上只跑了SS和kcptun
额 又看了下图表 应该就是0904的早期版本的问题 图表上553.62 GB的大部分是在0903和0904跑出去的

[xtaci]

@TMily 是的，0904早期版本有bug,0906已经修正。

[xtaci]

@baggiogogo 不好意思，我不用redsocks／adbyby 的

[baggiogogo]

@xtaci 没关系，我这小事，专心你的项目造福大家，感谢感谢。

[Cye3s]

server端好像比SMUX之前的版本占内存了，旧的跑两周内存不会超过30M，新的跑一周左右会到237M
CentOS 7.2 x64

[xtaci]

@Cye3s 服务器端用GOGC调整吧

[ppgl1]

smux同样设置是比yamux快，但至今所有版本下载大文件还是会断线，当然一般会续传看不出来，我是下bigfile网盘是才发现的，客户端session scavenged服务端broken pipe，您说的是客户端设置了autoexpire就会有brokenpipe，但同样设置yamux版却不会有，参数还是前几天那贴老样子0 40 2 1

[xtaci]

autoexpire会强制断线 ，之前的yamux不会强制断线，会占用不必要的带宽。正常行为。

[cjjdaq]

@baggiogogo
iptables -t nat -A PREROUTING -p tcp -j REDSOCKS
iptables -t nat -A REDSOCKS -d 0.0.0.0/8 -j RETURN
iptables -t nat -A REDSOCKS -d 10.0.0.0/8 -j RETURN
iptables -t nat -A REDSOCKS -d 127.0.0.0/8 -j RETURN
iptables -t nat -A REDSOCKS -d 169.254.0.0/16 -j RETURN
iptables -t nat -A REDSOCKS -d 172.16.0.0/12 -j RETURN
iptables -t nat -A REDSOCKS -d 192.168.0.0/16 -j RETURN
iptables -t nat -A REDSOCKS -d 224.0.0.0/4 -j RETURN
iptables -t nat -A REDSOCKS -d 240.0.0.0/4 -j RETURN
iptables -t nat -A REDSOCKS -p tcp -j REDIRECT --to-ports 10811
iptables -t nat -I OUTPUT -p tcp -j REDSOCKS
iptables -t nat -A zone_lan_prerouting -p tcp --dport 80 -j REDIRECT --to-ports 8118

试试吧

[baggiogogo]

@cjjdaq，好的，我试试，感谢！