Kcptun: 回馈，简易调节法，有需要看过来。

Created on 5 Oct 2016 · 19Comments · Source: xtaci/kcptun

题外话后面说，直奔主题，kcptun其实很容易使用，抓住两个重点就行。

一，窗口大小
二，使用前向纠错，或者不使用前向纠错

说一之前，需要做的是，明确下自身宽带的下载以及上传带宽，比如下载10M上传3M，确定下载没啥好说的，可能确定上传有点困惑，简单粗暴的办法，用百度云上传大文件，观察稳定后的上传速率，八九不离十，还不放心可以用一些测速软件一起辅助观察确定。

**接着说正题一，窗口大小的设定。**

1，如果你的宽带带宽小于VPS的带宽

（一般都是这个情况，比如家里10M，vps100M，那么调节的时候以客户端为主，服务端先设定一个固定的值比如1024 1024。接着集中精力调节客户端（wiki上有具体的计算方法，只要明白宗旨就是你想要达到一个什么样的带宽，一般以接近自身的带宽为理想），如果觉得wiki晦涩难懂，没关系，先随便设定比如256 85，（这里需要弄明白kcptun服务端和客户端的关系，客户端以rcvwnd也就是接收为主，这里设定256，说大白话就是你想要客户端以多大的带宽去接收服务端发来的数据，而确定客户端的发送窗口sndwnd相对来说就简单点，一般都是一个固定比例比如上传是下载的1/3等等，确定了接收窗口之后大概除一除也就OK了，这里设定85），设定好之后就要去验证所设定的窗口是否符合你的实际情况，以前看的多是用iperf去验证，我个人觉得对小白来说太麻烦了点，这里还是给出简单粗暴的办法，一般你的VPS主页都会有一些大文件提供给用户用于测试（比如500m.test等等，要的就是它，这里需要注意的是选择你VPS所在地点的测试文件，比如洛杉矶，不要你VPS是洛杉矶的，你去下达拉斯的文件。）下载之前确定好你的kcptun已经正常连接，然后开始下载，观察速度，大多数人这里就蒙了转不过弯，比如看到下载是500kb/s，然后就觉得窗口小了心想怎么着也该1m/s呀，然后开始折腾窗口去了，改大，过一会发觉怎么改大了还是500kb/s呀，想不通了，接着琢磨着上来发帖求助，别着急，你看错地方了，不是看软件里面下载速度，去你的路由里边看，这个都应该会吧，观察WAN口的下载，这时发现比如正好是10M的速度，好，改小窗口，比如210 70，再去下载观察，比如这下WAN口下载速率达不到10M了，变成8M，OK，再去改大窗口，逐步增大反复实践，最终我个人的经验是略微小于实际可以达到的速率为佳，比如9M或者9.几M，超过了路由就把你的包给丢了，白白浪费。慢着，可能有疑问，那软件里边下载怎么还是500kb/s呀，那失踪的500kb/s哪里去了？这个等会再说，先正确学会简单的测试办法，这个才是主要的，回头进阶，那就手到擒来了。

2，你的实际带宽大于VPS的带宽

比如家里200M,VPS100M，一样的，还是已调节客户端为主，但区别就是以你想要达到的带宽为主，比如调节到50M，而不是你实际的带宽200M或者100M，因为多数VPS是共享带宽，你一人占满了，别人没法活了，接着VPS老板要来找你麻烦不是。独服另当别论，一般100M独享，那就占满，不用白不用。方法和上边雷同，经过多次实践，基本都能达到你要想要的。

说二之前补充下遗漏，关于下载文件的选择，因为这个基本等同于你直接从VPS的拉文件的效果，有代表性并且简单，不排除特殊形况，比如VPS挂羊头卖狗肉，我觉得那种概率不高，至少地点上不会太大出入。那如果你的VPS没那个文件怎么办，也没事，找找你VPS同样地点的其他家VPS主页上的文件，还不放心就先用你的VPS直接wget去拉拉看，看能跑到多少速度，选速度大的。

**接着说二，使用前向纠错，还是不使用前向纠错。**

