想入行物聯網XMPP、MQTT、CoAP等物聯網協定不可不知

有關物聯網協議， 現在主要有XMPP、MQTT、CoAP、RESTful HTTP這四種， 想瞭解物聯網、進入這行業的必須瞭解一下， 全解且看下文吧。

國外有關四大協定比較

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

基本網路結構

XMPP中定義了三個角色， 用戶端， 伺服器， 閘道。 通信能夠在這三者的任意兩個之間雙向發生。 伺服器同時承擔了用戶端資訊記錄， 連接管理和資訊的路由功能。 閘道承擔著與異構即時通信系統的互聯互通，

功能

傳輸的是與即時通訊相關的指令。 在以前這些命令要麼用2進制的形式發送（比如QQ）， 要麼用純文字指令加空格加參數加分行符號的方式發送（比如MSN）。 而XMPP傳輸的即時通訊指令的邏輯與以往相仿， 只是協議的形式變成了XML格式的純文字。

優點

XMPP協定是自由、開放、公開的， 並且易於瞭解。 而且在用戶端、伺服器、組件、源碼庫等方面， 都已經各自有多種實現。

缺點

隨著通常超過70%的XMPP協議的伺服器的資料流程量的存在和近60%的被重複轉發， XMPP協議目前擁有一個大型架空中存在的資料提供給多個收件人。

協議二：物聯網協議MQTT

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

MQTT是基於二進位消息的發佈/訂閱程式設計模式的消息協定， 最早由IBM提出的， 如今已經成為OASIS規範。 由於規範很簡單， 非常適合需要低功耗和網路頻寬有限的IoT場景， 比如：

·遙感資料

·汽車

·智慧家居

·智慧城市

·醫療醫護

由於物聯網的環境是非常特別的， 所以MQTT遵循以下設計原則：

1.精簡， 不添加可有可無的功能。

2.發佈/訂閱（Pub/Sub）模式， 方便消息在感測器之間傳遞。

3.允許使用者動態創建主題， 零運維成本。

4.把傳輸量降到最低以提高傳輸效率。

5.把低頻寬、高延遲、不穩定的網路等因素考慮在內。

6.支援連續的會話控制。

7.理解用戶端計算能力可能很低。

8.提供服務品質管制。

9.假設資料不可知， 不強求傳輸資料的類型與格式， 保持靈活性。

運用MQTT協定， 設備可以很方便地連接到物聯網雲服務， 管理設備並處理資料， 最後應用到各種業務場景， 如下圖所示：

發佈/訂閱模式

與請求/回答這種同步模式不同， 發佈/訂閱模式解耦了發佈消息的客戶（發佈者）與訂閱消息的客戶（訂閱者）之間的關係， 這意味著發佈者和訂閱者之間並不需要直接建立聯繫。 打個比方， 你打電話給朋友， 一直要等到朋友接電話了才能夠開始交流， 是一個典型的同步請求/回答的場景；而給一個好友郵寄清單發電子郵件就不一樣， 你發好電子郵件該幹嘛幹嘛， 好友們到有空了去查看郵件就是了， 是一個典型的非同步發佈/訂閱的場景。

熟悉程式設計的同學一定非常熟悉這種設計模式了， 因為它帶來了這些好處：

·發佈者與訂閱者不必瞭解彼此， 只要認識同一個消息代理即可。

·發佈者和訂閱者不需要交互，發佈者無需等待訂閱者確認而導致鎖定。

·發佈者和訂閱者不需要同時線上，可以自由選擇時間來消費消息。

主題

MQTT是通過主題對消息進行分類的，本質上就是一個UTF-8的字串，不過可以通過反斜線表示多個層級關係。主題並不需要創建，直接使用就是了。

主題還可以通過萬用字元進行過濾。其中，+可以過濾一個層級，而#只能出現在主題最後表示過濾任意級別的層級。

舉個例子：

·building-b/floor-5：代表B樓5層的設備。

·+/floor-5：代表任何一個樓的5層的設備。

·building-b/#：代表B樓所有的設備。

注意，MQTT允許使用萬用字元訂閱主題，但是並不允許使用萬用字元廣播。

服務品質

為了滿足不同的場景，MQTT支援三種不同級別的服務品質（Quality of Service，QoS）為不同場景提供消息可靠性：

·級別0：盡力而為。消息發送者會想盡辦法發送消息，但是遇到意外並不會重試。

