Kcptun: 手动参数设定探讨

[xtaci]

策略1： 通过超时重传＋快速重传，响应速度优先（最大化响应时间）：
-mode manual -nodelay 1 -resend 2 -nc 1 -interval 20

策略2： 仅仅通过超时重传, 带宽效率优先（有效载比优先)。
-mode manual -nodelay 1 -resend 0 -nc 1 -interval 40 或
-mode manual -nodelay 0 -resend 0 -nc 1 -interval 20

策略3： 尽可能通过FEC纠删，最大化传输速度（推荐）：
-mode fast -datashard 5 -parityshard 5

[dolphinpaopao]

能否手动设定开或者关，增加一个统计一定时间内的丢包率来自动调整策略的功能。统计的时间长短，触发调整策略的丢包率，详细策略均可手动设置。这个有实现的可能行么？

[testcaoy7]

@dolphinpaopao 这就是Congestion Control，实现是可能的，但是会很复杂

[dolphinpaopao]

@testcaoy7 实现很复杂那就不要了，可能会影响稳定性，想要的是简洁稳定高效。目前这些手动参数设置挺好的。满足不同需求。

[kmahyyg]

stability is what we need most,the second is speed.
i prefer Strategy 2.
also, can you add more information about the arguments we can modify manually to this repo's wiki?

[xtaci]

策略1对于网页访问这种突发性请求，查询较为友好。
策略3对于视频流这种较为友好。

策略2较为中庸。

[koolwiki]

刚测试了一下，用策略2： -nodelay 1 -resend 0 -nc 1 -interval 40 的参数比fast2将近节约1/4的流量
策略2的另外一种 -nodelay 0 -resend 0 -nc 1 -interval 20会更省流量吗？

[xtaci]

说的很对，一切都是平衡

_响应速度, 传输带宽，高载荷比_ 三者是跷跷板。

比如响应速度，一个数据包发出后，判断对方是否接收到了，是等待一个RTT时间没有收到ACK就重发，还是说要再等等看。 真实的情况始终未知，-nodelay 1就是不多等了，结果ACK晚到了一点点，就多发包了; -nodelay 0就是已经等了RTT后，再等等看，那么如果再等了还等不到，这个时间就浪费了，响应时间就慢了，整体速度也拖慢了。 乐观主义还是悲观主义？

根据香农定理:

（1）信道容量由带宽及信噪比决定，增大带宽、提高信噪比可以增大信道容量；
（2）在要求的信道容量一定的情况下，提高信噪比可以降低带宽的需求，增加带宽可以降低信噪比的需求；
（3）香农公式给出了信道容量的极限，也就是说，实际无线制式中单信道容量不可能超过该极限，只能尽量接近该极限。在卷积编码条件下，实际信道容量离香农极限还差3dB；在Turbo编码的条件下，接近了香农极限。

(1) 可以理解为，高丢包率＝＝高噪音
(2) 可以理解为，固定丢包率下增大发送带宽 == 更高的传输成功率(比如通过FEC)；固定传输带宽下降低丢包率== 更高的传输成功率(比如通过DSCP)

策略3也可以理解为，我假定我的纠错包能全部把丢失的包还原出来，每5个包，2个纠错包， 小于 2/7的_均匀丢包率_下( <28%)，必定能还原出来，完全不需要重传。

策略1可以理解为, 我非常悲观的判断包一旦超过RTT，大概率丢失了，通过一切手段尽快重新发送。

[xtaci]

一组我的自用参数:

-mode manual -nodelay 0 -resend 0 -nc 1 -interval 40 -nocomp -dscp 46 -mtu 1400 -crypt aes-128 -datashard 70 -parityshard 30

server
-mode manual -nodelay 0 -resend 0 -nc 1 -interval 40 -dscp 46 -nocomp -mtu 1400 -crypt aes-128 -datashard 70 -parityshard 30

[dolphinpaopao]

@xtaci 你好，请问一下使用环境是怎样的，服务端是在vps上么？服务器的延迟丢包和本地带宽如何？

[xtaci]

200Mbps 联通, 日本vultr, ping 136ms, UDP丢包30%左右

[dolphinpaopao]

@xtaci ，另外再请教一下这样的环境下服务器的实际流量超出有效流量多少呢？kcptun的传输带宽能达到多少？

[RoyLi-Pvt]

200Mbps 联通 作者帝都啊 我天津联通100M 通过iperf测试vultr LA丢包率非常之低 只有0.043%
不知道晚上会不会恶化
另外目前用Fast3模式 看视频会断流 加载网页也是 用一段时间后会突然完全没流量 过一段时间就会恢复

