Kcptun: 1025起的各个版本加速效果明显弱于1009(Early Retransmit)?

Created on 31 Oct 2016 · 30Comments · Source: xtaci/kcptun

使用kcptun已经有好几个月了，每个版本基本都会第一时间升级。
使用1009版本非常稳定，virmach加速效果不错Youtube有10000-20000Kbps
然而在使用相同配置的前提下，自从1025起的每一个版本，包括1025/1028/1031，加速效果都近似于无，Youtube只有600-800kbps。服务器端切换回1009后即刻恢复正常。

使用json配置：
server.json:
{
"listen": ":443",
"target": "127.0.0.1:8191",
"key": "ricky",
"crypt": "salsa20",
"mode": "manual",
"mtu": 1400,
"sndwnd": 2048,
"rcvwnd": 2048,
"datashard": 70,
"parityshard": 30,
"dscp": 46,
"nocomp": true,
"acknodelay": false,
"nodelay": 0,
"interval": 40,
"resend": 0,
"nc": 1,
"sockbuf": 4194304,
"keepalive": 10
}

不知道是否1025起的版本需要有什么参数设置的改变，为何突然就失去加速效果了呢？

PARAMS

Source

LiR1cky

All 30 comments

是的 1025开始去掉了early retransmit特性，这个特性和FEC有重复之处。
在相同的流量下，可以通过提升FEC来弥补，比如配置
"datashard": 5, "parityshard": 5,

xtaci on 31 Oct 2016

另外，你的配置"resend": 0, 改为2，否则一点快速重传都没有

xtaci on 31 Oct 2016

修改了以下参数后情况有所好转
"datashard": 5,
"parityshard": 5,
"resend": 2,

不过速度依旧不佳，只能勉强到2000-3000bps，能否推荐一组新版本下针对高丢包高延迟的参数配置？

LiR1cky on 31 Oct 2016

1025后的版本，看油管直播会经常出现断流几秒又重新连上，但看一般的视频速度明显比旧版快。
1009版本，可以一直正常观看。
按照 -datashard 5 -parityshard 5 配置也没有正常。

katosun2 on 31 Oct 2016

把MTU改小为512后效果不错，基本能达到7000K了。最近丢包严重，ping值也倍增～估计等网络状况恢复还得重新把MTU调回去

LiR1cky on 31 Oct 2016

可以试试resend : 1 或者关闭fec(0,0)，"nodelay": 1, 组合

xtaci on 31 Oct 2016

1009版配合ss，稳定使用中，升级过25，出现服务器连接不上的情况，重启后，可以用，然后又断了

hangaj on 31 Oct 2016

试下resend:1 理论上是等价的。

xtaci on 31 Oct 2016

昨天重启了一下客户端的OS，之后就用
"datashard": 5,
"parityshard": 5,
"resend": 2,
“mtu": 512,
效果基本等同于之前版本了，今晚抽时间再分别测试下resend：1，和另一组fec(0,0), nodelay:1的效果。

LiR1cky on 1 Nov 2016

嗯，很好，两类策略：一类依赖重传，可以调整 resend / nodelay, 二类依赖FEC，比如fec(5:5)

xtaci on 1 Nov 2016

👍1

https://github.com/xtaci/kcptun/issues/137

xtaci on 1 Nov 2016

断流情况很严重.真的

cnmade on 1 Nov 2016

@xtaci 如果断流是因为参数的原因,能不能预置默认优化的参数.我懒得自己调整参数,也不懂有什么影响.

cnmade on 1 Nov 2016

没有默认最优参数，都需要根据实际情况调整

xtaci on 1 Nov 2016

小瓦300G 电信延迟250+丢包严重从安装kcp 就一直搞瞎搞发现 "resend": 2, "sndwnd" "rcvwnd" 可以调小小瓦太折腾了不弄流量蹭蹭直上控制流量又不卡不如fs顺 FEC根本就不知道怎么调
服务端 "crypt": "aes-192",
"mode": "manual",
"conn": 1,
"mtu": 1350,
"sndwnd": 128,
"rcvwnd": 256,
"datashard": 10,
"parityshard": 3,
"dscp": 46,
"nocomp": false,
"nodelay": 0,
"interval": 20,
"resend": 2,
"nc": 1,

sxml on 1 Nov 2016

今天测试了以下2种策略
only resend:
fec (0,0), -nodelay 1 -resend 2 -nc 1 -interval 20 ==>1500-1800kbps

only FEC:
-mode fast -datashard 5 -parityshard 5 ==>7000-11000 Kbps

很明显，对于我的网络情况来说FEC的效果远好于单纯的重传

background：
魔都电信，Virmach Phoneix, ping值大致在450左右，icmp丢包率接近30%

感觉在这种丢包率下能达到如此加速效果简直太神奇了！！！

LiR1cky on 1 Nov 2016

👍1

FEC要感谢香农

https://zh.wikipedia.org/wiki/%E6%9C%89%E5%99%AA%E4%BF%A1%E9%81%93%E7%BC%96%E7%A0%81%E5%AE%9A%E7%90%86

在信息论里，有噪信道编码定理指出，尽管噪声会干扰通信信道，但还是有可能在信息传输速率小于信道容量的前提下，以任意低的错误概率传送数据信息。这个令人惊讶的结果，有时候被称为信息原理基本定理，也叫做香农-哈特利定理或香农定理，是由克劳德·艾尔伍德·香农于1948年首次提出。
通信信道的信道容量或香农限制是指在指定的噪音标准下，信道理论上的最大传输率。

xtaci on 2 Nov 2016

👍1

试一下 1105，重新实现了early retransmit

xtaci on 5 Nov 2016

如下参数测试了一下，1102 Youtube 7000-11000kbps，1105 9000-170000kbps 提升还是挺明显的
"mode": "fast",
"mtu": 1400,
"datashard": 30,
"parityshard": 15,

LiR1cky on 5 Nov 2016

early retransmit可能是一个除了fastack/rto外的重要的补充。

另外，我一分钟前重新上传了下，麻烦再测试下。

xtaci on 5 Nov 2016

刚才测完就去看奇异博士了～～刚回来。
重新下载测试了一下，和之前下载的1105感觉差不多，大部分时间稳定在11000-17000kbps，不过瞬时跳到过20000kbps。

LiR1cky on 5 Nov 2016

好，稳定即可。