xtaci / kcptun Goto Github PK

环境：
服务器：西雅图ubuntu16.04(64) kcptun + 3proxy (socks5)
-mtu 1400 -sndwnd 2048 -rcvwnd 2048 -mode fast2
客户端：win10(64) IDM + kcptun，100M宽带 (因为电脑用的无线，实测下载大概有70M)
-conn 4 -mtu 1400 -sndwnd 256 -rcvwnd 2048 -mode fast2
测试用的都是最新的23号的版本

当我把conn设置为1时，下载可以稳定到2~3MB/s，任务管理器里显示大概用了40M的带宽
然而随着conn设置增大，下载效果越来越糟糕，看上去一卡一卡的，根本下不动
理论上调大点应该效果更好吧？不知道瓶颈在哪里，会不会在cpu运算上？

顺便还有一个问题，chrome上代理看网页，用的还是相同的设置。当载入图片很多的网页时，其它网页根本打不开，全部卡住。不知道这是kcptun的锅还是3proxy的？

谢谢

首先感谢作者提供如此优秀的程序！

我先说一下我这边的情况，我的测试环境是mt7620方案的openwrt路由器，MIPS32-LE构架，是目前的主流家用路由器。kcptun交叉编译成功，也可以正常运行。但是因为MIPS32的CPU性能比较弱，所以隧道以后只能跑到网速只能达到2-3Mbps（使用tea加密），在PC上测试的时候可以轻松超过20Mbps。猜测可能和kcptun使用加密传输有关。

请问作者能否增加 --crypt none 参数？不加密直接传输？另外其他参数是否有可以降低CPU和内存消耗的用法？路由器跑go语言实在伤不起的，谢谢作者！

--crypt value methods for encryption: aes, tea (default: "aes")

Milestone: Adaptive

Features to be included:

1. Adaptive FEC settings based on SNMP exchange
2. Adaptive SetNoDelay() settings based on SNMP exchange
3. MTU auto discovery
4. KCP window auto-expansion & shrinking based on SNMP exchange
5. Standardized UDP packet header format

Plan On : September, 2016

For everyone interested in this project, please express yourself.

2016/06/16 14:34:44 [ERR] yamux: keepalive failed: i/o deadline reached
2016/06/16 14:34:44 [ERR] yamux: Failed to read header: broken pipe
2016/06/16 14:34:44 stream closed

作者您好，我基本没有这方面的知识，不过想问一个问题，remote address: 118.26.142.194:36144，为什么端口号不是设置的29900呢？那么kcptun监听的端口号作用是什么呢？有点不太理解，不好意思，打扰了。

golang 1.5可以在安卓上运行，不知可以实现安卓运行不？

1、游戏可以丢包，加到 kcptun 里会不会因为重传导致延迟变大，游戏画面抖动？
2、但是 kcptun 的优点也是明显的，会保证数据延迟会很小，快速的重传数据！

总之，把游戏数据封装在 kcptun 里会让 PS4 这样的游戏体验更好么？ 应该怎么办？

近期在办公室应用 kcptun 时碰到以下问题：

• GPON 非对称接入，下行 100Mbps，上行 5Mbps，x86 网关连接光猫，网关 PPPOE 拨号
• kcptun + ss-redir 部署在网关
• 如当前主要是 kcptun 下行，则表现良好：kcp client RX 可超过 5MBps，tcp TX 超过 1MBps，多路 kcp 下行(如 Youtube 1080P)稳定
• 当有人通过 kcptun 上传(如 Google Drive)时，kcptun client 积极占用带宽，kcptun 至光猫流量超过 1MBps。此时其它 kcp 流量（无论上下行）都基本无法使用，甚至网关的 PPPOE 拨号断开并自动重连

该情况在办公室多人应用环境下非常突出，调节 kcptun 参数也没解决。现在正在考虑在 ss-redir 和 kcptun 之间使用 tc 做 QoS 来控制。

希望 kcptun 可实现简单的 QoS 控制 kcp TX 的总带宽。

