你的问题：其实是你客户端跟服务端，对TCP协议的原理了解的不够导致的。

TCP连接正常建立后：包括你客户端崩溃、非正常退出、网络链路中间的任何一个环节断掉，你服务端是无法及时感知到的。

而且，像网络链路中，某个路由断开，然后又恢复的情况下，是不影响你TCP的通信的。

所以，基于种种网络复杂性，单靠TCP协议本身，是无法做到精确感知网络连接是否真的正常、或已断开。

一个主流的作法是：你应该加一个消息重传机制，也就是，当出现上面这些服务端误判对方在线，而错误的将消息以对方“在线”的逻辑发送出去时，有个补救措施。

你可以去参考一下MobileIMSDK工程 ，它里面有有完整的心跳、QoS消息送达保证机制，你可以学习借鉴一下，应该能给你灵感。

引用：liang156com 发表于 2020-10-15 12:26
其实我的真正问题不是丢消息，这样不得不跟你说下我们的消息补偿机制了，我们现在每发送一条消息给客户端都 ...

这种情况，其实没有其它更好的办法

引用：magicnana999 发表于 2020-11-12 10:51
我觉得吧，还得在“如何准确的知晓客户端状态” 上，做些修改。
1 如果用 netty 的话，有默认的心跳机制， ...

“ 心跳机制有个时间间隔，如果刚好在时间间隔内，客户端掉线，服务端还未正确感知到，那么推送的时候会返回连接已关闭，这时手动修改客户端状态为已离线就好。”：
》这个怕是不容易办到，因为现在像netty这种服务端框架，数据发送都是异步送出，连接是否已关闭是不好直接获取的。而且对于非正常关闭的半开连接，服务端也是不知道的，它只当网络有问题，进入TCP的重传队列了，不会立即返回结果的。

引用：magicnana999 发表于 2020-11-12 14:21
刚翻了下netty 代码（java），发送消息的时候，可以注册一个监听，当最终结果到达的时候，可以做后续的处理 ...

对于netty来说，主要还是依赖于超时机制，但超时的话那就是多少秒之后的事情了，时间差还是免不了.
你看Netty源码的话，不用打开开发工具，可以直接用我编译的这个在线版本，网页里直接看：http://docs.52im.net/extend/docs/src/netty4_1/