[xtaci]

@TMily 那个是假的，流量上去了就开始丢包了。

[RoyLi-Pvt]

@xtaci 那就是需要长时间测试？ 我是设置成100M带宽测试60秒 要是设置成200M丢包就变成39%了 但是我家本身是100M的 最多能跑到120M

[xtaci]

从未断流

[RoyLi-Pvt]

@xtaci 嗯 断流的问题我今晚回去再调调参数 我先试试120M 发600秒看看丢包率

[RoyLi-Pvt]

@xtaci 刚刚试了试发600秒 丢包率还是很低 这回试试发9000秒 下班回家正好看结果
另外就是iperf 的测试结果有个警告信息：WARNING: did not receive ack of last datagram after 10 tries.

[xtaci]

killall -SIGUSR1 client_xxxxxx server_xxxxx 才能看到SNMP

[RoyLi-Pvt]

额 我测试用的是ipref 没看KCP的信息~ 因为只是测丢包率嘛 这两个会有很大差别么

[testcaoy7]

@xtaci 我也遇到过断流，主要发生在放映YouTube视频的时候，断流时网页浏览一切正常，就是视频流传不过来

[RoyLi-Pvt]

@testcaoy7 我断流时是全部断了 去看console的话应该是有sessionxxxxxxxxx之类的报错

[kmahyyg]

@xtaci 从我开始使用kcptun到现在，无论哪个版本，我都遇到了和 @TMily 一样的问题，试过fast/fast2模式，加载网页还是看ytb都会断流，不过目前适当调大wnd值以后好了一点点，但是经常yamux报i/o deadline reached.

[testcaoy7]

@TMily @kmahyyg 试着增加前向纠错的比例，我加大后断流很少发生了，因此，我也推荐3号策略

[RoyLi-Pvt]

@testcaoy7 嗯 回家试试新参数 这回按照作者大大的调的都是联通

[xtaci]

多看下我上面对_香农定理_的介绍，会加深认识。

[koolwiki]

@testcaoy7 请问3号策略流量消耗大概几倍啊？

[xtaci]

解释一下另一个问题:
-datashard 70 -parityshard 30 和 -datashard 7 -parityshard 3 有没有区别

回答:

1. 如果完全随机丢包（在时域上均匀分布） ，这两者没有差别，完全等价。
2. 如果在时域上不均匀，丢包一会儿有一会儿没有，这两者就有差别。 70/30的配置更又可能把数据纠错出来， 7/3的配置很容易全丢无法恢复。

选择在70+30的这个大区间整体丢包30%， 还是在 7+3的这个小区间整体丢包30%？ 只有试试。

[testcaoy7]

@xtaci fast.com和speedtest.net之间的成绩差异很大，改FEC的参数为70/30后，对speedtest.net的成绩有很大帮助，fast.com的成绩也有所提升

[testcaoy7]

@hbxntsxw 流量消耗和网络质量有很大关系，每个人都不一样，得自己试，策略3是通过FEC减少重传的流量消耗，但FEC本身也有流量开销，孰优孰劣，得自己在自己的网络环境下实地测试

[wxyzh]

刚用iperf3 测试了下，用25Mpbs的带宽测试，几乎不丢包，一旦超过基本全部丢包

[kmahyyg]

好吧，看样子得去增加前项纠错了。另：求丰富下repo的wiki

[sosmygirl]

@xtaci 你的自用参数支不支持shadowsocks-android??

[xtaci]

参数一致应该可以，没试过

[dolphinpaopao]

@xtaci 刚刚在我这里观察到了一个现象
server：./server -l :8388 -t 192.168.1.1:8080 -crypt salsa20 -key test -mtu 1400 -sndwnd 1024 -rcvwnd 1024 -mode fast -dscp 46 -datashard 9 -parityshard 3 -nocomp
两端版本均为最新的20160820，仅更改-datashard * -parityshard *这对参数
当为7/3时，YouTube视频缓冲速度很快显示的视频链接速度也很快达到1W+，fast.com测试的速度15Mb；
当为70/30时，YouTube视频缓冲很慢显示的连接速度只有3K，fast.com测试的速度却有很大提升达到了26Mb。
用（8/3、80/30），（6/3、60/30）多对参数测试了很多次，均为相同的现象，请问一下这是什么原因，有办法改善么？谢谢。

[wxyzh]

估计是丢包率太高，降低wnd，或者用iperf测试下在不同带宽下的丢包情况

dolphinpaopao [email protected]于2016年8月20日周六 20:39写道：

