开始

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。