物聯網通訊協議介紹對比

通訊對物聯網來講十分關鍵，不管是近距離無線傳輸技術仍是移動通訊技術，甚至是LPWAN都影響着物聯網的發展。通訊協議是指雙方實體完成通訊或服務所必須遵循的規則和約定。那麼物聯網都有哪些通訊協議？衆多的協議該如何選擇？

　　咱們將物聯網通訊協議分爲兩大類，一類是接入協議，一類是通信協議。接入協議通常負責子網內設備間的組網及通訊（文章《常見物聯網近距離無線通訊技術解析》有詳細介紹）；通信協議主要是運行在傳統互聯網TCP/IP協議之上的設備通信協議，負責設備經過互聯網進行數據交換及通訊。

　　本文羅列下市面上物聯網協議，總結下它們各自特色、特定的物聯網應用場景等。

　　物聯網聯接的問題空間

　　上圖爲物聯網聯接的問題空間，其中物聯網的通訊環境有Ethernet， Wi-Fi， RFID， NFC（近距離無線通訊）， Zigbee， 6LoWPAN（IPV6低速無線版本），Bluetooth， GSM， GPRS， GPS， 3G， 4G等網絡，而每一種通訊應用協議都有必定適用範圍。AMQP、JMS、REST/HTTP都是工做在以太網，COAP協議是專門爲資源受限設備開發的協議，而DDS和MQTT的兼容性則強不少。

　　互聯網時代，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數據格式的解析，都是不可能的任務。

　　REST/HTTP（鬆耦合服務調用）

　　REST （Representational State Transfer），表徵狀態轉換，是基於HTTP協議開發的一種通訊風格，目前還不是標準；

　　適用範圍：REST/HTTP主要爲了簡化互聯網中的系統架構，快速實現客戶端和服務器之間交互的鬆耦合，下降了客戶端和服務器之間的交互延遲。所以適合在物聯網的應用層面，經過REST開放物聯網中資源，實現服務被其餘應用所調用。

　　特色：

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

　　· 客戶端和服務器之間的交互在請求之間是無狀態的

　　· 在服務器端，應用程序狀態和功能能夠分爲各類資源，它向客戶端公開。資源的例子有：應用程序對象、數據庫記錄、算法等等。每一個資源都使用 URI （Universal Resource Identifier） 獲得一個唯一的地址。全部資源都共享統一的界面，以便在客戶端和服務器之間傳輸狀態

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

　　點評： REST/HTTP實際上是互聯網中服務調用API封裝風格，物聯網中數據採集到物聯網應用系統中，在物聯網應用系統中，能夠經過開放REST API的方式，把數據服務開放出去，被互聯網中其餘應用所調用。

　　CoAP協議

　　· CoAP （Constrained Application Protocol），受限應用協議，應用於無線傳感網中協議。

　　適用範圍：CoAP是簡化了HTTP協議的RESTful API，CoAP是6LowPAN協議棧中的應用層協議，它適用於在資源受限的通訊的IP網絡。

　　特色：

　　報頭壓縮：CoAP包含一個緊湊的二進制報頭和擴展報頭。它只有短短的4B的基本報頭，基本報頭後面跟擴展選項。一個典型的請求報頭爲10～20B。

　　方法和URIs：爲了實現客戶端訪問服務器上的資源，CoAP支持GET、PUT、POST和DELETE等方法。CoAP還支持URIs，這是Web架構的主要特色。

　　傳輸層使用UDP協議：CoAP協議是創建在UDP協議之上，以減小開銷和支持組播功能。它也支持一個簡單的中止和等待的可靠性傳輸機制。

　　支持異步通訊：HTTP對M2M（Machine-to-Machine）通訊不適用，這是因爲事務老是由客戶端發起。而CoAP協議支持異步通訊，這對M2M通訊應用來講是常見的休眠／喚醒機制。

　　支持資源發現：爲了自主的發現和使用資源，它支持內置的資源發現格式，用於發現設備上的資源列表，或者用於設備向服務目錄公告本身的資源。它支持RFC5785中的格式，在CoRE中用／．well—known／core的路徑表示資源描述。

　　支持緩存：CoAP協議支持資源描述的緩存以優化其性能。

　　協議主要實現：

　　· libcoap（C語言實現）

　　· Californium（java語言實現）

