物聯(lián)網(wǎng)通信協(xié)議的詳解及選擇建議

　　通信對物聯(lián)網(wǎng)來(lái)說(shuō)十分關(guān)鍵，無(wú)論是近距離無(wú)線(xiàn)傳輸技術(shù)還是移動(dòng)通信技術(shù)，甚至是LPWAN都影響著(zhù)物聯(lián)網(wǎng)的發(fā)展。通信協(xié)議是指雙方實(shí)體完成通信或服務(wù)所必須遵循的規則和約定。那么物聯(lián)網(wǎng)都有哪些通信協(xié)議？眾多的協(xié)議該如何選擇？

　　我們將物聯(lián)網(wǎng)通信協(xié)議分為兩大類(lèi)，一類(lèi)是接入協(xié)議，一類(lèi)是通訊協(xié)議。接入協(xié)議一般負責子網(wǎng)內設備間的組網(wǎng)及通信（文章《常見(jiàn)物聯(lián)網(wǎng)近距離無(wú)線(xiàn)通信技術(shù)解析》有詳細介紹）；通訊協(xié)議主要是運行在傳統互聯(lián)網(wǎng)TCP/IP協(xié)議之上的設備通訊協(xié)議，負責設備通過(guò)互聯(lián)網(wǎng)進(jìn)行數據交換及通信。

　　本文羅列下市面上物聯(lián)網(wǎng)協(xié)議，總結下它們各自特點(diǎn)、特定的物聯(lián)網(wǎng)應用場(chǎng)景等。

　　物聯(lián)網(wǎng)聯(lián)接的問(wèn)題空間

　　上圖為物聯(lián)網(wǎng)聯(lián)接的問(wèn)題空間，其中物聯(lián)網(wǎng)的通信環(huán)境有Ethernet， Wi-Fi， RFID， NFC（近距離無(wú)線(xiàn)通信）， Zigbee， 6LoWPAN（IPV6低速無(wú)線(xiàn)版本），Bluetooth， GSM， GPRS， GPS， 3G， 4G等網(wǎng)絡(luò )，而每一種通信應用協(xié)議都有一定適用范圍。AMQP、JMS、REST/HTTP都是工作在以太網(wǎng)，COAP協(xié)議是專(zhuān)門(mén)為資源受限設備開(kāi)發(fā)的協(xié)議，而DDS和MQTT的兼容性則強很多。

　　互聯(lián)網(wǎng)時(shí)代，TCP/IP協(xié)議已經(jīng)一統江湖，現在的物聯(lián)網(wǎng)的通信架構也是構建在傳統互聯(lián)網(wǎng)基礎架構之上。在當前的互聯(lián)網(wǎng)通信協(xié)議中，HTTP協(xié)議由于開(kāi)發(fā)成本低，開(kāi)放程度高，幾乎占據大半江山，所以很多廠(chǎng)商在構建物聯(lián)網(wǎng)系統時(shí)也基于http協(xié)議進(jìn)行開(kāi)發(fā)。包括google主導的physic web項目，都是期望在傳統web技術(shù)基礎上構建物聯(lián)網(wǎng)協(xié)議標準。

　　HTTP協(xié)議是典型的CS通訊模式，由客戶(hù)端主動(dòng)發(fā)起連接，向服務(wù)器請求XML或JSON數據。該協(xié)議最早是為了適用web瀏覽器的上網(wǎng)瀏覽場(chǎng)景和設計的，目前在PC、手機、pad等終端上都應用廣泛，但并不適用于物聯(lián)網(wǎng)場(chǎng)景。在物聯(lián)網(wǎng)場(chǎng)景中其有三大弊端：

　　1. 由于必須由設備主動(dòng)向服務(wù)器發(fā)送數據，難以主動(dòng)向設備推送數據。對于單單的數據采集等場(chǎng)景還勉強適用，但是對于頻繁的操控場(chǎng)景，只能推過(guò)設備定期主動(dòng)拉取的的方式，實(shí)現成本和實(shí)時(shí)性都大打折扣。

　　2. 安全性不高。web的不安全都是婦孺皆知，HTTP是明文協(xié)議，在很多要求高安全性的物聯(lián)網(wǎng)場(chǎng)景，如果不做很多安全準備工作（如采用https等），后果不堪設想。

