XMPP協議、MQTT協議、HTTP協議、CoAP協議的基本比較

一、先看下相關國外的專業數據對四大協議的比較：

XML的解析對於嵌入多設備來說是比較痛苦的 ，所以在嵌入設備上做開發的時候，最好不要選擇基於XML的協議。

二、四大協議的基本介紹：

物聯網協議XMPP

XMPP是一種基於標準通用標記語言的子集XML的協議，它繼承了在XML環境中靈活的發展性。因此，基於XMPP的應用具有超強的可擴展性。經過擴展以後的XMPP可以通過發送擴展的信息來處理用戶的需求，以及在XMPP的頂端建立如內容發佈系統和基於地址的服務等應用程序。而且，XMPP包含了針對服務器端的軟件協議，使之能與另一個進行通話，這使得開發者更容易建立客戶應用程序或給一個已經配置好XMPP協議的系統添加功能。

物聯網協議MQTT

MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸）是IBM開發的一個即時通訊協議，有可能成為物聯網的重要組成部分。該協議支持所有平臺，幾乎可以把所有聯網物品和外部連接起來，被用來當做傳感器和致動器（比如通過Twitter讓房屋聯網）的通信協議

物聯網協議CoAP

CoAP是受限制的應用協議(Constrained Application Protocol)的代名詞。在最近幾年的時間中，專家們預測會有更多的設備相互連接，而這些設備的數量將遠超人類的數量。在這種大背景下，物聯網和M2M技術應運而生。雖然對人而言，連接入互聯網顯得方便容易，但是對於那些微型設備而言接入互聯網非常困難。在當前由PC機組成的世界，信息交換是通過TCP和應用層協議HTTP實現的。但是對於小型設備而言，實現TCP和HTTP協議顯然是一個過分的要求。為了讓小設備可以接入互聯網，CoAP協議被設計出來。CoAP是一種應用層協議，它運行於UDP協議之上而不是像HTTP那樣運行於TCP之上。CoAP協議非常的小巧，最小的數據包僅為4字節。

物聯網協議RESTful HTTP

REST 指的是一組 架構約束條件和原則。滿足這些約束條件和原則的應用程序或設計就是 RESTful。

web 應用程序最重要的 REST 原則是，客戶端和服務器之間的交互在請求之間是無狀態的。從客戶端到服務器的每個請求都必須包含理解請求所必需的信息。如果服務器在請求之間的任何時間點重啟，客戶端不會得到通知。此外，無狀態請求可以由任何可用服務器回答，這十分適合 雲計算之類的環境。客戶端可以緩存數據以改進性能

三、從現有的移動端（Android）消息推送方案中，也可以看出MQTT協議和XMPP協議的優缺點

方案1、 使用GCM服務（Google Cloud Messaging）

簡介：Google推出的雲消息服務，即第二代的G2DM。

優點：Google提供的服務、原生、簡單，無需實現和部署服務端。

缺點：Android版本限制（必須大於2.2版本），該服務在國內不夠穩定、需要用戶綁定Google帳號，受限於Google。

方案2、 使用XMPP協議（Openfire + Spark + Smack）

簡介：基於XML協議的通訊協議，前身是Jabber，目前已由IETF國際標準化組織完成了標準化工作。

優點：協議成熟、強大、可擴展性強、目前主要應用於許多聊天系統中，且已有開源的Java版的開發實例androidpn。

缺點：協議較複雜、冗餘（基於XML）、費流量、費電，部署硬件成本高。

方案3、 使用MQTT協議（更多信息見： http://mqtt.org/ ）

簡介：輕量級的、基於代理的“發佈/訂閱”模式的消息傳輸協議。

優點：協議簡潔、小巧、可擴展性強、省流量、省電，目前已經應用到企業領域（參考： http://mqtt.org/software ），且已有C++版的服務端組件rsmb。

缺點：不夠成熟、實現較複雜、服務端組件rsmb不開源，部署硬件成本較高。

方案4、 使用HTTP輪循方式

簡介：定時向HTTP服務端接口（Web Service API）獲取最新消息。

優點：實現簡單、可控性強，部署硬件成本低。

缺點：實時性差。

對各個方案的優缺點的研究和對比，推薦使用MQTT協議的方案進行實現，主要原因是： MQTT最快速，也最省流量（固定頭長度僅為2字節），且極易擴展，適合二次開發 。

總結來說：

如果我們對上面的結果進行一次PK，我想最後的結果就是MQTT vs CoAP。HTTP對於嵌入式設備來說太重了，也不靈活，XMPP就更不用說了，與MQTT還有一比的便是CoAP——一個還在草稿階段的協議。