　　點評：CoAP和6LowPan，這分別是應用層協議和網絡適配層協議，其目標是解決設備直接鏈接到IP網絡，也就是IP技術應用到設備之間、互聯網與設備之間的通訊需求。由於IPV6技術帶來巨大尋址空間，不光解決了將來巨量設備和資源的標識問題，互聯網上應用能夠直接訪問支持IPV6的設備，而不須要額外的網關。

　　MQTT協議（低帶寬）

　　MQTT （Message Queuing Telemetry Transport ），消息隊列遙測傳輸，由IBM開發的即時通信協議，相比來講比較適合物聯網場景的通信協議。MQTT協議採用發佈/訂閱模式，全部的物聯網終端都經過TCP鏈接到雲端，雲端經過主題的方式管理各個設備關注的通信內容，負責將設備與設備之間消息的轉發。

　　MQTT在協議設計時就考慮到不一樣設備的計算性能的差別，因此全部的協議都是採用二進制格式編解碼，而且編解碼格式都很是易於開發和實現。最小的數據包只有2個字節，對於低功耗低速網絡也有很好的適應性。有很是完善的QOS機制，根據業務場景能夠選擇最多一次、至少一次、恰好一次三種消息送達模式。運行在TCP協議之上，同時支持TLS（TCP+SSL）協議，而且因爲全部數據通訊都通過雲端，安全性獲得了較好地保障。

　　適用範圍：在低帶寬、不可靠的網絡下提供基於雲平臺的遠程設備的數據傳輸和監控。

　　特色：

　　· 使用基於代理的發佈/訂閱消息模式，提供一對多的消息發佈

　　· 使用 TCP/IP 提供網絡鏈接

　　· 小型傳輸，開銷很小（固定長度的頭部是 2 字節），協議交換最小化，以下降網絡流量

　　· 支持QoS，有三種消息發佈服務質量：「至多一次」， 「至少一次」， 「只有一次」

　　協議主要實現和應用：

　　· 已經有PHP，JAVA，Python，C，C#等多個語言版本的協議框架

　　· IBM Bluemix 的一個重要部分是其 IoT Foundation 服務，這是一項基於雲的 MQTT 實例

　　· 移動應用程序也早就開始使用MQTT，如 Facebook Messenger 和com等

　　點評：MQTT協議通常適用於設備數據採集到端（Device-》Server，Device-》Gateway），集中星型網絡架構（hub-and-spoke），不適用設備與設備之間通訊，設備控制能力弱，另外實時性較差，通常都在秒級。

　　DDS協議（高可靠性、實時）

　　DDS（Data Distribution Service for Real-Time Systems），面向實時系統的數據分佈服務，這是大名鼎鼎的OMG組織提出的協議，其權威性應該能證實該協議的將來應用前景。

　　適用範圍：分佈式高可靠性、實時傳輸設備數據通訊。目前DDS已經普遍應用於國防、民航、工業控制等領域。

　　特色：

　　· 以數據爲中心

　　· 使用無代理的發佈/訂閱消息模式，點對點、點對多、多對多

　　· 提供多大21種QoS服務質量策略

　　協議主要實現：

　　· OpenDDS 是一個開源的 C++ 實現

　　· OpenSplice DDS

　　點評：DDS很好地支持設備之間的數據分發和設備控制，設備和雲端的數據傳輸，同時DDS的數據分發的實時效率很是高，能作到秒級內同時分發百萬條消息到衆多設備。DDS在服務質量（QoS）上提供很是多的保障途徑，這也是它適用於國防軍事、工業控制這些高可靠性、可安全性應用領域的緣由。但這些應用都工做在有線網絡下，在無線網絡，特別是資源受限的狀況下，沒有見到過實施案例。

　　AMQP協議（互操做性）

　　· AMQP（Advanced Message Queuing Protocol），先進消息隊列協議，這是OASIS組織提出的，該組織曾提出OSLC（Open Source Lifecyle）標準，用於業務系統例如PLM，ERP，MES等進行數據交換。

　　適用範圍：最先應用於金融系統之間的交易消息傳遞，在物聯網應用中，主要適用於移動手持設備與後臺數據中心的通訊和分析。

　　特色：

　　· Wire級的協議，它描述了在網絡上傳輸的數據的格式，以字節爲流

　　· 面向消息、隊列、路由（包括點對點和發佈/訂閱）、可靠性、安全

　　協議實現：

　　· Erlang中的實現有 RabbitMQ

　　· AMQP的開源實現，用C語言編寫OpenAMQ

　　· Apache Qpid

　　· stormMQ