·級別1：至少一次。消息接收者如果沒有知會或者知會本身丟失，消息發送者會再次發送以保證消息接收者至少會收到一次，當然可能造成重複消息。

·級別2：恰好一次。保證這種語義肯定會減少併發或者增加延時，不過丟失或者重複消息是不可接受的時候，級別2是最合適的。

服務品質是個老話題了。級別2所提供的不重不丟很多情況下是最理想的，不過往返多次的確認一定對併發和延遲帶來影響。級別1提供的至少一次語義在日誌處理這種場景下是完全OK的，所以像Kafka這類的系統利用這一特點減少確認從而大大提高了併發。級別0適合雞肋資料場景，食之無味棄之可惜，就這麼著吧。

消息類型

MQTT擁有14種不同的消息類型：

1.CONNECT：用戶端連接到MQTT代理

2.CONNACK：連接確認

3.PUBLISH：新發佈消息

4.PUBACK：新發佈消息確認，是QoS 1給PUBLISH消息的回復

5.PUBREC：QoS 2消息流的第一部分，表示消息發佈已記錄

6.PUBREL：QoS 2消息流的第二部分，表示消息發佈已釋放

7.PUBCOMP：QoS 2消息流的第三部分，表示消息發佈完成

8.SUBSCRIBE：用戶端訂閱某個主題

9.SUBACK：對於SUBSCRIBE消息的確認

10. UNSUBSCRIBE：用戶端終止訂閱的消息

11. UNSUBACK：對於UNSUBSCRIBE消息的確認

12. PINGREQ：心跳

13. PINGRESP：確認心跳

14. DISCONNECT：用戶端終止連接前優雅地通知MQTT代理

從現有的移動端（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協議

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

優點：協議簡潔、小巧、可擴展性強、省流量、省電，目前已經應用到企業領域，且已有C++版的服務端元件rsmb。

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

方案4、 使用HTTP輪循方式

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

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

缺點：即時性差。

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

由於物聯網中的很多設備都是資源受限型的，即只有少量的記憶體空間和有限的計算能力，所以傳統的HTTP協議應用在物聯網上就顯得過於龐大而不適用。 IETF的CoRE工作組提出了一種基於REST架構的CoAP協議。CoAP是6LowPAN協定棧中的應用層協定。該文在詳細介紹了CoAP協定的內容、特點和交互模型後，在uIPv6 START KIT無線網路開發套件上，使用Contiki嵌入式作業系統，不僅在流覽器端實現了CoAP協議而且用自己編寫的用戶端程式實現了CoAP協定，增加了和資料庫之間的交互功能，從而實現了在Web介面上不僅可以查看即時資料，還可以查看歷史資料的功能。

CoAP應用

由於無線物聯網中的設備很多都是資源受限型的，這些設備只有少量的記憶體空間和有限的計算能力。為此，IETF（Intemet Engineering Task Force）的CoRE（Constrained RESTful Environment）工作組為受限節點制定相關的REST（Representational State Transfer）形式的應用層協議。這就是CoRE工作組正在制訂的CoAP（Constrained Application Protocol）協議。

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

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

RESTful的關鍵是定義可表示流程元素/資源的物件。在REST中，每一個物件都是通過URL來表示的，物件使用者負責將狀態資訊打包進每一條消息內，以便物件的處理總是無狀態的。

RESTful的第二大問題是組合管理及流程綁定。企業對正規的（基於SOAP）SOA最大的反對聲之一便是，這種等級的發現和綁定靈活性不足以適應複雜性。

MQTT協定是IBM公司主推的協定，現有的情況下，MQTT比起XMPP和RESTful比較有優勢。如果我們對上面的結果進行一次PK，我想最 後的結果就是MQTT vs CoAP。HTTP對於嵌入式設備來說太重了，也不靈活，XMPP就更不用說了，與MQTT還有一比的便是CoAP——一個還在草稿階段的協議。

·發佈者和訂閱者不需要交互，發佈者無需等待訂閱者確認而導致鎖定。

·發佈者和訂閱者不需要同時線上，可以自由選擇時間來消費消息。

主題

MQTT是通過主題對消息進行分類的，本質上就是一個UTF-8的字串，不過可以通過反斜線表示多個層級關係。主題並不需要創建，直接使用就是了。

主題還可以通過萬用字元進行過濾。其中，+可以過濾一個層級，而#只能出現在主題最後表示過濾任意級別的層級。

舉個例子：