stream closed2016/06/15 21:33:24 stream closed
2016/06/15 21:33:24 [ERR] yamux: keepalive failed: i/o deadline reached
2016/06/15 21:33:24 [ERR] yamux: Failed to read header: broken pipe
2016/06/15 21:33:24 keepalive timeout

digitalocean vps: 512MB with 512MB swap

In client side, using wget to fetch a big file(~500MB), the server killed because OOM.

大神你好, 我看了kcptun 的issues大家的讨论, 貌似kcptun是用来做点对点tcp通信加速的?
不知道kcptun能否像shadowsock这样做proxy?

能否在QEMU通过虚拟环境编译一个客户端版用在路由器上?

if not, pls add the ipv6 support.
if so, pls tell me how to config the client when ipv6 addr is used.

difference between fast2 fast normal and default

大神们要不要考虑一下~

这种FEC是用不着重传的！

而且有现成的库
https://github.com/LucaFulchir/libRaptorQ

[ERR] yamux: keepalive failed: i/o deadline reached
[ERR] yamux: Failed to read header: broken pipe

这两个值是怎么计算的？谢谢。

我客户端才600k速度
然后服务端发送是4000多KB的速度...
最可怕的是客户端速度跑到1MB左右
服务端差不多用了10-12MB左右速度.....

根据观察，下行的chrome/kcptun流量的有效载荷比大约是1：2，即50%的有效载荷，不考虑上行。

是否能根据某种方法，比如依照香农定理，丢包作为噪音，计算出最大带宽。

另外一个问题是，延迟，带宽占用，有效载荷比，是不是一个不可解决的问题，或者理论极限是什么？

还需要考虑在ADSL这种非对称流量情况。

@yaleh @jannson

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x2444]

goroutine 248 [running]:
panic(0x243de0, 0xc8200100c0)
/usr/local/go/src/runtime/panic.go:481 +0x3e6
main.handleClient(0x4c5b10, 0xc82002e000, 0x0, 0x0)
/Users/trivita/mydev/src/github.com/xtaci/kcptun/client/main.go:28 +0x404
created by main.main.func1
/Users/trivita/mydev/src/github.com/xtaci/kcptun/client/main.go:228 +0x2009

2016/06/27 02:57:02 remote address: *************:28429
2016/06/27 02:57:02 [ERR] yamux: Failed to read header: snappy: corrupt input
2016/06/27 02:57:02 snappy: corrupt input
这个是上面原因造成的~

1. 下载文件speedtest基本上下载2-3MB之后就会断开。
2. 视频有时断有时不断，另外视频的status里面显示的connection speed也不正常，我只有10mbps的宽带，但是他能飙到60多k。
3. 在视频播放视频的同时打开其他网站会很困难。

我之前用的版本印象中没有出现过以上问题，应该是 a79537f 这个版本。

mode fast2
mtu 1464
mtu试过默认也没用
sndwnd和rcvwnd都是默认，服务端和客户端的版本、参数都是一样的
另外我是配合ss-libev一起用

下载断开时服务端的错误信息

2016/05/21 09:38:31 [ERR] yamux: Failed to read header: broken pipe
2016/05/21 09:38:31 broken pipe
2016/05/21 09:38:31 stream closed
2016/05/21 09:38:33 i/o timeout

下载断开时客户端的错误信息

2016/05/21 09:39:00 [ERR] yamux: keepalive failed: i/o deadline reached
2016/05/21 09:39:01 [ERR] yamux: Failed to read stream data: broken pipe
2016/05/21 09:39:01 [WARN] yamux: failed to send go away: session shutdown

Single connection ARQ will lead to HOL Blocking problem.
https://en.wikipedia.org/wiki/Head-of-line_blocking
QUIC solved this problem by stream based ARQ, not connection based.

Multiplexing

