实例：使用MQTT进行交互

最近在着手研究使用网页控制硬件的交互过程，发现mqtt协议有很多种语言的封装，整个思路也很清晰，就是一个客户端进行发布和订阅+服务器中间代理的过程，于是开始学习使用MQTT框架搭建交互平台。
客户端使用了MQTTjs，服务器使用mosca（基于nodejs）。

QoS在MQTT中有（摘自 MQ 遥测传输 (MQTT) V31 协议规范 ）：

MQTTjs只是支持了MQTT协议，并没有支持QoS，也就是说，只支持最低级别的“至多一次”（QoS0）。

在MQTT协议中，一个MQTT数据包由：固定头（Fixed header）、可变头（Variable header）、消息体（payload）三部分构成。
这里只了解消息体，固定头和可变头并不需要我们手动写。
payload消息体包含CONNECT、SUBSCRIBE、SUBACK、UNSUBSCRIBE四种类型的消息：

（1）Connect    与服务器建立连接。
（2）Disconnect    与服务器断开TCP/IP会话。
（3）Subscribe    订阅。
（4）UnSubscribe    取消订阅。
（5）Publish    发送消息请求，发送完成后返回应用程序线程。
二、实现（具体的API稍后呈现）

可以的
MQTT协议是为大量计算能力有限，且工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议,国内很多企业都广泛使用MQTT作为Android手机客户端与服务器端推送消息的协议

MQTT通信协议的基本介绍参考文章 NT35 MQTT通信 ，本篇给出阿里云的基本 *** 作，NT35E通过订阅阿里云的主题&发布信息与阿里云平台相互通信。

登录阿里云 → 工作台 → 物联网平台 → 进入控制台→ 公共实例

阿里云默认通信协议为MQTT，不需要特殊选择，用户按照如下步骤创建自己的产品：

创建产品 → 添加设备 

在"查看"标签中，包含了MQTT连接的基本三元组信息，也就是后面设备要填充的基本参数

      用户每定义一类产品都会自动生成对应的Topic列表，当然我们也可以"自定义Topic"便于自己测试。

       指令解析参考《Lierda NT35E&NT26E-CN AT命令手册》，这里给出使用到的AT指令对应参数说明以便于理解。

AT+LMQTTCFG=cloud,<tcpconnectID>[,<cloud _ type>,<data_type > ]

<tcpconnectID> 。MQTT Socket 标识符。范围：0~4。

<cloud_type>整型。2 alibaba，其他参数指定其他平台

<data_type>整型。阿里云平台 1 json数据 

AT+LMQTTCFG="cloud",0,2,1   对应就是对接阿里云平台，发送json格式的数据

AT+LMQTTCFG=aliauth,<tcpconnectID>[,<product_key>,<device_name>,<device_secret>]

填充阿里云平台中设备的三元组信息

AT+LMQTTCFG="aliauth",0,"a1JszCpjS61","NT35E_06011","390358fc595040aa73221e8393aba86c"

这部分是模组进行TCP链路连接(需抓包确认)

AT+LMQTTOPEN=<tcpconnectID>,<host_name>,<port>

host_name对应阿里云 "设备信息"→"MQTT连接参数" 中的 "mqttHostUrl"

AT+LMQTTOPEN=0,"a1JszCpjS61iot-as-mqttcn-shanghaialiyuncscom",1883

模组作为客户端，通过MQTT协议连接到服务器(需抓包确认)

AT+LMQTTCONN=<tcpconnectID>[,<clientID>[,<username>[,<password>]]]

<clientID>字符串型。客户端标识符。用户可以随便定义。 <username>,<password> 不需要填写

AT+LMQTTCONN=0,"NT35E"

AT+LMQTTSUBUNSUB=<tcpconnectID>,<subflag>,<msgID>,<topic1>[,<qos1>[,<topic2>[,<qos2>]d…]]

<subflag>整型。消息类型 0 订阅 1 取消订阅

<msgID>整型。数据包消息标识符。范围：0~65535。

<topic>带双引号的字符串型。客户端订阅或者退订的主题。长度范围：0~256 字节。

<qos>整型。客户端发送订阅消息(SUBSCRIBE)的 QoS 等级，此时为必选参数。2 正好一次，该主题下的消息确保接收端仅接收到一次

AT+LMQTTSUBUNSUB=0,0,1,"/a1JszCpjS61/ NT35E_06011 /user/COMMUTEST",2

这里注意<topic>对应参数的替换，里面的deviceName需要替换。

订阅主题之后，服务器下发的数据模组就可以正常接收了。模组下发位置

       发布消息在对应的设备目录下，如果有设备"订阅"对应的消息，平台"发布"相应的数据设备就可以接收到了。

AT+LMQTTPUB=<tcpconnectID>,<msgID>,<qos>,<retain>,<topic>,<msglen>,<msg>
<msgID>整型。 0~65535。任意定义，但<qos>=0 时，该参数值只能为0。

<qos>整型。 0 最多一次 1 至少一次 2  正好一次

<retain>整型 。服务器是否保存该消息。0 不保存  1 保存

<topic>带双引号的字符串型。 客户端发布消息的主题。长度范围：0~256 字节

<msglen>整型 。指定的消息数据长度。范围：0~1460。

<msg>字符串型。 需要发布的消息数据。

AT+LMQTTPUB=0,0,0,1,"/a1JszCpjS61/ NT35E_06011 /user/COMMUTEST",10,"1122334455"
       注意刚刚自己创建的主题属性是" 发布和订阅 "，所以模组发送该主题的信息，阿里云也是可以收到的

