有深入研究的 golang websocket 的大佬吗?遇到一个 30 秒自动断开的问题?

查看 274|回复 30
hellodudu86   
可以抓一下包 配置成明文的 websocket 信道 可以看看到底是哪里出的问题
meshell
OP
  
我没有用过这个库,随便猜测一下。
理论上 ws 这种应用层协议,没有主动关闭行为,是不会在自己层面关闭连接的。底层的 tcp 在没有 keepalive 介入的情况下,连接建立后能够无限保持。ws 库在收到关闭信号之后,会向更底层传递这个信号,于是 http 到 tcp 都会关闭相应 socket 。
上面的意思是,这个行为不是 ws 库和你的程序主动行为造成的。
我看到你说有定时发送 ping ,那么另一端是否有回应 pong 呢?如果没有回应的话会出现一种情况,接收方会保持正常,而发送方连续 30s 只有发送而没有接收,触发了更底层协议的某个断开机制。
正好 golang net/http 默认 transport 超时就是 30s 。如果上面的库是基于标准库实现的话,可能就是 http 层先断开了。
Ericcccccccc   
@kuanat 我客户端定时发得 ping 。服务端收到之后也回发 pong 。但是还是会 30 秒断开 。。。。
hellodudu86   
本地测试,如果没有断估计就是防火墙问题了。有些防火墙为了节省资源空闲 90s 就强制断
tairan2006   
听着像 timeout deadline 之类的问题
meshell
OP
  
@hellodudu86 目录这个只有 read deadline, 和 write deadline 这两个没有设置的。
meshell
OP
  
30s 这种很像是保活的问题,你把框架的参数一个一个拿出来仔细看看。
meshell
OP
  
我一般的排查思路是,先确定是客户端还是服务器主动断开,这一点可以在 conn 的 read 或者 write 接口调用返回时打印 err 得知。然后固定 30 秒就断开非常像设置了 conn 的 read 或者 write deadline ,也很有可能是传递上下文的 context 设置了 30 秒的超时,建议重点查下这两块地方。
cgtx   
可以加个应用层心跳
debug 的话,你要看一下整个网络链路,比如是不是中间的 LB 把连接给断了……
wwqgtxx   
@hellodudu86 特意看了 context 这个 context.Background()这个是没有超时的。read 都是设置的 是 0 ,write 都没有设置。。。我都要崩溃了。。。
您需要登录后才可以回帖 登录 | 立即注册

返回顶部