HTTP/2 on TCP suffers from head-of-line blocking in TCP. Since HTTP/2 multiplexes many streams atop TCP's single-bytestream abstraction, a loss of a TCP segment results in blocking of all subsequent segments until a retransmission arrives, irrespective of the HTTP/2 stream that is encapsulated in subsequent segments.

Because QUIC is designed from the ground up for multiplexed operation, lost packets carrying data for an individual stream generally only impact that specific stream. Each stream frame can be immediately dispatched to that stream on arrival, so streams without loss can continue to be reassembled and make forward progress in the application.

Caveat: QUIC currently compresses HTTP headers via HTTP/2 HPACK header compression on a dedicated header stream(3), which imposes head-of-line blocking for header frames only.

现象是，百度什么很好访问，确认走代理。但是 google 偶尔可以偶尔不行，很频繁。

当选用加密的时候：
https://github.com/xtaci/kcp-go/blob/master/sess.go#L108

加密的 mtu 会比默认 减去 headerSize

但是为何 SetMtu 这里的时候又没有减去？ 会有什么后果？

mtu 值需要客户端与服务器端的 mtu值能通，不被分片就可以了吧？不关新与其它服务器的 mtu 值的关系。

我准备去掉 Mtu 选项试试。

“tcp网络程序的传输承载”，这个怎么理解？是说用kcptun可以代替标准tcp达到更好的效果，还是说其他？如果是我估计的这个意思，建议直接说“是标准TCP的更好替代品”。

Sever / Debian 7.10 64bit (Openvz vps)
Clinet / Win10 64bit
kcptun version 20160517

Sever log

2016/05/17 11:53:05 version: 20160517
2016/05/17 11:53:05 listening on [::]:9999
2016/05/17 11:53:05 communication mode: fast
2016/05/17 11:53:05 sndwnd: 1024 rcvwnd: 1024
2016/05/17 11:53:05 mtu: 1350
2016/05/17 11:53:05 tunnel encryption: true
2016/05/17 11:53:16 remote address: clientip:43481
2016/05/17 11:53:23 dial tcp 127.0.0.1:12948: getsockopt: connection refused
2016/05/17 11:53:24 remote address: clientip:43481
2016/05/17 11:53:24 [ERR] yamux: Failed to read header: broken pipe
2016/05/17 11:53:26 i/o timeout
2016/05/17 11:53:46 remote address: clientip:43481
2016/05/17 11:53:48 i/o timeout
2016/05/17 11:53:53 remote address: clientip:43481
2016/05/17 11:53:55 i/o timeout

Client log

2016/05/17 11:53:16 version: 20160517
2016/05/17 11:53:16 listening on: [::]:8080
2016/05/17 11:53:16 communication mode: fast
2016/05/17 11:53:16 remote address: serverip:9999
2016/05/17 11:53:16 sndwnd: 1024 rcvwnd: 1024
2016/05/17 11:53:16 mtu: 1450
2016/05/17 11:53:16 tunnel encryption: true
2016/05/17 11:53:23 stream opened
2016/05/17 11:53:53 stream closed
2016/05/17 11:53:56 [ERR] yamux: keepalive failed: i/o deadline reached
2016/05/17 11:53:56 [ERR] yamux: Failed to read header: broken pipe

请问我该如何进一步调试。

很高兴看见 conn 的实现，对于大上行阻塞其它连接流量有帮助。但今天的测试中，使用 conn=4 在Chrome中向 dropbox.com 上传 10MB 文件始终失败。换成 20160605 SNMP 版本上传成功。所以我现在还是退回到自己用 20160605 SNMP 4进程加 pen 做负载均衡，近两周在小型办公场景中运行稳定，只是内存吃得比较厉害。

I try to use kcptun with ipv6 but the kcplog show that . I think maybe the kcptun doesn't support ipv6 address,Could you please consider supporting IPv6 addresses?

建议分析现有情况：

• 发送冗余度（重发比例）
• 接收冗余度
• 丢包率

方法和工具：

• Debug log
• 增加统计实现和 log
• Wireshark extension

进一步改进方向：

• ACK 和重发机制改进
• FEC

