由于现在的工作是偏物联网方向的，多学一点总归不会错的。
物联网（Internet of Things，IoT）最近曝光率越来越高。虽然HTTP是网页的事实标准，不过机器之间（Machine-to-Machine，M2M）的大规模沟通需要不同的模式：之前的请求/回答（Request/Response）模式不再合适，取而代之的是发布/订阅（Publish/Subscribe）模式。这就是轻量级、可扩展的MQTT（Message Queuing Telemetry Transport）可以施展拳脚的舞台。
这边思考下为什么P/S模式更加比R/R更加适合物联网呢。首先P/S的模式是一种主要你不主动断开订阅，就会持续进行发送的方式(可以通过心跳来检测接收方的在线情况)，RR模式则需要服务端被动回复。逻辑上两者是主动和被动的区别。
MQTT协议工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议。
-
（1）使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合。
这一点很类似于XMPP，但是MQTT的信息冗余远小于XMPP，,因为XMPP使用XML格式文本来传递数据。
-
（2）对负载内容屏蔽的消息传输。
-
（3）使用TCP/IP提供网络连接。
主流的MQTT是基于TCP连接进行数据推送的，但是同样有基于UDP的版本，叫做MQTT-SN。这两种版本由于基于不同的连接方式，优缺点自然也就各有不同了。
-
（4）有三种消息发布服务质量：
"至多一次"，消息发布完全依赖底层TCP/IP网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。这一种方式主要普通APP的推送，倘若你的智能设备在消息推送时未联网，推送过去没收到，再次联网也就收不到了。
"至少一次"，确保消息到达，但消息重复可能会发生。
"只有一次"，确保消息到达一次。在一些要求比较严格的计费系统中，可以使用此级别。在计费系统中，消息重复或丢失会导致不正确的结果。这种最高质量的消息发布服务还可以用于即时通讯类的APP的推送，确保用户收到且只会收到一次。
-
（5）小型传输，开销很小（固定长度的头部是2字节），协议交换最小化，以降低网络流量。
这就是为什么在介绍里说它非常适合"在物联网领域，传感器与服务器的通信，信息的收集"，要知道嵌入式设备的运算能力和带宽都相对薄弱，使用这种协议来传递消息再适合不过了。
-
（6）使用Last Will和Testament特性通知有关各方客户端异常中断的机制。
Last Will：即遗言机制，用于通知同一主题下的其他设备发送遗言的设备已经断开了连接。
Testament：遗嘱机制，功能类似于Last Will。
客户端
指使用MQTT的程序或设备。客户端总是去连接服务端。它可以
- 发布其他客户端可能会感兴趣的应用消息——————>change to server
- 订阅自己感兴趣的的应用消息
- 退订应用消息
- 从服务端断开连接
服务端
扮演订阅或发布应用消息的客户端之间的中间人。一个服务端
- 接受客户端的网络连接
- 接受客户端发布的应用消息
- 处理客户端订阅和退订的请求
- 转发匹配客户端订阅的应用消息
订阅：一个订阅由一个话题过滤器和一个最大的QoS组成。一个订阅只能关联一个会话。一个会话可以包含多个订阅。每个订阅都有不同的话题过滤器。
话题名称：指附着于应用消息的标签，服务端用它来匹配订阅。服务端给每个匹配到的客户端发送一份应用信息的拷贝。
话题过滤器：包含在订阅里的一个表达式，来表示一个或多个感兴趣的话题。话题过滤器可以包含通配符。
会话：一个有状态的客户端和服务端的交互。有些会话的存续依赖于网络连接，而其他则可以跨越一个客户端和服务端之间的多个连续的网络连接。
MQTT控制包：通过网络连接发送的包含一定信息的数据包。MQTT规范定义了14个不同类型的控制包，其中一个（PUBLISH包）用来传输应用信息。
数据表述
位：一个字节有8个位，从0到7。位7是最高有效位，位0是最低有效位。
整型数据值：整型数据值是16位大端序列：高阶字节在低阶字节之前。这意味着一个16位的字被放到网络上的时候，前面是最高有效位，后面是最低有效位。