java mqtt丢包_MQTT 3.1协议非严肃反思录

前言

MQTT 3.1协议在弱网络环境下(比如2G/3G等)表现不够好，因此才有了反思。

弱网环境下表现

手机等终端在弱网络环境下丢包情况会非常明显，连接MQTT Server成功率很低。相比单纯的请求-相应模型的HTTP，其成功率会比MQTT订阅成功高很多。

手机终端在每次TCP断开或断网后，会即刻发起TCP重连，连接成功，会重复以前步骤依次发送连接命令(CONNECT)，订阅命令(SUBSCRIBLE)，表明上看，这些过程没有任何问题，但问题就在于从终端成功建立到服务器的连接，到发送订阅命令，在弱网情况下，这个过程将会变得很昂贵：从TCP建立开始的三次握手到完整的订阅命令发送完毕，考虑到TCP堆栈的每次接收数据方响应ACK，这中间终端和服务器端至少产生了10次数据交互。

在网络变化频繁或者不太稳定的2G/3G网络环境下，这种过程显得有些冗长和不适应，同时会加重已经不堪的弱网络负载的负担。

弱网下，在任何一个阶段的执行过程中，都有可能产生突发性的网络中断的问题：

无法成功建立TCP链接，或死在三次握手期间，或数据包丢失在握手之后，或客户端连接超时过小

建立连接后，发送CONNECT命令后，或没接收到TCP ACK确认包，或客户端等待延时太小，导致订阅命令交互失败

发送SUBSCRIBLE命令后，但服务器端没收到，或因为丢包，或网络已断开，导致发送SUBSCRIBLE命令失败

成功发送SUBSCRIBLE命令后，或移动网络断开了(有些运营商针对认为HTTP的请求有超时