现在直观的感受是接收端冗余度很高，应该有空间进一步提高吞吐率和带宽利用率。

作者您好，我基本没有这方面的知识，不过想问一个问题，remote address: 118.26.142.194:36144，为什么端口号不是设置的29900呢？那么kcptun监听的端口号作用是什么呢？有点不太理解，不好意思，打扰了。

客户端的-r参数使用域名时会出现dns无法解析，报错信息如下
2016/06/27 14:56:28 lookup xxx.xxx on 223.5.5.5:53: dial udp 223.5.5.5:53: i/o timeout.
ping 该域名能ping通，并且能解析到正确的ip地址

如题，已知软路由支持pptp代理，支持域名分流，支持多线DNS，是不是可以采用kcptun来连接pptp服务器端和客户端？

客户端错误:

2016/06/25 20:51:58 version: 20160623
2016/06/25 20:51:59 listening on: [::]:12948
2016/06/25 20:51:59 encryption: aes
2016/06/25 20:51:59 nodelay parameters: 1 20 2 1
2016/06/25 20:51:59 remote address: 23.105.214.29:29900
2016/06/25 20:51:59 sndwnd: 256 rcvwnd: 2048
2016/06/25 20:51:59 mtu: 1400
2016/06/25 20:51:59 datashard: 10 parityshard: 3
2016/06/25 20:51:59 acknodelay: false
2016/06/25 20:51:59 dscp: 0
2016/06/25 20:51:59 conn: 4
2016/06/25 20:52:05 stream opened
2016/06/25 20:52:05 stream opened
...

服务端错误:

2016/06/25 08:49:17 version: 20160623
2016/06/25 08:49:17 listening on [::]:29900
2016/06/25 08:49:17 encryption: aes
2016/06/25 08:49:17 nodelay parameters: 1 20 2 1
2016/06/25 08:49:17 sndwnd: 2048 rcvwnd: 2048
2016/06/25 08:49:17 mtu: 1400
2016/06/25 08:49:17 datashard: 10 parityshard: 3
2016/06/25 08:49:17 acknodelay: false
2016/06/25 08:49:17 dscp: 0
2016/06/25 08:52:02 remote address: 113.251.58.186:16169
2016/06/25 08:52:02 stream opened
2016/06/25 08:52:02 stream closed
2016/06/25 08:52:02 remote address: 113.251.58.186:16170
2016/06/25 08:52:02 stream opened
2016/06/25 08:52:02 stream closed
2016/06/25 08:52:02 remote address: 113.251.58.186:16171
2016/06/25 08:52:02 stream opened
2016/06/25 08:52:02 stream closed
2016/06/25 08:52:02 remote address: 113.251.58.186:16172
2016/06/25 08:52:02 stream opened
2016/06/25 08:52:02 stream closed
2016/06/25 08:52:02 stream opened
2016/06/25 08:52:02 stream closed
2016/06/25 08:52:02 stream opened
2016/06/25 08:52:02 stream closed
2016/06/25 08:52:02 stream opened
...

客户端配置:

Dim RunKcptun
Set fso = CreateObject("Scripting.FileSystemObject")
Set WshShell = WScript.CreateObject("WScript.Shell")
'获取文件路径
currentPath = fso.GetFile(Wscript.ScriptFullName).ParentFolder.Path & ""
'软件运行参数
exeConfig = "client_windows_amd64.exe -l :12948 -r 23.105.214.29:29900 -key test -mtu 1400 -sndwnd 256 -rcvwnd 2048 -mode fast2 -conn 4"
'日志文件
logFile = "kcptun.log"
'拼接命令行
cmdLine = "cmd /c " & currentPath & exeConfig & " > " & currentPath & logFile & " 2>&1"
'启动软件
WshShell.Run cmdLine, 0, False
'等待1秒
'WScript.Sleep 1000
'打印运行命令
'Wscript.echo cmdLine
Set WshShell = Nothing
Set fso = Nothing
'退出脚本
WScript.quit

