對于物聯網,最重要的是在互聯網中設備與設備的通訊,現在物聯網在internet通信中比較常見的通訊協議包括:HTTP、websocket、XMPP、COAP、MQTT
1、HTTP和websocket
在互聯網時代,TCP/IP協議已經一統江湖,現在的物聯網的通信架構也是構建在傳統互聯網基礎架構之上。在當前的互聯網通信協議中,HTTP協議由于開發成本低,開放程度高,幾乎占據大半江山,所以很多廠商在構建物聯網系統時也基于http協議進行開發。包括google主導的physic web項目,都是期望在傳統web技術基礎上構建物聯網協議標準。
HTTP協議是典型的CS通訊模式,由客戶端主動發起連接,向服務器請求XML或JSON數據。該協議最早是為了適用web瀏覽器的上網瀏覽場景和設計的,目前在PC、手機、pad等終端上都應用廣泛,但并不適用于物聯網場景。在物聯網場景中其有三大弊端:
1. 由于必須由設備主動向服務器發送數據,難以主動向設備推送數據。對于單單的數據采集等場景還勉強適用,但是對于頻繁的操控場景,只能推過設備定期主動拉取的的方式,實現成本和實時性都大打折扣。
2. 安全性不高。web的不安全都是婦孺皆知,HTTP是明文協議,在很多要求高安全性的物聯網場景,如果不做很多安全準備工作(如采用https等),后果不堪設想…
3. 不同于用戶交互終端如pc、手機,物聯網場景中的設備多樣化,對于運算和存儲資源都十分受限的設備,http協議實現、XML/JSON數據格式的解析,都是“mission impossible”
HTTP的連接問題,HTTP客戶端和服務器之間的交互是采用請求/應答模式,在客戶端請求時,會建立一個HTTP連接,然后發送請求消息,服務端給出應答消息,然后連接就關閉了。(后來的HTTP1.1支持持久連接)
因為TCP連接的建立過程是有開銷的,如果使用了SSL/TLS開銷就更大。
在瀏覽器里,一個網頁包含許多資源,包括HTML,CSS,JavaScript,圖片等等,這樣在加載一個網頁時要同時打開連接到同一服務器的多個連接。
HTTP消息頭問題,現在的客戶端會發送大量的HTTP消息頭,由于一個網頁可能需要50-100個請求,就會有相當大的消息頭的數據量。
HTTP通信方式問題,HTTP的請求/應答方式的會話都是客戶端發起的,缺乏服務器通知客戶端的機制,在需要通知的場景,如聊天室,游戲,客戶端應用需要不斷地輪詢服務器。
當然,依然有不少廠商由于開發方便的原因,選擇基于HTTP協議構架物聯網系統,在設備資源允許的情況下,怎么避免上面提到的數據推送實時性低的問題呢?
websocket是一個可行的辦法。websocket是HTML5提出的基于TCP之上的可支持全雙工通信的協議標準,其在設計上基本遵循HTTP的思路,對于基于HTTP協議的物聯網系統是一個很好的補充。
但是問題是:http+websocket的方式,協議開銷代價太大。如果讓一個單片機去實現這樣的協議,性能會很吃力。
2、XMPP
由于物聯網設備通信的模式和互聯網中的即時通訊應用非常相似,互聯網中常用的即時通訊協議也被大量運用于物聯網系統構建中,這其中的典型是XMPP。
XMPP是基于XML的協議,由于其開放性和易用性,在互聯網及時通訊應用中運用廣泛。相對HTTP,XMPP在通訊的業務流程上是更適合物聯網系統的,開發者不用花太多心思去解決設備通訊時的業務通訊流程,相對開發成本會更低。但是HTTP協議中的安全性以及計算資源消耗的硬傷并沒有得到本質的解決。前段時間報出的黑客輕松破解的TCL洗衣機,正是采用XMPP協議。
無論是HTTP、websocket還是XMPP,在設計時都是根據互聯網應用場景設計的,雖然很多廠商把他們應用在物聯網系統中,但是必然會水土不服,這些協議的通病就是根本無法適用物聯網設備的多樣性,無法適用很多物聯網設備對低功耗、低成本的需求,難以在極低資源的物聯網設備中運用。能不能有協議既可以借用web技術的設計思想,同時又能適應惡劣的物聯網設備運行環境呢?
3、COAP
COAP協議的設計目標就是在低功耗低速率的設備上實現物聯網通信。coap和HTTP協議一樣,采用URL標示需要發送的數據,在協議格式的設計上也基本是參考HTTP協議,非常容易理解。同時做了以下幾點優化:
1. 采用UDP而不是TCP。這省去了TCP建立連接的成本及協議棧的開銷。
2. 將數據包頭部都采用二進制壓縮,減小數據量以適應低網絡速率場景。
3. 發送和接收數據可以異步進行,這樣提升了設備響應速度。
COAP協議就像一個針對物聯網場景的http移植品,很多設計保留了HTTP協議的影子,擁有web背景的開發者也能快速上手。但是由于很多物聯網設備隱藏在局域網內部,coap設備作為服務器無法被外部設備尋址,在ipv6沒有普及之前,coap只能適用于局域網內部(如wifi)通信,這也很大限制了它的發展。
4、MQTT協議
MQTT協議就很好的解決了coap存在的問題。MQTT協議是由IBM開發的即時通訊協議,相比來說比較適合物聯網場景的通訊協議。MQTT協議采用發布/訂閱模式,所有的物聯網終端都通過TCP連接到云端,云端通過主題的方式管理各個設備關注的通訊內容,負責將設備與設備之間消息的轉發。
使用發布/訂閱消息模式,提供一對多的消息發布,解除應用程序耦合。
對負載內容屏蔽的消息傳輸。
使用 TCP/IP 提供網絡連接。
有三種消息發布服務質量:
'至多一次',消息發布完全依賴底層 TCP/IP 網絡。會發生消息丟失或重復。這一級別可用于如下情況,環境傳感器數據,丟失一次讀記錄無所謂,因為不久后還會有第二次發送。
'至少一次',確保消息到達,但消息重復可能會發生。
'只有一次',確保消息到達一次。這一級別可用于如下情況,在計費系統中,消息重復或丟失會導致不正確的結果。
小型傳輸,開銷很小(固定長度的頭部是 2 字節),協議交換最小化,以降低網絡流量。
使用 Last Will 和 Testament 特性通知有關各方客戶端異常中斷的機制。
MQTT在協議設計時就考慮到不同設備的計算性能的差異,所以所有的協議都是采用二進制格式編解碼,并且編解碼格式都非常易于開發和實現。最小的數據包只有2個字節,對于低功耗低速網絡也有很好的適應性。有非常完善的QOS機制,根據業務場景可以選擇最多一次、至少一次、剛好一次三種消息送達模式。運行在TCP協議之上,同時支持TLS(TCP+SSL)協議,并且由于所有數據通信都經過云端,安全性得到了較好地保障。
當前的物聯網通信協議真的是百花齊放,沒有任何協議能夠在市場上占有統治地位。但要實現物聯網設備互聯互通(不同廠商、不同平臺、不同架構),關鍵點并不在上述接入協議或通訊協議的統一,而在于上層業務應用層協議的統一。無論是wifi、藍牙、亦或是mqtt、http都是設備進行數據通訊和交換的通道,規定的是通訊的格式;而通訊的內容的統一才是實現互聯互通的關鍵。
5、DDS
DDS(Data Distribution Service for Real-Time Systems),面向實時系統的數據分布服務,這是大名鼎鼎的OMG組織提出的協議,其權威性應該能證明該協議的未來應用前景。
適用范圍:分布式高可靠性、實時傳輸設備數據通信。目前DDS已經廣泛應用于國防、民航、工業控制等領域。
特點:
· 以數據為中心
· 使用無代理的發布/訂閱消息模式,點對點、點對多、多對多
· 提供多大21種QoS服務質量策略
協議主要實現:
· OpenDDS 是一個開源的 C++ 實現
· OpenSplice DDS
DDS很好地支持設備之間的數據分發和設備控制,設備和云端的數據傳輸,同時DDS的數據分發的實時效率非常高,能做到秒級內同時分發百萬條消息到眾多設備。DDS在服務質量(QoS)上提供非常多的保障途徑,這也是它適用于國防軍事、工業控制這些高可靠性、可安全性應用領域的原因。但這些應用都工作在有線網絡下,在無線網絡,特別是資源受限的情況下,沒有見到過實施案例。