　　3. 不同于用戶(hù)交互終端如pc、手機，物聯(lián)網(wǎng)場(chǎng)景中的設備多樣化，對于運算和存儲資源都十分受限的設備，http協(xié)議實(shí)現、XML/JSON數據格式的解析，都是不可能的任務(wù)。

　　REST/HTTP（松耦合服務(wù)調用）

　　REST （Representational State Transfer），表征狀態(tài)轉換，是基于HTTP協(xié)議開(kāi)發(fā)的一種通信風(fēng)格，目前還不是標準；

　　適用范圍：REST/HTTP主要為了簡(jiǎn)化互聯(lián)網(wǎng)中的系統架構，快速實(shí)現客戶(hù)端和服務(wù)器之間交互的松耦合，降低了客戶(hù)端和服務(wù)器之間的交互延遲。因此適合在物聯(lián)網(wǎng)的應用層面，通過(guò)REST開(kāi)放物聯(lián)網(wǎng)中資源，實(shí)現服務(wù)被其他應用所調用。

　　特點(diǎn)：

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

　　· 客戶(hù)端和服務(wù)器之間的交互在請求之間是無(wú)狀態(tài)的

　　· 在服務(wù)器端，應用程序狀態(tài)和功能可以分為各種資源，它向客戶(hù)端公開(kāi)。資源的例子有：應用程序對象、數據庫記錄、算法等等。每個(gè)資源都使用 URI （Universal Resource Identifier） 得到一個(gè)惟一的地址。所有資源都共享統一的界面，以便在客戶(hù)端和服務(wù)器之間傳輸狀態(tài)

　　· 使用的是標準的 HTTP 方法，比如 GET、PUT、POST 和 DELETE

　　點(diǎn)評： REST/HTTP其實(shí)是互聯(lián)網(wǎng)中服務(wù)調用API封裝風(fēng)格，物聯(lián)網(wǎng)中數據采集到物聯(lián)網(wǎng)應用系統中，在物聯(lián)網(wǎng)應用系統中，可以通過(guò)開(kāi)放REST API的方式，把數據服務(wù)開(kāi)放出去，被互聯(lián)網(wǎng)中其他應用所調用。

　　CoAP協(xié)議

　　· CoAP （Constrained Application Protocol），受限應用協(xié)議，應用于無(wú)線(xiàn)傳感網(wǎng)中協(xié)議。

　　適用范圍：CoAP是簡(jiǎn)化了HTTP協(xié)議的RESTful API，CoAP是6LowPAN協(xié)議棧中的應用層協(xié)議，它適用于在資源受限的通信的IP網(wǎng)絡(luò )。

　　特點(diǎn)：

　　報頭壓縮：CoAP包含一個(gè)緊湊的二進(jìn)制報頭和擴展報頭。它只有短短的4B的基本報頭，基本報頭后面跟擴展選項。一個(gè)典型的請求報頭為10～20B。

　　方法和URIs：為了實(shí)現客戶(hù)端訪(fǎng)問(wèn)服務(wù)器上的資源，CoAP支持GET、PUT、POST和DELETE等方法。CoAP還支持URIs，這是Web架構的主要特點(diǎn)。

　　傳輸層使用UDP協(xié)議：CoAP協(xié)議是建立在UDP協(xié)議之上，以減少開(kāi)銷(xiāo)和支持組播功能。它也支持一個(gè)簡(jiǎn)單的停止和等待的可靠性傳輸機制。

　　支持異步通信：HTTP對M2M（Machine-to-Machine）通信不適用，這是由于事務(wù)總是由客戶(hù)端發(fā)起。而CoAP協(xié)議支持異步通信，這對M2M通信應用來(lái)說(shuō)是常見(jiàn)的休眠／喚醒機制。

　　支持資源發(fā)現：為了自主的發(fā)現和使用資源，它支持內置的資源發(fā)現格式，用于發(fā)現設備上的資源列表，或者用于設備向服務(wù)目錄公告自己的資源。它支持RFC5785中的格式，在CoRE中用／．well—known／core的路徑表示資源描述。

　　支持緩存：CoAP協(xié)議支持資源描述的緩存以?xún)?yōu)化其性能。

　　協(xié)議主要實(shí)現：

　　· libcoap（C語(yǔ)言實(shí)現）

　　· Californium（java語(yǔ)言實(shí)現）

