MQTT 教程详解

阅读本文大概需要 3.66 分钟

很早就想写关于 MQTT 的文章了，它是一个基于订阅和发布的很强大的消息推送协议，看到网上各种不系统的教程，当时在学习过程中也采了不少坑，那时我就在想之后要写一份关于 MQTT 的详细教程，最近在突击学校期末考试，顺便也抽点时间总结以及和大家互动分享一下！

概述我们都知道，客户端想要从服务器端获取消息无外乎两种渠道：主动「pull」和被动「push」先来说说 pull,所谓的 pull，就是我们客户端在某个时刻主动的向服务器发起请求，服务器收到我们的请求后在后台根据业务流程将消息响应给相应客户端,这是最原始获取信息的途径，但是存在着一个很严重的问题，就是时效性，也就是说客户端必须主动地向服务器“要”消息，不然消息没法到达客户端。这种方案的一种改进是：客户端定时的向服务器发起请求，询问服务器当是否有新消息。不得不说这种方式在一定程度上解决了时效性的问题，但是需要消耗很多的资源，客户端需要更多的电量和流量，服务器在没有消息推送的情况下也要不停的处理客户端的询问请求。这种方式更多的用在小规模的系统当中。既然主动「注：这里我是站在客户端角度来说的」不太好，那就来看看被动「push」,被动就是说当服务器端有什么消息的时候都会向客户端进行推送 「push」，我们客户端可以实时的 get 到新消息，消息推送的产生弥补了之前时效性等问题，因此在开发中，对于那种即时性的，比较耗能的项目我们一般都会采用消息推送「push」的形式。当然，消息推送的主流技术也有很多种，比如 C2DM 云端推送平台 ，这是一个用来帮助开发者从服务器向Android应用程序发送数据的服务,简单,轻量级,允许服务器可以通知移动应用程序直接与服务器进行通信，以便于从服务器获取应用程序更新和用户数据，但是该服务需要依赖于 Google 官方提供的C2DM 服务器,由于国内的网络环境，这个服务经常不可用，如果想要很好的使用，我们的 App Server 必须也在国外，这个恐怕不是每个开发者都能够实现的;再比如 APNS 服务 ，是苹果公司推出的一款推送 通知服务，就是苹果用专门的服务器来接收我们自己的服务器发送过去的推送消息，然后再转发到指定的 IOS 设备上面去，接收到消息的设 备再把推送消息通知给应用程序，应用程序采用一些手段如铃声或者是通知 的方式来提醒用户收到了通知消息。C2DM 和 APNS 都是通过长连接的方式来实现消息推送的，长连接的意思是客户端向服务器发送请求并得到响应后，依然保持着链接，一旦服务器端有新的消息要推送，就推过这条连接来完成。APNS 相比于C2DM 而 言，提供的是一种可靠的长连接服务，不会因为资源不足而杀死长连接的进程。显而易见的是，长连接会消耗客户端更多的电量。再再比如基于 XMPP 协议的消息推送 ，这是一种基于 XML 的协议，它继承了在XML环境中灵活的发展性。这个协议成熟、强大、可扩展性强、目前主要应用于许多聊天系统中，且已有开源的 Java 版的开发实例 androidpn。但是该协议较复杂、冗余（基于XML）、费流量、费电，部署硬件成本高。毫无疑问，MQTT 就是今天我要介绍的主角，附上相关官网链接：MQTT 官网：http://mqtt.org/

MQTT 介绍：

百度云物接入IoT Hub：https://cloud.baidu.com/doc/IOT/ProductDescription.html#.E7.89.A9.E6.8E.A5.E5.85.A5

MQTT Android github:https://github.com/eclipse/paho.mqtt.androidMQTT 协议在线中文版：https://mcxiaoke.gitbooks.io/mqtt-cn/content/mqtt/01-Introduction.html

MQTT 介绍它是 IBM 公司 开发的一个即时通讯协议，也是一个物联网传输协议，它被设计用于轻量级的发布/订阅式的消息传输，旨在为低带宽和不稳定的网络环境中的物联网设备提供可靠的网络服务。它针对低带宽网络，低计算能力的设备，做了特殊的优化，使得其能适应各种物联网应用场景，其实现在很多的第三方推送平台也是基于 MQTT 实现的。MQTT 协议原理

MQTT 基于 TCP/IP 协议，是一种轻量级的发布/订阅式消息传输协议，MQTT 中存在着三种角色，分别是订阅者（Subscribe），消息代理服务器（Broker）和发布者（Publish），其中，订阅者和发布者都可以是客户端，消息代理是服务器，消息发布者同时也可以是订阅者。

1.MQTT 传输的消息分为两个部分：主题（Topic）和负载（payload）（1）主题：我们可以把它理解为消息的类型,客户端订阅某一个主题后，当有新消息的时候，服务器就可以向该客户端推送相应主题的内容。（2）负载：其实就是具体消息的内容。2.服务质量在 MQTT 协议中，服务质量用 QoS 表示，并且有以下三种取值（1）QoS =0，至多一次，可能会出现丢包的情况，使用在对实时性要求不高的情况，例如，将此服务质量与通信环境传感器数据一起使用。 对于是否丢失个别读取或是否稍后立即发布新的读取并不重要。（2）QoS =1,至少一次，保证包会到达目的地，但是可能出现重包。（3) QoS =2, 刚好一次，保证包会到达目的地，且不会出现重包的现象3.客户端 Client使用MQTT的程序或设备。客户端总是通过网络连接到服务端。它可以

发布应用消息给其它相关的客户端。

订阅以请求接受相关的应用消息。

取消订阅以移除接受应用消息的请求。

从服务端断开连接。

4.服务端 Server一个程序或设备，作为发送消息的客户端和请求订阅的客户端之间的中介，简单来说就是数据中转站，服务端

接受来自客户端的网络连接。

接受客户端发布的应用消息。

处理客户端的订阅和取消订阅请求。

转发应用消息给符合条件的已订阅客户端。

5.订阅 Subscription订阅包含一个主题过滤器（Topic Filter）和一个最大的服务质量（QoS）等级。订阅与单个会话（Session）关联。会话可以包含多于一个的订阅。会话的每个订阅都有一个不同的主题过滤器。6.主题名 Topic Name附加在应用消息上的一个标签，服务端已知且与订阅匹配。服务端发送应用消息的一个副本给每一个匹配的客户 端订阅。7.会话 Session客户端和服务端之间的状态交互。一些会话持续时长与网络连接一样，另一些可以在客户端和服务端的多个连续网络连接间扩展。总结总的来说，MQTT 协议它的基本思想就是当不同客户端发布消息后，那些消息通过消息代理服务器转发到相应订阅了该主题消息的客户端，在这个过程中服务器作为一个数据中转站，实现了不同客户端之间的消息实时传输。

本篇为入门篇，先理解一下关于 MQTT 的相关概念及思想，下一篇将开始搭建服务器并进行测试，如果你喜欢，欢迎关注我的微信公众号：「半夏薄荷澜」，今后可以一起交流互动学习，互相进步，同时，如果有好的建议或者想法，半夏愿意一直做你的意见箱，不断改进，完善和进步！