@xtaci https://github.com/xtaci 刚刚在我这里观察到了一个现象
server：./server -l :8388 -t 192.168.1.1:8080 -crypt salsa20 -key test
-mtu 1400 -sndwnd 1024 -rcvwnd 1024 -mode fast -dscp 46 -datashard 9
-parityshard 3 -nocomp
两端版本均为最新的20160820，仅更改-datashard * -parityshard *这对参数
当为7/3时，YouTube视频缓冲速度很快显示的视频链接速度也很快达到1W+，fast.com测试的速度15Mb；
当为70/30是，YouTube视频缓冲很慢显示的连接速度只有3K，fast.com测试的速度却有很大提升达到了26Mb。
用（8/3、80/30），（6/3、60/30）多对参数测试了很多次，均为相同的现象，请问一下这是什么原因，有办法改善么？谢谢。

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/xtaci/kcptun/issues/137#issuecomment-241197996, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ASpHqdZ808-suxcGsp97uP456PQ_GepPks5qhvV5gaJpZM4JnVaw
.

[xtaci]

https://github.com/hashicorp/yamux/pull/39

[xtaci]

@dolphinpaopao 你可以用fast2再试试，70+30慢是因为数据量太少根本不够70+30个数据包来纠错，y2b可能会先尝试少量数据，然后再慢慢加大发送量，而7+3很快就能纠错了。而fast测速的时候，一开始就以非常大量的数据发送，一次就达到了初始的70+30个数据包。

FEC对于大文件传输，比如用卫星传输8K电影到各个影院是非常合适的，对应fast.com测速。
对于突发性，交互性，试探性的，快速重传更合适，对应网页。
对于y2b这种，只要过了最初的70+30的点，会慢慢快起来。

如果有要快又要突发性好，那就只能以浪费带宽为代价了。

[kmahyyg]

@xtaci 建议搬运下skywin3000/kcp的repo的readme，你的wiki没有，大部分关键信息都在readme里，然而一眼看上去，小白很看不懂你说的，skywin3000他的readme基本可以解决这的大部分问题。

[dolphinpaopao]

@xtaci @wxyzh 感谢解答，我降低窗口，比例不变但减少数据包个数，目前表现较为均衡了。

[channingbox]

小白有问题要问 shadowsocks 已经在服务器端设立了加密 KCPTUN 就不用加密了吧 加密一个就行了吧

[xtaci]

kcptun加密是必须的，否则等于裸奔。

[channingbox]

嗯 明白了 谢谢大师能回复 我想到 我现在在服务器端用脚本 安装的 实在是不会 又不想求助别人 https://github.com/clangcn/kcp-server/blob/master/install-kcptun.sh

[koolwiki]

@xtaci 目前来看，兼顾安全性和效率属salsa20的加密方法最好吗？或者你最推荐什么加密方法？

[xtaci]

x86平台推荐默认的aes(AES-256)，如果性能不行，考虑aes192, aes128。
其他平台可以考虑blowfish, cast5, twofish
如果性能还是不行，考虑tea, salsa20

另外，如果承载的数据本身已经加密，salsa20足以。

[ragnaroks]

@xtaci 使用 -crypt none 等于裸奔?kcptun承载的不是被ss加密后的流量?

[xtaci]

@ragnaroks 头部加密的唯一办法目前是通过 -crypt， 否则很容易知道你在用kcp协议。

[ppgl1]

受益于作者的软件，非常感谢；用了很久，以前一直是瞎用，也不知道可以打印出调试信息，了解之后一看，流量利用率50%都不到，决定认真调一下，过程走了很多弯路，希望与诸位分享，网络盲+linux盲，错误多多包涵。

环境是北京联通线路50M，上行是6.5M，vps是9.9的板瓦工，ping150~200。

首先是测带宽，iperf测的上行6.5M能跑满，但下行超过16M的全丢，我以为就只能用16M了，但其实真跑起来是能到50M的，也不知道是iperf的毛病还是网络针对这些测试程序有所识别和欺骗，所以调收发窗口还是像说明里写的手动逐步加大，iperf可能不准。

fastretrans earlyretrans大于lost很多的时候：建议多等待一下，重传多了未必比等待更快，适当调高interval可以达到目的，但同时就增加了ping；开nodelay丢包会增多，我这里10%增到20%+，换来的响应速度感觉不太值；没开nodelay的另一个重要原因是板瓦工闲置一会再访问的时候一般都会卡几秒，是联通的原因还是超售需要等服务器资源我也不知道，反正这时候包基本全丢产生大量重传，不开nodelay的话，几秒后网页还能打开，开的话基本没反应，只能几秒后自己按刷新；

