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的應用會越來越廣！

MQTT協議及推送服務（二）