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

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

Protocol CoAP XMPP RESTful HTTP MQTT

Transport	UDP	TCP	TCP	TCP
Messaging	Request/Response	Publish/Subscribe Request/Response	Request/Response	Publish/Subscribe Request/Response
2G, 3G, 4G Suitability (1000s nodes)	Excellent	Excellent	Excellent	Excellent
LLN Suitability (1000s nodes)	Excellent	Fair	Fair	Fair
Compute Resources	10Ks RAM/Flash	10Ks RAM/Flash	10Ks RAM/Flash	10Ks RAM/Flash
Success Storied	Utility Field Area Networks	Remote management of consumer white goods	Smart Energy Profile 2 (premise energy management/home services)	Extending enterprise messaging into IoT application

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

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

物聯網協議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 原則是，客戶端和服務器之間的交互在請求之間是無狀態的。從客戶端到服務器的每一個請求都必須包含理解請求所必需的信息。若是服務器在請求之間的任什麼時候間點重啓，客戶端不會獲得通知。此外，無狀態請求能夠由任何可用服務器回答，這十分適合 雲計算之類的環境。客戶端能夠緩存數據以改進性能

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

方案一、 使用GCM服務（Google Cloud Messaging）
簡介：Google推出的雲消息服務，即第二代的G2DM。
優勢：Google提供的服務、原生、簡單，無需實現和部署服務端。
缺點：Android版本限制（必須大於2.2版本），該服務在國內不夠穩定、須要用戶綁定Google賬號，受限於Google。

方案二、 使用XMPP協議（Openfire + Spark + Smack）
簡介：基於XML協議的通信協議，前身是Jabber，目前已由IETF國際標準化組織完成了標準化工做。
優勢：協議成熟、強大、可擴展性強、目前主要應用於許多聊天系統中，且已有開源的Java版的開發實例androidpn。
缺點：協議較複雜、冗餘（基於XML）、費流量、費電，部署硬件成本高。

方案三、 使用MQTT協議
簡介：輕量級的、基於代理的「發佈/訂閱」模式的消息傳輸協議。
優勢：協議簡潔、小巧、可擴展性強、省流量、省電，目前已經應用到企業領域，且已有C++版的服務端組件rsmb。
缺點：不夠成熟、實現較複雜、服務端組件rsmb不開源，部署硬件成本較高。

方案四、 使用HTTP輪循方式
簡介：定時向HTTP服務端接口（Web Service API）獲取最新消息。
優勢：實現簡單、可控性強，部署硬件成本低。
缺點：實時性差。

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

總結來講：

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