关于 KCPTUN

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

V2EX 提问指南

这是一个创建于 2264 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

然而今天直接 ping 不通了。

有一样的人吗？

kcptun

ping

不通

原生

24 条回复 • 2018-09-10 21:48:36 +08:00

CCNemo

2018-09-10 09:27:29 +08:00 via Android

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

chingyat

2018-09-10 09:48:21 +08:00 via Android

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

x7395759

2018-09-10 10:08:37 +08:00

@CCNemo
@chingyat

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

wohenyingyu03

2018-09-10 10:12:30 +08:00

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

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

x7395759

2018-09-10 10:31:39 +08:00

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

xiao17174

2018-09-10 10:48:44 +08:00

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

paparika

2018-09-10 11:06:28 +08:00

服务端搞个定时重启吧

wohenyingyu03

2018-09-10 11:08:26 +08:00

@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

2018-09-10 11:09:25 +08:00

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

realkaiway

2018-09-10 11:14:47 +08:00 via iPhone

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

xiao17174

2018-09-10 11:42:21 +08:00

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

pythonee

2018-09-10 11:45:34 +08:00

我也有这个现象

x7395759

2018-09-10 14:13:25 +08:00

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

Justin13

2018-09-10 14:20:17 +08:00 via Android

上 bbr 嘛

paparika

2018-09-10 15:22:35 +08:00

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

x7395759

2018-09-10 15:56:47 +08:00

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

JohnSmith

2018-09-10 17:02:34 +08:00

udp 封锁

iceheart

2018-09-10 17:29:04 +08:00 via Android

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