前言

这里简单做一些小结和对比，针对前面的协议翻译部分，一阶段的学习完结。

MQTT-SN VS MQTT

MQTT-SN基于MQTT原有语义，但做了很多的调整。比如： 一个CONNECT消息被拆分为3个消息 主题名称需要使用主题标识符替代 * 网关地址可以广播、查询得知

MQTT-SN 与 MQTT对比，使用一张图介绍

QoS

有关QoS，MQTT-SN新增增加了哑客户端（QoS ：-1）支持：

网关的查询和发现

1. MQTT-SN客户端无须提前知道网关地址，接收网关的周期性广播好了，或直接广播一条网关查询；接收广播+主动查询，就够了
2. MQTT-SN对客户端/网关的乱入和丢失，处理的很好，备用网关在主网关挂掉之后即可转换为主网关，针对客户端而言，直接更新一个新的网关地址就可以
3. 存在的若干网关可以互相协调彼此之间角色，互为主备stand-by，出现问题，主机下线维护，从机升级主机

清理会话

和MQTT 3.1协议类似，在上一次的客户端成功连接时在CONNECT中设置了清理会话标志clean session为false，遗嘱特性Will也为true，再次连接时，那么服务器为其缓存订阅数据和遗嘱数据是否已经被删除，对客户端不透明，因为就算是服务器因内存压力等清理了缓存，但没有通知到客户端，会造成订阅、遗嘱的误解。

还好，MQTT-SN协议中，网关在清理掉遗嘱数据后，可以咨询客户端，或主动通知客户端断开，重新建立会话流程。

在MQTT 3.1.1协议中，服务器会在CONNACK中标记会话是否已经被持久的标记。

主题标识符（Topic id）

确切来说，MQTT-SN协议存在三种格式主题名称（topic name），可由消息标志位包含TopicIdType属性决定：

• 0b01：预分配的主题标识符（topic id），16位自然数，0-65535范围
• 0b10：预分配的短主题名称（short topic name），只有两个字符表示
• 0b00：正常主题名称（topic name），可直接附加在REGISTER/SUBSCRIBE/WILLTOPICUPD消息对应字段中

所有主题被替换成标识符，在发布PUBLISH消息时，直接使用被指定的主题标识符topic id、short topic name即可。

MQTT-SN流程梳理

下面对MQTT-SN常用流程进行的流程简单梳理：

              Client              Gateway            Server/Broker
                |                   |                    |
Generic Process | --- SERCHGW ----> |                    |
                | <-- GWINFO  ----- |                    |
                | --- CONNECT ----> |                    |
                | <--WILLTOPICREQ-- |                    |
                | --- WILLTOPIC --> |                    |
                | <-- WILLMSGREQ -- |                    |
                | --- WILLMSG ----> | ---- CONNECT ----> |(accepted)
                | <-- CONNACK ----- | <--- CONNACK ----- |
                | --- PUBLISH ----> |                    |
                | <-- PUBACK  ----- | (invalid TopicId)  |
                | --- REGISTER ---> |                    |
                | <-- REGACK  ----- |                    |
                | --- PUBLISH ----> | ---- PUBLISH ----> |(accepted)
                | <-- PUBACK  ----- | <---- PUBACK ----- |
                |                   |                    |
                //                  //                   //
                |                   |                    |
 SUBSCRIBE   -->| --- SUBSCRIBE --> | ---- SUBSCRIBE --> |
 [var Callback] | <-- SUBACK ------ | <--- SUBACK ------ |
                |                   |                    |
                //                  //                   //
                |                   |                    |
                | <-- REGISTER ---- | <--- PUBLISH ----- |<-- PUBLISH
                | --- REGACK  ----> |                    |
[exec Callback] | <-- PUBLISH  ---- |                    |
                | --- PUBACK   ---> | ---- PUBACK  ----> |--> PUBACK
                |                   |                    |
                //                  //                   //
                |                   |                    |
active -> asleep| --- DISCONNECT -> | (with duration)    |
                | <-- DISCONNECT -- | (without duration) |
                |                   |                    |
                //                  //                   //
                |                   |                    |
                |                   | <--- PUBLISH ----- |<-- PUBLISH
                |                   | ----- PUBACK ----> |
                |                   | <--- PUBLISH ----- |<-- PUBLISH
                |                   | ----- PUBACK ----> |
                |                   | (buffered messages)|
asleep -> awake |                   |                    |
                | --- PINGREQ ----> |                    |
awake state     | <-- PUBLISH  ---- |                    |
                | <-- PUBLISH  ---- |                    |
                | <-- PINGRESP ---- |                    |
asleep <-awake  |                   |                    |

MQTT-SN运行的协议栈

MQTT-SN可以运行在不同的无线协议上，只要可以满足MQTT-SN 所定义即可：支持双向数据传输和网关即可，MQTT-SN完全可以运行在其上面。

MQTT-SN可以在ZigBee、Bluetooth、RF、UDP、6loWPAN等底层协议层面运行。

MQTT-SN网络拓扑图

下面是来自网友的基于MQTT-SN运行的架构图：

但实际上的其网络拓扑可能更为复杂，比如两个不同的传感器网络：

小结

传感器和制动器，合称为SA。传感器汇报状态数值（自身发布PUBLISH消息），制动器会被某参数值触发（接收到的PUBLISH消息）。好比，文件的输入-输出模式，传感器用于文件的读取，制动器用于文件写入。或者使用管道阀门，某指标超过阀值触发制动器报警，SA一起作用便于更好追踪数据。大部分时间，PUBLISH消息被用于触发制动器，这建立在后端服务器的分析结果基础上。