　　XMPP協議（即時通訊）

　　XMPP（Extensible Messaging and Presence Protocol）可擴展通信和表示協議，XMPP的前身是Jabber，一個開源形式組織產生的網絡即時通訊協議。XMPP目前被IETF國際標準組織完成了標準化工做。

　　適用範圍：即時通訊的應用程序，還能用在網絡管理、內容供稿、協同工具、檔案共享、遊戲、遠端系統監控等。

　　特色：

　　· 客戶機/服務器通訊模式

　　· 分佈式網絡

　　· 簡單的客戶端，將大多數工做放在服務器端進行

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

　　點評：XMPP是基於XML的協議，因爲其開放性和易用性，在互聯網及時通信應用中運用普遍。相對HTTP，XMPP在通信的業務流程上是更適合物聯網系統的，開發者不用花太多心思去解決設備通信時的業務通信流程，相對開發成本會更低。可是HTTP協議中的安全性以及計算資源消耗的硬傷並無獲得本質的解決。

　　· JMS （Java Message Service），JAVA消息服務，這是JAVA平臺中著名的消息隊列協議。

　　Java消息服務（Java Message Service）應用程序接口，是一個Java平臺中關於面向消息中間件（MOM）的API，用於在兩個應用程序之間，或分佈式系統中發送消息，進行異步通訊。Java消息服務是一個與具體平臺無關的API，絕大多數MOM提供商都對JMS提供支持。

　　JMS是一種與廠商無關的 API，用來訪問消息收發系統消息，它相似於JDBC（Java Database Connectivity）。這裏，JDBC 是能夠用來訪問許多不一樣關係數據庫的 API，而 JMS 則提供一樣與廠商無關的訪問方法，以訪問消息收發服務。許多廠商都支持 JMS，包括 IBM 的 MQSeries、BEA的 Weblogic JMS service和 Progress 的 SonicMQ。 JMS 可以經過消息收發服務（有時稱爲消息中介程序或路由器）從一個 JMS 客戶機向另外一個 JMS客戶機發送消息。消息是 JMS 中的一種類型對象，由兩部分組成：報頭和消息主體。報頭由路由信息以及有關該消息的元數據組成。消息主體則攜帶着應用程序的數據或有效負載。根據有效負載的類型來劃分，能夠將消息分爲幾種類型，它們分別攜帶：簡單文本（TextMessage）、可序列化的對象 （ObjectMessage）、屬性集合 （MapMessage）、字節流 （BytesMessage）、原始值流 （StreamMessage），還有無有效負載的消息 （Message）。
      物聯網協議對比：

　　協議應用的側重方向

　　MQTT、 DDS、 AMQP、XMPP、 JMS、 REST、 CoAP這幾種協議都已被普遍應用，而且每種協議都有至少10種以上的代碼實現，都宣稱支持實時的發佈/訂閱的物聯網協議，可是在具體物聯網系統架構設計時，需考慮實際場景的通訊需求，選擇合適的協議。

　　以智能家居爲例，說明下這些協議側重應用方向。智能家居中智能燈光控制，可使用XMPP協議控制燈的開關；智能家居的電力供給，發電廠的發動機組的監控可使用DDS協議；當電力輸送到千家萬戶時，電力線的巡查和維護，可使用MQTT協議；家裏的全部電器的電量消耗，可使用AMQP協議，傳輸到雲端或家庭網關中進行分析；最後用戶想把自家的能耗查詢服務公佈到互聯網上，那麼可使用REST/HTTP來開放API服務。

　　物聯網協議的選擇

　　發佈/訂閱服務更適合物聯網環境下通訊

　　DDS、MQTT、AMQP和JMS都是基於發佈/訂閱模式，發佈/訂閱框架具備服務自發現、動態擴展、事件過濾的特色，它解決了物聯網系統在應用層的數據源快速獲取、物的加入和退出、興趣訂閱、下降帶寬流量等問題，實現物的聯接在空間上鬆耦合（雙方無需知道通訊地址）、時間上鬆耦合和同步鬆耦合。

　　服務質量（QoS）是物聯網通訊中的重要考慮因素

　　在服務策略的幫助下，DDS可以有效地控制和管理網絡帶寬、內存空間等資源的使用，同時也能控制數據的可靠性、實時性和數據的生存時間，經過靈活使用這些服務質量策略，DDS不只能在窄帶的無線環境上，也能在寬帶的有線通訊環境上開發出知足實時性需求的數據分發系統。