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的请求有超时判断），或等待超时，导致订阅失败
TCP是无感知的虚拟连接，中间断开两端不会立刻得到通知，否则就用不着心跳保活机制了。
举一个例子，线上的服务器根据日志分析，只接收到连接命令（CONNECT）但没有后续的订阅命令（SUBSCRIBLE）的情况，每天有上百万级别的数量。
总之，针对低速率弱网络环境，MQTT表现不怎么好。
业务改进点：
协议改进点：
有些建议看似冗余，批量或打包处理总比单个处理更高效一些、更节省资源，弱网络环境要求交互要尽可能的少，数据嘛要的是瞬间抵达，越快越好。
严格的分层和业务解耦，会导致性能问题。好比当前Linux内核的TCP/IP网络堆栈分层很清晰，每一层都各司其职，但和直接略过内核态直接运行在用户态(User Space)的Packet I/O相比，处理性能不是在一个档次上，比如Netmap 、DPDK等。
针对没有TCP/IP等网络堆栈支持的终端环境，MQTT爱莫能助了。
在一些类似于传感器电子元件中，资源十分受限，计算能力不足，嵌入TCP/IP网络堆栈不现实，比较好的方式基于IEEE 802.15.4用于低速无线个人域网(LR-WPAN)的物理层和媒体接入控制层规范之上发送UDP数据包，每一个数据包最大128个字节。
MQTT-SN（MQTT For Sensor Networks）协议就是为了非常受限类似传感器而设的，协议流程架构比较有趣：
更多协议细节，有待进一步阅读。
先来算一下网络传输的字节数。
以太网帧头至少18个字节，IP头固定20个字节，TCP头20个字节（UDP头部8个字节），再加上电信宽带计费的PPPoE的8个字节：
UDP可以比TCP节省12个字节。
MQTT-SN协议选择使用UDP，可以看出其在节省资源方面的努力。
再看看弱网环境。
在网络不好的情况下，UDP的时效性会好于TCP，TCP长连接中间交换过多、使之建立完整交互的过程成功率就很低。此种情况UDP的低延迟和实时性呈现的结果会表现的很突出。
TCP或HTTP理论上是可靠连接，但是在网络不好的时候，也不是那么可靠。客户端一般提交HTTP请求之后，没有确认是否提交成功，在弱网环境下会产生丢包，服务器端嘛收不到。另TCP网络堆栈会存在数据包重发机制 + 应用层重发请求，可能会导致内核处理多次数据包的重发（还有拥塞窗口会收缩，发包速度减慢），可能会加重弱网络的负载。
和TCP相比，UDP的无连接，代表了它快速，资源消耗小，突出表现就是延迟较小。至于数据包丢失没有重传，上层的业务层面应用协议/机制可以确保丢失的数据包重发或补发等，并且会更透明，安全的控性权。而TCP的包重发，上层应用没有控制权限。
连接协议方面：
总之，要实时性特诊，或者快速抵达终端的特性，不妨考虑一下UDP。不过呢，很多时候UDP和TCP大家会混合着使用，会互相弥补其不足。
若MQTT协议不能够满足业务需求，或许可考虑选择定制，或简化流程，或使用UDP重新实现，或者使用TCP／HTTP作为补充等，不一而足。
http://www.blogjava.net/yongboy/