MQTT-SN比较知名的实现，比如(http://eclipse.org/proposals/technology.mosquitto/)[Eclipse Mosquitto]，(RMSB)[http://git.eclipse.org/c/mosquitto/org.eclipse.mosquitto.rsmb.git/]等，但不是实现所有已定义细节，比如MQTT-SN协议转发部分(MQTT-SN Forwarder)，就鲜有实现，但实现不难嘛，可能缺乏相应的场景支持吧。

MQTT-SN支持类似于传感器的网关，稍强的网络可与适用于MQTT协议，这样看来，MQTT要做到连接一切（Connect anything），如IBM所发布的红皮书所说，要使用MQTT打造一个智能星球，有戏！

前言

本篇是MQTT-SN 1.2协议最后一篇翻译了，主要涉及实现要点，很简短。

需要支持QoS 值为 -1

QoS虽默认设置有0,1,2三个值，但还有一种情况其值为-1。来自客户端的PUBLISH消息中若QoS为-1的情况下，此刻客户端不会关心和网关有没有建立连接，也不在乎时间点，有消息就需要发出去。透明的网关需要维护此类消息并与远程的MQTT Server建立一个专用TCP连接。聚合网关或hybird混杂网关可使用已有的MQTT Server连接转发此类消息。

定时器和计时器实践建议

网关处理客户端的休眠和存活定时器，需要根据客户端在所发送消息中延续时间的定义值。例如，定时器值应该高出10%大于指定值持续时间1分钟，如果不高出50%。

网关持有的Topic Id和Topic Name的映射维护

协议严重建议所有客户端的Topic Id和Topic Name之间对应关系不应该使用一个共享池对象，因为这样可以避免不同客户端Topic Id和Topic Name匹配错误，将PUBLISH消息发错地方（客户端接收者），可能会导致引发潜在的不可恢复的灾难性后果。

正确做法是按照客户端的维度为维护Topic Id和Topic Name的对应关系。任何两个客户端之间可能会存在同样的Topic Name，但对应的Topic Id不一样。可能Topic Id一致，但Topic Name不一样。

ZigBee 相关问题

• 在ZigBee规范中，网关需要被托管在一个协调器节点内，MQTT-SN协议建议网关更应该而驻留在一个不间断运行的的ZigBee路由器节点上，能够随时接收来自客户端消息。
• 受限于ZigBee网络支持层有限的数据负载容量，MQTT-SN消息最大负载被限制为60字节。

小结

MQTT-SN 1.2协议到此翻译（非直译）完毕，嗯，有种想要吐血的感觉，但也是坚持了下来 (^_^)。

我的生涯一片无悔，我想起那天夕阳下的奔跑，那是我逝去的青春。
---《万万没想到》王大锤

前言

紧接上文，这是第三篇，主要是对MQTT-SN 1.2协议进行总体性功能描述。

嗯，这一部分可以结合着MQTT协议对比着来看。

网关的广播和发现

网关只能在成功连接到MQTT Server之后，才能够周期性的在无线个人区域网WPNs内对所有客户端广播ADVERTISE消息，便于客户端被动知道网关的存在。

在同一网络下，多个拥有不同Id的网关可有同时运行中，但会由客户端根据信号强弱决定连接具体网关，无论何时只能连接一个网关。

客户端可维护一份可用网关列表（包含网关地址），在接收到包含有新的网关id的ADVERTISE和GWINFO消息后，其列表需要添加新的网关元素进去。

ADVERTISE广播消息包含的下一次广播间隔时长Duration属性，单位秒，设为变量T_ADV，应该尽可能大与15分钟（900秒），频率降低是为了避免低速个人区域网络的拥塞。

针对接收ADVERTISE消息频率，处理能力较强客户端可以用于监督网关是否可用。eg：客户端连续N_ADV次接收不到某个网关ADVERTISE广播消息，可认为此网关经死掉不可用并且从已维护的网关列表中移除。同样的，作为备用的网关认为主网关已挂掉，此时可处于激活状态，正常发挥作用。

网关发送广播消息ADVERTISE的时间间隔很长，这对导致新加入的客户端不利，但客户端可以直接发送SEARCHGW广播消息进行查询网关。大量的新入设备会造成广播风暴造成网络拥挤，每一个新加入的客户端在发送SEARCHGW广播消息之前都需要获取一个随机的延迟发送值(0-Tsearchgw)，在延迟等待发送期间若接收到其它客户端发送的SEARCHGW广播消息，会取消掉自己的SEARCHGW广播消息发送，等待网关GWINFO消息通知。

SEARCHGW消息属性radius广播半径，记为变量Rb，1跳（1 hop）在一般密集部署下的MQTT-SN客户端基本可用。

网关接收到SEARCHGW会即刻回复包含自身id的GWINFO消息。客户端收到SEARCHGW后，若有需要延迟发送的SEARCHGW会取消掉，若自身维护一份多个可用网关列表，在等待T_GWINFO时间内没有收到GWINFO消息，会从列表中取出一条网关信息组装成GWINFO消息并广播出去。这就要求客户端已运行多时，并且维护多个可用网关列表。

GWINFO和SEARCHGW所包含半径radius属性值一致，这就要求底层网络在传输时进行决定是否需要传输到其它类型网络中。

若没有接收到响应，SEARCHGW消息可能被重新传输。两个连续的SEARCHGW消息重传间隔应该呈指数形式增加，避免太密集传输。

客户端的连接建立

无论是基于哪一种传输协议，TCP or UDP，客户端都需要建立连接，并且保持心跳，逻辑上和服务器端保持一条不断线的双向通道。下面一张图，演示了客户端建立连接的过程，并且设定客户端在CONNECT消息中标志位字段中遗嘱WILL属性为true，然后就有了遗嘱主题/消息的请求过程。

很多情况下，连接CONNECT是不需要遗嘱支持的，网关会直接返回CONNACK消息，但网关会因为拥塞或不支持一些CONNET特性，CONNACK所包含返回代码字段ReturnCode中包含拒绝代码，要求客户端检查是否连接成功，区别对待。比如：

 CONNACK消息返回状态码为0x01（Rejected: congestion，因拥塞被拒绝），客户端需要在T_WAIT时间间隔后进行重试。

回话清理

已经连接的客户端断线后，若之前在CONNECT中没有设置过会话清理（Clean Session）标识，那么之前的订阅等信息在网关处将会持久存在。相比MQTT，MQTT-SN中的“Clean Session”标识被扩展到遗嘱特性中。在CONNECT消息中，CleanSession和Will组合将会产生以下效果：

• CleanSession=true, Will=true: 网关将会删除之前对应的所有订阅和遗嘱，新的遗嘱主题/消息稍后即将重新处理
• CleanSession=true, Will=false: 网关将会删除之前对应的所有订阅和遗嘱，返回CONNACK消息
• CleanSession=false, Will=true: 网关将继续持有之前对应的所有订阅，新的遗嘱主题/消息稍后即将重新处理
• CleanSession=false, Will=false: 网关将会继续持有之前对应的所有订阅和遗嘱等数据，并返回CONNACK消息

更新遗嘱流程

• CONNEECTION中标志位Will中设置是否需要更新遗嘱主题/消息
• 空WILLTOPIC（两个字节）消息将会促使网关删除对应遗嘱数据
• WILLTOPICUPD/WILLMSGUPD可以更新/修改遗嘱主题、遗嘱消息
• 空白WILLTOPICUPD（两个字节）消息意味着请求网清空对应已有的遗嘱数据

主题注册流程

受限于无线传感器网络的有限带宽和微小消息负载，PUBLISH消息中不能够包含完整的主题名称topic name。这就需要客户端和网关之间通过注册流程，获取主题名称对应的（16位的自然数）topic id，然后塞入PUBLISH消息的topicId属性中。

客户端发送REGISTER消息，网关返回REGACK消息，其所包含的ReturenCode属性决定注册成功与否：

• ReturnCode = “accepted”，topicId可以很愉快的使用在稍后的PUBLISH消息中
• ReturnCode = “rejected: congestion”，客户端需要稍等一段时间（T_WAIT表示，大于5分钟）再次重新注册
• ReturnCode = “rejected: invalid topic ID/not supported”，客户端需要稍作调整，再次重新注册

任意时间，只能执行一个REGISTER消息，有没有完成注册流程，需要等待。

网关->客户端方向，网关发送REGISTER消息给通知客户端指定topicId对应某个主题，以便后面发送PUBLISH消息使用。若客户端在订阅SUBSCRIBE消息时使用了通配符（#/+），那么与之相匹配的topic name也将被一一通知到。因此不建议使用通配符，较为低效。

客户端发布流程

客户端一旦获取到topic name对应topic id，就可以直接发送PUBLISH消息了。这和MQTT协议相比，PUBLISH消息中Topic Name被替换成Topic Id，除此之外，还要注意ReturnCode：

• ReturnCode = “rejected: congestion”，客户端需要稍等一段时间（>5分钟）后再次重试
• ReturnCode = “rejected: invalid topic ID”，客户端需要重新注册topic name获取topic id，然后再次重新发布

QoS 1和 QoS 2在任一时间，都必须等待已有PUBLISH消息完成，才能进行下面的PUBLISH消息发布流程。

预定义topic id和两个字符的topic name

预定义的topic id已提前指派好对应的topic name，需要客户端和网关在代码层级支持，省略了中间注册流程，在连接建立之后可以马上进行PUBLISH消息，但这需要在PUBLISH标志Flags字段中设置TopicIdType值为0b01（0b10表示两个字节长度的短topic name）。虽然可以快速发送PUBLISH消息，但客户端想订阅预定义的topic id，接收对应的PUBLISH消息，一样需要发送SUBSCRIBLE消息请求进行订阅。若乱指定预定义topic id，会收到ReturnCode=“Rejection: invalid topic Id”的异常。

预定义的短topic name只有两个字符长度的字符串（也是两个字节），topic id为两个字节表示的一个自然数（0-65535），两者使用场景一致，都需要在标志位Flags设置TopicIdType具体值，0b01表示预定义topic id，0b10表示两个字节长度的短topic name，需要分清。

PUBLISH对应QoS -1值

这对仅仅支持PUBLISH QoS -1的非常简单的客户端实现而言，除此之外不支持任何特性。它不关心连接是否建立，也没有注册、订阅这一说，按照已经固化到代码中的网关地址直接发送PUBLISH消息，不关心网关地址是否正确、网关是否存活、消息是否发送成功。

下面的PUBLISH属性值依赖于QoS -1的情况：

• QoS标志，被置为0b11
• TopicIdType标志，可能是（预定义topic id）0b01也可能是（短topic name）0b10
• TopicId字段，预定义topic id或短topic name
• Data字段，需要发送的数据，没啥变化

客户端的订阅和退订

客户端对某个主题感兴趣，可以发起SUBSCRIBLE流程，携带上感兴趣的主题名（topic id），服务器一般会返回包含有指定主题Id（topic id）的SUBACK消息。订阅失败，可以从PUBACK的ReturnCode中获知：

• ReturnCode = “rejected: congestion”，客户端需要稍等一段时间T_WAIT（>5分钟）后再次重试

有一种情况是SUBSCRIBLE订阅主题包含通配符，网关的处理就很简单，在SUBACK中返回的topic id为0x0000。稍后，网关向客户端发送REGISTER消息走注册流程，通知通配符匹配到的主题对应的topic id值。

来自客户端的SUBSCRIBLE消息一样支持预定义topic id，以及短topic name，这和PUBLISH消息差不多。

退订就很简单，客户端发送UNSUBSCRIBLE消息，网关返回UNSUBACK消息。

但同一时刻，客户端只允许处理订阅SUBSCRIBLE或取消订阅UNSUBSCRIBLE按照串行化顺序，下一个操作依赖于上一个操作完全成功。

网关发布流程

服务器发布流程和客户端类似，在发布之前需要检测其主题是否已经向客户端提前注册过，若无需要把主题和指定的topic id放入REGISTER消息中发送给客户端进行注册流程，然后等待客户端处理结果REGACK。注册通过，然后才能正常发送PUBLISH消息。

网关需要确保REGISTER的主题以及PUBLISH消息的内容负载都不能太长超过当前网络负载上限（比如在ZigBee环境下不能超过60个字节），取消注册/发布流程就好了。

网关发布PUBLISH消息时，客户端检测到未知的topic id，把拒绝理由封装到PUBACK后，网关遇到ReturnCode=“Rejected: invalid Topic ID”非法topic id，需要考虑删除或重新注册。

客户端或许会拒绝其注册，或许会不允许PUBLISH消息，网关如上静默处理就好了，失败就失败了，不需要告知别人。

客户端发布流程于此类似，需要在发布之前进行主题注册以获取指定的topic id，提交PUBLISH消息后，同样需要检查PUBACK所包含的ReturnCode字段是接受还是拒绝，因网络拥塞而产生的拒绝，客户端需要在T_WAIT时间后再次重试。

客户端的发布必须是串行方式，下一个需要发送到PUBLISH消息需要等待上一个发送成功被网关接受之后才能进行处理。

心跳保活流程

一般是客户端->网关，网关->客户端也没有问题。但要求PINGREQ -> PINGRESP 一定要单个时针循环，PINGREQ发送者不能也是PINGRESP的发送者，那样不但乱了流程，也浪费了网络资源。嗯，不允许双向互发。

客户端可基于心跳机制监测已连接网关健康与否，连续多次接收不到来自网关的PINGRESP消息后，客户端连接下一个可替换的网关。因为客户端的连接和心跳和其它客户端状态属性不同步，但这可能会带来一个问题，同一时间若有大量的客户端洪水般同时连接一个网关，网关可能毫无征兆的会被冲垮掉。这就要求网关要有批量的连接处理能力，并发特性增强才行。

客户端断线流程

客户端主动发送DISCONNECT消息告知网关需要断线之后，若有交换信息的需要可以重新发起一个新的会话连接。DISCONNECT消息之后，网关不会清理掉已有订阅和遗嘱数据，除非在之前的CONNECT消息中已硬性设置了CleanSession会话清理标识为true。网关接收到DISCONNECT消息之后会返回一个DISCONNECT消息作为响应。

有一种情况是客户端会突然接收到来自网关的DISCONNECT消息，这也许是网关自身发生了异常错误，或网关无法定位客户端的消息归属（客户端的消息和客户端无法关联到一起），此时客户端需要发送CONNECT消息重建与网关的会话连接。

客户端重传流程

客户端->网关的消息都是单路传播的，这依赖于客户端所持有的已连接网关的单播地址。

客户端发送一个消息之后，需要启动一个重试定时器Tretry和一个重试计数器Nretry用以监督网关消息响应。定时器会被客户端在指定时间内接收到来自网关的消息后取消掉，若没有准时接收到则会触发定时器执行消息重发流程，连续Nretry次重发后，客户端会直接取消掉当前流程，判断当前网关已经断线，需要连接到另外一个可用的网关。假如另外的网关也是连接失败，会尝试重连之前的网关。

若在休眠状态下，一旦超过重试计数器值，客户端直接进入休眠状态。

客户端休眠支持策略

这里所说的客户端指的是依赖电池驱动的电子设备，你要明白一个事实，节省电池资源是多麽的重要，省电就是关键，没电了就没得玩了嘛。当不处于激活状态时为了省电就得需要进入睡眠/休眠状态，当有数据需要接收或发送时就可以醒过来。网关嘛需要追踪设备的休眠状态并且支持缓存需要发送给休眠设备的消息，在设备唤醒时一一发送。

下面是客户端的状态转换图，很清晰描述了各种状态之间的交互：

客户端具有五种状态：激活（active），休眠（asleep），唤醒（awake），断线（disconnected），丢失（lost），每次只能是其中一种。

网关需要监督客户端的状态，开始于CONNECT消息中存活时长字段（keep alive），在大于存活时长时间内网关接收不到来自客户端消息，网关认为客户端已经处于丢失状态（lost），会激活对应的遗嘱特性若存在的话。

客户端发送DISCONNECT消息但没有duration休眠时长字段，网关这将处于没有时间监督的断线状态。一旦包含duration休眠时长字段，表示客户端需要休眠一段时间，网关这客户端被转换为休眠状态，休眠时长为duration所定义在值。超过此休眠时长的一段时间内，网关若接收不到客户端发送过来的任何消息，那么客户端会被转化为丢失状态，若已设置遗嘱特性，此时遗嘱特性会生效。客户端休眠期间需要被发送的消息都会被网关缓存。

睡眠状态下流程图会更形象的说明流程：

毫无疑问，网关可使用一个休眠定时器维护客户端的休眠状态等，休眠定时器会被停掉当网关接收到客户端发送过的PINGREQ消息，网关从PINGREQ消息所包含的Client Id检索是否存在已缓存的PUBLISH消息，若有会一一按照顺序发送到客户端。所有对应已缓存消息发送完毕后，会随之发送一个PINGRESP消息。若没有缓存消息，网关直接返回一个PINGRESP消息。网关会重新启动休眠定时器，网关维护的客户端状态被转换为休眠状态，客户端在接收到PINGRESP消息之后，将直接转向休眠状态，节省用电。

客户端在唤醒状态下处理消息，遵守“客户端重传流程”行为，一旦达到重试计数器限制，将进入睡眠状态。

客户端从休眠状态转向唤醒状态用于检查网关是否为其缓存消息时，需要发送一个PINGREQ消息到网关；从休眠/唤醒状态转换为激活状态，需要发送一个CONNECT消息告知网关；转换为断线状态时需要发送两个字节的DISCONNECT（没有休眠时长字段duration）消息；需要重新定义的休眠时长，发送一个DISCONNECT消息（包含新的duration时长值）通知网关即可。

小结

功能性描述介绍完了，基本上MQTT-SN协议介绍已接近尾声，最后面的篇章就是短短的实现描述了。

前言

紧接着上篇初步介绍，本文为第二篇，主要梳理MQTT-SN 1.2协议中定义的消息格式。

通用消息格式

消息头部

• 长度要么是1个字节，要么3个字节表示，并且自身也会包含在其内。一个字节可表示256长度，一般情况下，完全够用了。
• 只需要判断第一个字节是否为 0x01，若是那么长度为3个字节表示，剩下的两个字节会表示真正的消息长度，最大长度为65535
• 否则长度就是一个字节表示，256个长度，大部分消息长度都是一个字节，除非特别提醒

备注：

 MQTT-SN不支持消息的分片和重组。底层网络所定义数据包长度若小于MQTT-SN消息的最大长度，自身进行的分片和重组，对MQTT-SN协议本身不受影响。

MQTT-SN消息类型

MQTT-SN定义的消息类型数量众多，超过25个，感觉有些头大。

消息可变部分

可变字段很多，与MQTT相比，多了：

1. 持续时长字段（Duration）
2. 标识符Flags有所不同，下面表格进行说明
3. 网关地址（GwAdd），可变长度，但依赖于底层网络，在ZigBee网络中2个字节长度
4. 一个字节网关Id（GwId）
5. 协议Id（ProtocolId），一个字节，唯一值 0x01，统一表示协议名称和协议名称
6. 广播路径跳数(广播路径深度/广播辐射范围)，Radius，一个字节表示，0x00表示广播给当前网络中所有节点
7. CONNECT/REGISTER/SUBSCRIBE/PUBLISH等消息对应回执中都会包含返回码Recode Code，见下表格

具体消息格式说明

ADVERTISE

网关周期性会对当前网络下所有客户端、节点进行广播，用于客户端发现可用网关。

SEARCHGW

客户端主动寻找网关进行广播的消息，广播路径范围受限于当前网络环境下的客户端部署密度，比如只有1跳广播在非常密集的网络环境下客户端都可以彼此互相访问。

GWINFO

GWINFO作为对SEARCHGW消息的响应：

• 若由网关发出，则无GwAdd字段
• 若来自于客户端，需要包含网关地址

CONNECT

客户端向网关发出建立连接的消息。

在CONNECT消息标志位具体表示如下：

• 0/1 表示具体值待定
• X 表示没有使用到

在Flags中使用到的标志位：

1. Will：若为1，客户端会在稍后请求遗嘱主题和遗嘱消息
2. CleanSession：不但表示订阅持久化，同时也被可扩展到遗嘱主题和遗嘱消息中

CONNACK

网关对客户端发出CONNECT消息的响应。

WILLTOPICREQ

根据客户端CONNECT标志位中WILL字段为true情况下，网关向客户端发出遗嘱主题请求，格式如下：

只有头部部分，很简单。

WILLTOPIC

客户端作为网关WILLTOPICREQ请求响应消息。下面是一个正常版本的WILLTOPIC消息：

此时的标志位如下

而空的WILLTOPIC也是允许存在的，就两个字节表示，用于客户端请求删除已存在于服务器端的对应遗嘱主题和消息。

WILLMSGREQ

根据客户端CONNECT标志位中WILL字段为真情况下，网关向客户端发出遗嘱消息请求，格式如下：

只有头部部分，没有别的。

WILLMSG

客户端对网关WILLMSGREQ请求的响应，从而把遗嘱消息传递给网关进行保存。

REGISTER

• 客户端-->网关，请求主题（topic name）对应的主题标识符（topic id）
• 网关-->客户端，通知主题（topic name）已经被指派到某个主题标识符（topic id）

REGACK

客户端或网关针对REGISTER消息的响应。

PUBLISH

PUBLISH消息用于客户端或网关发布消息用：

标识位具体如下：

标识位里面各个字段和MQTT协议一致，无须多解释。

PUBACK

客户端/网关仅仅对QoS 1/2的PUBLISH消息做出响应。

处理PUBLISH消息异常？在PUBACK消息中的ReturnCode字段中以相应值体现出来，这就要求接收者处理拒绝理由。

PUBREC, PUBREL, PUBCOMP

只有在PUBLISH消息中QoS 2时，PUBREC, PUBREL, PUBCOMP才会一起登场，否则是没有出场机会的。消息格式嘛，都很统一：

SUBSCRIBE

SUBSCRIBE用于客户端订阅某个主题的消息。

标识位具体如下：

此处，标志位中TopicIdType决定了SUBSCRIBE消息中TopicId/TopicName字段具体填充值：预定义topic id，或短小两个字符表示主题（topic name），或直接填写主题。

SUBACK

网关->客户端，订阅处理情况的确认回执，接受订阅或出于其它原因拒绝之。

标识位具体如下：

SUBACK消息标志位中QoS为网关根据实际情况授权后的QoS具体值，这也应该是客户端需要知道并处理的。

UNSUBSCRIBE

UNSUBSCRIBE用于客户端取消订阅某个主题的消息。

标识位具体如下：

UNSUBSCRIBE消息标志位中唯一可用属性TopicIdType决定了UNSUBSCRIBE消息中TopicId/TopicName字段具体填充值。

UNSUBACK

网关->客户端，取消订阅处理情况的确认回执，很简单，4个字节表示。

PINGREQ

和MQTT协议中的PINGREQ一致，存活检测。

PINGRESP

接受PINGREQ消息的一方，如网关响应PINGRESP消息表示自己现在运行OK。

另外一个意图，若唤醒状态客户端发送PINGREQ消息之后，直接收到PINGRESP消息，表示网关当前暂时没有为其缓存的消息可供发送。

很简单，两个字节表示足矣。

DISCONNECT

• 客户端->网关，客户端主动关闭当前连接，网关响应确认消息。只有表示自己进入睡眠状态的客户端，才会在DISCONNECT消息中附加Duration持续字段。
• 网关->客户端，网关由于异常主动通知客户端关闭两者之间连接，客户端接收到DISCONNECT时需要发送CONNECT消息到网关，重试重新建立连接。没有Duration字段填充。

网关接收到要进入休眠状态的客户端发送的包含有Duration字段DISCONNECT消息时，可以直接返回2个字节的（不能包含有Duration字段）DISCONNECT消息以示确认。

WILLTOPICUPD

客户端发送请求网关更新其遗嘱主题。

标识位具体如下：

协议规定只有两个字节空WILLTOPICUPD也是允许存在的，存在意义用于客户端请求网关删除已保存的遗嘱主题和遗嘱消息等。

WILLTOPICRESP

WILLTOPICRESP为网关收到WILLTOPICUPD后作出的应答消息。

WILLMSGUPD

客户端->网关，确认更新的遗嘱消息。

WILLMSGRESP

WILLMSGRESP为网关收到WILLMSGUPD后作出的应答消息。

转发封装

在MQTT-SN架构图中，MQTT-SN Forwarder转发器适用于客户端无法直接访问网关或当前传感器网络区域中不存在网关时，转发器作用就体现出来了：

1. 接收MQTT-SN客户端消息封装后转发给上游网关
2. 解封上游网关所发送消息，直接发送给对应客户端

转发器作用于消息的封装转发，解封发送，针对消息不做修改。

转发器对MQTT-SN消息封装格式：

无线节点Id（Wireless Node Id）：

• 转发器->网关，无线节点Id为转发器所在的无线节点Id，便于告知网关转发器位置
• 网关->转发器，无线节点Id为网关的无线节点Id

控制交换字段Ctrl，单个字节，位表示含义：

小结

MQTT-SN 1.2规范中所定义消息格式介绍完毕，下一篇将对MQTT-SN主要流程功、能进行阐述。

前言

这一段时间在翻看MQTT-SN的协议，对针对不依赖于TCP传输的MQTT协议十分感兴趣，总是再想着这货到底是怎么定义的。一系列文章皆有MQTT-SN 1.2协议所拼装组成，原文档地址： MQTT-SN_spec_v1.2.pdf

MQTT-SN文档分为7个部分，我直接按照从前到后的顺序，直接组装成四个小篇。嗯，若放在一篇文章中，文字太长，造成排版难度。

非直译，完全按照自己理解整理而成，请知晓。

版本变迁历史

1. 2007-11-29 1.0版本
2. 2008-6-5 1.1版本，增加休眠设备支持
3. 2011-5-20 1.2版本

• 增加消息长度255字节支持
• 增加转发封装支持
• 增加返回代码"0x03 Rejected, not supported"
• ReturnCode 增加到WILLTOPICRESP和WILLMSGRESP消息中

MQTT-SN名称由来

原名是MQTT-S，但会引起人们的误解，因此更名成MQTT-SN：

As part of the job of applying the same or similar license terms to the MQTT-S specification as those on the MQTT specification, we are proposing a small name change. The new name would be MQTT-SN, standing for exactly the same long name, MQTT for Sensor Networks. Some people had assumed that the S in MQTT-S stood for secure, so we hope this change will avoid that confusion. -- Ian Craggs

MQTT-SN存在目的

MQTT for Sensor Networks is aimed at embedded devices on non-TCP/IP networks, such as Zigbee. MQTT-SN is a publish/subscribe messaging protocol for wireless sensor networks (WSN), with the aim of extending the MQTT protocol beyond the reach of TCP/IP infrastructure for Sensor and Actuator solutions.

针对适配传感装置（缩写为SA）的特定版MQTT协议，一般运行在嵌入式电池驱动的电子元件中，传输通过基于IEEE 802.15.4规范无线低速网络构成的无线传感网络（WSN），同样具有企业级别特性具有以数据为核心的（data-centric）订阅/发布特性。

总之，针对低功耗、电池驱动、处理存储受限的设备、不支持TCP/IP协议栈网络的电子器件而定制，比如常见的ZigBee（或XBee），对所依赖的底层传输网络不可知，但只要网络支持双向数据传输和网关，都是可以支持较为上层的MQTT-SN协议传输。比如简单数据报服务，只要支持一个源端点发送数据到一个特定目的地端点，这对支持MQTT-SN协议，就足够了。广播数据报传输服务也是必须的用于网关和终端的自动发现流程。为了降低广播风暴，MQTT-SN定义了广播路径深度（广播范围或广播半径）。

一些名词和术语

• topic id，主题标识符，两个字节16位表示的自然数（java语言short类型，0-65535范围），对应于主题topic name
• 网关/服务器（gateway/server），在MQTT-SN中统一称之为网关，主要处理和MQTT-SN客户端的交互，缩写为网关
• MQTT-SN终端和客户端（client），统一称之为客户端，其实也是嵌入式传感设备，或电子元件，资源受限，在无线区域个人网中运行
• IEEE 802.15.4，完整栈的整个数据上限为128个字节，一般选择UDP（相比20个字节的TCP协议，UDP报文头部仅仅需要8个字节）协议传输数据
• 低速网络/当前网络，指的是LR-WPAN（low-rate wireless personal area network,），低速无线个人区域网络

MQTT-SN VS MQTT

尽管MQTT-SN被设计成尽可能接近于MQTT，但那些低功耗、电池驱动、资源受限的设备所在网络场景为低速带宽、高连接失败、物理层数据包上线为128字节。文档提出了以下不同点：

1. CONNECT消息被拆分成三个消息（CONNECT，WILLTIPIC，WILLMSG），后两者用于客户端传递遗嘱主题和遗嘱消息等
2. 在PUBLISH消息中主题（topic name）被替换成两个字节长度自然数（topic id），这个需要客户端通过注册流程进行获取对应的topic id
3. 预定义（提前定义）topic id和topic name，省去中间注册流程，客户端和网关要求提前在其固件中指定
4. 协议引入的自动发现机制可帮助客户端发现潜在的网关。若存在多个网关，彼此可协调是为主从互备或者负载均衡
5. "clean session"即可作用于订阅持久化，也被扩展作用于遗嘱特性（遗嘱主题和遗嘱消息）
6. 针对休眠设备增加离线保活机制支持，当有消息时代理需要缓存，客户端被唤醒时再发送

MQTT-SN架构示意

在MQTT-SN架构图中，存在三种组件：

1. MQTT-SN 客户端
2. MQTT-SN 网关，可单独存在，也可以被集成到MQTT服务器中。需要承担MQTT-SN和MQTT协议之间的转换工作
3. MQTT-SN 转发器，负责转发当前客户端数据到不可直接访问的网关上去，针对客户端而言网关不可直接访问时，转发器作用就凸显。转发器封装MQTT-SN消息转发给网关，解封来自网关的消息发送给客户端。网关不能够篡改原始数据。

MQTT-SN传输网关

MQTT-SN网关传输方式，下面的图片一目了然。

1. 透明网关，会为每一个客户端都建立一个TCP连接到MQTT服务器的通道，这样会较为耗费网关网络资源，但模型简单
2. 聚合网关，只建立一条TCP连接通道到MQTT服务器上，所有的客户端共享一个通道，很经济的说。

网关需要抉择哪些消息需要和远程的MQTT Server进行交互，比如只选择客户端发送的PUBLISH、SUBSCRIBLE消息等。

小结

上面简单介绍了MQTT-SN，下面将会介绍MQTT-SN消息头部和格式。

以前看英文文章或资料，看完之后，摘要或者忘记。这一次选择感兴趣的MQTT 3.1.1介绍文章资料，引文见文末，作为练手；非完全翻译，去除掉一些广告性描述，若侵权，请告知。

在沉寂了四年之后，QTT 3.1.1规范于2014年10月30号正式发布，与此同时MQTT 3.1.1已成为OASIS（结构化信息标准促进组织）开放物联网消息传递协议标准（连接1 连接2），换种说法就是MQTT 3.1.1已升级为国际物联网标准。

正如HTTP为人们通过万维网分享信息铺平了道路一样，MQTT能将几十亿低成本、嵌入式数据采集遥测设备连接到网络。

与MQTT 3.1（还不是国际物联网标准呢）规范相比，MQTT 3.1.1目标在于消除歧义，尽可能的向后兼容，事实上一些大众所需的新特性被包含在这个版本（更多的是物联网标准推动），因此不仅是一个维护版本，也是一种巨大的进步呢。除了概念的澄清和陈旧规范重写外，有一些很有趣的变化是值得注意的。

会话表示标志（Session Present Flag）

如果一个终端与服务器之间建立一个持久会话连接(假设这个终端没有使用到一个“clean session”标记清除已有回话标志), 一个新增的“Session Present”标志（会话表示标志，逻辑值为true或false）会在CONNACK中出现，表明MQTT服务器已经拥有当前客户端上次连接会话信息，比如订阅的主题，排队信息和其它信息等。

会话表示标志若为true，客户端可减少了一次发送订阅SUBSCRIBLE交互步骤，有助于更有效的数据通信；为false，客户端需要再次发送订阅SUBSCRIBLE消息，不可略过。

新增订阅失败代码反馈

MQTT 3.1.1之前，终端连接之后无法知道其发送的订阅主题是否被MQTT服务器接受与否。此新特性较适用于细粒度权限MQTT主题管理；若无授权，服务器会把错误代码(0x80)附加在SUBACK中，客户端就可以知道订阅失败。

MQTT匿名客户端

需要支持临时或匿名？客户端仅仅需要在发送CONNECT时把客户端标识符（ client identifier ）置空（零长度）即可，MQTT服务器会为此类请求生成一个随机、唯一客户端标记符。但这要求客户端必须设置Clean Session标记为1，否则服务器端会直接返回包含0x02 (Identifier rejected)代码的CONNACK，同时关闭连接。

可用于后端程序（不需要维护回话状态）向终端发送消息的客户端，MQTT服务器程序可区别对待。

快速发布无等待

这是一个新增的特别有用的特性，客户端可以在发送CONNECT之后，可无须等待MQTT服务器返回的CONNACK，根据需要即刻发送PUBLISH、SUBSCRIBLE、DISCONNEECT等消息，可避免客户端资源等待。此特性也适用于突发模式（burst-mode）客户端需求，只关心数据要尽快的发送出去，而不是去担心是否需要维护一个长连接。

这需要MQTT服务器实现在分发消息之前检查客户端是否有权限发布到这些主题上。

客户端标识符可以变长一些

MQTT 3.1针对客户端标识符（ client identifier）限制是23个字节，实际环境下会有所不便，已有遗留系统可能使用UUID作为客户端的标识符，这样服务器端需要做一些彼此之间的MAP映射。 MQTT 3.1.1中上限为65535个字节，毕竟成为业界标准，需要兼容大量的遗留设备和基础设施。

其它小改变

1. CONNECT消息可变头部协议名称MQIsdp被改为MQTT，语义更准确
2. 所有字符串明确规定使用UTF-8编码，包括客户端标识符(Client Identifier)
3. CONNECT消息可变头部协议版本号，由0x03变成了0x04 QoS 0类型PUBLISH消息DUP标记必须被设置为0
4. MQTT Over WebSocket 被定义，互联网地址编码分配机构（Internet Assigned Numbers Authority）分配标识符为mqtt。虽在MQTT 3.1规范通篇没有提到WebSocket，但因其二进制属性可以很容易的在WebSocket通道传输。

术语变化

• MQTT代理 -> MQTT服务器（MQTT Broker is now MQTT Server）
• 消息ID -> 包ID（Message ID is now Packet ID）
• 消息类型 -> 包类型（Message Type is now Packet Type）
• 主题路径 -> 主题名称（Subscribe and Unsubscribe take Topic Paths, rather than Topic names）
• 以前在固定头部，现在在包类型中( Flags in the fixed header are now specific to the packet type
• 0字节保留信息需要清除 （A zero byte retained message MUST NOT be stored as a retained message on the Server ）

小结

当前MQTT 3.1.1已经在很多活跃开源项目/商业产品得到支持。比如Eclipse Paho，Mosquitto，JBoss A-MQ 6.1, Apache ActiveMQ 5.10-SNAPSHOT，Apache Camel 2.13.0，HiveMQ等。

关于Eclipse Paho:

1. Eclipse Paho 1.0支持MQTT 3.1.1和MQTT 3.1规范
2. Eclipse Paho 0.9仅支持 MQTT 3.1规范

包含MQTT 3.1.1和MQTT 3.1的客户端可以混合使用，彼此可以共存于同一个MQTT服务器下，在基本消息传输层面没有多大修改，同样的PUBLISH消息可以在MQTT客户端中自由流转，这个需要服务器端编码支持。

已有的MQTT 3.1客户端可以用着急升级，但升级之后可以从新增特性中收益良多。

引用

1. 6 facts why it’s worth upgrading to the brand new MQTT 3.1.1 version
2. Differences between 3.1.0 and 3.1.1
3. other ……

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

弱网环境下表现

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

手机终端在每次TCP断开或断网后，会即刻发起TCP重连，连接成功，会重复以前步骤依次发送连接命令（CONNECT），订阅命令（SUBSCRIBLE），表明上看，这些过程没有任何问题，但问题就在于从终端成功建立到服务器的连接，到发送订阅命令，在弱网情况下，这个过程将会变得很昂贵：

从TCP建立开始的三次握手到完整的订阅命令发送完毕，考虑到TCP堆栈的每次接收数据方响应ACK，这中间终端和服务器端至少产生了10次数据交互。

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

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

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

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

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

4. 成功发送SUBSCRIBLE命令后，或移动网络断开了（有些运营商针对认为HTTP的请求有超时判断），或等待超时，导致订阅失败

TCP是无感知的虚拟连接，中间断开两端不会立刻得到通知，否则就用不着心跳保活机制了。

举一个例子，线上的服务器根据日志分析，只接收到连接命令（CONNECT）但没有后续的订阅命令（SUBSCRIBLE）的情况，每天有上百万级别的数量。

总之，针对低速率弱网络环境，MQTT表现不怎么好。

改进点

业务改进点：

1. 客户端的连接超时、等待超时设大一点，两秒太短，可设置长一些，比如10秒
2. 服务器端支持在接收到用户发送CONNECT命令后，瞬间发送一些live data/hot data（早已缓存的数据），类似于HTTP请求-相应模型，目的嘛，一些热数据发送给终端要趁早，越快越好（所谓出名要趁早嘛）；这个需要客户端、服务器端同时支持

协议改进点：

1. CONNECT命令可变头部包含"MQisdp"太多余了，学院派风格嘛
2. 允许在连接命令中负载（payload）中携带订阅Topic字符串
3. 允许在连接命令中表示上次连接订阅的Topic发生变化否，携带订阅业务，虽冗余，但实用。 eg：订阅的Topic没有发生变化，TOPICCHANGE:0；退订，UNSUBSCRIBE:TOPICONE；SUBSCRIBE：TOPIC_TWO
4. PUBLISH、PUBACK等支持的 Message Identifier 才16位，太短，实际业务无法做到全局唯一。引入mid和业务id的映射对应关系？那是状态，需要维护，代价还是蛮高的。业界流行看法，无状态化的架构才是便于横向、竖向、纵向、四方向的扩展，呵呵。最好方式就是修改使之支持字符串形式，否则维护代价高！
5. 心跳命令PINGREQ/PINGREQ可以做到一个字节传输，节省一个字节，有些强迫症的感觉嘛
6. 低速率网络需要做一些兼容和调整

有些建议看似冗余，批量或打包处理总比单个处理更高效一些、更节省资源，弱网络环境要求交互要尽可能的少，数据嘛要的是瞬间抵达，越快越好。

严格的分层和业务解耦，会导致性能问题。好比当前Linux内核的TCP/IP网络堆栈分层很清晰，每一层都各司其职，但和直接略过内核态直接运行在用户态(User Space)的Packet I/O相比，处理性能不是在一个档次上，比如Netmap 、DPDK等。

MQTT-SN

针对没有TCP/IP等网络堆栈支持的终端环境，MQTT爱莫能助了。

在一些类似于传感器电子元件中，资源十分受限，计算能力不足，嵌入TCP/IP网络堆栈不现实，比较好的方式基于IEEE 802.15.4用于低速无线个人域网(LR-WPAN)的物理层和媒体接入控制层规范之上发送UDP数据包，每一个数据包最大128个字节。

MQTT-SN（MQTT For Sensor Networks）协议就是为了非常受限类似传感器而设的，协议流程架构比较有趣：

更多协议细节，有待进一步阅读。

TCP不是最适合的移动网络传输协议

先来算一下网络传输的字节数。

以太网帧头至少18个字节，IP头固定20个字节，TCP头20个字节（UDP头部8个字节），再加上电信宽带计费的PPPoE的8个字节：

• TCP数据包头部信息至少占有66个字节
• UDP数据报头部信息至少占有54个字节

UDP可以比TCP节省12个字节。

MQTT-SN协议选择使用UDP，可以看出其在节省资源方面的努力。

再看看弱网环境。

• 在网络可达情况下，UDP可以在TCP建立第一次握手期间就已经把数据送达目的地
• 完成三次握手期间，UDP客户端和UDP服务器在数据层面可以完成一次完整的交互（PING-PONG）

在网络不好的情况下，UDP的时效性会好于TCP，TCP长连接中间交换过多、使之建立完整交互的过程成功率就很低。此种情况UDP的低延迟和实时性呈现的结果会表现的很突出。

TCP或HTTP理论上是可靠连接，但是在网络不好的时候，也不是那么可靠。客户端一般提交HTTP请求之后，没有确认是否提交成功，在弱网环境下会产生丢包，服务器端嘛收不到。另TCP网络堆栈会存在数据包重发机制 + 应用层重发请求，可能会导致内核处理多次数据包的重发（还有拥塞窗口会收缩，发包速度减慢），可能会加重弱网络的负载。

和TCP相比，UDP的无连接，代表了它快速，资源消耗小，突出表现就是延迟较小。至于数据包丢失没有重传，上层的业务层面应用协议/机制可以确保丢失的数据包重发或补发等，并且会更透明，安全的控性权。而TCP的包重发，上层应用没有控制权限。

连接协议方面：

• TCP面向连接会产生状态管理和维护，成本不小，比如经常看到的客户端reset异常等。一次完整的请求周期必须固定在一台服务器上
• UDP无连接的特性。每次请求的数据包可以随机分配到不同的机器上进行处理，可以做到完全无状态化横向扩展

总之，要实时性特诊，或者快速抵达终端的特性，不妨考虑一下UDP。不过呢，很多时候UDP和TCP大家会混合着使用，会互相弥补其不足。

小结

若MQTT协议不能够满足业务需求，或许可考虑选择定制，或简化流程，或使用UDP重新实现，或者使用TCP／HTTP作为补充等，不一而足。

想想，还真有点小激动呢！ ------ 《万万没想到》王大锤

MQTT协议诞生之初，就未曾考虑通过HTTP传输。这也正常，网络受限、不稳定网络不太适合HTTP（2G/3G网络大家使用WAP不也OK嘛）。在网络较为充裕的桌面端而言，虽纯文本对比二进制而言没多大优势，受制于历史遗留和使用习惯，以及一大票传统基础设施方便控制事宜，传统互联网/企业型应用，HTTP协议都是默认最佳选择，安全可控，人机友好。选择HTTP也在情理之中。

虽桌面端日渐式微，但做统一的全平台化消息系统/消息中间件，也是趋势。

MQTT OVER HTTP，为WEB环境提供HTTP通道协议支持，在统一平台化这样的考量下，就显得合情合理。 MQTT相比其它基于HTTP的交换协议而言（比如socket.io），流量节省，消息质量可控。

一句话，比它强大的，没有它轻量。比它还轻的，没有它可控。

总之，在资源受限环境下表现如此优异，那么桌面端会表现的更为优秀。

HTTP支持情况

二进制支持，针对浏览器端JavaScript而言，处理起来，如同在石器时代要处理工业时代一些通讯方式，非常吃力。支持Javascript二进制操作的浏览器现状：

来源于：http://caniuse.com/xhr2

这和支持Websocket的浏览器的基本重叠。

要想让HTTP传输MQTT具体消息二进制，然后由浏览器javascript脚本进行解析，无法做到支持所有常见浏览器，需要考虑纯文本方式的传输。

设计摘要

AJAX方式，支持跨域，支持所有主流平台，桌面+移动设备；所有浏览器，移动的，桌面的，包括IE6+。那么最理想方式就是JSONP，基于文本通信的Long-polling JSONP方式。

MQTT 协议关键交互点： 1. 连接获取授权 1. 订阅/退订主题 1. 发布消息 1. 等待订阅消息 1. 关闭连接

若支持HTTP方式完成以上功能/步骤，服务器端需要支持接收HTTP纯文本内容请求，拼装、转换成Java对象，业务层面实现数据流转、交换，直接插入到更具体业务中，这样就很容易。虽类似于桥接，但减少了桥接的路径（HTTP —》MQTT），减少资源占用，性能上有所保证。

HTTP 文本方式，和MQTT二进制之间需要某些规则的转换，为了兼容，需要单独定义接口传输接口，ChannelEntry，双通道和单通道处理数据的方式不同，单通道的HTTP JSONP需要支持短暂缓存消息并等待客户端的依次获取。发布/接收订阅消息时，TCP/Websocket利用双通道对应Channel可直接发送。

HTTP通道已经预留出接口，便于支持其它类型的HTTP传输通道，比如需要在非浏览器环境中实现常规的long polling/Http Streaming，仅仅需要做到实现相应接口即可。

客户端ID的生成方式，一般是由服务器端生成的SessionId决定。传输纯文本方式比较结构化JSON结构比较合适。

JSONP只支持HTTP GET方式，这一点需要牢记。

传输接口定义

1. 连接获取授权 /jsonp/connect
2. 订阅主题 /jsonp/subscribe
3. 等待订阅消息 /jsonp/waiting
4. 发布主题 /jsonp/publish
5. 退订主题 /jsonp/unsubscrible
6. 关闭连接 /jsonp/disconnect

要求返回的消息类型都是JSON字符串形式，订阅/发布的消息，一定要包含{id:10, msg:'具体消息内容'}类似json字符串。

简单示范

一般传输的是文字内容，但具有结构化的，非json莫属。无论是走TCP方式二进制流还是JSONP传输的内容体，json都是不错的可结构化数据的选择。

浏览器端jquery，支持jsonp请求，这里有一个简单示范：

填写好地址，自动执行连接，订阅，接收消息，一个最简单的Demo表现了其流程。

小结

简单实现jsonp形式的MQTT OVER HTTP，做到文本和二进制彼此之间交换数据。总之在纯HTTP环境下使用MQTT协议，是一个不错的选择。

MQTT协议专注于网络、资源受限环境，建立之初不曾考虑WEB环境，倒也正常。虽然如此，但不代表它不适合HTML5环境。

HTML5 Websocket是建立在TCP基础上的双通道通信，和TCP通信方式很类似，适用于WEB浏览器环境。虽然MQTT基因层面选择了TCP作为通信通道，但我们添加个编解码方式，MQTT Over Websocket也可以的。

这样做的好处，MQTT的使用范畴被扩展到HTML5、桌面端浏览器、移动端WebApp、Hybrid等，多了一些想像空间。这样看来，无论是移动端，还是WEB端，MQTT都会有自己的使用空间。

浏览器支持

话说，现代化浏览器都已经支持Websocket，这里有一个所有浏览器支持列表：

更详细列表，请直接访问：http://caniuse.com/websockets

毫无疑问，火狐和谷歌浏览器带动了现代浏览器的发展，对HTML5标准的支持也是如此。支持Websocket的浏览器单纯从上面数字来讲，73.88%的支持率。但实际上还得参考浏览器市场占有率：

上图数据，来源于: 2014年4月份全球主流浏览器市场份额排行榜

超过60%用户机器上浏览器的支持Websocket，数据很可观。

移动hybrid型应用会很欢迎Websocket

• 内置浏览器支持HTML5，Javascript操作Websocket连接MQTT
• 借助于原生TCP socket通道连接MQTT服务器，暴露JavaScript接口，间接使用

不支持Websocket的桌面浏览器，可以考虑Flash socket来帮忙！

针对不支持websocker的部分历史浏览器，可以考虑一下Flash socket，虽然使用Flashsocket用以模拟Websocket就很容易理解，但条件如下： - 需要单独占用一个端口专用于安全跨域访问策略 - 需要浏览器支持二进制Blob 支持二进制操作的浏览器现状：

来源于：http://caniuse.com/xhr2

比较一下支持Websocket和XHR2的桌面浏览器，重叠率很高，使用Flash Socket用以模拟Websocket必要性不大，在类似于IE平台上，不如直接使用Flash版本的

https://github.com/yangboz/as3MQTT/tree/master/MQTTClient_AS3

不支持Websocket浏览器怎么办

不是所有浏览器都支持Websocket，尤其是阻碍历史发展的IE6/IE7/IE8/IE9。MQTT协议为二进制协议压根和HTTP纯文本不兼容，尤其浏览器端JavaScript处理文本很合适，但二进制就显得笨手笨角，除非支持XHR2。

1. 单独使用Flash MQTT Client，这这方面见解不深，实践很少，不便多说，您要是很了解，不妨告知一二。
2. HTTP纯文本方式进行二进制对接

这部分后面专门会讲到。

服务器端支持

现有一些解决方案可能是后面为MQTT Broker，前面是添加一层代理。比如：例如 mod_websocket ，对应在线示范：http://test.mosquitto.org/ws.html

表面上看着很解藕的，实际上模仿的还是传统型的短连接反向代理架构：Nginx/Apache ＋Java/PHP/Python/Ruby。

客户端建立一条连接，服务器端需要使用到至少两个文件句柄，中间多了一层路径。优雅的解决方案，可以向socket.io看起。一套服务端程序，同时提供若干种协议供终端选择。其实，一台MQTT Broker中间件服务器，可以绑定多个端口，一个面向纯TCP的1883端口，一个面向Websocket的80/8080端口，共享基础逻辑，面向不同协议。

Websocket协议适配

服务器添加对Websocket支持，基本不用做多大改动。对比Tcp的附加到单个Channel的处理器列表：

Websocket对应单个Channel的处理器列表：

为了支持Websocket协议，仅仅额外增加了：

小结

啰啰嗦嗦的讲了一大通Websocket，总之对Websocket的支持还算容易。后面有时间写写如何使用HTTP协议达到MQTT OVER HTTP的效果。

前言

MQTT定义了物联网传输协议，其标准倾向于原始TCP实现。构建于TCP的上层协议堆栈，诸如HTTP等，在空间上多了一些处理路径，稍微耗费了CPU和内存，虽看似微乎其微，但对很多处理能力不足的嵌入式设备而言，选择原始的TCP却是最好的选择。

但单纯TCP不是所有物件联网的最佳选择，提供构建与TCP基础之上的传统的HTTP通信支持，尤其是浏览器、性能富裕的桌面涉及领域，还是企业最 可信赖、最可控的传输方式之一。支持多种多样的连接通道，让目前所有一切皆可联网，除了原始TCP Socket，还要支持构建于其之上的HTTP、HTML5 Websocket，就很有必要。

mqtt.io，Pub/Sub中间件，也可以称之为推送服务器，涵盖所有主流桌面系统、浏览器平台，并且倾斜 于移动互联网，以及物联网的广阔适应天地。使用一句英文概括可能更为合适："Make everything connect”，让所有物件都可连接。其业务目标，可用下图概括：

mqtt.io致力于做下一代支持所有主流桌面平台、所有主流浏览器、所有可联网物件都可以联网的PUB/SUB消息推送系统。

构建此系统，在于降低传统企业各自分散的推送系统，统一运营，统一管理，节省人员、运维开支。

注意事项

1. mqtt.io是一个项目名称，没有官网，http://www.mqtt.io，和这个项目没有一毛钱关系。
2. 项目地址：https://github.com/yongboy/mqtt.io，
3. 项目名称启发于 http://socket.io http://netty.io 等知名framework。
4. 目前只实现QoS 0基本特性，实现概览，后期会根据反馈，做出一些调整

依赖

1. netty 4，目前JAVA IO界明星
2. mqtt-library 二进制和MQTT对象的转换，这种苦活累活都是它来做，真心让人喜欢。

数据流转

解码器

用于转换二进制流到JAVA对象的过程：

编码器

对所有要写入网卡缓冲区的JAVA对象转换成二进制：

借助于mqtt-library项目，编解码不复杂。

MQTT的消息处理

更具体的可以查看项目。

小结

简单介绍了一个简单的不能再简单的MQTT Server，只具有最基本的QoS 0类型的消息订阅等。

后面，对HTML 5 Websocket，会在现有基础代码之上，不做多大改动，增加对MQTT Over WebSocket的支持。

前面的笔记已把所有消息类型都过了一遍，这里从消息流的角度尝试解读一下。

网络故障

在任何网络环境下，都会出现一方连接失败，比如离开公司大门那一刻没有了WIFI信号。但持续连接的另一端-服务器可能不能立即知道对方已断开。类似网络异常情况，都有可能在消息发送的过程中出现，消息发送出去，就丢失了。

MQTT协议假定客户端和服务器端稳定情况一般，彼此之通信管道不可靠，一旦客户端网络断开，情况就会很严重，很难恢复原状。

但别忘记，很多客户端会有永久性存储设备支持，比如闪存ROM、存储卡等，在通信出现异常的情况下可以用于保存关键数据或状态信息等。

总之，异常网络情况很复杂，只能小心处理之。

消息重发策略

在QoS > 0情况下，PUBLISH、PUBREL、SUBSCRIBE、UNSUBSCRIBE等类型消息在发送者发送完之后，需要等待一个响应消息，若在一个指定时间段内没有收到，发送者可能需要重试。重发的消息，要求DUP标记要设置为1.

等待响应的超时应该在消息成功发送之后开始算起，并且等待超时应该是可以配置选项，以便在下一次重试的时候，适当加大。比如第一次重试超时10秒，下一次可能为20秒，再一次重试可能为60秒呢。当然，还要有一个重试次数限制的。

还有一种情况，客户端重新连接，但未在可变头部中设置clean session标记，但双方(客户端和服务器端)都应该重试先前未发送的动态消息（in-flight messages）。客户端不被强制要求发送未被确认的消息，但服务器端就得需要重发那些未被去确认的消息。

QoS level决定的消息流

QoS level为Quality of Service level的缩写，翻译成中文，服务质量等级。

MQTT 3.1协议在"4.1 Quality of Service levels and flows"章节中，仅仅讨论了客户端到服务器的发布流程，不太完整。因为决定消息到达率，能够提升发送质量的，应该是服务器发布PUBLISH消息到订阅者这一消息流方向。

QoS level 0

至多发送一次，发送即丢弃。没有确认消息，也不知道对方是否收到。

针对的消息不重要，丢失也无所谓。

网络层面，传输压力小。

QoS level 1

所有QoS level 1都要在可变头部中附加一个16位的消息ID。

SUBSCRIBE和UNSUBSCRIBE消息使用QoS level 1。

针对消息的发布，Qos level 1，意味着消息至少被传输一次。

发送者若在一段时间内接收不到PUBACK消息，发送者需要打开DUB标记为1，然后重新发送PUBLISH消息。因此会导致接收方可能会收到两次PUBLISH消息。针对客户端发布消息到服务器的消息流：

针对服务器发布到订阅者的消息流：

发布者（客户端/服务器）若因种种异常接收不到PUBACK消息，会再次重新发送PUBLISH消息，同时设置DUP标记为1。接收者以服务器为例，这可能会导致服务器收到重复消息，按照流程，broker（服务器）发布消息到订阅者（会导致订阅者接收到重复消息），然后发送一条PUBACK确认消息到发布者。

在业务层面，或许可以弥补MQTT协议的不足之处：重试的消息ID一定要一致接收方一定判断当前接收的消息ID是否已经接受过

但一样不能够完全确保，消息一定到达了。

QoS level 2

仅仅在PUBLISH类型消息中出现，要求在可变头部中要附加消息ID。

级别高，通信压力稍大些，但确保了仅仅传输接收一次。

先看协议中流程图，Client -> Server方向，会有一个总体印象：

Server -> Subscriber：

Server端采取的方案a和b，都包含了何时消息有效，何时处理消息。两个方案二选一，Server端自己决定。但无论死采取哪一种方式，都是在QoS level 2协议范畴下，不受影响。若一方没有接收到对应的确认消息，会从最近一次需要确认的消息重试，以便整个（QoS level 2）流程打通。

消息顺序

消息顺序会受许多因素的影响，但对于服务器程序，必须保证消息传递流程的每个阶段要和开始的顺序一致。例如，在QoS level 2定义的消息流中，PUBREL流必须和PUBLISH流具有相同的顺序发送：

流动消息(in-flight messages)数量允许有一个可保证的效果：

• 在流动消息(in-flight)窗口1中，每个传递流在下一个流开始之前完成。这保证消息以提交的顺序传递
• 在流动消息(in-flight)大于1的窗口，只能在QoS level内被保证消息的顺序

消息的持久化

在MQTT协议中，PUBLISH消息固定头部RETAIN标记，只有为1才要求服务器需要持久保存此消息，除非新的PUBLISH覆盖。

对于持久的、最新一条PUBLISH消息，服务器不但要发送给当前的订阅者，并且新的订阅者(new subscriber，同样需要订阅了此消息对应的Topic name）会马上得到推送。

Tip：新来乍到的订阅者，只会取出最新的一个RETAIN flag = 1的消息推送，不是所有。

消息流的编码/解码

MQTT协议中，由目前定义的14种类型消息在客户端和服务器端之间数据进行交互。若以JAVA语言构建MQTT服务器，可选择Netty作为基础。

在Netty中，数据的进入和流出，代表了一次完整的交互。无论是要进入的还是要流出的数据(单独以服务器为例)，都可看做字节流。若把每种类型消息抽象为一个具体对象，那么处理起来就不难了。

客户端->服务器，进入的字节流，逐个字节/单位读取，可还原成一个具体的消息对象（解码的过程）。

要发送到客户端的消息对象，转换（编码）成字节流，然后由TCP通道流转到接收者。

小结

断断续续记录了MQTT 3.1协议的若干阅读笔记，总之是把协议个人认为不够清晰，或者我不好理解的地方，着重进行了分析。也便于自己以后回过来头来翻阅，不是那么快的忘却。

这次要讲到客户端/服务器的发布消息行为，与PUBLISH相关的消息类型，会在这里看到。

PUBLISH

客户端发布消息经由服务器分发到所有对应的订阅者那里。一个订阅者可以订阅若干个主题(Topic name)，但一个PUBLISH消息只能拥有一个主题。

消息架构一览：

固定头部

DUP flag，设为0，表示当前为第一次发送。

RETAIN flag，只有在PUBLISH消息中才有效。

• 1：表示发送的消息需要一直持久保存，不但要发送给当前的订阅者，并且以后新来的订阅了此Topic name的订阅者会马上得到推送。 备注：新来乍到的订阅者，只会取出最新的一个RETAIN flag = 1的消息推送，不是所有。
• 0：仅仅为当前订阅者推送此消息。

可变头部

Topic name，UTF-8编码字符串形式，不支持通配符！

消息体

一般作为UTF-8编码写入接口，但不排除自定义的消息格式。

空的消息体（zero-length）的PUBLISH消息也可以是合法的。

当服务器接收到空消息体(zero-length payload)、retain = 1、具有topic name的一个PUBLISH特殊消息，表示同时满足retain = 1、相同topic name的这两个特征的被持久化PUBLISH消息，可被删除。

Response/响应

固定头部QoS level决定了消息中间件针对发布者具体需要响应的内容：

备注：仅仅针对发布PUBLISH消息的发布者。

Actions:

无论是订阅者还是服务器接收到PUBLISH消息之后，需要根据QoS level执行不同动作。

如果服务器收到PUBLISH消息，参与者指的是订阅者。如果订阅者收到PUBLISH消息，参与者就是服务器。 需要注意：

1. 发布者发布的PUBLISH消息发送到服务器，在payload/消息体处可能夹带有私货，可能含有自定义的数据 格式
2. 若兼容MQTT客户端，经由服务器分发到所有对应订阅者处只能是规规矩矩的PUBLISH消息，并且固定头部的RETAIN标志不能被设置成有效值1

授权

未经授权的发布者提交的PUBLISH消息，服务器会忽略掉，客户端不会被通知。

PUBACK

作为订阅者/服务器接收（QoS level = 1）PUBLISH消息之后对发送者的响应，整个消息不复杂。

虽没有消息体，但可变头部附加一个16位的无符号short类型。

PUBREC

字面意思为Assured publish received，作为订阅者/服务器对QoS level = 2的发布PUBLISH消息的发送方的响应，确认已经收到，为QoS level = 2消息流的第二个消息。 和PUBACK相比，除了消息类型不同外，其它都是一样。

无论是订阅者还是服务器，在消费PUBREC消息之后需要发送一个PUBREL消息给发送者（和PUBREC具有同样的消息ID），确认已收到。

PUBREL

Qos level = 2的协议流的第三个消息，有PUBLISH消息的发布者发送，参与方接收。完整示范如下：

QoS level 1，PUBREL消息要求如此。

DUP flag 为0，表示消息第一次被发送。

毫无疑问，剩余长度为2个byte长度。

可变头部中，消息ID和发布者接收到的PUBREC所包含的消息ID是一致的。

动作：

1. 服务器接收到发布者（a）的PUBREL消息，此时服务器让发布者（a）刚才发布PUBLISH消息可用，发送此PUBLISH消息给所有订阅此主题的订阅者，然后发送PUBCOMP消息给发布者（a）
2. 可变头部包含消息ID和服务器接收的PUBREL消息ID是一致的。 一个订阅者接收到PUBREL消息，订阅者使PUBLISH消息可用，然后反馈一个PUBCOMP消息给服务器

PUBCOMP

作为QoS level = 2消息流第四个，也是最后一个消息，由收到PUBREL的一方向另一方做出的响应消息。

完整的消息一览，和PUBREL一致，除了消息类型。

当客户端接收一个PUBCOMP消息时，客户端摒弃原来的消息，因为它已经成功发送消息到服务器。

小结

消息的发布和确认等一些流程，主要是跟消息发布者所设定的QoS level有关；稍加整理，绘制了下面一张图，理解起来可能会更清晰些：

上图针对的是客户端发布消息到服务器端的方向。

为了确保消息已经成功传递过去，只有收到了确认，才会让人特别放心。

在QoS level = 2时，通信双方都需要知道各自的确认流程以及所处阶段等，交互很多，数据量大的情况下，可能会造成数据线路传递拥塞。服务器选择QoS = 0/1，大部分情况都是可以应对的。 比如重要消息，就要确保对方都要收到，然后彼此确认，OK，这个消息是真实、有效的。

无论Qos level为0、1，还是2，服务器（具备所有条件都满足之后）总要把收到的具体内容和topic组装成一个新的PUBLISH Message（也不一定要重新构造，但要求推送的PUBLISH消息，一定要具有明确的主题和内容，RETAIN标志不能设置为1）推送到所有感兴趣的订阅者。

嗯，消息的发布来源别忘记还有可能来自CONNECT消息中的Will Topic和Will Message，若是设置了Will flag标记的话。