cnbatch / kcptube Goto Github PK

一些建议

1. 客户端建立连接后在两侧输出连接信息提示，目前服务端不能显示有多少客户端连接到服务端
2. 建议显示网络统计信息，显示实时或若干秒内的统计信息，例如网速，有效网速，丢包率，延迟，丢包后使用fec恢复数据的成功率。这些信息可以更好的帮助用户调整配置参数，否则调参全靠自己猜测

我自己的 2 台 vps，我平时使用多种方式与 vps 连接，这其中我使用 SSH 作为代理。但我搭建了 kcptube 后，发现延迟相关有点大，具体表现是：

我的vps 的 Ping 是 147～155ms ，比较恒定。
我通过 SSH 连接后，HTTP 的延迟是 310ms
但我通过 kcptube 之后，http 延迟是 700ms+
比如下面的截图

Imgur

问题场景，下载 http://mirror.uoregon.edu/ubuntu-releases/20.04.6/ 的iso桌面安装映像（4.1GB），vps位于俄勒冈州，在vps上测试wget下载这个俄勒冈州立大学的托管网站映像没有任何问题，但是vps通过kcptube（有端口跳跃）转发gost的socks5代理，在境内用firefox浏览器设置代理进行下载就会出现随机的中断的问题（无论是否晚高峰），为了对比同一台vps安装hysteria转发gost的socks5代理，在境内用firefox浏览器设置代理进行下载没有任何问题，顺利下载4.1GB的iso文件

为了防止俄勒冈州立大学的托管网站有特殊问题，另外也使用了 http://mirrors.vcea.wsu.edu/ubuntu-releases/20.04.6/ 华盛顿州立大学的托管网站，然后在华盛顿州再开了另外一台vps，在vps上测试wget下载这个华盛顿州立大学的托管网站的iso桌面安装映像（4.1GB）没有任何问题，但同样这台vps通过kcptube（有端口跳跃）转发gost的socks5代理，在境内用firefox浏览器设置代理进行下载也出现随机的中断的问题（无论是否晚高峰），为了对比同一台vps安装hysteria转发gost的socks5代理，在境内用firefox浏览器设置代理进行下载没有任何问题，也顺利下载4.1GB的iso文件

但奇怪的是这些vps的kcptube转发gost的socks5代理，在境内连续1个多小时播放4k视频却完全没有中断或卡顿（无论是否晚高峰），也是使用firefox浏览器设置socks5代理进行播放的，只有下载大容量文件才会随机出现中断，而且以上所有测试在晚高峰及白天的早上低峰时间段都做过，情况一样，应该和拥挤没有关系

谢谢！

version:20240515 client.

Error

[58456.235864] kcptube[13360]: segfault at 200 ip 000000000045eedb sp 00007f908011cb90 error 4 in kcptube[401000+342000]

Config

mode=client
listen_on=127.0.0.1
listen_port=101
destination_port=57100-57500
dport_refresh=600
destination_address=xxxxxxx
encryption_algorithm=AES-GCM
encryption_password=634218
udp_timeout=180
keep_alive=30
fec=25:5
kcp=fast3
outbound_bandwidth=20M
inbound_bandwidth=100M
ipv4_only=true

如果大佬有精力，能否考虑在同一个客户端配置文件增加多个端口转发，类似下面的配置方式，而且这样也可以不需要在服务器定义转发目的地端口，全部由客户端配置文件决定

"forward": {
"127.0.0.1:12322": "127.0.0.1:22",
"0.0.0.0:5201/tcp": "127.0.0.1:5201",
"0.0.0.0:5353/udp": "8.8.8.8:53"
}

或者

"relay_tcps": [
{
"listen": "127.0.0.1:2222", // TCP 转发监听地址
"remote": "123.123.123.123:22", // TCP 转发目标地址
"timeout": 300 // TCP 超时秒数
},
{
"listen": "127.0.0.1:13389", // TCP 转发监听地址
"remote": "124.124.124.124:3389", // TCP 转发目标地址
"timeout": 300 // TCP 超时秒数
}
],
"relay_udps": [
{
"listen": "127.0.0.1:5333", // UDP 转发监听地址
"remote": "8.8.8.8:53", // UDP 转发目标地址
"timeout": 60 // UDP 超时秒数
},
{
"listen": "127.0.0.1:11080", // UDP 转发监听地址
"remote": "9.9.9.9.9:1080", // UDP 转发目标地址
"timeout": 60 // UDP 超时秒数
}
],