是不是糊里糊涂，说不定前向和向前还搞错，没关系，我也糊里糊涂。但能让你不糊涂的是，失踪的500kb/s要问它拿。这里要引入两个重要的参数datashard和parityshard，默认是10和3。按照wiki的指引，有个计算公式（max_bandwidth_fec = max_bandwidth * (10 + 3) /10 = 1.3*max_bandwidth ＝ 1.3 * 25Mbps = 32.5Mbps）其他的暂时不去管它，明白这个1.3倍是怎么计算出来的就行，回头设定别的数值时要会算大概对带宽带来多大的影响，这是一个固定的数值，以计算公式为例，32.5M的带宽其中就有7.5M要被它占去，那么如果10M就要被占去2.3M，也就是说下载中，10M的带宽实际反映出来的带宽约7M，也就是上面胡乱举例的只能达到500kb/s，戏曰失踪了500kb/s。到这，别忙着说坑爹，这失踪的并不是白白失踪，后面再聊，现在只要明白，这两个参数所带来的影响，如果不想被它影响，怎么办，凉拌，设置0 0，两个蛋，那就是没影响，那这是不是说10M可以完全找回来，不是，因为还有其他开销，这个开销也许需要深究KCP去了，没那必要了，愉快的使用kcptun才是包括我在内的多数人的诉求不是。

明白了上面两点，基本可以简单快速的去部署适合自己的kcptun了，下面再聊聊一些个人使用中体会。

测试窗口不说了，重复劳动，没什么难度，说说前向纠错。
因为正好有三个不同地点的VPS，以及经过不断的实践，所以虽然不懂神马技术，但经验是不缺的，希望能帮助初用者少走弯路以及借此感谢作者和其他热心人士的支持。感谢！

在使用前向纠错的问题上，不能一概而论，没有对错。一定要结合自己的VPS来说，假设你的带宽富余比如100M，恰巧你所选的VPS线路又相对比较稳定，ping值丢包值不管什么时候都大概在一定的范围内，那么我建议你使用前向纠错，因为虽然付出了一定的带宽作为代价，但得到的更加稳定，可以在一定范围内把丢了的包给找回来（和前面两个参数设定相关，比如30%以内的丢包）而且有了KCP的加持能得到更快的响应速度（相关可去KCP的主页了解），不要小看稳定，我巴不得稳定呢，就不用没事瞎折腾了不是。

带宽小的呢，比如我，可能会难以取舍，但好在我不只有一台vps，所以我选择了其中比较符合条件的一台使用前向纠错作为二号选手，随时待命以免一号受伤。

这一号选手，是我最喜欢的付出的代价也最高，但也是让我最不省心的，九成的时间相当抢眼，ping70ms和我这ping阿里云DNS差不多，不需要使用任何玩意都够high，但有个毛病，好的东西追求者就多，以至于有时到了高峰时段爆ping能爆到200ms，虽然对下载没什么影响，不加外挂依然跑满我的带宽，但。。。youtube就够呛，虽然也只是秒开和不秒开的区别，可是我依然觉得不爽，因为我的使用情况基本就是奔着youtube去的，这台我就没有使用前向纠错，而是在网络良好的时段测出最大化利用带宽的窗口后使用，这里也是个取舍，到底应该是在通畅时段或者拥挤时段去测这个窗口，这个我个人建议是结合你VPS的月流量看待问题，如果NT甚至无限的，流量用不完的，那么拥挤的时候去测，这时可以马上得出的结论是，最困难的时候都过了，那么剩下的都是好日子，浪费点流量不算神马事。

流量紧张的，那一定要畅通的时候去测，理由和前面相反。到这可能有人要问，那你这样一号选手畅通时候设定好了，那拥挤的时候受不受影响，那肯定受影响，看过wiki肯定明白ping值是设定带宽的先决条件之一，70ms和200ms差太多了，带来的直接后果就是拥挤的时候下载速度减半，但前面说了我的诉求主要是youtube，长时间的观察其实youtube并不是时时刻刻需要要占满带宽，而是一会5M一会3M的间断请求，实际也确实是这样，畅通时13000的连接速率到了拥挤时变成7000左右，乍看天差地别，但实际感受没什么区别，依然秒开。感觉好像不靠谱，但看过KCP作者的描述或许能够释然，他把TCP形容成大运河，KCP形容成激流，也许youtube需要的正是激流。如果你需要的是运河，那就不要像我这样设置。当然还有更好的办法，因为有luci-app-kcptun的出现，配置几套参数备用变成了简单事，需要时方便点一下就好，或者弄个定时任务神马的应该也可以实现，那就不是本文讨论的范畴了，八仙过海吧。

