skywind3000
KCP的超时RTO增长竟然是线性增加
“TCP超时计算是RTOx2，这样连续丢三次包就变成RTOx8了，十分恐怖，而KCP启动快速模式后不x2，只是x1.5（实验证明1.5这个值相对比较好），提高了传输速度” 由于TCP的RTO是指数增加的，所以丢三次包是RTOx8，根据上面的描述，我还以为是RTOx1.5x1.5x1.5，然而测试结果却是每次+RTO/2的线性增加，由于快速模式默认RTO只有30ms，所以每次RTO+15ms，发得根本停不下来。 假如这个设定是作者故意的，那我认为应该在描述部分写清楚，以免造成误解。或者是我测试方法有问题...
加了一点注释，看代码逻辑中的确是这样的，线性增加，重发会过于频繁，改成如下可能好些：
if (kcp->nodelay == 0) {
segment->rto += segment->rto;
} else {
segment->rto += segment->rto / 2;
}
@LiuqingYang @skywind3000 代码中是这样的
if (kcp->nodelay == 0) {
segment->rto += kcp->rx_rto;
} else {
segment->rto += kcp->rx_rto / 2;
kcp->rx_rto并没有发生变化，所以每次加的都是一个固定数值，应该是线性增加吧，代码中有变更kcp->rx_rto的地方?没注意到。
@skywind3000 segment->rto 会初始化为kcp->rx_rto，kcp->rx_rto是固定的，后续segment->rto的增加都是一个固定数值。
@skywind3000 kcp 的 rto 只跟 ack rtt 有关，不受丢包重传影响，所以 @zsounder 说增加的是是固定数值。
其实差别不大，满足你们的要求： https://github.com/skywind3000/kcp/releases/tag/1.6
kcp->nodelay = 0, 1 时采用指数增长 kcp->nodelay = 2 时采用线性增长
大部分丢包 1,2 次重传就解决了，并非像你们说的那样洪水猛兽，说的好像带宽要被 kcp 挤爆了一样，至于么？那么多线上产品用的好好的。