mirror of
https://github.com/fatedier/frp.git
synced 2026-05-15 08:05:49 -06:00
[GH-ISSUE #1657] work connection closed before response StartWorkConn message: EOF #1313
Labels
No labels
In Progress
WIP
WaitingForInfo
bug
doc
duplicate
easy
enhancement
future
help wanted
invalid
lifecycle/stale
need-issue-template
need-usage-help
no plan
proposal
pull-request
question
todo
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/frp#1313
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @windowscv on GitHub (Feb 16, 2020).
Original GitHub issue: https://github.com/fatedier/frp/issues/1657
Issue is only used for submiting bug report and documents typo. If there are same issues or answers can be found in documents, we will close it directly.
(为了节约时间,提高处理问题的效率,不按照格式填写的 issue 将会直接关闭。)
(请不要在 issue 评论中出现无意义的 加1,我也是 等内容,将会被直接删除。)
(由于个人精力有限,和系统环境,网络环境等相关的求助问题请转至其他论坛或社交平台。)
Use the commands below to provide key information from your environment:
You do NOT have to include this information if this is a FEATURE REQUEST
What version of frp are you using (./frpc -v or ./frps -v)?
frps 0.31.2
frpc 0.31.2
What operating system and processor architecture are you using (
go env)?centos 7.3+bbr fq
Configures you used:
FRPS:
FRPC:
Steps to reproduce the issue:
1.在两台机器连接测试 香港-香港,出现错误
work connection closed before response StartWorkConn message: EOF
read from workConn for udp error: EOF
和reconnect to server error: i/o deadline reached
其中第一个最为频繁
2.在一台本地机器同时安装frpc和frps进行测试
Describe the results you received:
以下是本地测试的结果
Describe the results you expected:
有可能是多路复用导致的吗
Additional information you deem important (e.g. issue happens only occasionally):
发生错误后断开
Can you point out what caused this issue (optional)
@fatedier commented on GitHub (Feb 16, 2020):
log_level 设置为 trace,然后 frpc 和 frps 的日志都贴一下。
@windowscv commented on GitHub (Feb 16, 2020):
特地设置了时区..但是好像没生效,frps里写了authentication_timeout = 0
FRPC
FRPS
@fatedier commented on GitHub (Feb 17, 2020):
你贴的 frpc 和 frps 的日志的 RunID 对不上,最好贴一下同一时间点的日志。
@windowscv commented on GitHub (Feb 17, 2020):
不知道为什么,在同一台机器的环境测试,清除了日志的,时间线还是不同..但是日志确实是同一时间的
@fatedier commented on GitHub (Feb 18, 2020):
@as1543100166 时间其实还好,主要是 RunID,每次客户端连上服务端后,服务端会主动分配一个 RunID,表征这个客户端,服务端和客户端打印的日志都会加上这个 id,用来判断打印出的日志对应的是哪个客户端和哪次连接。
RunID 不一样,说明打印出的日志可能对应不上。
@windowscv commented on GitHub (Feb 18, 2020):
@fatedier
FRPS
FRPC
问题似乎出在
2020/02/18 13:41:58 [D] [control.go:219] [5f0704510c2134ce] work connection pool is full, discarding@windowscv commented on GitHub (Feb 21, 2020):
@fatedier
或许发现了问题 我的理解中 pool_count = 1 这个参数的意思是预先链接,如果有需要就从队列中取出一个链接使用,然后再新建到参数设置的链接上限,这样始终有活动的链接可用
但是实际上,同时只会有一个链接可用....如果超了就会报错
更改为更大,或者为0即修复了这个问题
@fatedier commented on GitHub (Feb 21, 2020):
@as1543100166 正常情况下,是保持这么多个数的连接,取出一个,就请求再建立一个。在某些异常情况下,会请求的次数过多,这样就丢弃多出的连接(这个并不会对实际使用造成影响)。
这个报错只是丢弃了多出的连接,和你遇到的 i/o deadline 以及其他的网络问题没有关系的。后续可以考虑增加这个 pool_count 的默认值,或者不打印出这个错误了。
@windowscv commented on GitHub (Feb 21, 2020):
@fatedier
还是会出现这个问题,出现这个错误后就会断开
还有我这里一个frps连接了多个frpc,我发现在其他frpc重连时,其他所有的都会断开(好像)
准备详细测试下..
@fatedier commented on GitHub (Feb 21, 2020):
@as1543100166 还是日志级别设置为 trace,如果在本地测试的时候能复现,可以把测试的配置贴出来,我这里自己复现一下。
@fatedier commented on GitHub (Feb 25, 2020):
@as1543100166 有进展吗?
@windowscv commented on GitHub (Feb 25, 2020):
@fatedier
我这边暂时解决了,我把tcp_mux关闭之后,基本上解决了(很少出现断开,除非是心跳失败)
具体原因未知(怀疑是多路复用的心跳失败了)
@fatedier commented on GitHub (Feb 25, 2020):
@as1543100166 恩,多路复用这块目前用的是第三方库,自己本身会有一个心跳检测,时间间隔比 frp 自身的心跳更短一些。如果网络有波动的话,心跳失败就会断开连接。我主要关心的是在单机环境下,是否能够复现这个问题。
@windowscv commented on GitHub (Feb 25, 2020):
@fatedier
这是我在本地环境下刚刚测试的,开启tcp_mux之后frpc依旧会报错(但是好像并不会断开,没有测试关闭之后有没有报错)
我之前的问题应该就是丢包导致多路复用心跳失败的锅了
frps
FRPc
@fatedier commented on GitHub (Feb 25, 2020):
@as1543100166 你这个单机的测试,基本上是没有问题的,这个报错可以忽略的,不影响,之后的版本中会考虑优化一下,这样的情况就不打印错误日志了。
@wangjintianya commented on GitHub (Feb 23, 2023):
这个问题后面修复了吗