mqtt协议理解

标签（空格分隔）： mqtt

这个协议因为公司需要做物联网方面的东西, 去工厂里面向技术人员讨论告诉我需要的一些技术,让我去琢磨.

由于物联网的环境是非常特别的，所以MQTT遵循以下设计原则：

精简，不添加可有可无的功能。
发布/订阅（Pub/Sub）模式，方便消息在传感器之间传递。
允许用户动态创建主题，零运维成本。
把传输量降到最低以提高传输效率。
把低带宽、高延迟、不稳定的网络等因素考虑在内。
支持连续的会话控制。
理解客户端计算能力可能很低。
提供服务质量管理。
假设数据不可知，不强求传输数据的类型与格式，保持灵活性。

这些也算是它的优点.

科普一下mqtt 一部分引用别的文章,加上我的理解;

发布/订阅模式

与请求/回答这种同步模式不同，发布/定义模式解耦了发布消息的客户（发布者）与订阅消息的客户（订阅者）之间的关系，这意味着发布者和订阅者之间并不需要直接建立联系。打个比方，你打电话给朋友，一直要等到朋友接电话了才能够开始交流，是一个典型的同步请求/回答的场景；而给一个好友邮件列表发电子邮件就不一样，你发好电子邮件该干嘛干嘛，好友们到有空了去查看邮件就是了，是一个典型的异步发布/订阅的场景。
熟悉编程的同学一定非常熟悉这种设计模式了，因为它带来了这些好处：

从上面可以知道:

发布者与订阅者不必了解彼此，只要认识同一个消息代理(服务端)即可。
发布者和订阅者不需要交互，发布者无需等待订阅者确认而导致锁定。
发布者和订阅者不需要同时在线，可以自由选择时间来消费消息(这个要注意消息类型)。

ps:其实这种可以用生活中使用的微信形象解释这种消息模式 :
甲给乙发送一个消息;
(其中就相当于甲发布了一个消息,而发布消息的目标是乙订阅的主题,只是这个主题是乙收消息的主题,甲传过来的消息可以分解为:发送人,发送的消息这样的参数)

乙不需要在线,但是在线就可以接收;

乙给甲发消息;
甲订阅了个接收消息的主题,而乙就是发到这个主题中
![消息发送订阅][3]

主题

MQTT是通过主题对消息进行分类的，本质上就是一个UTF-8的字符串，不过可以通过反斜杠表示多个层级关系。主题并不需要创建，直接使用就是了。
主题还可以通过通配符进行过滤。其中，+可以过滤一个层级，而*只能出现在主题最后表示过滤任意级别的层级。举个例子：