　　點(diǎn)評：CoAP和6LowPan，這分別是應用層協(xié)議和網(wǎng)絡(luò )適配層協(xié)議，其目標是解決設備直接連接到IP網(wǎng)絡(luò )，也就是IP技術(shù)應用到設備之間、互聯(lián)網(wǎng)與設備之間的通信需求。因為IPV6技術(shù)帶來(lái)巨大尋址空間，不光解決了未來(lái)巨量設備和資源的標識問(wèn)題，互聯(lián)網(wǎng)上應用可以直接訪(fǎng)問(wèn)支持IPV6的設備，而不需要額外的網(wǎng)關(guān)。

　　MQTT協(xié)議（低帶寬）

　　MQTT （Message Queuing Telemetry Transport ），消息隊列遙測傳輸，由IBM開(kāi)發(fā)的即時(shí)通訊協(xié)議，相比來(lái)說(shuō)比較適合物聯(lián)網(wǎng)場(chǎng)景的通訊協(xié)議。MQTT協(xié)議采用發(fā)布/訂閱模式，所有的物聯(lián)網(wǎng)終端都通過(guò)TCP連接到云端，云端通過(guò)主題的方式管理各個(gè)設備關(guān)注的通訊內容，負責將設備與設備之間消息的轉發(fā)。

　　MQTT在協(xié)議設計時(shí)就考慮到不同設備的計算性能的差異，所以所有的協(xié)議都是采用二進(jìn)制格式編解碼，并且編解碼格式都非常易于開(kāi)發(fā)和實(shí)現。最小的數據包只有2個(gè)字節，對于低功耗低速網(wǎng)絡(luò )也有很好的適應性。有非常完善的QOS機制，根據業(yè)務(wù)場(chǎng)景可以選擇最多一次、至少一次、剛好一次三種消息送達模式。運行在TCP協(xié)議之上，同時(shí)支持TLS（TCP+SSL）協(xié)議，并且由于所有數據通信都經(jīng)過(guò)云端，安全性得到了較好地保障。

　　適用范圍：在低帶寬、不可靠的網(wǎng)絡(luò )下提供基于云平臺的遠程設備的數據傳輸和監控。

　　特點(diǎn)：

　　· 使用基于代理的發(fā)布/訂閱消息模式，提供一對多的消息發(fā)布

　　· 使用 TCP/IP 提供網(wǎng)絡(luò )連接

　　· 小型傳輸，開(kāi)銷(xiāo)很?。ü潭ㄩL(cháng)度的頭部是 2 字節），協(xié)議交換最小化，以降低網(wǎng)絡(luò )流量

　　· 支持QoS，有三種消息發(fā)布服務(wù)質(zhì)量：“至多一次”， “至少一次”， “只有一次”

　　協(xié)議主要實(shí)現和應用：

　　· 已經(jīng)有PHP，JAVA，Python，C，C#等多個(gè)語(yǔ)言版本的協(xié)議框架

　　· IBM Bluemix 的一個(gè)重要部分是其 IoT Foundation 服務(wù)，這是一項基于云的 MQTT 實(shí)例

　　· 移動(dòng)應用程序也早就開(kāi)始使用MQTT，如 Facebook Messenger 和com等

　　點(diǎn)評：MQTT協(xié)議一般適用于設備數據采集到端（Device-》Server，Device-》Gateway），集中星型網(wǎng)絡(luò )架構（hub-and-spoke），不適用設備與設備之間通信，設備控制能力弱，另外實(shí)時(shí)性較差，一般都在秒級。

　　DDS協(xié)議（高可靠性、實(shí)時(shí)）

　　DDS（Data Distribution Service for Real-Time Systems），面向實(shí)時(shí)系統的數據分布服務(wù)，這是大名鼎鼎的OMG組織提出的協(xié)議，其權威性應該能證明該協(xié)議的未來(lái)應用前景。

　　適用范圍：分布式高可靠性、實(shí)時(shí)傳輸設備數據通信。目前DDS已經(jīng)廣泛應用于國防、民航、工業(yè)控制等領(lǐng)域。

　　特點(diǎn)：

　　· 以數據為中心

　　· 使用無(wú)代理的發(fā)布/訂閱消息模式，點(diǎn)對點(diǎn)、點(diǎn)對多、多對多

　　· 提供多大21種QoS服務(wù)質(zhì)量策略

　　協(xié)議主要實(shí)現：

