了不起的 MQTT 物联网协议

MQTT是在低带宽高延迟不可靠的网络下进行数据相对可靠传输的应用层协议。 MQTT的核心思想是简单并适应物联网环境。

诞生时间

TCP协议诞生于1974年冷战期间。 MQTT诞生于1999年互联网初期，TCP协议比MQTT协议诞生早了25年。 Ashton提出IoT概念也是在1999年，因此MQTT协议生逢其时。当时MIT Auto-ID Labs的Kevin Ashton为了把宝洁的供应链上的RFID标签和互联网连接起来，在1999年第一个提出了IoT这个概念。

发明起因

TCP协议和MQTT协议的设计都与卫星通信有着直接的联系。 1972年时，Kahn在IPTO公司参与了一个卫星通信网络项目，他就搞了个子项目来搭建卫星基站的无线电数据包通信网络。 有了这个项目的经验，他发现有必要开发一个通用的开放架构的网络模型，从而让不同软硬件的网络都可以互相通信。

在1973年Vinton Cerf也参与了这个项目，他们俩于同年实现了TCP的第一个版本。1974年的时候，TCP协议规范正式发布，编号为RFC 675。 在20世纪90年代中期IBM在帮助石油和天然气公司客户设计有效的数据传输协议时，就出现了对MQTT这种物联网环境下的数据传输协议的需求。

当时，为了实现数千英里长的石油和天然气管道的无人值守监控，采取的设计方案是将管道上的传感器数据通过卫星通信传输到监控中心。

这种应用场景有如下几个特点：

• 石油天然气管道线路非常长，要接许多沿线的数据采集网关；
• 服务器要能接成千上万个通信客户端；
• 石油管道传感器的数据采集频率不高，
• 不需要一下子传输大量数据；
• 现场采集网关由于量大，考虑到采购成本，CPU和存储等计算资源都很有限；
• 石油管道会穿越很多无人区，附近没有网络设施，因此使用卫星通讯最为经济；
• 高轨道的GEO卫星站得高看得远，覆盖范围广，但轨道高延迟就大了。中低轨道的LEO/MEO卫星延迟小，但是覆盖区域有限，每天都会出现卫星切换时的网络中断。因此需要客户端和服务器端都能够保留消息收发状态，在网络恢复正常后继续发送；
• 卫星链路带宽低（当然也有高带宽的），通信流量费用高昂；因此需要尽量节省传输的消息的流量开销；
• 有些数据发送失败，不需要重发。但是有些消息比如阀门泄露告警或控制石油管道阀门的命令，就必须要在网络有问题的情况下也要能确保发送成功。

因此，针对石油管道传感器和控制装置数据采集和控制设计的传输协议，需要满足如下要求：

• 服务器要能接成千上万个客户端；每次消息传输的数据量不大；
• 协议客户端软件要能在CPU和存储等计算资源都很有限的单片机、单板机、RTU等上运行；
• 并能方便的实现移植到不同的硬件上；
• 带宽低，通信流量费用高昂；需要最大限度地减少传输消息大小；
• 卫星不会24小时都覆盖得到，会有段时间发生卫星通信中断；
• 预期会遇到频繁的网络中断（低带宽，高延迟，不可靠，高成本运行的网络），需要传输协议能够异步管理消息。
• 在卫星通信中断时：MQTT网络中的服务器/代理可以保存和转发从客户端到客户端的消息，如果断开连接，它将能够在以后重新连接时获取消息。
• 在环境允许的情况下提供传统的消息服务质量。提供不同等级的“服务质量”。

协议位置

TCP是OSI第四层的传输层协议。 MQTT是基于TCP的七层应用层协议。

协议定位

TCP设计考虑的是面向连接的、可靠的、基于字节流的传输层通信协议。 MQTT则是在低带宽高延迟不可靠的网络下进行数据相对可靠传输的应用层协议。

设计思想

TCP的核心思想是分组交换。 MQTT的核心思想是简单并适应物联网环境。

传输单位

TCP的传输单位是packet，当应用层向TCP层发送用于网间传输的、用8位字节表示的数据流，TCP则把数据流分割成适当长度的报文段，最大传输段大小（MSS）通常受该计算机连接的网络的数据链路层的最大传送单元（MTU）限制。 MQTT的传输单位是消息，每条消息字节上限在MQTT Broker代理服务器上进行设置，可以设置超过1M大小的消息上限。

技术挑战

TCP需要解决的问题是在IP包传输过程中，处理异构网络环境下的网络拥塞、丢包、乱序、重复包等多种问题。 MQTT解决的问题是，在低带宽高延迟不可靠的网络下和资源有限的硬件环境内，进行相对可靠的数据传输。

服务质量

TCP是一个可靠的流传输服务，通过ACK确认和重传机制，能够保证发送的所有字节在接收时是完全一样的，并且字节顺序也是正确的。 MQTT提供三种可选的消息发布的QoS服务等级。MQTT客户端和MQTT代理服务器通过session机制保证消息的传输可靠性。开发人员可以根据业务需要选择其中一种。