如何解决 go grpc: connection reset by peer 的问题?
- 内容介绍
- 文章标签
- 相关推荐
本文共计928个文字,预计阅读时间需要4分钟。
最近添加的推送功能直接反射,他手下的设备以grpc+stream的方式向我服务端发送数据。偶尔会收到错误。现象如下:+ 已建立了一段时间的连接,正常使用。+ 突然client.Send返回eof。+ 客户端有报错:
最近添哥一直反映,他手下的设备以grpc stream的方式向我服务端发送数据。偶然会收到错误。现象如下:
- 连接已经建立了一段时间,正常使用。
- 突然client.Send 返回 eof。
- 客户端有报错:connection reset by peer
- 在服务端找到错误:context canceled
这里不得不提一下,客户端上报到服务的网络环境并不是很好,而且服务端每个进程有数十万个协程在运行,处理上十万条grpc stream。
选取了几个设备在服务端与客户端tcpdump,通过七七四十九天,终于捕获到了异常时的抓包。
现象:
- 正常情况下,服务端客户端定期互Ping。
- 当异常时,在服务端/客户端的抓包会发现Ping包未回。很快连接断开。
猜测和grpc keepalive功能有关。
本文共计928个文字,预计阅读时间需要4分钟。
最近添加的推送功能直接反射,他手下的设备以grpc+stream的方式向我服务端发送数据。偶尔会收到错误。现象如下:+ 已建立了一段时间的连接,正常使用。+ 突然client.Send返回eof。+ 客户端有报错:
最近添哥一直反映,他手下的设备以grpc stream的方式向我服务端发送数据。偶然会收到错误。现象如下:
- 连接已经建立了一段时间,正常使用。
- 突然client.Send 返回 eof。
- 客户端有报错:connection reset by peer
- 在服务端找到错误:context canceled
这里不得不提一下,客户端上报到服务的网络环境并不是很好,而且服务端每个进程有数十万个协程在运行,处理上十万条grpc stream。
选取了几个设备在服务端与客户端tcpdump,通过七七四十九天,终于捕获到了异常时的抓包。
现象:
- 正常情况下,服务端客户端定期互Ping。
- 当异常时,在服务端/客户端的抓包会发现Ping包未回。很快连接断开。
猜测和grpc keepalive功能有关。