·building-b/floor-5：代表B樓5層的設備。

·+/floor-5：代表任何一個樓的5層的設備。

·building-b/#：代表B樓所有的設備。

注意，MQTT允許使用萬用字元訂閱主題，但是並不允許使用萬用字元廣播。

服務品質

為了滿足不同的場景，MQTT支援三種不同級別的服務品質（Quality of Service，QoS）為不同場景提供消息可靠性：

·級別0：盡力而為。消息發送者會想盡辦法發送消息，但是遇到意外並不會重試。

·級別1：至少一次。消息接收者如果沒有知會或者知會本身丟失，消息發送者會再次發送以保證消息接收者至少會收到一次，當然可能造成重複消息。

·級別2：恰好一次。保證這種語義肯定會減少併發或者增加延時，不過丟失或者重複消息是不可接受的時候，級別2是最合適的。

服務品質是個老話題了。級別2所提供的不重不丟很多情況下是最理想的，不過往返多次的確認一定對併發和延遲帶來影響。級別1提供的至少一次語義在日誌處理這種場景下是完全OK的，所以像Kafka這類的系統利用這一特點減少確認從而大大提高了併發。級別0適合雞肋資料場景，食之無味棄之可惜，就這麼著吧。

消息類型

MQTT擁有14種不同的消息類型：

1.CONNECT：用戶端連接到MQTT代理

2.CONNACK：連接確認

3.PUBLISH：新發佈消息

4.PUBACK：新發佈消息確認，是QoS 1給PUBLISH消息的回復

5.PUBREC：QoS 2消息流的第一部分，表示消息發佈已記錄

6.PUBREL：QoS 2消息流的第二部分，表示消息發佈已釋放

7.PUBCOMP：QoS 2消息流的第三部分，表示消息發佈完成

8.SUBSCRIBE：用戶端訂閱某個主題

9.SUBACK：對於SUBSCRIBE消息的確認

10. UNSUBSCRIBE：用戶端終止訂閱的消息

11. UNSUBACK：對於UNSUBSCRIBE消息的確認

12. PINGREQ：心跳

13. PINGRESP：確認心跳

14. DISCONNECT：用戶端終止連接前優雅地通知MQTT代理

從現有的移動端（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協議

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

優點：協議簡潔、小巧、可擴展性強、省流量、省電，目前已經應用到企業領域，且已有C++版的服務端元件rsmb。

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

方案4、 使用HTTP輪循方式

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

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

缺點：即時性差。

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

由於物聯網中的很多設備都是資源受限型的，即只有少量的記憶體空間和有限的計算能力，所以傳統的HTTP協議應用在物聯網上就顯得過於龐大而不適用。 IETF的CoRE工作組提出了一種基於REST架構的CoAP協議。CoAP是6LowPAN協定棧中的應用層協定。該文在詳細介紹了CoAP協定的內容、特點和交互模型後，在uIPv6 START KIT無線網路開發套件上，使用Contiki嵌入式作業系統，不僅在流覽器端實現了CoAP協議而且用自己編寫的用戶端程式實現了CoAP協定，增加了和資料庫之間的交互功能，從而實現了在Web介面上不僅可以查看即時資料，還可以查看歷史資料的功能。

CoAP應用

由於無線物聯網中的設備很多都是資源受限型的，這些設備只有少量的記憶體空間和有限的計算能力。為此，IETF（Intemet Engineering Task Force）的CoRE（Constrained RESTful Environment）工作組為受限節點制定相關的REST（Representational State Transfer）形式的應用層協議。這就是CoRE工作組正在制訂的CoAP（Constrained Application Protocol）協議。

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

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

RESTful的關鍵是定義可表示流程元素/資源的物件。在REST中，每一個物件都是通過URL來表示的，物件使用者負責將狀態資訊打包進每一條消息內，以便物件的處理總是無狀態的。

RESTful的第二大問題是組合管理及流程綁定。企業對正規的（基於SOAP）SOA最大的反對聲之一便是，這種等級的發現和綁定靈活性不足以適應複雜性。

MQTT協定是IBM公司主推的協定，現有的情況下，MQTT比起XMPP和RESTful比較有優勢。如果我們對上面的結果進行一次PK，我想最 後的結果就是MQTT vs CoAP。HTTP對於嵌入式設備來說太重了，也不靈活，XMPP就更不用說了，與MQTT還有一比的便是CoAP——一個還在草稿階段的協議。