背景： 设备支持MQTT协议，主动推送设备消息到MQTT服务器。 设备定义了上线消息和下线消息，下线消息由"遗嘱"消息来实现，上线消息由设备发送，当客户端重连时，会主动发送上线请求。 业务服务器订阅MQTT服务器，来接受设备的消息。
问题： 发现上下线消息时混乱的，即业务服务器收到设备的下线消息，但是设备仍然在推送消息，似乎并没有下线。
思考： 谁来发送"遗嘱"下线消息？
MQTT服务器 MQTT服务器如何判断是否下线？ 遗嘱消息发布的条件，包括但不限于： 服务端检测到了一个I/O错误或者网络故障。 客户端在保持连接（Keep Alive）的时间内未能通讯。 客户端没有先发送DISCONNECT报文直接关闭了网络连接。 由于协议错误服务端关闭了网络连接。 重启设备判断什么条件才会触发"遗嘱"？
断开设备后，MQTT服务器并不会 立刻发送 "遗嘱"消息，而是在一段时间后，即心跳时间(上述第二种)后才会触发"遗嘱"消息，这很好理解，断电后服务器啥消息都没收到，就会认为客户端其实没有断开。 wireshark能拯救世界！
重启设备后，一段时间，MQTT服务器下发了一条“下线”消息，我通过wireshark仔细分析，结果有一条非常有意思的消息！
MQTT服务器一直向设备发送"挥手“报文(断开连接第一步)，但设备压根不管，仍然一直向MQTT服务器发送数据，而且MQTT服务器仍然一直接收数据。
思考： 这是谁的问题？
我知道"挥手"报文是tcp协议规定，也就是“挥手“的处理层是传输层处理，而传输层的处理肯定和MQTT服务器无关。至于传输层会出现bug这种事情，我简直不敢想。 也就是最大的可能是客户端。但是传输层出现问题，这怎么可能？？？？ 定睛一看（每次在这种细节上，我总是不够细心，或许这是我的一个属性吧）
我观察了很久，突然发现一个非常“震惊”的消息。

我发现MQTT服务器回客户端"挥手"消息(灰色的那条)的端口是3340，而MQTT服务器回客户端ack消息的端口是3344，这怎么可能？
深思熟虑后，以及对比多家开源MQTT服务器后，我终于发现真正问题 。
MQTT的遗嘱判断非常简单，只要判断连接断开就立刻发送遗嘱消息，不需要判断全部存活的连接中，是否包含相同的clientID 对整个bug流程梳理。
设备在某段时间掉电，然后又重新连接了。此时设备发送上线消息，但是MQTT服务器在一段时间后，终于判断连接断开，从而发送下线消息。
解决方法： 放弃"遗嘱"消息，通过一段时间是否收到业务据来判断客户端是否“宕机”。 自己实现MQTT服务器，每次发送遗嘱消息时，对整个active连接判断是否有相同的clientID，我一直都是这么做的。 生成一个随机值A，对遗嘱消息进行修改，遗嘱消息都带上一个A。对上线消息进行修改，带上一个A。
当业务服务器，收到上线消息时，要把clientID和随机值A绑定存下来，获得下线消息时，从里面取出随机值，和当前的clientID绑定的随机值对比，如果相同则说明确实下线，如果不相同，则说明这是上个连接的值。