MQTT协议

MQTT

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输协议），是一种基于发布/订阅（Publish / Subscribe）模式的轻量级通讯协议，该协议构建于TCP/IP协议上。

MQTT协议运行于TCP之上，属于应用层协议，因此只要是支持TCP/IP协议栈的地方，都可以使用MQTT。

MQTT最大的优点在于可以以极少的代码和有限的带宽，为远程设备提供实时可靠的消息服务。做为一种低开销、低带宽占用的即时通讯协议，MQTT在物联网、小型设备、移动应用等方面有广泛的应用。在物联网开发中，MQTT不是唯一的选择，与MQTT互相竞争的协议有XMPP和CoAP协议等。

MQTT协议的中心是MQTT服务器或代理 （broker）：

每条MQTT命令消息的消息头都包含一个固定的报头，有些消息会携带一个可变报文头和一个负荷。消息格式如下：

1.Fixed header 固定报头，所有报文都包含

2.Variable header 可变报头，部分报文包含

3.Payload 有效载荷，部分报文包含

参考整理：https://blog.csdn.net/weixin_44060108/article/details/103629375 | https://blog.csdn.net/anxianfeng55555/article/details/80908795

固定报文头（Fixed Header）

MQTT固定报文头最少有两个字节:

1. 第一字节前4bit表示报文类型（Message Type），后4bit是QoS级别等报文类型的标志位。
2. 第二字节开始是剩余长度字段，该长度是后面的可变报文头加消息负载的总长度，该字段最多允许四个字节。

报文类型Message Type:

比如建立连接的前四位报文为0001,则转换成十进制=1,刚好对应上表中的CONNECT,也就是客户端请求连接服务端的意思。

报文标志

继续上面那个图,紧跟着Message Type为0001的 CONNECT 后面的后四位报文标志为0000,表示缺省（Reserved）,一般这四位用于标示发送重复数（DUP） （1字节） 、服务质量 （QoS） （2字节）、保留标志（RETAIN）（1字节）

DUP：发布消息的副本。用来在保证消息的可靠传输，如果设置为 1，则在下面的变长中增加MessageId，并且需要回复确认，以保证消息传输完成，但不能用于检测消息重复发送。

QoS看下一模块。

RETAIN：发布保留标识，表示服务器要保留这次推送的信息，如果有新的订阅者出现，就把这消息推送给它，如果设有那么推送至当前订阅者后释放。

举个例子，当发送一条(消息安全等级)QoS=2的消息时,固定报头的第一个字节为:

这里可以看到,前四位0011转换成10进制就是3也就是对应报文类型的3 PUBLISH也就是发布消息类型的报文
后四位0100,这里就不能转十进制了 ,可以直接对应报文标志图的四个(3210)比特位,这里很明显0100对应的是QoS2,
同理如果后四位是0010,那么对应就表示是一条QoS1的消息。

MQTT 中的 QoS 等级

作为最初用来在网络带宽窄、信号不稳定的环境下传输数据的协议，MQTT 设计了一套保证消息稳定传输的机制，包括消息应答、存储和重传。在这套机制下，提供了三种不同层次 QoS：

1. QoS0，At most once，至多一次。Sender 发送的一条消息，Receiver 最多能收到一次，也就是说 Sender 尽力向 Receiver 发送消息，如果发送失败，也就算了
2. QoS1，At least once，至少一次。Sender 发送的一条消息，Receiver 至少能收到一次，也就是说 Sender 向 Receiver 发送消息，如果发送失败，会继续重试，直到 Receiver 收到消息为止，但是因为重传的原因，Receiver 有可能会收到重复的消息
3. QoS2，Exactly once，确保只有一次。Sender 发送的一条消息，Receiver 确保能收到而且只收到一次，也就是说 Sender 尽力向 Receiver 发送消息，如果发送失败，会继续重试，直到 Receiver 收到消息为止，同时保证 Receiver 不会因为消息重传而收到重复的消息

要注意的是，QoS 是 Sender 和 Receiver 之间达成的协议，不是 Publisher 和 Subscriber 之间达成的协议。也就是说 Publisher 发布一条 QoS1 的消息，只能保证 Broker 能至少收到一次这个消息；至于对应的 Subscriber 能否至少收到一次这个消息，还要取决于 Subscriber 在 Subscribe 的时候和 Broker 协商的 QoS 等级。

