MQTT协议及推送服务
MQTT简介
MQTT全称叫做Message Queuing Telemetry Transport，意为消息队列遥测传输，是IBM开发的一个即时通讯协议。由于其维护一个长连接以轻量级低消耗著称，所以常用于移动端消息推送服务开发。
MQTT特性
MQTT具有如下特性：
使用发布／订阅消息模式，提供一对多消息发布；
对负载内容屏蔽的消息传输；
使用TCP/IP进行网络连接；
主流的MQTT是基于TCP进行连接的，同样也有UDP版本的MQTT，但是不太常用，叫做MQTT-SN。
具有三种消息发布服务质量选项；
1.“至多一次”，通常app的推送使用的就是这种模式。也就是说，如果移动设备在消息推送的时候没有联网，那么再次联网就不会收到通知了；
2.“至少一次”，可以确保消息收到，但消息可能会重复；
3.“只有一次”，确保消息到达一次，比如计费系统， 如果出现消息重复或者丢失会导致系统结果不正确的问题。
小型传输，开销很小（固定长度的头部是2字节），协议交换最小化，以降低网络流量；
这就是为什么MQTT能以轻量级低消耗著称，所以MQTT特别适用于低开销、低宽带占用的即时通讯场景。
通知有关各方客户端异常中断的机制。
MQTT协议实现方式
image
在MQTT协议中有三种身份：
发布者(Publish)。发布者其实是客户端，可以进行发布消息；
代理(Broker)。代理指的是服务器，比较有名的是eqmtt，当前，你也可以用其他成熟的框架去搭建MQTT服务；
订阅者(Subscribe)。一般指的是客户端，不过，发布者同时也可以是订阅者。
MQTT客户端
一般来说，客户端可以实现一下功能：
给其他客户端发布订阅的信息；
订阅其他客户端发布的信息；
退订和订阅主题；
断开服务器连接。
MQTT服务端
MQTT服务端也称为消息代理，经常你会听到broker这个词。它可以实现一下功能：
接收来自客户端的网络连接；
接受客户发布的应用信息；
处理来自客户端主题订阅和退订请求；
向订阅的客户端转发应用程序消息。
MQTT协议中的方法
MQTT和HTTP一样，也定义了一些动作，来表示对确定资源进行操作。
Connect，等待于服务器建立连接；
Disconnect，等待客户端完成所做的工作，并与服务器断开TCP/IP会话；
Subscribe，主题订阅；
UnSubscribe，主题取消订阅；
Publish，发送消息。
移动端推送服务
消息推送服务目前已经是app开发中必备的一个功能了，及时地将消息推送给用户，可以使得用户不会错过重大新闻或者重要事件通知。一般，推送服务有三种实现方式：
轮询方式。客户端不断的查询服务器，检索新内容。这种方式的缺点十分明显，如果轮询频率过快，会大量消耗网络带宽和电池；
长连接方式。客户端和服务端维持一条TCP/IP长连接，服务端向客户端push数据。这种方式可以避免轮询方式带来的性能问题，但是长连接依然会带来耗能问题。目前苹果的APNS和谷歌的GCM都是基于此方案来实现推送服务的；
SMS方式。当服务端有新内容的时候，会发送一条类似短信的指令传给客户端，客户端收到后从服务端下载新内容。由于运营商并没有免费开放这种指令，使用需要向运营商缴纳部分费用，所以并没有大量运用起来，但是这种方式非常的高效和及时。
iOS和Andorid推送的实现差异
之前我们说过，目前移动端的推送服务实现都是基于长连接方式实现的。服务端和客户端之间需要存在一条长连接来维持，当服务端主动推送内容给客户端时，客户端可以接收到该内容。
iOS推送服务
在iOS系统中，这个长连接是由系统去维护，iOS上所有应用的推送都是先将推送推到苹果推送服务器(APNs)上，应用需要推送功能时，需要先注册推送服务。其流程图如下所示：
推送注册流程图
首先，苹果会下发deviceToken，这是apns推送实现的基础。APNs推送能够实现就是基于deviceToken来推送的，只有正确的deviceToken才会被APNs接受，一般第三方推送商就是来收集deviceToken来进行推送的。
当开始进行推送内容的时候，服务端会将内容先推到APNs，然后，剩下的就都交给APNs去做了，其推送内容流程如下：
推送注册流程图
苹果这么做，不管是给用户还是开发者，带来的好处都是实实在在的：
由于是系统级别的长连接，所以不会出现被杀死而不发推送的现象；
省电。不用每个app都去各自维护一个自己的长连接；
安全可靠。为了能够使用推送服务，必须先在开发者账号注册推送功能，这就大大降低了长连接滥用的场景。
对于开发来说，实现起来十分容易，服务端只要将正确的deviceToken和推送内容发送给APNs，然后客户端进行推送注册和逻辑处理就行了。
Android推送服务
Android系统上，Google也推出了和APNS类似的服务，叫做GCM。但是由于国情原因(你懂得)，导致该服务在中国无法使用。所以，国内Andorid的普遍做法是自己维护一条长连接，和自己的推送服务器或者第三方推送商对接。
其实现原理APNs没有本质区别，但是由于一个设备通常需要维持多个长连接，所以在耗能这块，Andorid这块处理就不尽人意，并且，由于后台可以常驻，所以安全性这块也得不到保障。
除了类似APNs的实现，在Android上，也可以采用轮询方式，也可以简单实现推送功能。
MQTT实现消息推送
iOS端实现
对于iOS端使用MQTT来实现消息推送服务，比较常见的做法就是采用离线消息的方式去做，服务端发送推送消息，发送到APNs上，然后APNs通知客户端收到通知消息，客户端去服务端拉取最新消息列表，然后展示的界面上并处理相关逻辑。
Android端实现
由于并不是做Android开发，并且Android方面采用方式五花八门，了解的做法是类似iOS的实现，利用MQTT将服务端和客户端建议一个长连接，然后服务端将消息直接推倒客户端上，客户端收到推送消息后，去服务端拉取最新的消息列表。
总结
对于移动设备来说，MQTT以低开销、低带宽著称，十分适合搭建推送服务。目前方案也比较成熟，希望未来MQTT的应用会越来越广！
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
