一个诡异的缓冲问题

[palxex]

版本：0701和0719均能重现 环境：server vultr tokyo debian sid x64，client OSX 10.11.5和10.11.6都能重现 配置：默认参数，改了key，mode fast2，其他参数均未添加（后来根据issue中的计算方法设置client sndwnd=32 rcvwnd=256后重新进行了测试，现象完全没变化） 测试方法：

1. kcptun内嵌SS，服务器的kcptun server指向ss server，本地ss client指向kcptun client，应用程序（chrome/curl）使用ss的socks5代理下载
2. kcptun内嵌sniproxy，服务器的kcptun server指向sniproxy server，本地kcptun绑定80、443端口指向kcptun server对应端口，dnsmasq修改对应站域名，应用程序不做任何改动

现象：（为简单起见只进行了测试1的，附上asciinema录屏。方法2的实测结论完全一致）

• 这个vps在本地直连，无论HTTP还是SS速度都很低，虽然ping也就100多点，丢包率也不算高，不知何故。https://asciinema.org/a/4qvq4i078sf8aj31znhj1po1p
• finalspeed+SS能把应用程序可感知的速度直接提升到本地带宽上限。https://asciinema.org/a/amh3r7yqyytr26z209bowaf39
• kcptun能将速度提到差不多的程度，但表现有点奇怪：下载程序仍然在以跟该服务器连接的原始速度下载，但是带宽监测显示本地带宽被占满了。一开始我还以为这些带宽都做了无用功，但经过仔细测试发现是这样的：虽然应用程序以为速度只有这么慢，但其实那些占掉的带宽都在kcptun缓冲中。等到缓冲结束，kcptun会把整个缓冲的内容直接扔给下载程序。观察起来就是1%...2%...3%然后biu的一下就100%了这样。https://asciinema.org/a/3zsaokhqp0gyv2ye0sgxuz0qt

结果就是应用程序完全失去了对网速的感应能力，这样其实会有很多问题。就个人用途来说，需要用kcptun加速的很多目标服务器都是跟本地直连速度极低的。这种情况下很可能kcptun正在飙速度，本地下载的程序（比如chrome）却以为根本下不动直接把链接断掉了，导致加速完全失去了意义。另外如果下载的包极大，中间有其他事想暂停把网络释放出来用，那缓存数据就完全废掉了。最后，换用kcptun后看youtube时connection speed只能达到fs能用时（大概这个月初finalspeed被针对，具体情况是下载任何东西都会随机断线）的1/10左右（虽然消耗的带宽实际上基本一样），看高清成了奢望，我猜可能也与此有关。 请求作者确认一下，这是个bug还是个feature，抑或本人网络环境导致的独特问题？

编辑：附上一组SNMP数据 KCP SNMP: {BytesSent:708595 BytesReceived:539190211 MaxConn:1 ActiveOpens:1 PassiveOpens:0 CurrEstab:1 InErrs:0 InCsumErrors:263 InSegs:837484 OutSegs:41973 OutBytes:31680971 RetransSegs:872 FastRetransSegs:11 EarlyRetransSegs:29 LostSegs:832 RepeatSegs:83736 FECRecovered:14296 FECErrs:0 FECSegs:188452}

[xtaci]

很有趣，你可以贴一下你的cpu/mem等硬件配置

[palxex]

2012版mac mini，CPU是2.5G的五代i5，看了下支持aes-ni（所以crypt=none也提升不了速度），内存是16G 1600Mhz DDR3。 另外看来这确实是我碰到的独特问题了吗？您那边是直接提升了应用的网络速度？

[xtaci]

这个问题看上去是由于进程调度的不均匀导致的 ，你可以尝试启动的时候，限制client的进程数 GOMAXPROCS=1 ./client_darwin....... 另外，注意观察CPU的占用率，可以试试在两端加入-dscp 46参数，我这里一切正常的，立即能反映到app.

[palxex]