剩余报文长度

表示本次报文的剩余长度（字节位数）

比如这个红色框的报文转换成十进制是29,则表示还有29个字节是本次报文的,绿色框则就是剩余的报文了,刚好是29个,不信你数数

剩余长度字段单个字节最大值为二进制0b0111 1111，16进制0x7F。也就是说，单个字节可以描述的最大长度是127字节。为什么不是256字节呢？因为MQTT协议规定，单个字节第八位（最高位）若为1，则表示后续还有字节存在，第八位起“延续位”的作用。

例如，数字64，编码为一个字节，十进制表示为64，十六进制表示为0×40。数字321（65+2*128）编码为两个字节，重要性最低的放在前面，第一个字节为65+128=193（0xC1），第二个字节是2（0x02），表示2×128。

由于MQTT协议最多只允许使用四个字节表示剩余长度（如下图），并且最后一字节最大值只能是0x7F不能是0xFF，所以能发送的最大消息长度是256MB，而不是512MB。

可变报文头（Variable Header）

可变报文头主要包含协议名、协议版本、连接标志（Connect Flags）、心跳间隔时间（Keep Alive timer）、连接返回码（Connect Return Code）、主题名（Topic Name）等。

根据MQTT文档说明，把所有相关的信息列出来。如下：

绿色的为用到的。红色表示没有用到的。

协议名

协议名是表示协议名 MQTT 的UTF-8编码的字符串。MQTT规范的后续版本不会改变这个字符串的偏移和长度。如果协议名不正确，服务端需要断开客户端的连接。

协议名格式如下：

CONNECT中的协议名

协议级别

协议级别通俗来讲就是协议的版本。

客户端用8位的无符号值表示协议的修订版本。对于3.1.1版协议，协议级别字段的值是4(0x04)。如果发现不支持的协议级别，服务端必须给发送一个返回码为0x01（不支持的协议级别）的CONNACK报文响应CONNECT报文，然后断开客户端的连接。

MQTT3.1.1的协议级别格式如下：

连接标志

连接标志字节包含一些用于指定MQTT连接行为的参数。它还指出payload字段是否存在。

连接标志的结构：

1.有效负载（playload）字段的存在与否并不是reserved字段来指定，而是will flag、user Name等字段。
比如：如果will flag为1，则负载中需要包含will topic、will message等字段。如果需要用户名密码，则负载中需要包含这些信息。

2.服务端必须验证CONNECT控制报文的保留标志位（第0位reserved）是否为0，如果不为0必须断开客户端连接

所有连接标志的意义：

Keep alive

其格式如下：

MSB表示最大有效位，LSB表示最小有效位。这里没有什么特殊含义，这里只是表示两个字节来描述Keep alive。至于官方文档中说明Keep Alive允许的最大值是18小时12分15秒，这是从2^16/3600=18.2044得出的。

Keep Alive说明：

1. 客户端负责保证控制报文发送的时间间隔不超过保持连接的值。如果没有任何其它的控制报文可以发送，客户端必须发送一个PINGREQ报文。不管保持连接的值是多少，客户端任何时候都可以发送PINGREQ报文，并且使用PINGRESP报文判断网络和服务端的活动状态。

2. 如果保持连接的值非零，并且服务端在一点五倍的保持连接时间内没有收到客户端的控制报文，它必须断开客户端的网络连接，认为网络连接已断开。

3. 客户端发送了PINGREQ报文之后，如果在合理的时间内仍没有收到PINGRESP报文，它应该关闭到服务端的网络连接。

4. 保持连接的值为零表示关闭保持连接功能。这意味着客户端不断开连接。

不管保持连接的值是多少，任何时候，只要服务端认为客户端是不活跃或无响应的，可以断开客户端的连接。

至此，CONNECT报文的所有内容已经学习，最后用官方文档的CONNECT结构图来总结：

有效负荷（Payload）

Payload直译为负荷，可能让人摸不着头脑，实际上可以理解为消息主体（body）。

当MQTT发送的消息类型是CONNECT（连接）、PUBLISH（发布）、SUBSCRIBE（订阅）、SUBACK（订阅确认）、UNSUBSCRIBE（取消订阅）时，则会带有负荷。

MQTT其他特点

异步发布/订阅实现

发布/订阅模式解耦了发布消息的客户（发布者）与订阅消息的客户（订阅者）之间的关系，这意味着发布者和订阅者之间并不需要直接建立联系。