　　· OpenDDS 是一個(gè)開(kāi)源的 C++ 實(shí)現

　　· OpenSplice DDS

　　點(diǎn)評：DDS很好地支持設備之間的數據分發(fā)和設備控制，設備和云端的數據傳輸，同時(shí)DDS的數據分發(fā)的實(shí)時(shí)效率非常高，能做到秒級內同時(shí)分發(fā)百萬(wàn)條消息到眾多設備。DDS在服務(wù)質(zhì)量（QoS）上提供非常多的保障途徑，這也是它適用于國防軍事、工業(yè)控制這些高可靠性、可安全性應用領(lǐng)域的原因。但這些應用都工作在有線(xiàn)網(wǎng)絡(luò )下，在無(wú)線(xiàn)網(wǎng)絡(luò )，特別是資源受限的情況下，沒(méi)有見(jiàn)到過(guò)實(shí)施案例。

　　AMQP協(xié)議（互操作性）

　　· AMQP（Advanced Message Queuing Protocol），先進(jìn)消息隊列協(xié)議，這是OASIS組織提出的，該組織曾提出OSLC（Open Source Lifecyle）標準，用于業(yè)務(wù)系統例如PLM，ERP，MES等進(jìn)行數據交換。

　　適用范圍：最早應用于金融系統之間的交易消息傳遞，在物聯(lián)網(wǎng)應用中，主要適用于移動(dòng)手持設備與后臺數據中心的通信和分析。

　　特點(diǎn)：

　　· Wire級的協(xié)議，它描述了在網(wǎng)絡(luò )上傳輸的數據的格式，以字節為流

　　· 面向消息、隊列、路由（包括點(diǎn)對點(diǎn)和發(fā)布/訂閱）、可靠性、安全

　　協(xié)議實(shí)現：

　　· Erlang中的實(shí)現有 RabbitMQ

　　· AMQP的開(kāi)源實(shí)現，用C語(yǔ)言編寫(xiě)OpenAMQ

　　· Apache Qpid

　　· stormMQ

　　XMPP協(xié)議（即時(shí)通信）

　　XMPP（Extensible Messaging and Presence Protocol）可擴展通訊和表示協(xié)議，XMPP的前身是Jabber，一個(gè)開(kāi)源形式組織產(chǎn)生的網(wǎng)絡(luò )即時(shí)通信協(xié)議。XMPP目前被IETF國際標準組織完成了標準化工作。

　　適用范圍：即時(shí)通信的應用程序，還能用在網(wǎng)絡(luò )管理、內容供稿、協(xié)同工具、檔案共享、游戲、遠端系統監控等。

　　特點(diǎn)：

　　· 客戶(hù)機/服務(wù)器通信模式

　　· 分布式網(wǎng)絡(luò )

　　· 簡(jiǎn)單的客戶(hù)端，將大多數工作放在服務(wù)器端進(jìn)行

　　· 標準通用標記語(yǔ)言的子集XML的數據格式

　　點(diǎn)評：XMPP是基于XML的協(xié)議，由于其開(kāi)放性和易用性，在互聯(lián)網(wǎng)及時(shí)通訊應用中運用廣泛。相對HTTP，XMPP在通訊的業(yè)務(wù)流程上是更適合物聯(lián)網(wǎng)系統的，開(kāi)發(fā)者不用花太多心思去解決設備通訊時(shí)的業(yè)務(wù)通訊流程，相對開(kāi)發(fā)成本會(huì )更低。但是HTTP協(xié)議中的安全性以及計算資源消耗的硬傷并沒(méi)有得到本質(zhì)的解決。

　　· JMS （Java Message Service），JAVA消息服務(wù)，這是JAVA平臺中著(zhù)名的消息隊列協(xié)議。

　　Java消息服務(wù)（Java Message Service）應用程序接口，是一個(gè)Java平臺中關(guān)于面向消息中間件（MOM）的API，用于在兩個(gè)應用程序之間，或分布式系統中發(fā)送消息，進(jìn)行異步通信。Java消息服務(wù)是一個(gè)與具體平臺無(wú)關(guān)的API，絕大多數MOM提供商都對JMS提供支持。

