V2ray-core: kcp断流问题

Created on 5 Jul 2016  ·  22Comments  ·  Source: v2ray/v2ray-core

20160705140212
wget挂http代理下载大文件必定会断流
firefox socks代理下载大文件也会断流
客户端/服务端都无报错 版本:1.18,1.18.2
kcp连接方法 拥塞控制:关闭 服务端uplinkCapacity设置为29 客户端downlinkCapacity为40 mtu:1400. 开启了动态端口

Most helpful comment

做一个反馈。
我的服务器端使用的是1.21.1,在使用动态端口的情况下(kcp连接),刚配置好时没有问题,但是如果长时间空置(比如人离开电脑一个小时,或者关机一个晚上),再次使用时就无法连接,此时无论是重启服务器中的v2ray还是重启服务器,甚至将动态端口重新改为静态端口,都连接不上(这里指1.21和1.21.1两个版本的client)。检查server端,发现使用动态端口时一直重复警告信息“[Warning]Point: Unable to find an inbound handler with tag: detour”,而client端在等待较长时间(如5min)后,有一定概率出现警告"VMess|outbound: Failed to read response from tcp:xxx.xxxx.xxx:443: EOF"或"VMess|outbound: Failed to read response from udp:8.8.4.4:53: EOF"。国外网站一直不能连通。
可是奇怪的是,如果我使用1.18.2版本的client(版本都是windows 64位,使用win7 64位系统),此时能够连通国外网站,但是相比之前,速度慢许多。
最新的结果是,在这样的情况下,能使用的最新客户端是1.19.2,速度比1.18.2快不少。

All 22 comments

downlinkCapacity设为2试试

删除了kcp的额外设置也会断流,我2台VPS不同线路, 都存在这个问题,今天测试了1.17.1发现也会断流, wget下一半就断流了,kcp+ss就不断流.
刚在内网用2台电脑间传输测试没发现断流.

初步认为是内部 race condition 导致的数据错乱,不过我暂时还不能重现。有待进一步调查。

要不我给你个配置文件 你去试试? 新买了台VPS做测试

如果你能分享一下 SSH 登录信息就更好了。不过我无法保证测试的时间,可能到周末才有空。

我邮件给你吧, 注意查收
另外还有个bug 服务器 配置文件检查无错误但是无法启动 命令敲完出现
V2Ray v1.18.2 (New Order) 20160704
An unified platform for anti-censorship.
进程就结束了
另外alterId的数量跟连接速度有关系么?

正在试用你的机器,你的 detour1 所对应的 inbound 的 protocol 没写,我帮你补上了。至于为什么没有 log 这一点很奇怪,在 mac os 上是有的。

alterId 和速度没关系,alterId 的数量和内存有关系,但如果不大于 100,应该观察不到内存的变化。

今天从shadowsocks-go + kcptun 换到 v2ray,开了kcp,结果几个小时后还是换回去了,原因:

  1. 建立连接太慢,服务端,客户端都是冷启动的话,首次打开推特要10多秒,ss+kcp差不多秒开.
  2. 速度太慢,之前可以看youtube 1080p,v2ray 看720p都有些卡,开了kcp阻塞控制,参数(1,100/20,20).
  3. 稳定性太差,待机十几分钟半小时后,很大几率就再也连不上了,而ss+kcp 只有休眠恢复后才会死掉.

以上不知道是我的设置有问题还是网络有问题?非专业人士不太会判断。

另外有个问题,动态端口是不是不能和shadowsocks 同时启用?

@Rememberli V2Ray 版本? 1.18.2?

  1. 看上去像是 DNS 的问题,你可以把客户端配置文件中的 "domainStrategy": "IPIfNonMatch" 删掉试试。
  2. 如果是 1.18.2,看一下 Youtube 的 Stats for Nerds,如果速度是平稳的,可以提高服务器端的 uplinkCapacity 试试。
  3. 待机是什么意思?浏览器关闭十几分钟,还是浏览器开着视频暂停?
  4. 动态端口和 Shadowsocks 是互相独立的,Shadowsocks 不能使用动态端口功能;VMess 动态端口和 Shadowsocks 可以同时开启;

断流问题依然存在..
20160711103018

vmess+kcptun的客户端就不断流
20160711122903
会不会是这个原因引起的?

我昨天没仔细看,你的 VPS 上是开启了动态端口是么?上述断流也是发生在使用动态端口的时候?

@v2ray

待机就是关掉浏览器电脑不用,大概十几分钟就不行了。
我把我的配置文件email发给你,你有空帮忙仔细看看有没有什么问题好了,另外我试了增加动态端口的配置,结果失败,可以一并告诉我怎么改动态端口,谢谢!