这个模式有以下好处：

1. 发布者与订阅者只需要知道同一个消息代理即可；
2. 发布者和订阅者不需要直接交互；
3. 发布者和订阅者不需要同时在线。

由于采用了发布/订阅实现，MQTT可以双向通信。也就是说MQTT支持服务端反向控制设备，设备可以订阅某个主题，然后发布者对该主题发布消息，设备收到消息后即可进行一系列操作。

二进制格式实现

MQTT基于二进制实现而不是字符串，比如HTTP和XMPP都是基于字符串实现。由于HTTP和XMPP拥有冗长的协议头部，而MQTT固定报文头仅有两字节，所以相比其他协议，发送一条消息最省流量。

MQTT的安全

由于MQTT运行于TCP层之上并以明文方式传输，这就相当于HTTP的明文传输。作为传输协议，MQTT仅关注消息传输，提供合适的安全功能是开发者的责任。安全功能可以从三个层次来考虑——应用层、传输层、网络层。

1. 应用层：在应用层上，MQTT提供了客户标识（Client Identifier）以及用户名和密码，可以在应用层验证设备。
2. 传输层：类似于HTTPS，MQTT基于TCP连接，也可以加上一层TLS，传输层使用TLS加密是确保安全的一个好手段，可以防止中间人攻击。客户端证书不但可以作为设备的身份凭证，还可以用来验证设备。
3. 网络层：如果有条件的话，可以通过拉专线或者使用VPN来连接设备与MQTT代理，以提高网络传输的安全性。

选择用户数据格式

MQTT协议只实现了传送消息的格式，并没有限制用户协议需要按照一定的风格，因此在MQTT协议之上，我们需要定义一套自己的通信协议。比如说，发布者向设备发布一条打开消息，设备可以回复一个消息并携带返回码，这样的消息格式是使用二进制、字符串还是JSON格式呢？

JSON

JSON中文全称是JavaScript对象标记语言，在这门语言中，一切都是对象。因此，任何支持的类型都可以通过JSON来表示，例如字符串、数字、对象、数组等。其语法规则是：

1. 对象表示为键值对；
2. 数据由逗号分隔；
3. 花括号保存对象；
4. 方括号保存数组。

JSON层次结构简洁清晰，易于阅读和编写，同时也易于机器解析和生成，有效提升网络传输效率。

MQTT+JSON是目前最优方案。协议简洁清晰、易于阅读、解析和生成等，也考虑了服务器端开发者和设备端开发者的开发成本。

MQTT与其他协议

目前各大平台都开始支持MQTT协议，MQTT相比其他协议有什么优势呢？物联网设备能不能用其他的协议呢？下面是MQTT与其他部分协议的比较，给大家作为参考。

MQTT与TCP Socket

虽然MQTT运行于TCP层之上，看起来这两者之间根本没有比较性，但笔者觉得还是有必要叙述一番，因为大多数从事硬件或嵌入式开发的工程师，都是直接在TCP层上通信的。从事嵌入式开发工作的人都应该知道LwIP，LwIP是一套用于嵌入式系统的开放源代码TCP/IP协议栈，LwIP在保证嵌入式产品拥有完整的TCP/IP功能的同时，又能保证协议栈对处理器资源的有限消耗，其运行一般仅需要几十KB的RAM和40KB左右的ROM。

也就是说，只要是嵌入式产品使用了LwIP，就支持TCP/IP协议栈，进而可以使用MQTT协议。

由于TCP协议有粘包和分包问题，所以传输数据时需要自定义协议，如果传输的数据报超过MSS（最大报文段长度），一定要给协议定义一个消息长度字段，确保接收端能通过缓冲完整收取消息。一个简单的协议定义：消息头部+消息长度+消息正文。

当然，使用MQTT协议则不需要考虑这个问题，这些MQTT都已经处理好了，MQTT最长可以一次性发送256MB数据，不用考虑粘包分包的问题。

总之，TCP和MQTT本身并不矛盾，只不过基于Socket开发需要处理更多的事情，而且大多数嵌入式开发模块本身也只会提供Socket接口供厂家自定义协议。

MQTT与HTTP

