关于 KCPTUN

[x7395759]

有没有使用 KCPTUN 用着用着就不能用了，但是原生的$$还是可以用，过一阵子 KCPTUN 又可以用了。

然而今天直接 ping 不通了。

有一样的人吗？

[CCNemo]

上个月就发现这情况了，停用比开着稳定多了。

[chingyat]

我也一样。解决方法是不用 kcptun。

[x7395759]

@CCNemo
@chingyat

不开速度很慢怎么办 T-T

[wohenyingyu03]

端口被封？看看 KCPTUN 日志呗。ping 不通了$$还能用？

本地与服务端用不同端口开多路 kcptun，shadowsocks 做一个灾备或者负载均衡迷惑墙。

[x7395759]

@wohenyingyu03 ping 不通了$$为什么不能用，ICMP 和$$又不是同一个协议。请问均衡负载怎么迷惑墙？还不是均衡的几个都要访问。

[xiao17174]

kcptun 是通过大量的重复发 UDP 包来实现加速.而这种加速其实挺占带宽的.甚至看起来像是 DDOS,所以很容易被链路上的某点封端口或者临时黑名单.

[paparika]

服务端搞个定时重启吧

[wohenyingyu03]

@x7395759 墙的 ICMP 协议优先级远高于$$协议，ping 不通了$$如何能用？不是很理解。家庭宽带对一个海外 ip 的特定端口每天固定有大量流量，这个特征似乎还挺明显的


@xiao17174 kcptun 还真不是靠大量重复发包实现的，一个官网例子：

”发送端发送了 1,2,3,4,5 几个包，然后收到远端的 ACK: 1, 3, 4, 5，当收到 ACK3 时，KCP 知道 2 被跳过 1 次，收到 ACK4 时，知道 2 被跳过了 2 次，此时可以认为 2 号丢失，不用等超时，直接重传 2 号包，大大改善了丢包时的传输速度。“

正常模式下只是增加了 10%～ 20%的带宽占用而已。

[holmesabc]

断流换 kcpraw。ping 不通等几个小时再试试

[realkaiway]

一直都是用锐速，kcptun 还是不稳定

[xiao17174]

@wohenyingyu03 感谢回复,不过你说的只是 kcp 本身的原理和理想情况下使用 kcp 所带来的开销.(kcp 本身并不是针对 fq 开发的(为了游戏),kcptun 倒是可以说是为了 fq 而生)
并且,你说的这些和大量重复发包并不冲突.我说的是表象,你讲的是重复发包的原因.kcptun 是基于 udp 的 kcp 实现,当你在 kcptun 中设置较高的流畅度时,在 fq 的场景下,流量 double 是很正常的.你可以实测一下.
同时倒推一下现象也不难发现,突然不能使用 kcptun 了,但同时在 kcptun 的 server 和 client 都不修改任何参数的情况下,隔一段时间又突然能上了.这不就是明显的被临时 block 端口的表现吗?那能被临时 block 端口的原因无外乎这么几个了.

[pythonee]

我也有这个现象

[x7395759]

@paparika 服务端重启可以解决这个被墙的问题？什么原理。

[Justin13]

上 bbr 嘛

[paparika]

@x7395759 不一定有关，不过怀疑 kcptun 有内存泄露，vps 内存隔一段时间会比较高

[x7395759]

@paparika 应该是正常水平，我的 kcptun 都还没有挂过，但是我有一台机器上的 ss 倒是经常挂。刚刚上去看了一下发现果然又是 ss 挂了。

[JohnSmith]

udp 封锁

[iceheart]

kcptun 的前向纠错抢带宽抢的太厉害，
所谓前向纠错，就是这个算法可以做到 n 个包编码成 n+m 个，收到其中的任意 n 个就能恢复原始 n 个数据。
所以只要 m/n 大于丢包率，就能基本保证不用重传数据。
随着丢包率上升，只要调整 m 值，就能保证速度和数量。
有限带宽下，kcptun 把带宽都抢走，别人就没的用了，大家都用 kcptun,网络就堵死了。因为丢包率越来越高，所以发包的 m 值越来越大，这是个死循环。
即使基于这个原因，封锁 kcptun 也是合理的。所以，还是尽量少用

[FakeLeung]

我也是，我也想不用，但是不用看油管才 2000k，开了就有 20000k 的速率。

[x7395759]

@JohnSmith 应该是了。