3. MQTT简要介绍

MQTT协议是广泛应用的物联网协议，使用测试MQTT协议需要MQTT的代理。有两种方法使用MQTT服务，一是租用现成的MQTT服务器，如阿里云，百度云，华为云等公用的云平台提供的MQTT服务，使用公用的MQTT服务器的好处是省事，但如果仅仅用于测试学习还需要注册帐号，灵活性差些，有的平台还需要付费。另一方法是自己使用开源的MQTT组件来搭建。
MQTT服务器非常多，如apache的ActiveMQ，emtqqd，HiveMQ，Emitter，Mosquitto，Moquette等等。
这里介绍的是用轻量级的mosquitto开源项目来搭建一个属于自己的MQTT服务器。
第一步：需要安装一台linux主机，这不多介绍，可以使用真机安装也可以使用虚拟机安装。如果仅仅是自己测试使用都可以。
第二步：下载mosquitto需要的依赖
sudo apt-get install libssl-devsudo apt-get install uuid-devsudo apt-get install cmake
第三步：下载mosquitto并解压，现在mosquitto官网最新的版本是151
tar xzvf mosquitto-151targz
第四步：编译
cd mosquitto-151/
make
make install
第五步：启动mosquitto
/mosquitto -v
1535473957: mosquitto version 151 starting
1535473957: Using default config
1535473957: Opening ipv4 listen socket on port 1883
1535473957: Opening ipv6 listen socket on port 1883
这时候mosquitto就会以默认的参数启动。如果需要带配置文件可以修改配置文件mosquittoconf，
启动时候加上参数 -c，
/mosquitto -c mosquittoconf
可以看到，mosquitto监听的端口为1883
这时候我们的MQTT服务器就搭建好了。可找一个mqtt客户端来测试一下。
先发布一个主题“home/garden/fountain/2”
内容是“hello world”
这时候在mosquitto会打印出下面的log
535474247: New connection from 1921681105 on port 1883
1535474247: New client connected from 1921681105 as MQTT_FX_Client (c1, k60)
1535474247: No will message specified
1535474247: Sending CONNACK to MQTT_FX_Client (0, 0)
1535474307: Received PINGREQ from MQTT_FX_Client
1535474307: Sending PINGRESP to MQTT_FX_Client
1535474339: Received PUBLISH from MQTT_FX_Client (d0, q0, r0, m0, 'home/garden/fountain/2', (12 bytes))
1535474367: Received PINGREQ from MQTT_FX_Client
1535474367: Sending PINGRESP to MQTT_FX_Client
订阅主题“home/garden/fountain/2”
可以看到收到了自己发布的消息。
用wireshark抓包
可以看到抓到了一个MQTT的publish的报文。

两者虽然都是从传统的Pub/Sub消息系统演化出来的，但是进化的方向不一样，以下是几个比较突出的点：
Kafka是为了日志收集的场景，抛弃exact once的语义而支持at least once以便得到更高的可扩展性。
MQTT是为了物联网场景而优化，不但提供多个QoS选项（exact once、at least once、at most once），而且还有层级主题、遗嘱等等特性。
说白了都是传统消息系统（老爸）的子嗣，只是与不同的场景（老妈）结合的产物。

MQTT跟WebSocket关系不大。他们不是在一个层级的。

WebSocket 很多网站使用轮询实现推送技术。轮询是在特定的的时间间隔（比如1秒），由浏览器对服务器发出>

Comet使用了AJAX改进了轮询，可以实现双向通信。但是Comet依然需要发出请求，而且在Comet中，普遍采用了长链接，这也会大量消耗服务器带宽和资源。

于是，WebSocket协议应运而生。 浏览器通过 JavaScript 向服务器发出建立 WebSocket 连接的请求，连接建立以后，客户端和服务器通过 TCP 连接直接交换数据。WebSocket 连接本质上是一个 TCP 连接。

WebSocket在数据传输的稳定性和数据传输量的大小方面，具有很大的性能优势。Websocketorg 比较了轮询和WebSocket的性能优势：

>

Use Case A： 1,000个客户端每秒接受一个message，网络吞吐量 （21,000）=2,000 bytes = 16,000 每秒bits

Use Case B： 10,000个客户端每秒接受一个message，网络吞吐量 （210,000）=20,000 bytes = 160,000 每秒bits

Use Case C： 100,000个客户端每秒接受一个message，网络吞吐量 （2100,000）=200,000 bytes = 1,600,000 每秒bits

MQTT 协议是为大量计算能力有限，且工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议，它具有以下主要的几项特性：

非常小的通信开销（最小的消息大小为 2 字节），小型传输，开销很小（固定长度的头部是 2 字节），协议交换最小化，以降低网络流量。

支持各种流行编程语言（包括 C，Java，Ruby，Python 等等）且易于使用的客户端；

使用发布 / 订阅消息模式，提供一对多的消息发布，解除应用程序耦合。

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

使用 TCP/IP 提供网络连接。

有三种消息发布服务质量，让消息能按需到达目的地，适应在不稳定工作的网络传输需求 ：

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

"至少一次"，确保消息到达，但消息重复可能会发生。

"只有一次"，确保消息到达一次。这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。

MQTT是非常流行的设备的接入协议，包括IBM、亚马逊、微软的IoT托管服务都有支持，而CoAP在这方面几乎没有露面的机会。感觉以下几点是MQTT优于CoAP的主要原因：
MQTT基于TCP，在做反控设备的时候比UDP更可靠，比如CoAP走3G、4G的时候甚至需要实现CoAP over TCP，否则反控很不稳定甚至无法联通。
MQTT异步Pub/Sub实现，好比发个微信，无需等待对方确认便可以继续，而不像CoAP那样必须等待对方应答才能返回的同步模式。
MQTT为物联网提供了许多体贴的设计，比如QoS，比如“遗言”的设计。
篇幅有限，无法完全枚举MQTT的优越性，建议参考以下文章：
MQTT入门篇
MQTT进阶篇
MQTT安全篇
MQTT实战篇
当然，CoAP在功耗方面有优势，不过随着物联网设备特别是网管的计算能力加强，这点应该不是主要矛盾。

---