kcptun
kcptun copied to clipboard
xtaci
A Quantum-Safe Secure Tunnel based on QPP, KCP, FEC, and N:M multiplexing.
2021/11/20 10:36:56 stream opened in: 192.168.0.89:60216 out: 129.0.0.3.:xxxx(3) 2021/11/20 10:37:26 stream closed in: 192.168.0.89:60216 out: 129.0.0.3:xxxx(3)
When run second client on linux amd64, it will show such a error: `listen udp :29900: bind: address already in use` It seems like linux amd64 client (release v20210922) always...
内网的NAS直接开放端口用于外部访问,速度不稳定,百兆的宽带,有时6-7M/s下载,很多时间只有600-700KB/s. 试图使用kcptun加速来提高速度. 但是外网无法访问网页或ssh或其他. NAS上设置kcptun服务端, Openwrt路由器转发UDP端口到NAS. 局域网内 设置kcptun客户端, 直接连接NAS 或者连接外网IP 都可以访问NAS网页. 外部访问时,可以连接,但是无法访问网页,也测试过ssh连接,同样内网可以访问,外网不可以访问. 两种访问方式使用了同样的配置文件. 外部访问时,服务端1分钟后 stream close 并出现 io: read/write on closed pipe 怀疑与Openwrt本身或者端口转发有关. 难道是运营商有限制 测试过直接将kcptun服务设置在openwrt上,同样的问题,外部不能访问. 测试过使用kcptun访问vps内部的网页.没有问题. 外部访问时 客户端的日志: PS D:\Desktop> .\kcptun.exe...
如题。。 目前synology里面的docker版本还是v20210624，最新的已经到20210922了。
在无tcp参数时，工作良好。最近 qos厉害，我就尝试了 -tcp 参数。 https://i.imgur.com/3P0HL35.jpg
用 `v2ray` 使用手机流量进行链接，`kcptun` 在 `Termux` 中运行，拥有 `root` 权限 服务端日志如下，客户端日志也是这样 ``` 2021/07/14 10:39:03 stream closed in: 106.121.181.12:31768(13) out: 127.0.0.1:6328 2021/07/14 10:39:03 stream closed in: 106.121.181.12:31768(21) out: 127.0.0.1:6328 2021/07/14 10:39:03 stream closed...
您好，作者 国内朋友的网络环境是这样的：https://i.imgur.com/BqJTgbF.png ，流量穿透，三大运营商都穿，访问大陆网络资源没有任何问题，但是通过shadowsocks访问外网非常痛苦， 手机上的shadowsocks-android和电脑上的shadowsocks-Qt5一会儿就断，断了过一会又自动连上，然后再断.....朋友在家里上外网痛苦，跟我语音连线痛苦，我放他家里的一台用来翻回国的小主机连接也痛苦。 现在可以确定的是shadowsocks断流的时候直接访问的bilibili播放正常，从国内网站的下载也没有中断。 国外的节点一直是安装的clowwindy的ss版本，配合kcptun，已经这样稳定使用了好几年，翻回国的小主机也是安装的clowwindy的服务端配合zerotier使用，朋友搬家到现地址后发现都不好用了。 kcptun的配置很简单：mode=fast2;remoteaddr=xxx.xxx.xx.xx:yyyyy （手机） -t "127.0.0.1:xxxxx" -l ":xxxxx" -mode fast2 （电脑） shadowsocks的配置也很简单：ssserver -p xxxxx -k xxxxxxx -m aes-256-cfb 因为目前没有其他宽带可以换，而且手机信号也不好，用流量不现实，所以只能想想技术上解决的办法。有人说是kcp被阻断，试过不上kcp似乎稳定一点，但是速度极慢，慢到如同断流... 请问：对付这种流量穿透的宽带，有没有什么特别的配置方式可以解决断流的问题？或者您有没有什么建议？谢谢！
目前在长肥管道下如果想达到高带宽利用率，存在以下矛盾 在「发送与接收端的RTT」大于「协议处理周期」(即interval参数)时，不存在同一个发送窗口的尺寸，在发送策略为窗口中有数据就应发尽发的策略下，既满足一次性突发传输的速率不超过预设带宽，又能保持持续传输达到预设带宽。 举例：发送端与接收端固有物理带宽均为200mbps，平均RTT为90ms，kcptun的发送周期为20ms, kcptun的mtu设置为1400 为了达成持续发送时窗口容纳BDP的数据，配置发送窗口为1536。但这会造成在突发传输时，20ms内的峰值带宽达到持续传输的(RTT/发送周期)倍数，即4.5倍，实际峰值带宽会达到约900mbps。 一方面，发送数据超过实际带宽对于数据传输延迟造成不利影响，另一方面，这种行为是不被服务商允许的，实际效果是在突发传输后，AWS与ALI/TX的机器间会出现对应端口传输的数据RTT变为1000ms的惩罚措施，该惩罚持续时长为60s。 目前通过tc在发送端机器与接收端机器把发送速度限制到200mbps，同时做20ms的发送平滑措施，没有出现过一次惩罚问题，也没有因此而产生过断流问题。 但这个措施只是保底解决被惩罚的问题，在突发期被tc丢弃的数据会依赖重传，这部分数据会增大其传输延迟。不如直接从源头上控制发送速率，达成更低的传输延迟。这样也更符合KCP的设计目标——为流速优化 所以建议增加最大发送带宽限制功能，针对底层的单个KCP连接，根据配置的最大发送速率决定一次发送的最大数据量，而不是窗口有空间就全部发出去。 如果在kcptun层面，增加配置单个端上连接的最大发送带宽与接收带宽，并在发送时协商，让对端的发送速率匹配到其发送速率与我方接收速率的最低值，则更为方便。
最近刚刚发现 kcptun，觉得很不错。如果能再增加一些功能的话，可能会更加地好： 1）隧道两端实现了对TCP联接的支持，是否可以继续增加对UDP模式的支持（包括组播），类似于UDPSpeeder？ 2）可否增加对LZ4算法的支持？LZ4的压缩效果似乎比Snappy更好，尤其是在针对特定种类的数据而使用定制字典的时候。如果打算支持UDP客户端，则包含短记录的UDP报文很需要这方面的考虑。例如，处理股票行情时，LZ4+字典，几乎可以干掉三分之二的尺寸。 3）建议增加对总体最大发送带宽的控制，当跑在专线上时，可以更好地应对脉冲高峰的出现。
问问题前先搜索ISSUE，并搞清楚下面的问题: 1、有没有类似测试工具，比如测试kcp跟UDPspeeder针对udp加速效果？ Before firing issue, make sure you figured out the following common questions. PLEASE DO SEARCH FIRST. 1. Check your ```-key xxx``` for at least 3 times, ***MAKE SURE***...
