开始
MQTT协议的开发公司，诞生时间等信息，可以通过google先生去查，这里就省略了。只说以下几个信息。
- 最新版本3.1.1
- 协议的详细内容，有各个语言版本的说明。中文版链接
- linux上最常用的是mosquitto
优点
- 十分轻量，最小可以做到2byte。处理速度快，占用带宽小。特别适合在M2M场景下使用。
- 可以做到一对一，一对多，双向通信
- 实际上也是基于TCP/IP的
- 消息可控可处理。采用pub/sub的方式，pub端发送某一主题的消息给服务器，sub订阅某些主题。中间的服务器可以进行很多处理，然后分发消息给sub。
主题管理
sub只能接收订阅的主题。主题可以使用[/]来设定成阶层的构造。
比如sub端想接收某一个服务器（或者是数据中心）的温度湿度消息。
/datacenter/abc/tokyo/floor/01/temperature
/datacenter/abc/tokyo/floor/01/humidity
/datacenter/abc/osaka/floor/01/temperature
/datacenter/abc/osaka/floor/01/humidity
/datacenter/xyz/tokyo/floor/05/temperature
/datacenter/xyz/tokyo/floor/05/humidity
/datacenter/xyz/nagoya/floor/12/temperature
/datacenter/xyz/nagoya/floor/12/humidity
sub端可以使用一些符号，模糊订阅一批主题。
- 准确订阅
/datacenter/abc/tokyo/floor/01/temperature
ABC数据中心的tokyo的1层的温度
- 前方一致订阅
/datacenter/xyz/nagoya/#
使用[#]获取 xyz数据中心的nagoya的所有阶层的温度和湿度
- 部分一致订阅
/datacenter/+/tokyo/floor/+/humidity
使用[+]获取所有数据中心的tokyo的所有阶层的湿度
[#]和[+]可以组合使用。
** 有意思的是sub可以使用通配符订阅，pub端却不能使用，必须发布完整的主题名 **
QoS
pub 发布消息到达sub端，可以指定以下三种品质等级
QoS0 : 就发送一次，sub收到收不到都不再重新发。
**QoS1 **: 保证至少sub端收到一次。但是有可能多次接到。
- pub发送出去后，需要sub返回一个【已收到】的回信。如果pub在一定时间未收到回信，会重复发送同一个消息，直到收到sub的回信。
QoS2 : 保证至少且只有一次sub端接到消息。
- 这个属于比较有意思的一项。需要来回两次，每次携带的状态码都不一样。在成功前，会一直重复发送。直到最终成功。
遗言机制
协议有专门设定遗言的标志： Will Flag。同时会影响另外两个位（Will Qos和Will Retain）是否有效。
Will Flag
就是pub客户端预先定义好，在自己跟MQTT服务器异常断开的情况下，所留下的最后遗愿（Last Will），也称之为遗嘱（Testament）。 这个遗嘱就是一个由客户端预先定义好的主题和对应消息，附加在CONNECT的可变头部中，在客户端连接出现异常的情况下，由服务器主动发布此消息。
只有在Will Flag位为1时，Will Qos和Will Retain才会被读取，此时消息体Playload中要出现Will Topic和Will Message具体内容，否则，Will QoS和Will Retain值会被忽略掉。
Will Qos
两位表示，和PUBLISH消息固定头部的QoS level含义一样。
若标识了Will Flag值为1，那么Will QoS就会生效，否则会被忽略掉。
Will RETAIN
如果设置Will Flag，Will Retain标志就是有效的，否则它将被忽略。
当客户端意外断开服务器发布其Will Message之后，服务器是否应该继续保存。这个属性和PUBLISH固定头部的RETAIN标志含义一样。
PUBLISH固定头部的RETAIN
定义MQTT服务器是否保留最后一次pub传递过来的消息。如果保留的话，当下一次消息发布前，如果有心的sub端加入，那么就把MQTT上保留的消息发送给新追加的sub端。
比如：一个小时或者一天才发布一次，新的消息接收端（sub端）却随时会追加的场景，就适合设定设定RETAIN。