我好像应该另开一个issue:P

对启用了动态端口,我主要都在用动态端口。 静态的kcp刚测试过没问题,动态端口的kcp有问题,无论同时开启几个端口,都会断流。 那台机器是专门给你测试的,我一般很少用

还是关于内存的问题
版本:1.19.2 kcp 静态端口 alterId:100
使用方式:bittorrent 浏览器youtube wget杂七杂八的下载流量都走vmess 流量一般都在2MB/s
我在服务器上挂客户端一段时候后进程的内存占用会越来越高 。
基本2到3天就到500-600MB了
有时候传输300MB的东西内存涨幅在100MB左右,大概用了400个连接 。
这服务器还跑了2个数据库在,内存硬盘io都比较吃紧,不想频繁重启客户端。
能把整体占用控制在100MB内么? 整体50MB就能在路由器上部署了。
go语言难道也是不会释放内存么? 另外动态端口的kcp断流有修复么?

  1. 关于断流的问题,1.20 中又做了一点点修复,我的测试中完全看不到断流的现象。你碰到的情况可能是因为 1) 动态端口刷新时候会切断之前端口上的连接 2) 服务器端的 V2Ray 重启了(在 panic 的时候 V2Ray 会自动重启),重启完由于之前的 session 丢失,导致断流
  2. 服务器内存过高是一个已知问题,正在修复。1.20 新增了两个选项 readBufferSize 和 writeBufferSize,并调小了默认值(之前是 4),可以用于减少内存的占用。客户端应该不会有那么高,如果你的客户端占用超过 100 MB,请新开一个 issue。

内存释放的问题大致是这样的,Go 的垃圾回收并不是用完立即回收的,而是有某种触发机制。V2Ray 的某些做法刚好让 Go 认为这些内存之后还需要继续使用,就没有释放。在服务器端 V2Ray 没办法判断之后还有没有大量的并发连接,于是就不能及时地释放内存。

顺便我想问一下,你的 400 个连接是并发的还是有先后的?每个连接的速度都有 2MB/s?

应该是并发的, 一起2MB/s
等下晚上测试下降低下alterid数量测试下1.20

20160718133139
最新版动态端口的kcp还是断流
有必要去学学go了
感觉端口的变化并不能降低被识别特征的概率..
接着测试内存问题 alterId:30 缓存配置默认
bt下了3个新番. 高并发导致内存上升至320M
20160718135936
然后看youtube wget下点东西后内存占用下降到170M
20160718141057
目前148M
qq 20160718144700

我是说把动态端口关掉,在动态端口刷新的时候,一定会造成断流的。如果你要下载大文件,可以配置一个单独的连接到主端口来下载,然后其它的请求继续使用动态端口。

嗯 明白了

做一个反馈。
我的服务器端使用的是1.21.1,在使用动态端口的情况下(kcp连接),刚配置好时没有问题,但是如果长时间空置(比如人离开电脑一个小时,或者关机一个晚上),再次使用时就无法连接,此时无论是重启服务器中的v2ray还是重启服务器,甚至将动态端口重新改为静态端口,都连接不上(这里指1.21和1.21.1两个版本的client)。检查server端,发现使用动态端口时一直重复警告信息“[Warning]Point: Unable to find an inbound handler with tag: detour”,而client端在等待较长时间(如5min)后,有一定概率出现警告"VMess|outbound: Failed to read response from tcp:xxx.xxxx.xxx:443: EOF"或"VMess|outbound: Failed to read response from udp:8.8.4.4:53: EOF"。国外网站一直不能连通。
可是奇怪的是,如果我使用1.18.2版本的client(版本都是windows 64位,使用win7 64位系统),此时能够连通国外网站,但是相比之前,速度慢许多。
最新的结果是,在这样的情况下,能使用的最新客户端是1.19.2,速度比1.18.2快不少。

应该已经修复。

发现一种可能的断流原因

服务端配置的时候没有给 user 配置 security,这时应该默认的 security 为 auto,按照文档描述运行框架为amd64和s390x时为aes-128-gcm加密方式,其他情况则为chacha20-poly1305加密方式

客户端使用 v2rayx,默认的 security 为 aes-128-cfb

其他参数配置正确的情况下,如果客户端 security 配置为 aes-128-cfb 时,可以正常连接使用,但是下载大文件会断流;客户端 security 修改为 aes-128-gcm 则一切正常。

Was this page helpful?
0 / 5 - 0 ratings