谢谢！

本机测试，发现一点增加fec配置，则无法通过链接测试

去掉fec，则可以通过链接测试

服务端配置
mode=server
kcp=fast2
inbound_bandwidth=300M
outbound_bandwidth=30M
listen_port=30000-30100
destination_port=16261
destination_address=127.0.0.1
encryption_algorithm=none
ipv4_only=true
fec=20:4

客户端配置
mode=client
kcp=fast2
inbound_bandwidth=300M
outbound_bandwidth=30M
listen_port=16261
destination_port=30000-30100
destination_address=127.0.0.1
encryption_algorithm=none
ipv4_only=true
fec=20:4

.

Is d an abbreviation for destination?
这里的d是否是destination的缩写词？

Based on the above guesses, I think that dport_refresh refers to the refresh interval of the UDP target port, is my understanding correct?
基于以上猜测，我认为dport_refresh指的是udp目标端口刷新的时间间隔，我的理解是否正确？

I'm also wondering, why would flushing the destination port be considered, rather than modifying the source port?
我还想知道，为什么会考虑刷新目标端口，而不是修改源端口？

kcptube-linux-glibc-x64.tar.xz
服务端及客户端操作系统都是ubuntu 20.04.6服务器版（非桌面版）

root用户启动
#./kcptube kcpclient.conf
客户端报告错误
kcptube version 20230924
Error Found in Configuration File(s): No
Servers: 0
Relays: 0
Clients: 1
start_up() running in client mode
[2023-09-25 11:11:11 +0000] open: Too many open files

如果是kcptube-linux-musl-x64.tar.bz2版
报告错误
open: No file descriptors available

系统open files数是缺省的，没有改变过
# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 3491
max locked memory (kbytes, -l) 65536
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 3491
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

下面是服务器的配置文件内容，服务器没有报错

mode=server
kcp=fast1
inbound_bandwidth=500M
outbound_bandwidth=500M
listen_port=11000-11999
destination_port=6000
destination_address=127.0.0.1
dport_refresh=20
encryption_password=password
encryption_algorithm=AES-GCM
keep_alive=10
ipv4_only=1

下面是客户端的配置文件内容

mode=client
kcp=fast1
inbound_bandwidth=450M
outbound_bandwidth=50M
listen_port=6000
destination_port=11000-11999
destination_address=www.mydomain.com
dport_refresh=20
encryption_password=password
encryption_algorithm=AES-GCM
keep_alive=10
ipv4_only=1
mux_tunnels=65535

上面的mux_tunnels=1020也一样的报错

请教一下应该怎样修改参数才能运行

谢谢！

问题场景
在我的服务器上把kcptube升级到20231202版本后随机闪退，看syslog里面有segfault的打印，之前用20231126版本没出现过这个问题

Dec 17 12:25:22 localhost kernel: [ 2091.126124] tube[663]: segfault at 7f2846623408 ip 000000000046189a sp 00007f2846a301a0 error 4 in tube[401000+310000]

用的是kcptube-linux-musl-x64.tar.bz2这一个文件

我的配置是这样的
mode=client
kcp=fast1
inbound_bandwidth=500M
outbound_bandwidth=500M
listen_on=A.A.A.A
listen_port=port
destination_port=port
destination_address=A.B.C.D
dport_refresh=30
encryption_password=AAAAAAAAAAAAAAAAA
encryption_algorithm=xchacha20
ipv4_only=1
blast=1
mux_tunnels=10 // 这行是我最近新加的，不知道是否有影响

mode=server
kcp=fast1
inbound_bandwidth=500M
outbound_bandwidth=500M
listen_port=port
destination_port=port
destination_address=127.0.0.1
encryption_password=AAAAAAAAAAAAAAAAA
encryption_algorithm=xchacha20
log_path=/tmp/
ipv4_only=1
blast=1

My tunnel MTU set as defualt 1440.WG need set 1440-80=1360?

能不能提供静态编译的二进制？

.

I wanna use watchtower automatic update.thx

首先20231010版在一份服务器配置文件，一个kcptube客户端站点情况下，播放4k视频没有问题，使用的是issue 8的配置

有问题的场景是一份服务器配置文件，两个同城运营商的异地客户端站点同时连接这台的服务器（即分别两个站点linux客户端，服务器还是只有一份配置），两个站点同时播放4k视频就卡顿，同样使用的是issue 8的配置，而且已经分别尝试使用fast1/fast3/fast5，情况一样