服务端配置:

./server_linux_amd64 -l :29900 -t 127.0.0.1:443 -key test -mtu 1400 -sndwnd 2048 -rcvwnd 2048 -mode fast2 > kcptun.log 2>&1 &

服务器OS: Centos 6 x86_64 RAM:256
客户端OS: windows7 64
重庆电信光纤100M

我在用shadowsocks,参考的此教程:https://blog.kuoruan.com/102.html

降低CPU的途径如下:

1. NewCipher creates and returns a new cipher.Block. The key argument should be the AES key, either 16, 24, or 32 bytes to select AES-128, AES-192, or AES-256. 即是在kcp-go中，所有NewCipher的地方，只传入pass[:16]，执行AES-128加密，如果-key给的足够长，依然很安全(8位以上数字字母)
2. 不加--tuncrypt，这是一层额外的加密，上层有TLS/SSL加密的情况下，是不需要加这个参数的。

client版本： v20160620 amd64 (15，16版本同样问题)
OS版本：Openwrt x64

如果不指定conn参数，使用默认值，运行4天内存占用都正常

当然我不是这么无聊发个issue不是专门来赞你.

而是要顺便问问有没有人转成.Net的kcp-go库和kcptun? 最好是C#的.

最后还是感谢作者的努力, 让我看youtube从900 kbps变成20000kbps.

最新的5月6日编译包i386 linux版本有问题，运行时显示trace/breakpoint trap，无法执行。

在以往的观察当中，更多用户喜欢 config.json 的配置。类似： ./kcp_server -c config.json

这样的好处是文件容易传输，密码什么的在里面。启动也方便。用 cli 常常忘记上次写的密码是什么，参数有哪些。

版本：kcptun-linux-amd64-20160602.tar.gz
运行环境：CentOS Linux release 7.2.1511 (Core) x64位 512M内存的VPS
运行命令：./kcptun_server -t "127.0.0.1:1583" -l "0.0.0.0:1755" -mtu 1480 -key "xxxxx" >/dev/null 2>&1 &
现象：运行一段时间后server端进程消失

把运行日志输出到log文件，也只能看到某个stream open后就没有后继日志了，进程就退出了
而Ubuntu 14.04.4 x64 PC机上的客户端跑得很稳定

2016/06/27 15:28:24 version: 20160627
2016/06/27 15:28:24 listening on [::]:29900
2016/06/27 15:28:24 encryption: aes
2016/06/27 15:28:24 nodelay parameters: 1 20 2 1
2016/06/27 15:28:24 sndwnd: 2048 rcvwnd: 2048
2016/06/27 15:28:24 compression: true
2016/06/27 15:28:24 mtu: 1400
2016/06/27 15:28:24 datashard: 10 parityshard: 3
2016/06/27 15:28:24 acknodelay: false
2016/06/27 15:28:24 dscp: 0
2016/06/27 15:28:58 remote address: 2xx.x.2x.41:37849
2016/06/27 15:28:58 [ERR] yamux: Failed to read header: snappy: corrupt input
2016/06/27 15:28:58 snappy: corrupt input
2016/06/27 15:28:58 remote address: 2xx.x.2x.41:37849
2016/06/27 15:28:58 [ERR] yamux: Failed to read header: snappy: corrupt input
2016/06/27 15:28:58 snappy: corrupt input
2016/06/27 15:28:58 remote address: 2xx.x.2x.41:37849
2016/06/27 15:28:58 [ERR] yamux: Failed to read header: snappy: corrupt input
2016/06/27 15:28:58 snappy: corrupt input
2016/06/27 15:28:58 remote address: 2xx.x.2x.41:37849
2016/06/27 15:28:58 [ERR] yamux: Failed to read header: snappy: corrupt input
2016/06/27 15:28:58 snappy: corrupt input

vps 为 ubuntu 16.04的系统，之前用cetos6.4 就没有问题