可是OSX上dscp的setsockopt看起来不起作用啊。。。不管了，换上这组参数测了下，结果貌似更极端，常规下载完全停止，直接从0%蹦到100%了。 然后我想是不是测试文件的问题，于是换了几个比较大的测试文件。这次换的文件都超过100M，结果看起来就变成了：app开始就停那等着，然后突然增加约16MB，然后又不动了，然后再突然增加约16MB。。。直到下完。看起来昨天的测试是因为文件太小（只有10MB)，16M的缓冲直接到头了。 问下这个16M的缓冲块是代码里写死的么？

[xtaci]

确实是有个16MB的缓冲区设定，这是单流最大内存消耗的一个限制，和这个行为没有直接关系。

我想知道的是，你带宽是多少，以及丢包率

[xtaci]

然应用程序以为速度只有这么慢，但其实那些占掉的带宽都在kcptun缓冲中。

这个问题是因为有丢包 比如1到100号包，第一号包丢了，必须等到1号包到位，才能传给app. 我猜测你的网络丢包应该很严重。

最后，换用kcptun后看youtube时connection speed只能达到fs能用时（大概这个月初finalspeed被针对，具体情况是下载任何东西都会随机断线）的1/10左右（虽然消耗的带宽实际上基本一样）

fs是用的tcp头部发送的，ISP对tcp和udp是区分对待的，tcp更优待。 udp的实际丢包率远高于tcp，尤其是电信，30％～50%的udp丢包是常事。但缺点是tcp容易被RST掐断。

[palxex]

Sorry 回复晚了。 哦，忘记提了，联通网络，上下行带宽是2Mbps/20Mbps。丢包率如果看ping的话，其实很低，大概20个包丢一个——以前用电信时确实高。另外fs我平时是用udp的，这次出了问题后，切到它的tcp（记得有人分析过是个自己写的rudp）也同样会随机断线，所以只能停止使用了。 用iperf3测了下，tcp模式可以顺利完成测试，udp模式压根测不过。看来可以确定是我网络的问题了，多谢您的分析。

[xtaci]

继续降低rcvwnd

[palxex]

rcvwnd 512及以上：curl显示速度约100k，kcptun client 1.4M（从istatsmenu里看） rcvwnd 256：curl速度约100k，kcptun client 900k-1.2M rcvwnd 128：curl速度约100k，kcptun client ~500k。 rcvwnd 64: curl速度约100k, kcptun client 200k-300k。

[wxyzh]

我这边也会断线 ，用curl测试kcp承载的ss，每两分钟测试一次。目前测试了约25小时，出现了47次连接失败。 haproxy 运行大概23小时，inter 3s rise 10 fall 3检测到直连的ss累计断线13分钟左右

[palxex]

我这边倒不是断线，而是如作者分析因为udp丢包过于严重性能不行。刚查了下用kcptun替换finalspeed这两天带宽消耗暴增了40倍以上，达到了每天100GB，这每月1T也撑不住啊。看来还是考虑在finalspeed上小改改看能不能骗过墙吧。。。

[xtaci]

不看视频就没事，小水管就是要省着用。

[xtaci]

@palxex 这个问题今天偶然发现，可能问题出在协议上，很快会有fix!

1%...2%...3%然后biu的一下就100%了这样

这个问题

[palxex]

使用0725测试版，fast2模式其他默认进行了测试，还是kcptun+SS+curl socks5，测试文件为vbox 5.0.26安装dmg。结果仍然是curl显示速度与kcptun存在很大差异，不过不再存在之前测得的每16M缓存现象，而是直接从10%左右（8M）蹦到了100%（85M）。估计还是udp丢包率太高的原因。

[xtaci]

@palxex 已经放到了release了， kcp原版已改。

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

[palxex]

这是重新下载正式版后的再次测试：https://asciinema.org/a/86nabuvc3qr4ki9r73bk24a6s 现在的情况更像一开始的描述，不再是每16M app得到一次更新，而是kcptun传输完后一次发给app。

[xtaci]

嗯，这个问题比较棘手，你可以考虑切换一下net.ipv4.tcp_congestion_control = vegas这种延迟敏感的算法来试试。

[palxex]

谢谢，不过试过后情况没啥改观。现在的网络环境下面也许我应该放弃用udp承载tcp的尝试了。不过再有新版本我还会来测试的。