HTTP最初的目的是提供一种发布和接收HTML页面的方法，主要用于Web。HTTP是典型的C/S通讯模式：请求从客户端发出，服务端只能被动接收，一条连接只能发送一次请求，获取响应后就断开连接。该协议最早是为了适用Web浏览器的上网浏览场景而设计的，目前在PC、手机、Pad等终端上都应用广泛。由于这样的通信特点，HTTP技术在物联网设备中很难实现设备的反向控制，不过非要实现也不是不行，下面看一下Web端的例子。

目前，在微博等SNS网站上有海量用户公开发布的内容，当发布者发布消息，数据传到服务器更新时，就需要给关注者尽可能的实时更新内容。Web网站基于HTTP协议，使用HTTP协议探测服务器上是否有内容更新，就必须频繁地让客户端请求服务器进行确认。在浏览器中要实现这种效果，可以使用Comet技术，Comet是基于HTTP长连接的“服务器推”技术，主要有两种实现模型：基于AJAX的长轮询（long-polling）方式和基于Iframe及htmlfile的流（streaming）方式。这两种技术模型在这里不详细展开，有兴趣的读者可以查阅相关资料。

如果要实现设备的反向控制，可能就要用到前面提到的Comet技术。由于需要不断的请求服务器，会导致通信开销非常大，加上HTTP冗长的报文头，在节省流量上实在没有优势。

当然，如果只是单纯地让设备定时上报数据而不做控制，也是可以使用HTTP协议的。

MQTT与XMPP

最有可能与MQTT竞争的是XMPP协议。XMPP（可扩展通讯与表示协议）是一项用于实时通讯的开放技术，它使用可扩展标记语言（XML）作为交换信息的基本格式。其优点是协议成熟、强大、可扩展性强。目前主要应用于许多聊天系统中，在消息推送领域，MQTT和XMPP互相竞争。下面列举MQTT与XMPP各自的特性：

1. XMPP协议基于繁重的XML，报文体积大且交互繁琐；而MQTT协议固定报头只有两个字节，报文体积小、编解码容易；
2. XMPP基于JID的点对点消息传输；MQTT协议基于主题(Topic)发布\订阅模式，消息路由更为灵活；
3. XMPP协议采用XML承载报文，二进制必须进行Base64编码或其他方式处理；MQTT协议未定义报文内容格式，可以承载JSON、二进制等不同类型报文，开发者可以针对性的定义报文格式；
4. MQTT协议支持消息收发确认和QoS保证，有更好的消息可靠性保证；而XMPP主协议并未定义类似机制；
5. 在嵌入式设备开发中大多使用的是C语言开发，C语言解析XML是非常困难的。MQTT基于二进制实现且未定义报文内容格式，可以很好的兼顾嵌入式C语言开发者；而XMPP基于XML，开发者需要配合协议格式，不能灵活开发。

综上所述，在嵌入式设备中，由于需要一个灵巧简洁，对设备开发者和服务端开发者都友好的协议，MQTT比XMPP更具有优势。

MQTT与CoAP

CoAP也是一个能与MQTT竞争的协议。其模仿HTTP的REST模型，服务端以URI方式创建资源，客户端可以通过GET、PUT、POST、DELETE方式访问这些资源，并且协议风格也和HTTP极为相似。

不过，如果使用CoAP可能会让物联网后台的情况变得复杂，比如MQTT可以实现一个最简单的IoT架构：Device + MQTT服务器 + APP，手机端或Web端可以直接从MQTT服务器订阅想要的主题。而CoAP可能需要这样的架构：CoAP + Web + DataBase + App，使用CoAP必须经过DataBase才能转给第三方。

至于CoAP和MQTT孰优孰劣，这里不作定论。不过目前来说，CoAP资料还是略少。而且，MQTT除了可以应用于物联网领域，在手机消息推送、在线聊天等领域都可以有所作为。

小结

经过以上的比较，我们可以得出如下结论：

MQTT基于异步发布/订阅的实现解耦了消息发布者和订阅者，基于二进制的实现节省了存储空间及流量，同时MQTT拥有更好的消息处理机制，可以替代TCP Socket一部分应用场景。

相对于HTTP和XMPP，MQTT可以选择用户数据格式，解析复杂度低，同时MQTT也可用于手机推送等领域。手机作为与人连接的入口，正好建立了人与物的连接，可谓一箭双雕。当然，其他协议也可以作为一个辅助的存在，HTTP可以为只需定时上传数据的设备服务，CoAP则更适用于非常受限的移动通信网络。