　　JMS是一種與廠(chǎng)商無(wú)關(guān)的 API，用來(lái)訪(fǎng)問(wèn)消息收發(fā)系統消息，它類(lèi)似于JDBC（Java Database Connectivity）。這里，JDBC 是可以用來(lái)訪(fǎng)問(wèn)許多不同關(guān)系數據庫的 API，而 JMS 則提供同樣與廠(chǎng)商無(wú)關(guān)的訪(fǎng)問(wèn)方法，以訪(fǎng)問(wèn)消息收發(fā)服務(wù)。許多廠(chǎng)商都支持 JMS，包括 IBM 的 MQSeries、BEA的 Weblogic JMS service和 Progress 的 SonicMQ。 JMS 能夠通過(guò)消息收發(fā)服務(wù)（有時(shí)稱(chēng)為消息中介程序或路由器）從一個(gè) JMS 客戶(hù)機向另一個(gè) JMS客戶(hù)機發(fā)送消息。消息是 JMS 中的一種類(lèi)型對象，由兩部分組成：報頭和消息主體。報頭由路由信息以及有關(guān)該消息的元數據組成。消息主體則攜帶著(zhù)應用程序的數據或有效負載。根據有效負載的類(lèi)型來(lái)劃分，可以將消息分為幾種類(lèi)型，它們分別攜帶：簡(jiǎn)單文本（TextMessage）、可序列化的對象 （ObjectMessage）、屬性集合 （MapMessage）、字節流 （BytesMessage）、原始值流 （StreamMessage），還有無(wú)有效負載的消息 （Message）。
物聯(lián)網(wǎng)協(xié)議對比：

　　協(xié)議應用的側重方向

　　MQTT、 DDS、 AMQP、XMPP、 JMS、 REST、 CoAP這幾種協(xié)議都已被廣泛應用，并且每種協(xié)議都有至少10種以上的代碼實(shí)現，都宣稱(chēng)支持實(shí)時(shí)的發(fā)布/訂閱的物聯(lián)網(wǎng)協(xié)議，但是在具體物聯(lián)網(wǎng)系統架構設計時(shí)，需考慮實(shí)際場(chǎng)景的通信需求，選擇合適的協(xié)議。

　　以智能家居為例，說(shuō)明下這些協(xié)議側重應用方向。智能家居中智能燈光控制，可以使用XMPP協(xié)議控制燈的開(kāi)關(guān)；智能家居的電力供給，發(fā)電廠(chǎng)的發(fā)動(dòng)機組的監控可以使用DDS協(xié)議；當電力輸送到千家萬(wàn)戶(hù)時(shí)，電力線(xiàn)的巡查和維護，可以使用MQTT協(xié)議；家里的所有電器的電量消耗，可以使用AMQP協(xié)議，傳輸到云端或家庭網(wǎng)關(guān)中進(jìn)行分析；最后用戶(hù)想把自家的能耗查詢(xún)服務(wù)公布到互聯(lián)網(wǎng)上，那么可以使用REST/HTTP來(lái)開(kāi)放API服務(wù)。

　　物聯(lián)網(wǎng)協(xié)議的選擇

　　發(fā)布/訂閱服務(wù)更適合物聯(lián)網(wǎng)環(huán)境下通信

　　DDS、MQTT、AMQP和JMS都是基于發(fā)布/訂閱模式，發(fā)布/訂閱框架具有服務(wù)自發(fā)現、動(dòng)態(tài)擴展、事件過(guò)濾的特點(diǎn)，它解決了物聯(lián)網(wǎng)系統在應用層的數據源快速獲取、物的加入和退出、興趣訂閱、降低帶寬流量等問(wèn)題，實(shí)現物的聯(lián)接在空間上松耦合（雙方無(wú)需知道通信地址）、時(shí)間上松耦合和同步松耦合。

　　服務(wù)質(zhì)量（QoS）是物聯(lián)網(wǎng)通信中的重要考慮因素

　　在服務(wù)策略的幫助下，DDS能夠有效地控制和管理網(wǎng)絡(luò )帶寬、內存空間等資源的使用，同時(shí)也能控制數據的可靠性、實(shí)時(shí)性和數據的生存時(shí)間，通過(guò)靈活使用這些服務(wù)質(zhì)量策略，DDS不僅能在窄帶的無(wú)線(xiàn)環(huán)境上，也能在寬帶的有線(xiàn)通信環(huán)境上開(kāi)發(fā)出滿(mǎn)足實(shí)時(shí)性需求的數據分發(fā)系統。