building-b/floor-5：代表B楼5层的设备。
+/floor-5：代表任何一个楼的5层的设备。
building-b/*：代表B楼所有的设备。

注意，MQTT允许使用通配符订阅主题，但是并不允许使用通配符广播(发送消息)。

通配符:

主题层级分隔符: `/`

/ 被用来分割主题树的每一层，并给主题空间提供分等级的结构。当两个通配符在一个主题中出现的时候，主题层次分隔符的使用是很重要的。

ps:类似于新闻分类中的结构 / 全球新闻/中国新闻/码农新闻

单层通配符`+`

+ 只匹配主题的一层。比如说，finance/stock/+匹配finance/stock/ibm和finance/stock/xyz，但是不匹配finance/stock/ibm/closingprice。另外，因为单层通配符只匹配1层，finance/+不匹配finance。

单层通配符可以被用于主题树的任意层级，连带多层通配符。它必须被用在主题层级分隔符/的右边，除非它是指定自己。因此，+和finance/+都是有效的，但是finance+无效。单层通配符可以用在主题树的末端，也可以用在中间。比如说，finance/+和finance/+/ibm都是有效的。

ps:匹配一层就是匹配全球新闻/ 而订阅码农新闻的人并不能收到发送给全球新闻/ 这个有通配符的主题的信息

多层通配符: `#`

# 是一个匹配主题中任意层次数的通配符。比如说，如果你订阅了finance/stock/ibm/#，你就可以接收到以下这些主题的消息。

>finance/stock/ibm
>finance/stock/ibm/closingprice
>finance/stock/ibm/currentprice
>

多层通配符有可以表示大于等于0的层次。因此，finance/#也可以匹配到单独的finance，在这种情况下#代表0层。在这种语境下主题层次分隔符/就没有意义了。因为没有可以分的层次。

多层通配符只可以确定当前层或者下一层。因此，#和finance/#都是有效的，但是finance#不是有效的。多层通配符一定要是主题树的最后一个字符。比如说，finance/#是有效的，但是finance/#/closingprice是无效的。

ps:多层匹配就是匹配全球新闻下的所有子主题订阅码农新闻的人能收到发送给全球新闻/# 这个有通配符的主题的信息

主题语法和用法

当你建立一个应用，设计主题树的时候应该考虑以下的主题名字的语法和语义：

主题至少有一个字符长。

主题名字是大小写敏感的。比如说，ACCOUNTS和Accounts是两个不同的主题。

主题名字可以包含空格。比如，Accounts payable是一个有效的主题。

以/开头会产生一个不同的主题。比如说，/finnace与finance不同。/finance匹配”+/+”和/+,但不匹配+

不要在任何主题中包含null（Unicode \x0000）字符。

以下的原则应用于主题树的建造和内容

在主题树中，长度被限制于64k内但是在这以内没有限制层级的数目。
可以有任意数目的根节点；也就是说，可以有任意数目的主题树。

服务质量

为了满足不同的场景，MQTT支持三种不同级别的服务质量（Quality of Service，QoS）为不同场景提供消息可靠性：

级别0：尽力而为。消息发送者会想尽办法发送消息，但是遇到意外并不会重试。

级别1：至少一次。消息接收者如果没有知会或者知会本身丢失，消息发送者会再次发送以保证消息接收者至少会收到一次，当然可能造成重复消息。

级别2：恰好一次。保证这种语义肯待会减少并发或者增加延时，不过丢失或者重复消息是不可接受的时候，级别2是最合适的。

服务质量是个老话题了。级别2所提供的不重不丢很多情况下是最理想的，不过往返多次的确认一定对并发和延迟带来影响(不适合api)。级别1提供的至少一次语义在日志处理这种场景下是完全OK的，所以像Kafka这类的系统利用这一特点减少确认从而大大提高了并发。级别0适合鸡肋数据场景，食之无味弃之可惜，就这么着吧。

ps:所以还是用级别1写api吧.0有点不稳妥,万一哪天发送个表白消息到妹子那里,妹子没收到造成不回复你.你还以为妹子不同意,或者默认…

消息类型

MQTT拥有14种不同的消息类型(报文的类型)：

CONNECT：客户端连接到MQTT代理
CONNACK：连接确认
PUBLISH：新发布消息
PUBACK：新发布消息确认，是QoS 1给PUBLISH消息的回复
PUBREC：QoS 2消息流的第一部分，表示消息发布已记录
PUBREL：QoS 2消息流的第二部分，表示消息发布已释放
PUBCOMP：QoS 2消息流的第三部分，表示消息发布完成
SUBSCRIBE：客户端订阅某个主题
SUBACK：对于SUBSCRIBE消息的确认
UNSUBSCRIBE：客户端终止订阅的消息
UNSUBACK：对于UNSUBSCRIBE消息的确认
PINGREQ：心跳
PINGRESP：确认心跳
DISCONNECT：客户端终止连接前优雅地通知MQTT代理

搭配一个我在测试时所分析的服务器的消息日志更清晰看到使用:

New connection from 192.168.1.166 on port 1883.

1520560007: New client connected from 192.168.1.166 as 036914380929367040071489983908 (c1, k60).

-新的连接 客户端连接指定的ClientID为036914380929367040071489983908 清除session  k60: 表示keep-alive=60s

1520560007: Sending CONNACK to 036914380929367040071489983908 (0, 0)

-发送连接ACK包给客户端 

1520560007: Received SUBSCRIBE from 036914380929367040071489983908

-服务器收到一个来自ClientID为036914380929367040071489983908的订阅请求 

1520560007:     SN69143809293670ctr (QoS 0)

-服务器识别036914380929367040071489983908订阅的主题为 SN69143809293670ctr，
指定的QOS=0遗嘱保留被设置为 0，服务端必须将遗嘱消息当作非保留消息发布

1520560007: 036914380929367040071489983908 0 SN69143809293670ctr

-给ClientID=036914380929367040071489983908客户端发送订阅SN69143809293670ctr ACK回包

1520560007: Sending SUBACK to 036914380929367040071489983908

-服务器发送内容给客户端日志

1520560017: Received PUBLISH from 036914380929367040071489983908 (d0, q0, r0, m0, 'SN69143809293670state', ... (99 bytes))

-服务器正在发送一个消息给ClientID=036914380929367040071489983908的客户端，消息体大小为99 bytes，消息主题为‘SN69143809293670state’
(d0, q2, r0, m0)的解释, 以下参数具体含义，参考MQTT协议
　　d: 表示mqtt报头的DUP字段
　　q: 表示的QOS字段
　　r: 表示的是RETAIN
　　m: 表示的是消息ID,即mid

ps:这个东西可以参考一下官方文档; 传送门

MQTT代理(算是服务端了)

市面上有相当多的高质量MQTT代理，其中mosquitto是一个开源的轻量级的C实现，完全兼容了MQTT 3.1和MQTT 3.1.1。下面我们就以mosquitto为例演示一下MQTT的使用。环境是百度开放云的云服务器以及Ubuntu 14.04.1 LTS，简单起见MQTT代理和客户端都安装在同一台云服务器上了。
centos安装方法

首先SSH到云服务器，安装mosquitto以及搭配的客户端：apt-get install mosquitto
apt-get install mosquitto-clients

现在在云端模拟云服务，订阅某办公楼5层的温度作为主题：

mosquitto_sub -d -t ‘floor-5/temperature’
Received CONNACK
Received SUBACK
Subscribed (mid: 1): 0

然后另外打开一个SSH连接，模拟温度计发送温度消息：
mosquitto_pub -d -t ‘floor-5/temperature’ -m ‘15’
Received CONNACK
Sending PUBLISH (d0, q0, r0, m1, ‘floor-5/temperature’, … (2 bytes))

此时回到第一个SSH客户端可以看到信息已经接收到了，之后便是心跳消息：

Received PUBLISH (d0, q0, r0, m0, ‘floor-5/temperature’, … (2 bytes))
15
Sending PINGREQ
Received PINGRESP

需要注意的是mosquitto客户端默认使用QoS 0，下面我们使用QoS 2订阅这个主题：

mosquitto_sub -d -q 2 -t ‘floor-5/temperature’
Received CONNACK
Received SUBACK
Subscribed (mid: 1): 2

切换到另外SSH连接然后在这个主题里面发送温度消息：

mosquitto_pub -d -q 2 -t ‘floor-5/temperature’ -m ‘15’
Received CONNACK
Sending PUBLISH (d0, q2, r0, m1, ‘floor-5/temperature’, … (2 bytes))
Received PUBREC (Mid: 1)
Sending PUBREL (Mid: 1)
Received PUBCOMP (Mid: 1)

此时回到第一个SSH客户端可以看到信息已经接收到了，以及相应的多次握手消息：

Received PUBLISH (d0, q2, r0, m1, ‘floor-5/temperature’, … (2 bytes))
Sending PUBREC (Mid: 1)
Received PUBREL (Mid: 1)
15
Sending PUBCOMP (Mid: 1)

至此我们初步了解了MQTT的基本知识！接下来会发布mqtt在php和node.js中的使用文章,敬请期待;