Kcp用着用着偶尔就会断开{伪解决方案} #228
Kcp用着用着偶尔就会断开{伪解决方案} #228
Comments
参数也不贴 |
和参数没关系,我测试过半年多的时间并且不管是移动和电信网络都试过。。这个问题在所有使用kcp都出现是udp大流量被运营商自动封这个ip的udp连接。这个时间你们技术宅可能没有耐心测试,我因为一天24小时开youtube看skynews,他的断流时间也不固定可能一个小时也可能几十分钟,可能你和附近udp的国外带宽有关,如果断流了你只要等待十几分钟到半个小时就正常。解决这个问题只有finalspeed采用的将udp封装成tcp来发包。就从来不断线,我测试了大概一周都不断流。当然用finalspeed的udp模式和kcptun一样出现这个问题,v2ray 所使用的mkcp也同样有这个问题。只要用udp大量发包的必定被自动断流一段时间。 至于用搬瓦工的openvz的兄弟你们是无解的。。。速度换kvm的vps吧 可惜我每个版本都测试了,这个问题无解,只有等作者把udp封装成tcp的功能出现再使用了。。。 |
很抱歉,现在才看到作者的回复 我现在把参数贴一下 。 |
搬瓦工用finalspeed只能UDP。 |
我当时测试发现,公司的网络出国的UDP数据绝对被干扰了。也可能和时间有关?我在家使用没什么问题。 |
尝试降低MTU=512 |
@xtaci 服务端和客户端都需要降低么? |
是的,参考 #218 |
鹏博士的网,搬瓦工的VPS,也是频繁断开,10分钟-半小时左右会恢复。 经测试,断开后,除了80和443端口以外的所有TCP端口都被封,而且是Server --> Client的下行流量被封,上行没有影响 UDP端口似乎都被封了(也只是下行 被封),还没有找到简便的测试方法,不确定,留待测试。 而ICMP ping命令始终能通,这使人不禁寄希望于 应该是 端口封锁/Qos,不含端口的VPN协议流量应该可以通过,但是又会碰上GFW的封锁。 如果只是 对UDP端口单独进行统计流量,流量过大就触发封锁规则的话,那么 在Server端 用 测试方法,对于TCP,使用netcat或nmap(可选:可辅助用tcpdump,wireshark进行确认) 测试单个端口:
这里的端口可以是没有监听的, 如果可以连通,出来的警告是
批量测试:
对于UDP,不能使用nmap进行批量测试,因为UDP没有三次握手,从而没有返回包(Server--> Client)。 |
@feizhenzhuang 例如
同时要调大 不过这个 不是针对 每个 packet 随机化端口,而是针对 每一个connection 随机化端口。 下面这个好像是针对 packet的 如何控制 kcptun 每个connection的流量大小? |
@linhua55 我也是鹏博士的网,那有什么好的解决办法么? |
好奇怪,这两天没断了,也没用上面提到过的 今天中午又开始断了,看来不是这个原因 |
一直断,所以用了上面的随机端口方案,但发现,封的时候不是封服务器的udp,而且是对宽带本身的udp进出进行封堵,重新拨号换ip后就能连上了。。这就无解了。。。 |
@cjjdaq 我在客户端用nc,服务端用tcpdump测试: 客户端用nc访问一个udp端口,在服务端的tcpdump可以看到收到了从客户端访问这个udp端口的包。 从此看来是,客户端到服务端的udp上行流量不受影响 你试试 调大 |
我的宽带电信的,公网ip,断的时候,我宽带的udp出不去进不来(只有等待解封,要么重新拨号),但我用其它省的宽带(电信固定ip)连接到服务器的udp一切正常。 |
@cjjdaq |
其它省的连接一直正常,就我这里的电信封,我日 |
上海的电信也会审查过滤
cjjdaq <notifications@github.com>于2016年12月9日周五 下午2:21写道:
… 其它省的连接一直正常,就我这里的电信封,我日
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#228 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADMsUGAntY0Bjvxfy_jNIMxuB5eamecYks5rGPNugaJpZM4Kb6qi>
.
|
@cjjdaq
显示的出口ip是一样的 |
@cjjdaq
http://thesprawl.org/research/host-discovery/#udp-ping 用python程序测试了一下,确实是UDP上行流量 不通,UDP下行流量是通的。但是如果UDP上行流量只发送 |
你是要搞扩频通信啊 ,两组 UDP亦可 |
@xtaci @cjjdaq 注意:这是python3的代码
客户端:udpClient.py 需要将YOUR_SERVER_IP改为自己服务器的真实ip
|
@cjjdaq |
封锁策略又变为 |
@linhua55 会不会是路由器本身的问题,比如这个参数太小 net.core.rmem_max = 26214400 启动的时候,有没有出现setsocket buffer报错 |
[root@5K-W20:/proc/sys/net/core]#cat rmem_default 这是我的路由器上的值,确实比你小很多。会影响吗? 启动的时候,setsocket buffer不会报错。 |
kcptun默认是设置4MB, 如果太小,udp包太快,kcp处理太慢,可能会内核丢包。 |
这种丢包能通过什么数据看到吗?我最近开了FEC,流量一大以后路由器的CPU必定满载。 |
/proc/net/snmp应该能看到 |
@xtaci 路由器不受我控制。 服务端的话,用tcpdump查看了,有发出去的包,但在客户端用tcpdump查看只有发出去的包没有进来的包 |
自家的话,我觉得排查下路由是有必要的,这个状况,要么ISP要么路由,必有其一要背这个锅。 |
现在连TCP 443端口也限制了,使用原生的Shadowsocks没有速度, 必须使用带混淆功能的ShadowsocksR。 配合net-speeder (双倍发包),竟然也能达到自身带宽的一半速度。但是这种无脑双倍发包还是浪费带宽。 搜索了一下 单/双边加速方案, 发现似乎可以在openvz上实现 用户态的网络协议栈(user space network stack)。 然后看到了这一句话:
http://blog.csdn.net/dog250/article/details/53730374 改协议号说不定可行!!! 当然,改协议号之后还得混淆(成http/https流量) |
初步实现了 用TCP传输UDP(不进行三次握手),通过使用raw socket(/pcap)(需要以root运行) 伪造数据包类型,绕过正常的内核协议栈。 但还没进行混淆 不过测试一下,带宽利用率还没有net-speeder高(即不到一半带宽),可能是参数没调好,或该程序有bug |
https://github.com/linhua55/some_kcptun_tools/tree/master/relayRawSocket |
借鉴了 https://github.com/linhua55/some_kcptun_tools/tree/master/relayRawSocket ,使用raw socket和libev,远端通信为伪TCP报文,重新实现了kcptun的最基本功能(未实现加密和纠错等,仍在测试),只需一个程序即可,不需要再另外建立UDP over TCP隧道,不容易“卡住”,欢迎试用 |
借鉴了楼上的relayRawSocket和kcptun-raw。 |
wangyu你好,请问客户端支持Windows平台吗
在 2017-08-10 12:51:30,"wangyu-" <notifications@github.com> 写道:
借鉴了楼上的relayRawSocket和kcptun-raw。
专门应对UDP 封锁和UDP QoS 的通用解决方案。用raw socket把udp协议包装成tcp,有模拟3次握手,模拟序号,模拟tcp option;还可以把流量包装成icmp。支持几乎任何udp应用。包括kcptun和finalspeed。支持openvz。稳定。
https://github.com/wangyu-/udp2raw-tunnel
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@HongdaWang 暂时没做windows客户端,但是windows配合vmware或者openwrt路由器可以稳定使用。 ==updated== |
好的,谢谢你的贡献,后边会有各平台gui客户端的,交给社区吧
在 2017-08-10 13:32:24,"wangyu-" <notifications@github.com> 写道:
@HongdaWang 暂时没做windows客户端,但是windows配合vmware或者openwrt路由器可以稳定使用。
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@wangyu- 感觉已经被你刷屏了 |
@ccsexyz 我把@ccsexyz的项目也贴出来 ,https://github.com/ccsexyz/tunnel 。 跟udp2raw 比侧重点不同,各有优劣。 |
@wangyu- 我的意思是贴一次就可以了,像Chion82那样。因为每回复一次就会给watch这个项目的人发一封邮件。 |
多谢提醒,我注意。之前我只注意到了回复issue会给issue的参与人员发一封邮件。没注意到会给watch项目的所有人发。 造成困扰,不好意思。 |
@wangyu- |
@sqwwqw5 这是个非常好的问题。 如果是普通的udp over tcp确实就失去意义了。 udp2raw只是给udp加上了伪造的tcp header,本质上还是udp,不存在udp over tcp的问题。 |
@xtaci 希望后面kcptun直接支持这样的功能啊,就不用我们各种配置了哈哈,这个有可能吗? |
VPS:搬瓦工
OS :Debian 7.0 x86_64
客户端版本=服务器版本 :0922
ssr版本:3.7.4.1
问题描述:最近这几天当我打开KCP和SS配合翻墙观看youtube视频时,开始没有什么问题,网速也很快,但是过了大概十分钟左右后,突然就不能翻墙了,此时我切换ss直连vps, 经测试连接没有问题。在这种无法使用kcp的情况下,经过大概半小时 我再测试使用kcp配合翻墙,发现又可以使用了。请问这是为什么呢?
PS: 我在网上查询相关问题时 有不少人遇到和我类似的问题,有人说是isp封锁了UDP端口 (不知道对错)
谢谢您的帮助,感激不尽
(客户端参数未调整,只是用的ssr版本的shadowsocks,把UDP over TCP 勾选后(见楼下图),经过我接近三个小时的youtube视频播放测试,之前的视频播放一段时间就断开现象没有遇到,之后的几天,该问题也没有遇到。所以我认为这应该算是一个解决方案吧。逃)
update:最近我的ssr即使打开 UDP over TCP 也是会看一会视频就断开 过几天试试降低MTU值
The text was updated successfully, but these errors were encountered: