MQTT 基本认知

物联网 (internet of thing) ，表示的是可以把一些带某些传感器的设备(终端)，接入到互联网的行为。

通过互联网连接这些设备，这些设备就能够互相协作。

而 MQTT 就是这些设备之间数据通信的一个基于 TCP/IP 的协议。

每个终端都和实现了 MQTT 协议的代理/服务器相连。

通过 published MQTT 代理服务器的某个 主题 发送数据。

通过 subscription 从 MQTT 代理服务器获取自己订阅的 主题 数据。

MQTT 协议是一种轻量级的、灵活的网络协议。并且非常适合 IOT 的场景。

大多数开发人员已经熟悉了 HTTP WEB 协议。那么为什么不让 IOT 设置链接到 WEB 服务？

设备可以采用 HTTP 请求的形式发送数据，并采用 HTTP 响应的形式从服务器获取数据，接受更新。

因为对于 IOT 的设备来说，这种 主动请求--> 被动等待应答的 数据传输模型存在严重的局限性：

那么，MQTT 为什么如此轻便且灵活？MQTT 协议的一个关键的特性是 发布/订阅模型 。它将数据的发布者和接受者分离。

一个设备终端既可以是数据的发布者 (published) 也可以是数据的订阅者 (subscription) 。

一个设备如果要发布数据，只需要往代理服务器中 相应的主题发布数据内容即可。

一个设备如果需要接受到数据，只需要在代理服务器中， 提前订阅自己需要关注的主题即可。

MQTT 最基本的体验，就是使用 mosquitto 。

Mosquitto是一款实现了 MQTT v31 协议的开源消息代理软件，提供轻量级的，支持发布/订阅的的消息推送模式，使设备对设备之间的短消息通信简单易用。

它可以理解成一个 MQTT 的代理服务器。

基本步骤如下：

安装成功截图

使用 brew services start mosquitto 启动 MQTT 服务

运行截图

然后再打开另外两个终端窗口，模拟两个IOT设备。A 订阅 MQTT 服务。B 向 MQTT 的服务发送数据。

A订阅当前MQTT的某个服务。

B向 MQTT 服务器发布(published) 数据。

然后，我们就可以在A控制台里看到由 B 通过 MQTT 服务发送的数据了。

基本流程图

控制台 A 向 MQTT 服务器订阅 dw/demo 服务，并被动的等待 MQTT 服务器返回数据。

控制台 B 主动的向 MQTT 服务器的 dw/demo 服务发送 published 数据，之后。服务器会主动向事先订阅了 dw/demo 的终端分发此消息。

MQTT 是一种链接协议，它指定了如何组织数据字节并通过 TCP/IP 网络传输它们。但实际上，开发人员并不需要链接这个链接协议的具体细节。我们只需要知道，每条消息都有一个命令和数据有效负载。该命令定义消息类型(比如 CONNECT 消息或者 SUB SCRIBE 消息)。所有的 MQTT 库和工具都提供了直接处理这些消息的基本方法，并且能自动填充一些必要的字段(在数据包的对应字节填充)，比如消息和客户端 ID。

首先客户端发送一条 CONNECT消息 来链接代理。CONNECT 消息要求建立从客户端到代理服务器的链接。

CONNECT 命令的基本参数

当客户端向代理服务器发送一条 CONNECT 命令之后，服务器会调用 CONNACK 命令，告知服务链接的状态。

CONNACK 命令的基本参数

当客户端和服务器建立连接之后，客户端就可以向服务器订阅某些主题的。(发送一条或多条 SUBSCRIBE消息 )。

表明当服务器接受到其他终端推送的此主题数据时，服务器会默认发送给它。

SUBSCRIBE 参数列表

当客户端成功的向服务器订阅某个主题之后，服务器会返回一条 SUBACK 的消息，其中包含一个或者多个 returnCode 参数。

SUBACK消息参数