但是回退使用20231002版就完全没有问题，与上面一样的是一份服务器配置文件，两个同城运营商的异地客户端站点同时连接这台的服务器（两个站点linux客户端就是上面使用的两台，服务器还是同样这份配置不变），两个站点同时播放4k视频完全不会出现卡顿问题，同样使用的是issue 8的配置，使用fast5，至少证明kcptube是可以同时支持多客户端没有传输性能问题的

.

相对于本地端口转发（或者叫正向端口转发），远程端口转发这个功能一般是由ssh -R命令实现的，或者如gost的rtcp://:10122/127.0.0.1:22命令参数实现

应用场景是远端的服务器在内网，只能出局连接公网，没有端口映射权限，而客户端的机器有公网地址或能够进行端口映射，然后客户端机器作为kcptube的服务端，而远端服务器反而作为kcptube的客户端连接到客户端机器

如果这时kcptube有远程端口转发功能的话，可以把服务器的端口如22/21/23等转发（或映射）给客户端机器的一个自定义端口，这时用户连接到客户端机器的这些自定义端口就等于直接连接到了服务器的相应端口

主要是考虑kcptube作为一个优秀的流量转发工具，更全面的流量转发功能也是更多用户使用的动力

谢谢！

你好，我按照文档中的导入方式导入镜像后发现启动容器还是会尝试去dockerhub拉取镜像，然后发现导入的镜像名称和tag都是，请问是打包时的问题还是需要额外增加一个手动给镜像打上kcptube tag的步骤？

env: archlinux with kernel ipv6.disable=1: ipv6.disable=1
dmesg:

[    0.000000] Linux version 6.1.24-1-lts (linux-lts@archlinux) (gcc (GCC) 12.2.1 20230201, GNU ld (GNU Binutils) 2.40) #1 SMP PREEMPT_DYNAMIC Thu, 13 Apr 2023 17:22:35 +0000
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-linux-lts root=UUID=28507de7-6bf8-4229-b994-4169fdba432e rw net.ifnames=0 loglevel=3 quiet ipv6.disable=1 audit=0

config:

mode=server
kcp=andante
listen_port=3000
destination_port=6000
listen_on=0.0.0.0
destination_address=127.0.0.1
encryption_password=qwerty1234
encryption_algorithm=AES-GCM

errlog:

error_found: No
Servers: 1
Clients: 0
start_up() running in server mode
[2023-04-20 03:27:44 +0000] open: Address family not supported by protocol      Port Number: 3000
bye

一些建议

1. 客户端建立连接后在两侧输出连接信息提示，目前服务端不能显示有多少客户端连接到服务端
2. 建议显示网络统计信息，显示实时或若干秒内的统计信息，例如网速，有效网速，丢包率，延迟，丢包后使用fec恢复数据的成功率。这些信息可以更好的帮助用户调整配置参数，否则调参全靠自己猜测

我最近使用kcptube玩游戏还在好奇发包倍率是多少,今天就看到FEC的更新了,看完完整的WIKI,有一些疑问

一般来说，应当 D + R > 19。

我的服务器在晚高峰丢包率大概是7%左右,然后现在使用fast1,因为这个通道是纯玩游戏的,流量完全不在乎

能否设置 为 fast6 , 然后FEC 使用 2:4 , 使用3倍流量发包

使用 wireguard -> kcptube

这是我的配置

mode=server
kcp=fast6
inbound_bandwidth=1G
outbound_bandwidth=1G
listen_port=8585-8686
destination_port=51820
destination_address=wireguard
encryption_password=game
encryption_algorithm=AES-GCM
blast=1
fec=2:4

正确配置了，也打开了防火墙，各自能看到对应的端口被KcpTube接管了，--try也没问题。

但是服务端并没有显示有客户端接入，流量也基本全是0。客户端上除了监听端口，并没有发现有其他用于和服务端通信的端口占用。

mode=client
kcp=regular4
inbound_bandwidth=500M
outbound_bandwidth=50M
#kcptube should listen on 51820, so the wireguard client can connect to this port.
listen_port=51820

#this is the port of server side's kcptube
destination_port=5900
destination_address=0.0.0.0
encryption_password=qwerty1234
encryption_algorithm=AES-GCM

mode=server
kcp=regular4
inbound_bandwidth=1G
outbound_bandwidth=1G
#Listening on 59000
listen_port=5900

#The port number of server side's wireguard
destination_port=51820

#if wireguard and kcptube are running on the same server, use localhost, or 127.0.0.1, or ::1
destination_address=localhost
encryption_password=qwerty1234
encryption_algorithm=AES-GCM

./udp2raw_amd64 -c -l0.0.0.0:5900 -ripvps:443 -k "passwd" --raw-mode easy-faketcp --seq-mode 0 --cipher-mode none
./udp2raw -s -l0.0.0.0:443 -r 0.0.0.0:5900 -a -k passwd --raw-mode faketcp --seq-mode 0 --cipher-mode none

the command does not want to run.

因为/etc/sysctl.conf文件里面的net.core.rmem_max参数对于udp包传输的性能有比较关键的影响，

以hysteria协议为例，它原来的1.x项目里面有专门说明net.core.rmem_max参数值与带宽值的一些建议比例关系

另外xtaci/kcptun项目也有专门说明net.core.rmem_max参数的，当然它还提到了其他一些相关参数，不过就我自己测试来看，对udp传输性能影响最关键的还是net.core.rmem_max参数，估计这也是hysteria项目当时仅仅是建议了net.core.rmem_max参数值的原因

谢谢！

与客户端通信一直正常，但统计信息里却没有任何流量信息。只有一个客户端连接进来，开启了端口跳跃

kcptube version 20240602
Error Found in Configuration File(s): No
Servers: 1
Relays: 0
Clients: 0
kcptube is running in server mode
[2024-06-05 22:21:03 +0800] Summary of server.conf
receive (raw): 0 Byte/s, receive (inner): 0 Byte/s, send (inner): 0 Byte/s, send (raw): 0 Byte/s, fec recover: 0
mux_tunnels: receive (tcp): 0 Byte/s, receive (udp): 0 Byte/s, send (tcp): 0 Byte/s, send (udp): 0 Byte/s

[2024-06-05 22:22:03 +0800] Summary of server.conf
receive (raw): 0 Byte/s, receive (inner): 0 Byte/s, send (inner): 0 Byte/s, send (raw): 0 Byte/s, fec recover: 0
mux_tunnels: receive (tcp): 0 Byte/s, receive (udp): 0 Byte/s, send (tcp): 0 Byte/s, send (udp): 0 Byte/s

[2024-06-05 22:23:03 +0800] Summary of server.conf
receive (raw): 0 Byte/s, receive (inner): 0 Byte/s, send (inner): 0 Byte/s, send (raw): 0 Byte/s, fec recover: 0
mux_tunnels: receive (tcp): 0 Byte/s, receive (udp): 0 Byte/s, send (tcp): 0 Byte/s, send (udp): 0 Byte/s

[2024-06-05 22:24:03 +0800] Summary of server.conf
receive (raw): 0 Byte/s, receive (inner): 0 Byte/s, send (inner): 0 Byte/s, send (raw): 0 Byte/s, fec recover: 0
mux_tunnels: receive (tcp): 0 Byte/s, receive (udp): 0 Byte/s, send (tcp): 0 Byte/s, send (udp): 0 Byte/s

[2024-06-05 22:25:03 +0800] Summary of server.conf
receive (raw): 0 Byte/s, receive (inner): 0 Byte/s, send (inner): 0 Byte/s, send (raw): 0 Byte/s, fec recover: 0
mux_tunnels: receive (tcp): 0 Byte/s, receive (udp): 0 Byte/s, send (tcp): 0 Byte/s, send (udp): 0 Byte/s

[2024-06-05 22:26:03 +0800] Summary of server.conf
receive (raw): 0 Byte/s, receive (inner): 0 Byte/s, send (inner): 0 Byte/s, send (raw): 0 Byte/s, fec recover: 0
mux_tunnels: receive (tcp): 0 Byte/s, receive (udp): 0 Byte/s, send (tcp): 0 Byte/s, send (udp): 0 Byte/s

[2024-06-05 22:27:03 +0800] Summary of server.conf
receive (raw): 572 Bytes/s, receive (inner): 34 Bytes/s, send (inner): 317 Bytes/s, send (raw): 1060 Bytes/s, fec recover: 0
KCP#2315679149 average latency: 63 ms
KCP#4048496981 average latency: 47 ms
mux_tunnels: receive (tcp): 0 Byte/s, receive (udp): 0 Byte/s, send (tcp): 0 Byte/s, send (udp): 0 Byte/s