fec我无论怎么设置，5/2这种小数的还是50/20大数的，recovered比例都太小，还是靠重传靠谱些，就放弃了

最终设置如下--crypt salsa20 --mode manual --nodelay 0 --interval 50 --resend 2 --nc 1 --mtu 1350 --sndwnd 128 --rcvwnd 512 --datashard 80 --parityshard 5 --dscp 46

上面配置丢包最高20%一般10%，fec6%；计算带宽512/0.15/1024x8x1.2x1.06≈35Mbps 还有富余，实际情况也符合计算结果

附一组数据，忙时闲时都有覆盖，丢包大概10%，有效流量大概80%，除了卡那几秒没办法其余很满意
KCP SNMP:&{BytesSent:5499611172 BytesReceived:14360715 MaxConn:175 ActiveOpens:0 PassiveOpens:346 CurrEstab:173 InErrs:0 InCsumErrors:123782 InSegs:312480 OutSegs:5754505 OutBytes:7007375273 RetransSegs:640017 FastRetransSegs:181370 EarlyRetransSegs:218159 LostSegs:240488 RepeatSegs:2 FECRecovered:126 FECErrs:0 FECSegs:17524}

同时有几个疑问：incsumerr是什么？fast跟early有什么区别？recovered是恢复的次数还是包数，有人恢复效率高吗？repeat是指超过物理带宽的重传？
又想起一个不知道算不算bug，如果写命令行的话那四个隐藏参数要紧跟mode，如果中间夹了别的参数会不起效果

[xtaci]

@ppgl1

1. incsumerr = In checksum error ，和/proc/net/snmp的命名一致。这个几乎100%是由于kcp-go的keepalive数据包产生的(完全随机数据)
2. fast是快速重传，early retransmit是在数据包数量不足以满足快速重传的时候，立即重发。建议google
3. recovered是恢复的数据包个数

测试很有代表性，总之还是那句话，带宽利用率和响应速度无法同时满足。

[SOE-121]

一直在思考为什么kcptun比finalspeed慢一点，或许是花样搞太多了，不如简单粗暴。
向前纠错不理想啊，网络好的时候纠错包浪费带宽，网络不好的时候丢包频率往往和预计的不一样。
nodelay我怎么试都是反效果。。
我的参数
服务器:
--sndwnd 800 --rcvwnd 80 --nocomp --mode manual --interval 1 --datashard 4 --parityshard 0 --nc 1 --resend 1
客户端:
--sndwnd 80 --rcvwnd 800 --nocomp --mode manual --interval 1 --datashard 4 --parityshard 0 --nc 1 --resend 1
俺的的策略就是关闭向前纠错，均匀的多倍发包，然后快速重传
interval 1 表示每秒调用1000次，每次发送4个包，那么每秒就发送4000个数据包
每个包1.3k，1.3 x 4000 ≈ 5m，就是以40Mbps发包
然后我的搬瓦工RTT延迟0.2秒
4000 x 0.2 = 800 最大发送窗口，家庭宽带上传只有下行十分之一，那么服务器最大接收窗口 = 80
服务器和客户端的窗口刚好对调
看youtube有效载荷比1/4，也就是10Mbps下载1/3

[xtaci]

慢一点的原因是udp本来就是二等公民，丢包率比tcp高10倍

[baggiogogo]

@xtaci 在不用kcptun的情况，无论测速还是下载，线路本身可以跑满下载带宽。差别是看油管时不使用kcptun没有使用kcptun畅快。
请教下这种情况下参数设置思路，感谢。

[xtaci]

你可以把这个问题想成全国的高速公路收费站， 某些收费站很宽大，基本不堵塞，另外一些就堵几公里长。 你下载跑满带宽，只不过是根本就没有碰到收费站而已，还在市内。 @baggiogogo

[xtaci]

https://github.com/xtaci/kcptun/issues/218 这个mtu的issue很有意思

[xtaci]

5:3 FECRecovered:539 FECErrs:0 FECSegs:13960

5:4 FECRecovered:1896 FECErrs:0 FECSegs:50221

5:5 FECRecovered:15697 FECErrs:0 FECSegs:17089

dataShard/parityShard的不同比值在丢包率为34.6% 下的还原率关系，可以看出，在parity越过了丢包率这个值后，数据还原率爆发性增长。

[peakvision]

3/(5+3)已经超过链路丢包率，向前纠错量已经大于丢包损失率，理论上降低重传，此后爆发的fes_recovered对传输有实质改善吗？

[xtaci]

需要观察SNMP确保FECRecovered是否真的接近FECSegs， 如果是，一定会有质的飞跃。