returnCode : 值 0 - 2 ，表示成功订阅，并返回这个订阅消息的 QOS。值 128 ： 订阅失败。

既然客户端可以向服务器订阅某个主题，当然也可以取消订阅。

与 SUBSCRIBE 订阅命令相反的命令是 UNSUBSCRIBE 取消订阅命令。

此命令非常简单。只有一个topic(主题)参数。

上面讲的是订阅，订阅是需要有消息从服务器发送过来的。但是服务器本身基本不产生数据，那数据从何而来呢？

通过另外一个客户端执行 PUBLISH 命令，往代理服务器发送数据。并最终通过代理服务器将数据传递给订阅了此服务的客户端。

PUBLISH 消息参数

对于 MQTT 的一张基本理解图

基本流程图：

最后总结

参考资料：

初识 MQTT

MQTT协议是Message Queuing Telemetry Transport的缩写，中文名叫作消息队列遥测传输。是一个即时通讯协议，该协议支持所有平台，可以当作传感器来使用，举个例子，你仅仅在家通过此协议制造一个“传感器”，家里有医疗设备和装置并且安上了无线发射器，这样很适合那些有旧疾而且需要定期检查的病人们，在家就可以用设备自我检查之后通过无线MQTT协议将检查结果发送给负责你的医生，医生可以随时查看你的健康状况，并给出合理的建议，这样极大地方便了用户和医生的交流，非常便利。所以在推送信息和快速即时方面MQTT协议发展前景很是可观。

而TCP协议是学过计算机的人都比较熟悉的协议，分了四层，面向连接又可靠，可以用于文件传输、远程登陆、发送邮件等，但传输速度较慢，要求也比较多。这两个协议中大多数人都会推荐MQTT协议，因为MQTT是建立在TCP基础之上的，光实时性这一点就符合许多人的要求，现在信息高速时代大家要的第一点就是快速，让生活方便，并且比TCP有过之而无不及。

我也相信在未来MQTT协议会出现在我们的生活各个方面，这样灵活便捷的协议如果我们很好地利用，对我们信息技术的发展一定有着很大的帮助，这也是移动互联网发展的特色了吧。其实也不能绝对性地说MQTT比TCP好，只能说它功能更加全面，适应时代发展的要求，所以推荐选择它。

现在MQTT协议国内外也在逐渐应用，相信它会发展得越来越好的。

android消息推送GCM、XMPP、MQTT三种方案的优劣：

1、GCM服务（Google Cloud Messaging）优点：Google提供的服务、原生、简单，无需实现和部署服务端。缺点：Android版本限制，该服务在国内不够稳定、需要用户绑定Google帐号，受限于Google。

2、XMPP协议（Openfire + Spark + Smack）优点：协议成熟、强大、可扩展性强、目前主要应用于许多聊天系统中，且已有开源的Java版的开发实例androidpn。缺点：协议较复杂、冗余（基于XML）、费流量、费电，部署硬件成本高。

3、MQTT协议优点：协议简洁、小巧、可扩展性强、省流量、省电，目前已经应用到企业领域，且已有C++版的服务端组件rsmb。缺点：不够成熟、实现较复杂、服务端组件rsmb不开源，部署硬件成本较高。

d消息推送可以去了解一下极光，极光是个不错的平台。极光紧密围绕移动开发者需求，打造的开发者服务平台，可以提供一站式SaaS服务，通过全面覆盖PC、手机、传感器、无线路由器等多种设备数据，打造全域数据平台。当前，不断更新的SaaS产品及服务已深受国内百万开发者的认可和信赖。

根据实地观察，单台mqtt服务如果并发达到5w以上，就经常出故障；在2w左右内网访问服务器就比较卡了。

注：配置是4核 16G内存，虚机。配置有点差。对CPU的消耗比较高，内存基本没啥消耗，所以建议把CPU整好点。

1、 什么是MQTT

MQTT（MessageQueueing Telemetry Transport Protocol）的全称是消息队列遥感传输协议的缩写，是由IBM公司推出的一种基于轻量级代理的发布/订阅模式的消息传输协议，运行在TCP协议栈之上，为其提供有序、可靠、双向连接的网络连接保证。由于其开放、简单和易于实现所以能够应用在资源受限的环境中，对于M2M和物联网应用程序来说是一个相当不错的选择。

2、 为什么要用MQTT？

MQTT协议是针对如下情况设计的：

M2M（Machine to Machine） communication，机器端到端通信，比如传感器之间的数据通讯 因为是Machine to Machine，需要考虑： Machine，或者叫设备，比如温度传感器，硬件能力很弱，协议要考虑尽量小的资源消耗，比如计算能力和存储等 M2M可能是无线连接，网络不稳定，带宽也比较小

MQTT的特点:

发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合。这一点很类似于1 这里是列表文本XMPP，但是MQTT的信息冗余远小于XMPP

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

使用TCP/IP提供网络连接。主流的MQTT是基于TCP连接进行数据推送的，但是同样有基于UDP的版本，叫做MQTT-SN。这两种版本由于基于不同的连接方式，优缺点自然也就各有不同了。

三种消息传输方式QoS：

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

1代表“至少一次”，确保消息到达，但消息重复可能会发生。

2代表“只有一次”，确保消息到达一次。这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。 备注：由于服务端采用Mosca实现，Mosca目前只支持到QoS 1

如果发送的是临时的消息，例如给某topic所有在线的设备发送一条消息，丢失的话也无所谓，0就可以了（客户端登录的时候要指明支持的QoS级别，同时发送消息的时候也要指明这条消息支持的QoS级别），如果需要客户端保证能接收消息，需要指定QoS为1，如果同时需要加入客户端不在线也要能接收到消息，那么客户端登录的时候要指定session的有效性，接收离线消息需要指定服务端要保留客户端的session状态。

mqtt基于订阅者模型架构，客户端如果互相通信，必须在同一订阅主题下，即都订阅了同一个topic，客户端之间是没办法直接通讯的。订阅模型显而易见的好处是群发消息的话只需要发布到topic，所有订阅了这个topic的客户端就可以接收到消息了。

发送消息必须发送到某个topic，重点说明的是不管客户端是否订阅了该topic都可以向topic发送了消息，还有如果客户端订阅了该主题，那么自己发送的消息也会接收到。

小型传输，开销很小（固定长度的头部是2字节），协议交换最小化，以降低网络流量。这就是为什么在介绍里说它非常适合“在物联网领域，传感器与服务器的通信，信息的收集”，要知道嵌入式设备的运算能力和带宽都相对薄弱，使用这种协议来传递消息再适合不过了。

使用Last Will和Testament特性通知有关各方客户端异常中断的机制。Last Will：即遗言机制，用于通知同一主题下的其他设备发送遗言的设备已经断开了连接。Testament：遗嘱机制，功能类似于Last Will 。

Android中消息推送有如下几种方式：

1、轮询(Pull)方式：客户端定时向服务器发送询问消息，一旦服务器有变化则立即同步消息。　　2、SMS(Push)方式：通过拦截SMS消息并且解析消息内容来了解服务器的命令，但这种方式一般用户在经济上很难承受。　　3、持久连接(Push)方式：客户端和服务器之间建立长久连接，这样就可以实现消息的及时行和实时性。

消息推送，就是在互联网上通过定期传送用户需要的信息来减少信息过载的一项新技术。推送技术通过自动传送信息给用户，来减少用于网络上搜索的时间。根据用户的兴趣来搜索、过滤信息，并将其定期推给用户，帮助用户高效率地发掘有价值的信息。

关于消息推送的方式也可以使用第三方平台来帮助实现，然而极光就是一个不错的选择。极光私有云提供贴身专属定制，为您打造安全稳定高性能的私有云系统，助力企业业务升级。