在较大的 TCP 侧带宽情况下，即使使用 tc sfq 控制这一侧输入，KCP TX 队列仍会被少数大流量连接占慢，导致大量短连接响应缓慢。最典型的是从千兆以太局域网中向 pppoe 拨号的 WAN 上传大文件，会导致 web page 访问缓慢 主要原因是 kcp TX 使用的是 fifo 策略，在 TCP rx 快于 kcp TX 时不利于小流量连接。而由于 kcptun 进程的发出的 udp sport 一致，也无法在 kcp 侧 TX 上使用 tc sfq 来处理这一问题。

有两种处理方法：

• kcptun client 连接 server 时使用多个 udp sport, 甚至为每个 TCP 连接分配不同的 udp sport。此时即可使用 tc sfq 进行 QoS 。
• 在 kcp tx 上应用 TCP 连接信息，实现类似 tc sfq 的机制。此时无需外部的 tc sfq 即可改善短连接体验。

@xtaci 您好，我在

426 packets transmitted, 359 received, 15% packet loss, time 425007ms
rtt min/avg/max/mdev = 343.108/485.715/644.402/77.218ms

的网络环境（欧洲aws实时发送数据=>北京阿里云收到后返回200，traceroute -I 显示18跳）下进行测试。

client端部署在欧洲aws上，连接 client端的是4个node进程，keepalive的超时时间设置为2分钟。
server端部署在国内阿里云上，阿里云机器的带宽是10M，server端转发给nginx（server和nginx在同一台机器），nginx直接返回200。

4个node进程刚启动后，其中三个进程的套接字会涨到200左右，然后回落到20，另一个稳定在40左右。
之后client出现下面信息：

2016/03/19 11:03:09 read tcp 127.0.0.1:54321->127.0.0.1:46589: use of closed network connection
2016/03/19 11:03:10 stream **opened**
2016/03/19 11:03:10 <nil>
2016/03/19 11:03:10 stream closed
2016/03/19 11:03:10 read tcp 127.0.0.1:54321->127.0.0.1:46590: use of closed network connection
2016/03/19 11:03:11 stream opened
2016/03/19 11:03:11 <nil>
2016/03/19 11:03:11 stream closed
2016/03/19 11:03:11 read tcp 127.0.0.1:54321->127.0.0.1:46591: use of closed network connection
2016/03/19 11:03:11 stream opened
2016/03/19 11:03:11 <nil>
2016/03/19 11:03:11 stream closed
2016/03/19 11:03:11 read tcp 127.0.0.1:54321->127.0.0.1:46592: use of closed network connection
2016/03/19 11:03:12 stream opened
2016/03/19 11:03:12 <nil>
2016/03/19 11:03:12 stream closed
2016/03/19 11:03:12 read tcp 127.0.0.1:54321->127.0.0.1:46593: use of closed network connection
2016/03/19 11:03:12 <nil>
2016/03/19 11:03:12 stream closed
2016/03/19 11:03:12 read tcp 127.0.0.1:54321->127.0.0.1:46594: use of closed network connection
2016/03/19 11:03:12 stream opened
2016/03/19 11:03:12 <nil>
2016/03/19 11:03:12 stream closed

查看套接字，前三个进程的套接字还是稳定在20，另一个由40涨到200左后，最后降到20.，同时4个node 程序无法向client发送数据，出现异常信息

socket hang up

node 进程由pm2 守护，程序对异常有处理，当发生这类异常时，会尝试重新发送，但一直没能成功。

发送的数据大小平均为52981字节。

请问：

1. 发生use of closed network connection的原因是什么，如何解决？（我之前加了连接池，可以避免这个错误的发生，但觉得不是最好的解决方案）；
2. 在这样的网络环境下，kcp的一些参数比如像窗口size的大小，怎样设置比较合理，依据是什么；
3. 正常发送的数据大小大约是211924（测试时的4倍）字节，这样的数据大小kcp调整参数后，是否可以发送？（我尝试过2倍，发送不成功，卡住了。具体原因还没查）

期待您的回复，非常感谢！