[2024-06-05 22:28:03 +0800] Summary of server.conf
receive (raw): 0 Byte/s, receive (inner): 0 Byte/s, send (inner): 0 Byte/s, send (raw): 0 Byte/s, fec recover: 0
KCP#2315679149 average latency: 63 ms
KCP#4048496981 average latency: 47 ms
mux_tunnels: receive (tcp): 0 Byte/s, receive (udp): 0 Byte/s, send (tcp): 0 Byte/s, send (udp): 0 Byte/s

[2024-06-05 22:29:03 +0800] Summary of server.conf
receive (raw): 682 Bytes/s, receive (inner): 25 Bytes/s, send (inner): 118 Bytes/s, send (raw): 3349 Bytes/s, fec recover: 0
KCP#2315679149 average latency: 63 ms
KCP#2212510674 average latency: 47 ms
KCP#4048496981 average latency: 47 ms
mux_tunnels: receive (tcp): 0 Byte/s, receive (udp): 0 Byte/s, send (tcp): 0 Byte/s, send (udp): 0 Byte/s

[2024-06-05 22:30:03 +0800] Summary of server.conf
receive (raw): 572 Bytes/s, receive (inner): 34 Bytes/s, send (inner): 317 Bytes/s, send (raw): 1060 Bytes/s, fec recover: 1
KCP#2212510674 average latency: 47 ms
KCP#3286824258 average latency: 48 ms
KCP#1253317755 average latency: 47 ms
mux_tunnels: receive (tcp): 0 Byte/s, receive (udp): 0 Byte/s, send (tcp): 0 Byte/s, send (udp): 0 Byte/s

[2024-06-05 22:31:03 +0800] Summary of server.conf
receive (raw): 0 Byte/s, receive (inner): 0 Byte/s, send (inner): 0 Byte/s, send (raw): 0 Byte/s, fec recover: 0
KCP#2212510674 average latency: 47 ms
KCP#3286824258 average latency: 48 ms
KCP#1253317755 average latency: 47 ms
mux_tunnels: receive (tcp): 0 Byte/s, receive (udp): 0 Byte/s, send (tcp): 0 Byte/s, send (udp): 0 Byte/s

[2024-06-05 22:32:03 +0800] Summary of server.conf
receive (raw): 0 Byte/s, receive (inner): 0 Byte/s, send (inner): 0 Byte/s, send (raw): 0 Byte/s, fec recover: 0
KCP#3286824258 average latency: 48 ms
KCP#1253317755 average latency: 47 ms
mux_tunnels: receive (tcp): 0 Byte/s, receive (udp): 0 Byte/s, send (tcp): 0 Byte/s, send (udp): 0 Byte/s

[2024-06-05 22:33:03 +0800] Summary of server.conf
receive (raw): 0 Byte/s, receive (inner): 0 Byte/s, send (inner): 0 Byte/s, send (raw): 0 Byte/s, fec recover: 0
mux_tunnels: receive (tcp): 0 Byte/s, receive (udp): 0 Byte/s, send (tcp): 0 Byte/s, send (udp): 0 Byte/s

[2024-06-05 22:34:03 +0800] Summary of server.conf
receive (raw): 0 Byte/s, receive (inner): 0 Byte/s, send (inner): 0 Byte/s, send (raw): 0 Byte/s, fec recover: 0
mux_tunnels: receive (tcp): 0 Byte/s, receive (udp): 0 Byte/s, send (tcp): 0 Byte/s, send (udp): 0 Byte/s

[2024-06-05 22:35:03 +0800] Summary of server.conf
receive (raw): 0 Byte/s, receive (inner): 0 Byte/s, send (inner): 0 Byte/s, send (raw): 0 Byte/s, fec recover: 0
mux_tunnels: receive (tcp): 0 Byte/s, receive (udp): 0 Byte/s, send (tcp): 0 Byte/s, send (udp): 0 Byte/s

I started the docker in the Synolgy Docker and had mounted configfiel.conf, when I tried to start it , I got the ERROR :

Start container local-kcptube failed: {"message":"OCI runtime create failed: container_linux.go:367: starting container process caused: exec: \"/kcptube\": permission denied: unknown"}.

Then I tried start a new docker container from Portainer but it's not so lucky , I got the same error .

如题，KCP对TCP是可靠传输，通常KCP也不支持转发UDP，所以好奇KCPTube对UDP是可靠转发还是非可靠转发。

有没有健康检查的方式？好做高可用/负载均衡