题外话后面说,直奔主题,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.3max_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了事,这样还不行,那还有啥办法不是。

本文转载自GitHub再次感谢作者及热心人士,祝大家使用愉快。