说到这，我想适合您的参数也该快速设置好了，该提醒您的是，这时把服务器端1024 1024变更为所测定好的客户端参数，反过来就好，这个不难理解，那边的发送就是这边的接收，虽然说两头参数设置不一致的话以小的为准，但还是加个保险，以免出现万一引起VPS提供商的注意以及影响他人使用。到了这，不打算精益求精的话，足够了愉快的使用了，更进阶的问题，已经有手动参数设置的讨论，可以去看看，特别是只有一台vps的情况下，更应该去看看，找找适合您的法子，我比较懒，如果我设置的参数在某些极少数的情况下失灵了，直接切换VPS，就不去深究到底是VPS线路出问题还是母鸡被D了这些问题，至于使用kcptun会不会被VPS提供商注意这些问题，对于我来说属于玄学，因为我无法控制，能力范围内我已经尽力去限制我的使用，而不是简单的两头1024了事，这样还不行，那还有啥办法不是。

再次感谢作者及热心人士，祝大家使用愉快。

FAQ PARAMS

Source

baggiogogo

👍15 🎉1

Most helpful comment

嗯，本科是通信工程

xtaci on 7 Oct 2016

👍15 🎉1

All 19 comments

看了你写的，有点感想：

知识的传递远胜于工具本身，KCP提供了一个极简的可靠传输的实现，并点出了传输中的关键问题，要感谢@skywind3000。因为简单，所以生命力强。以此为基础，你甚至可以基于ICMP包做传输，当然TCP也不在话下，因为这是回归到通信的本质问题去思考。如果借这个项目，能让更多人明白到这些知识，并从另一个角度去看待TCP，并服务于实际的项目中，比如游戏，语音视频通信，是一件好事。

PS. 项目提供的参数，确实是需要根据实际情况来调整，这里我还是推荐通过分析SNMP，这是最准确的方式。

xtaci on 5 Oct 2016

以前都是用现成的路由固件，好多事情后知后觉，对于项目以及作者更是知之甚少，后来随着慢慢深入，了解了一些，有些连道谢都没机会了，更别提出点力了，很遗憾。
站在使用者、受益者的角度，受能力限制无法更加专业的为项目提供帮助，能做的只有反馈一些问题或者分享一些经验，算略尽绵薄之力吧，尽量不只是简单的索取。

baggiogogo on 6 Oct 2016

@xtaci 大哥是学通信工程的前辈吗？

JimLee1996 on 6 Oct 2016

嗯，本科是通信工程

xtaci on 7 Oct 2016

👍15 🎉1

有意思，赞一个，其实窗口大小等同于 tcp 的 sndbuf, rcvbuf，决定最大可同时发送的数据：
最大可用带宽 = min(发送窗口大小, 远端接收窗口大小) / rtt

kcp默认使用比较保守的类tcp流控，启用快速模式后，流控关闭。本身kcp面向流速，这个影响还算好，
谁有精力可以开发一个面向流量的版本，比如，引入速率控制，即接收端在ack包里向发送端报告，自己前段时间成功接收数据的每秒KB数是多少，发送端收集到以后，通过短时平滑，算出一个短时平均速率v，然后控制自己的cwnd，以p = v * k 的速度进行发送（k > 1.0 ，比如取1.2），然后用上面的公式，根据 p 和 rtt，计算出当前可用 cwnd 来。

有空可以给 kcp 加一个接口，可以让各种流控方案轻松的插入到kcp里，比如外面继承实现一个 congestion control 类，然后添加给 kcp，kcp就可以覆盖原有 cwnd计算方式，然后基类 congestion control 里面有一些基本事件，kcp可以在特定的时间点调用，比如收到ack，收到数据包了，丢包了，重发了，之类的。

skywind3000 on 7 Oct 2016

一个估计从专业角度看通篇胡说八道的帖子把二位都引来了，惶恐，不过也了了我的小小心愿。🙏

baggiogogo on 7 Oct 2016

但是一台VPS并不是只为一个固定网络环境设备提供代理，家里调好了，单位的网络可能又不行了。
最大问题是手机使用有点麻烦，在wifi 下很好用，但换到3G/4G网络下，常常就断流需要重新连接，有时可能还需要重启服务。所以为了保证手机一直在线，只好关闭kcp在需要时才打开。
KCP的加速效果确实的很好，但与调优相比，更希望能在不同网络环境下连接的稳定。

triaqu on 8 Oct 2016

@xtaci 请问我用路由器openwrt 运行ss，然后局域网的树莓派运行kcptun client，调校好了，客户端参数为sndwnd 256 rcv wnd 900 dscp 46 datashard 10 parityshard 3，然后用iphone 运行测速，以及youtube，可以达到满速，看树莓派上的网络loading，也确实很平滑稳定在23Mbps 左右，可是用另外一个android 手机Nexus 6P跑的时候却发现，非常不平滑，最高速度也只有6－10Mbps，这又是什么问题？有没有什么思路可以查找原因？