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

[meshell]

目前问题是这样的如果发送的消息不是 OpText,OpBinary 这两种类型的话，连接会在 30 秒自动断开。

我定时不管是服务端还是客户端发送 opPing 也会断开。

只有一直定时发 OpText,OpBinary 这两种类型才不会断开。

看了源码也没有发现这个 30 秒在那里设置的。

库是: github.com/gobwas/ws

[hxzhouh1]

有没有可能是防火墙干的？ 抓包看看？

[hxzhouh1]

有没有可能是防火墙干的？ 抓包看看？
@hxzhouh1 我遇到过某个环境，网关/防火墙 会 90s 定时把 stream 断掉

[OneMan]

排除法，防火墙检查，换另外服务端测试，换另外客户端测试。
目测可能是服务端代码，有 30 秒的检查

[meshell]

@hxzhouh1 我是 mac 应该没有这么一说吧。我把本地的代理关了也是一样的。

[meshell]

@OneMan 目前两端都是 go 程序测试的，我试试浏览器不发 text,bin 测试下。

[david98]

可以抓一下包 配置成明文的 websocket 信道 可以看看到底是哪里出的问题

[kuanat]

我没有用过这个库，随便猜测一下。

理论上 ws 这种应用层协议，没有主动关闭行为，是不会在自己层面关闭连接的。底层的 tcp 在没有 keepalive 介入的情况下，连接建立后能够无限保持。ws 库在收到关闭信号之后，会向更底层传递这个信号，于是 http 到 tcp 都会关闭相应 socket 。

上面的意思是，这个行为不是 ws 库和你的程序主动行为造成的。

我看到你说有定时发送 ping ，那么另一端是否有回应 pong 呢？如果没有回应的话会出现一种情况，接收方会保持正常，而发送方连续 30s 只有发送而没有接收，触发了更底层协议的某个断开机制。

正好 golang net/http 默认 transport 超时就是 30s 。如果上面的库是基于标准库实现的话，可能就是 http 层先断开了。

[meshell]

@kuanat 我客户端定时发得 ping 。服务端收到之后也回发 pong 。但是还是会 30 秒断开 。。。。

[Ipsum]

本地测试，如果没有断估计就是防火墙问题了。有些防火墙为了节省资源空闲 90s 就强制断

[hellodudu86]

听着像 timeout deadline 之类的问题

[meshell]

@hellodudu86 目录这个只有 read deadline, 和 write deadline 这两个没有设置的。

[Ericcccccccc]

30s 这种很像是保活的问题，你把框架的参数一个一个拿出来仔细看看。

[hellodudu86]

我一般的排查思路是，先确定是客户端还是服务器主动断开，这一点可以在 conn 的 read 或者 write 接口调用返回时打印 err 得知。然后固定 30 秒就断开非常像设置了 conn 的 read 或者 write deadline ，也很有可能是传递上下文的 context 设置了 30 秒的超时，建议重点查下这两块地方。

[tairan2006]

可以加个应用层心跳

debug 的话，你要看一下整个网络链路，比如是不是中间的 LB 把连接给断了……

[meshell]

@hellodudu86 特意看了 context 这个 context.Background()这个是没有超时的。read 都是设置的 是 0 ，write 都没有设置。。。我都要崩溃了。。。

[meshell]

@tairan2006 ping,pong 就是吧。还是 ？

[meshell]

@kuanat 大佬没有看到你说得这个 。。“ 正好 golang net/http 默认 transport 超时就是 30s 。”，关键我也不是用得 http.client

[cgtx]

小王，我是张总，这个问题你都要上 v2 来问，昨天你给我的保证让我很不能信服啊。明天来办一下离职手续吧。

[wwqgtxx]

个人建议你写一个最小复现代码挂 gist 上让大家伙试试

[mango88]

用 github 给的 server 示例，没复现你的问题