你看到的ping丢包率，不一定是实际丢包率，观察SNMP是最准确的。

[peakvision]

@xtaci killall -SIGUSR1哪些比值计算丢包呢，单客户端情况下用客户端InSeg/服务器的OutSeg去计算服务器到客户端的丢包率吗？我的客户端运行在win上。

@wxyzh 请问你iperf3参数是什么，我用-c -u -t 10 -R，无论-b从10M到50M，测试结果都好像不正常。

[xtaci]

统计意义上，可以用(1- 接收端的InSeg ／ 发送端的OutSeg) 约等于生命周期的丢包率。
LostSeg是发送端自己认为自己超时丢包的，不准确。
FECRecovered / FECSegs 一定要接近1

[peakvision]

呃，我的客户端是在windows上，看来打印不出来。

[geerda123]

@peakvision 请问iperf参数是多少，我也想知道

[peakvision]

@geerda123
server:
iperf3 -s -f M -V

client:
iperf3 -c server_ip -f M -V -R -u -t 10 -b 40M -l 800 -w 8192

我测试的时候client是windows版的。vps带宽是100mbit，基本上我认为调整上面的-l即可，但我的bin执行的时候经常报错，而且结果感觉不准。

[geerda123]

不用锁端口吗，-p等。-V 绑定一个IPv6地址。好像没必要。有大神告诉你吗，我怕测试结果不是通过kcptun

2016-12-04 21:15 GMT+08:00 peakvision [e-mail]:

@geerda123 https://github.com/geerda123
server:
iperf3 -s -f M -V

client:
iperf3 -c -f M -V -R -u -t 10 -b 40M -l 800 -w 8192

我测试的时候client是windows版的。vps带宽是100mbit，基本上我认为调整上面的-l即可，
但我的bin执行的时候经常报错，而且结果感觉不准。

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

[linhua55]

@peakvision

server:
iperf3 -s -f M -V

client:
iperf3 -c server_ip -f M -V -R -u -t 10 -b 40M -l 800 -w 8192

应该去掉client端命令中的-u，不是UDP模式，应该是TCP模式

[peakvision]

@linhua55 测试是为了考察kcptun的理论速度，所以跟随kcptun测udp。

[linhua55]

@peakvision
谢谢。 唉，一测，40M UDP丢包率竟然高达92%， 5M 30%， 10M 65%

[peakvision]

@linhua55 你的客户端运行在什么平台上？
我测出来也是udp丢得奇高，感觉与kcptun实际效果出入很大。

[linhua55]

@peakvision
可以看一下这个issue https://github.com/esnet/iperf/issues/386
运行在 Windows下的 Archlinux虚拟机上，用vagrant软件来管理这个虚拟机，非常方便。参数上，干脆舍弃FEC了。
有个主意： 创建一个 可方便比较的文件 放在服务器上，用UDP传输这个文件，同时记录时间点，然后在客户端比较原始文件和接受到的这个文件的差异 来分析丢包率。和丢包的特征（如丢包的分布曲线） 多测几次，然后提取出共同的特征来 建模 生成这些参数

现在是用：iftop工具，具体命令是sudo iftop -B来查看占用带宽大小 是否符合 iperf3 测得的。 和 Shadowsocks客户端中，显示日志中的速度曲线来调参数的。 在显示的带宽稳定的情况下，曲线中的低谷 表示 有丢包，或包不能被FEC还原。 高谷表示 没有丢包或包成功被FEC还原。

小的FEC参数，如7/3，高谷会处于较低速度，因为就算连着几个包被还原，总体短时流量(7+7+...)也较小。而大的FEC参数 70/30，高谷会在较高的速度上，因为一旦有一个包 被还原，这个短时流量(70)是较大的。

[linhua55]

@peakvision
这个测得到丢包率是相对于服务器的带宽的，而服务器的带宽往往远大于自己的带宽，因此测得不准。

只有在服务器带宽和自己的带宽相等的情况下(或使用工具如tc，来限制服务器的带宽)，这里显示的丢包率才是准确的。

[peakvision]

@linhua55 因为加了iperf3加了-b去指定使用带宽，所以测不准的问题我也怀疑是iperf3的bug。

[chilejiang1024]

哪个参数是会影响小图片的接收的? 网页上的小图片都收不到....
就是各种用户头像 都是空的...

-crypt salsa20 -nocomp -datashard 90 -parityshard 10 -mtu 1400 -sndwnd 128 -rcvwnd 512 -dscp 46 -autoexpire 300 -keepalive 10 -mode fast

测试丢包率为 10%左右