即時線上人數:41 參觀總人數:281971
Smart Pad

頁面路徑選單

產業新知
  • facebook
  • Plurk
  • Twitter
  • Weibo
  • qq
  • renren
  • 微信

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

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

國外有關四大協議比較

協議一:物聯網協議XMPP

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

基本網絡結構

XMPP中定義了三個角色,客戶端,伺服器,網關。通信能夠在這三者的任意兩個之間雙向發生。伺服器同時承擔了客戶端信息記錄,連接管理和信息的路由功能。網關承擔著與異構即時通信系統的互聯互通,異構系統可以包括SMS(簡訊),MSN,ICQ等。基本的網絡形式是單客戶端通過TCP/IP連接到單伺服器,然後在之上傳輸XML。

功能

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

優點

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

缺點

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

協議二:物聯網協議MQTT

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

MQTT簡介

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
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)協議。
協議四:物聯網協議RESTful HTTP
REST 指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程式或設計就是 RESTful。
Web 應用程式最重要的 REST 原則是,客戶端和伺服器之間的交互在請求之間是無狀態的。從客戶端到伺服器的每個請求都必須包含理解請求所必需的信息。如果伺服器在請求之間的任何時間點 重啟,客戶端不會得到通知。此外,無狀態請求可以由任何可用伺服器回答,這十分適合雲計算之類的環境。客戶端可以緩存數據以改進性能。
RESTful的關鍵是定義可表示流程元素/資源的對象。在REST中,每一個對象都是通過URL來表示的,對象用戶負責將狀態信息打包進每一條消息內,以便對象的處理總是無狀態的。
RESTful的第二大問題是組合管理及流程綁定。企業對正規的(基於SOAP)SOA最大的反對聲之一便是,這種等級的發現和綁定靈活性不足以適應複雜性。
協議:其他
MQTT協議是IBM公司主推的協議,現有的情況下,MQTT比起XMPP和RESTful比較有優勢。如果我們對上面的結果進行一次PK,我想最 後的結果就是MQTT vs CoAP。HTTP對於嵌入式設備來說太重了,也不靈活,XMPP就更不用說了,與MQTT還有一比的便是CoAP——一個還在草稿階段的協議。

出處 : 2017-04-13 由 傑哥侃物聯網 發表于科技