注意这里模组发送数据的时候，也推送了自己发送的数据，因为刚刚订阅了这个主题，所以模组订阅(收)到了对应的数据

       前面我们通过NT35E与平台进行信息交互，那么为什么是这样填写对应的参数呢，每个参数对应的说明在阿里云上是什么样的呢，用户可以查看阿里云的<帮助文档>进行确认。

       上面我们使用三元组的方式( 一机一密 )实现NT35E与阿里云平台通信，但实际生产过程中该方式不好实现，比如工厂有1000个设备生产，如果每个设备都复制不同的三元组，很难实现工厂批量化生产，此时可以通过 一型一密 的通信方式解决该问题。

一型一密模组端实现方式后续更新。

1、 什么是MQTT

MQTT（MessageQueueing Telemetry Transport Protocol）的全称是消息队列遥感传输协议的缩写，是由IBM公司推出的一种基于轻量级代理的发布/订阅模式的消息传输协议，运行在TCP协议栈之上，为其提供有序、可靠、双向连接的网络连接保证。由于其开放、简单和易于实现所以能够应用在资源受限的环境中，对于M2M和物联网应用程序来说是一个相当不错的选择。

2、 为什么要用MQTT？

MQTT协议是针对如下情况设计的：

M2M（Machine to Machine） communication，机器端到端通信，比如传感器之间的数据通讯 因为是Machine to Machine，需要考虑： Machine，或者叫设备，比如温度传感器，硬件能力很弱，协议要考虑尽量小的资源消耗，比如计算能力和存储等 M2M可能是无线连接，网络不稳定，带宽也比较小

MQTT的特点:

发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合。这一点很类似于1 这里是列表文本XMPP，但是MQTT的信息冗余远小于XMPP

对负载内容屏蔽的消息传输。

使用TCP/IP提供网络连接。主流的MQTT是基于TCP连接进行数据推送的，但是同样有基于UDP的版本，叫做MQTT-SN。这两种版本由于基于不同的连接方式，优缺点自然也就各有不同了。

三种消息传输方式QoS：

0代表“至多一次”，消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。

1代表“至少一次”，确保消息到达，但消息重复可能会发生。

2代表“只有一次”，确保消息到达一次。这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。 备注：由于服务端采用Mosca实现，Mosca目前只支持到QoS 1

如果发送的是临时的消息，例如给某topic所有在线的设备发送一条消息，丢失的话也无所谓，0就可以了（客户端登录的时候要指明支持的QoS级别，同时发送消息的时候也要指明这条消息支持的QoS级别），如果需要客户端保证能接收消息，需要指定QoS为1，如果同时需要加入客户端不在线也要能接收到消息，那么客户端登录的时候要指定session的有效性，接收离线消息需要指定服务端要保留客户端的session状态。

mqtt基于订阅者模型架构，客户端如果互相通信，必须在同一订阅主题下，即都订阅了同一个topic，客户端之间是没办法直接通讯的。订阅模型显而易见的好处是群发消息的话只需要发布到topic，所有订阅了这个topic的客户端就可以接收到消息了。

发送消息必须发送到某个topic，重点说明的是不管客户端是否订阅了该topic都可以向topic发送了消息，还有如果客户端订阅了该主题，那么自己发送的消息也会接收到。

小型传输，开销很小（固定长度的头部是2字节），协议交换最小化，以降低网络流量。这就是为什么在介绍里说它非常适合“在物联网领域，传感器与服务器的通信，信息的收集”，要知道嵌入式设备的运算能力和带宽都相对薄弱，使用这种协议来传递消息再适合不过了。

使用Last Will和Testament特性通知有关各方客户端异常中断的机制。Last Will：即遗言机制，用于通知同一主题下的其他设备发送遗言的设备已经断开了连接。Testament：遗嘱机制，功能类似于Last Will 。

MQTT协议是Message Queuing Telemetry Transport的缩写，中文名叫作消息队列遥测传输。是一个即时通讯协议，该协议支持所有平台，可以当作传感器来使用，举个例子，你仅仅在家通过此协议制造一个“传感器”，家里有医疗设备和装置并且安上了无线发射器，这样很适合那些有旧疾而且需要定期检查的病人们，在家就可以用设备自我检查之后通过无线MQTT协议将检查结果发送给负责你的医生，医生可以随时查看你的健康状况，并给出合理的建议，这样极大地方便了用户和医生的交流，非常便利。所以在推送信息和快速即时方面MQTT协议发展前景很是可观。

而TCP协议是学过计算机的人都比较熟悉的协议，分了四层，面向连接又可靠，可以用于文件传输、远程登陆、发送邮件等，但传输速度较慢，要求也比较多。这两个协议中大多数人都会推荐MQTT协议，因为MQTT是建立在TCP基础之上的，光实时性这一点就符合许多人的要求，现在信息高速时代大家要的第一点就是快速，让生活方便，并且比TCP有过之而无不及。

我也相信在未来MQTT协议会出现在我们的生活各个方面，这样灵活便捷的协议如果我们很好地利用，对我们信息技术的发展一定有着很大的帮助，这也是移动互联网发展的特色了吧。其实也不能绝对性地说MQTT比TCP好，只能说它功能更加全面，适应时代发展的要求，所以推荐选择它。

现在MQTT协议国内外也在逐渐应用，相信它会发展得越来越好的。

---