IOT（物聯(lián)網(wǎng)）的七大通信協(xié)議
2020-9-24新聞
在物聯(lián)網(wǎng)協(xié)議中，我們一般分為兩大類，一類是傳輸協(xié)議，一類是通信協(xié)議。傳輸協(xié)議一般負責子網(wǎng)內(nèi)設備間的組網(wǎng)及通信；通信協(xié)議則主要是運行在傳統(tǒng)互聯(lián)網(wǎng)TCP/IP協(xié)議之上的設備通訊協(xié)議，負責設備通過互聯(lián)網(wǎng)進行數(shù)據(jù)交換及通信。
上圖為物聯(lián)網(wǎng)聯(lián)接的問題空間，其中物聯(lián)網(wǎng)的通信環(huán)境有Ethernet， Wi-Fi， RFID， NFC（近距離無線通信）， Zigbee， 6LoWPAN（IPV6低速無線版本），Bluetooth， GSM， GPRS， GPS， 3G， 4G等網(wǎng)絡，而每一種通信應用協(xié)議都有一定適用范圍。AMQP、JMS、REST/HTTP都是工作在以太網(wǎng)，COAP協(xié)議是專門為資源受限設備開發(fā)的協(xié)議，而DDS和MQTT的兼容性則強很多。
互聯(lián)網(wǎng)時代，TCP/IP協(xié)議已經(jīng)一統(tǒng)江湖，現(xiàn)在的物聯(lián)網(wǎng)的通信架構(gòu)也是構(gòu)建在傳統(tǒng)互聯(lián)網(wǎng)基礎架構(gòu)之上。在當前的互聯(lián)網(wǎng)通信協(xié)議中，HTTP協(xié)議由于開發(fā)成本低，開放程度高，幾乎占據(jù)大半江山，所以很多廠商在構(gòu)建物聯(lián)網(wǎng)系統(tǒng)時也基于http協(xié)議進行開發(fā)。包括google主導的physic web項目，都是期望在傳統(tǒng)web技術基礎上構(gòu)建物聯(lián)網(wǎng)協(xié)議標準。
HTTP協(xié)議是典型的CS通訊模式，由客戶端主動發(fā)起連接，向服務器請求XML或JSON數(shù)據(jù)。該協(xié)議最早是為了適用web瀏覽器的上網(wǎng)瀏覽場景和設計的，目前在PC、手機、pad等終端上都應用廣泛，但并不適用于物聯(lián)網(wǎng)場景。在物聯(lián)網(wǎng)場景中其有三大弊端：
(1) 由于必須由設備主動向服務器發(fā)送數(shù)據(jù)，難以主動向設備推送數(shù)據(jù)。對于單單的數(shù)據(jù)采集等場景還勉強適用，但是對于頻繁的操控場景，只能推過設備定期主動拉取的的方式，實現(xiàn)成本和實時性都大打折扣。
(2) 安全性不高。web的不安全都是婦孺皆知，HTTP是明文協(xié)議，在很多要求高安全性的物聯(lián)網(wǎng)場景，如果不做很多安全準備工作（如采用https等），后果不堪設想。
(3) 不同于用戶交互終端如pc、手機，物聯(lián)網(wǎng)場景中的設備多樣化，對于運算和存儲資源都十分受限的設備，http協(xié)議實現(xiàn)、XML/JSON數(shù)據(jù)格式的解析，都是不可能的任務。
IOT的七大通信協(xié)議:
1. REST/HTTP(松耦合服務調(diào)用)
REST即表述性狀態(tài)傳遞，是基于HTTP協(xié)議開發(fā)的一種通信風格。
適用范圍：
REST/HTTP主要為了簡化互聯(lián)網(wǎng)中的系統(tǒng)架構(gòu)，快速實現(xiàn)客戶端和服務器之間交互的松耦合，降低了客戶端和服務器之間的交互延遲。因此適合在物聯(lián)網(wǎng)的應用層面，通過REST開放物聯(lián)網(wǎng)中資源，實現(xiàn)服務被其他應用所調(diào)用。
特點：
（1）REST 指的是一組架構(gòu)約束條件和原則。滿足這些約束條件和原則的應用程序或設計就是RESTful。
（2）客戶端和服務器之間的交互在請求之間是無狀態(tài)的。
（3）在服務器端，應用程序狀態(tài)和功能可以分為各種資源，它向客戶端公開，每個資源都使用 URI 得到一個唯一的地址。所有資源都共享統(tǒng)一的界面，以便在客戶端和服務器之間傳輸狀態(tài)。
（4）使用的是標準的 HTTP 方法，比如：GET、PUT、POST 和 DELETE。
REST/HTTP其實是互聯(lián)網(wǎng)中服務調(diào)用API封裝風格，物聯(lián)網(wǎng)中數(shù)據(jù)采集到物聯(lián)網(wǎng)應用系統(tǒng)中，在物聯(lián)網(wǎng)應用系統(tǒng)中，可以通過開放REST API的方式，把數(shù)據(jù)服務開放出去，被互聯(lián)網(wǎng)中其他應用所調(diào)用。
2. CoAP協(xié)議
CoAP (Constrained Application Protocol)，受限應用協(xié)議，應用于無線傳感網(wǎng)中協(xié)議。
適用范圍：
CoAP是簡化了HTTP協(xié)議的RESTful API，CoAP是6LowPAN協(xié)議棧中的應用層協(xié)議，它適用于在資源受限的通信的IP網(wǎng)絡。
特點：
?。?）報頭壓縮：CoAP包含一個緊湊的二進制報頭和擴展報頭。它只有短短的4B的基本報頭，基本報頭后面跟擴展選項。一個典型的請求報頭為10～20B。
?。?）方法和URIs：為了實現(xiàn)客戶端訪問服務器上的資源，CoAP支持GET、PUT、POST和DELETE等方法。CoAP還支持URIs，這是Web架構(gòu)的主要特點。
（3）傳輸層使用UDP協(xié)議：CoAP協(xié)議是建立在UDP協(xié)議之上，以減少開銷和支持組播功能。它也支持一個簡單的停止和等待的可靠性傳輸機制。
（4）支持異步通信：HTTP對M2M（Machine-to-Machine）通信不適用，這是由于事務總是由客戶端發(fā)起。而CoAP協(xié)議支持異步通信，這對M2M通信應用來說是常見的休眠／喚醒機制。
?。?）支持資源發(fā)現(xiàn)：為了自主的發(fā)現(xiàn)和使用資源，它支持內(nèi)置的資源發(fā)現(xiàn)格式，用于發(fā)現(xiàn)設備上的資源列表，或者用于設備向服務目錄公告自己的資源。它支持RFC5785中的格式，在CoRE中用／．well—known／core的路徑表示資源描述。
（6）支持緩存：CoAP協(xié)議支持資源描述的緩存以優(yōu)化其性能。
協(xié)議主要實現(xiàn)：
· libcoap（C語言實現(xiàn)）
· Californium（java語言實現(xiàn)）
CoAP和6LowPan，這分別是應用層協(xié)議和網(wǎng)絡適配層協(xié)議，其目標是解決設備直接連接到IP網(wǎng)絡，也就是IP技術應用到設備之間、互聯(lián)網(wǎng)與設備之間的通信需求。因為IPV6技術帶來巨大尋址空間，不光解決了未來巨量設備和資源的標識問題，互聯(lián)網(wǎng)上應用可以直接訪問支持IPV6的設備，而不需要額外的網(wǎng)關。
3. MQTT協(xié)議(低帶寬)
MQTT (Message Queuing Telemetry Transport )，消息隊列遙測傳輸，由IBM開發(fā)的即時通訊協(xié)議，相比來說比較適合物聯(lián)網(wǎng)場景的通訊協(xié)議。MQTT協(xié)議采用發(fā)布/訂閱模式，所有的物聯(lián)網(wǎng)終端都通過TCP連接到云端，云端通過主題的方式管理各個設備關注的通訊內(nèi)容，負責將設備與設備之間消息的轉(zhuǎn)發(fā)。
適用范圍：
在低帶寬、不可靠的網(wǎng)絡下提供基于云平臺的遠程設備的數(shù)據(jù)傳輸和監(jiān)控。
特點：
?。?） 使用基于代理的發(fā)布/訂閱消息模式，提供一對多的消息發(fā)布
（2） 使用 TCP/IP 提供網(wǎng)絡連接
?。?） 小型傳輸，開銷很?。ü潭ㄩL度的頭部是 2 字節(jié)），協(xié)議交換最小化，以降低網(wǎng)絡流量
?。?） 支持QoS，有三種消息發(fā)布服務質(zhì)量：“至多一次”， “至少一次”， “只有一次”
協(xié)議主要實現(xiàn)和應用：
?。?） 已經(jīng)有PHP，JAVA，Python，C，C#等多個語言版本的協(xié)議框架
?。?） IBM Bluemix 的一個重要部分是其 IoT FoundaTIon 服務，這是一項基于云的 MQTT 實例
?。?） 移動應用程序也早就開始使用MQTT，如 Facebook Messenger 和com等
MQTT協(xié)議一般適用于設備數(shù)據(jù)采集到端（Device-》Server，Device-》Gateway），集中星型網(wǎng)絡架構(gòu)（hub-and-spoke），不適用設備與設備之間通信，設備控制能力弱，另外實時性較差，一般都在秒級。
4. DDS協(xié)議(高可靠性、實時)
DDS(Data Distribution Service for Real-Time Systems)，面向?qū)崟r系統(tǒng)的數(shù)據(jù)分布服務。
適用范圍：
分布式高可靠性、實時傳輸設備數(shù)據(jù)通信。目前DDS已經(jīng)廣泛應用于國防、民航、工業(yè)控制等領域。
特點：
?。?） 以數(shù)據(jù)為中心
?。?） 使用無代理的發(fā)布/訂閱消息模式，點對點、點對多、多對多
（3） 提供多大21種QoS服務質(zhì)量策略
協(xié)議主要實現(xiàn)：
· OpenDDS 是一個開源的 C++ 實現(xiàn)
· OpenSplice DDS
DDS很好地支持設備之間的數(shù)據(jù)分發(fā)和設備控制，設備和云端的數(shù)據(jù)傳輸，同時DDS的數(shù)據(jù)分發(fā)的實時效率非常高，能做到秒級內(nèi)同時分發(fā)百萬條消息到眾多設備。DDS在服務質(zhì)量（QoS）上提供非常多的保障途徑，這也是它適用于國防軍事、工業(yè)控制這些高可靠性、可安全性應用領域的原因。但這些應用都工作在有線網(wǎng)絡下，在無線網(wǎng)絡，特別是資源受限的情況下，沒有見到過實施案例。
5. AMQP協(xié)議(互操作性)
AMQP(Advanced Message Queuing Protocol)，先進消息隊列協(xié)議，用于業(yè)務系統(tǒng)例如PLM，ERP，MES等進行數(shù)據(jù)交換。
適用范圍：
最早應用于金融系統(tǒng)之間的交易消息傳遞，在物聯(lián)網(wǎng)應用中，主要適用于移動手持設備與后臺數(shù)據(jù)中心的通信和分析。
特點：
?。?） Wire級的協(xié)議，它描述了在網(wǎng)絡上傳輸?shù)臄?shù)據(jù)的格式，以字節(jié)為流
（2） 面向消息、隊列、路由（包括點對點和發(fā)布/訂閱）、可靠性、安全
協(xié)議實現(xiàn)：
· Erlang中的實現(xiàn)有 RabbitMQ
· AMQP的開源實現(xiàn)，用C語言編寫OpenAMQ
· Apache Qpid
· stormMQ
6. XMPP協(xié)議(即時通信)
XMPP(Extensible Messaging and Presence Protocol)可擴展通訊和表示協(xié)議，一個開源形式組織產(chǎn)生的網(wǎng)絡即時通信協(xié)議。
適用范圍：
即時通信的應用程序，還能用在網(wǎng)絡管理、游戲、遠端系統(tǒng)監(jiān)控等。
特點：
?。?） 客戶機/服務器通信模式
（2） 分布式網(wǎng)絡
?。?） 簡單的客戶端，將大多數(shù)工作放在服務器端進行
?。?） 標準通用標記語言的子集XML的數(shù)據(jù)格式
XMPP是基于XML的協(xié)議，由于其開放性和易用性，在互聯(lián)網(wǎng)及時通訊應用中運用廣泛。相對HTTP，XMPP在通訊的業(yè)務流程上是更適合物聯(lián)網(wǎng)系統(tǒng)的，開發(fā)者不用花太多心思去解決設備通訊時的業(yè)務通訊流程，相對開發(fā)成本會更低。但是HTTP協(xié)議中的安全性以及計算資源消耗的硬傷并沒有得到本質(zhì)的解決。
7. JMS
JMS (Java Message Service)，即消息服務，這是JAVA平臺中著名的消息隊列協(xié)議。
Java消息服務應用程序接口，是一個Java平臺中關于面向消息中間件(MOM)的API，用于在兩個應用程序之間，或分布式系統(tǒng)中發(fā)送消息，進行異步通信。Java消息服務是一個與具體平臺無關的API，絕大多數(shù)MOM提供商都對JMS提供支持。
JMS是一種與廠商無關的 API，用來訪問消息收發(fā)系統(tǒng)消息，它類似于JDBC（Java Database Connectivity）。這里，JDBC 是可以用來訪問許多不同關系數(shù)據(jù)庫的 API，而 JMS 則提供同樣與廠商無關的訪問方法，以訪問消息收發(fā)服務。許多廠商都支持 JMS，包括 IBM 的 MQSeries、BEA的 Weblogic JMS service和 Progress 的 SonicMQ。 JMS 能夠通過消息收發(fā)服務（有時稱為消息中介程序或路由器）從一個 JMS 客戶機向另一個 JMS客戶機發(fā)送消息。消息是 JMS 中的一種類型對象，由兩部分組成：報頭和消息主體。報頭由路由信息以及有關該消息的元數(shù)據(jù)組成。消息主體則攜帶著應用程序的數(shù)據(jù)或有效負載。根據(jù)有效負載的類型來劃分，可以將消息分為幾種類型，它們分別攜帶：簡單文本（TextMessage）、可序列化的對象 （ObjectMessage）、屬性集合 （MapMessage）、字節(jié)流 （BytesMessage）、原始值流 （StreamMessage），還有無有效負載的消息 （Message）。
協(xié)議對比：
協(xié)議應用的側(cè)重方向
MQTT、 DDS、 AMQP、XMPP、 JMS、 REST、 CoAP這幾種協(xié)議都已被廣泛應用，并且每種協(xié)議都有至少10種以上的代碼實現(xiàn)，都宣稱支持實時的發(fā)布/訂閱的物聯(lián)網(wǎng)協(xié)議，但是在具體物聯(lián)網(wǎng)系統(tǒng)架構(gòu)設計時，需考慮實際場景的通信需求，選擇合適的協(xié)議。
以智能家居為例，說明下這些協(xié)議側(cè)重應用方向。智能家居中智能燈光控制，可以使用XMPP協(xié)議控制燈的開關；智能家居的電力供給，發(fā)電廠的發(fā)動機組的監(jiān)控可以使用DDS協(xié)議；當電力輸送到千家萬戶時，電力線的巡查和維護，可以使用MQTT協(xié)議；家里的所有電器的電量消耗，可以使用AMQP協(xié)議，傳輸?shù)皆贫嘶蚣彝ゾW(wǎng)關中進行分析；最后用戶想把自家的能耗查詢服務公布到互聯(lián)網(wǎng)上，那么可以使用REST/HTTP來開放API服務。
物聯(lián)網(wǎng)協(xié)議的選擇
發(fā)布/訂閱服務更適合物聯(lián)網(wǎng)環(huán)境下通信
DDS、MQTT、AMQP和JMS都是基于發(fā)布/訂閱模式，發(fā)布/訂閱框架具有服務自發(fā)現(xiàn)、動態(tài)擴展、事件過濾的特點，它解決了物聯(lián)網(wǎng)系統(tǒng)在應用層的數(shù)據(jù)源快速獲取、物的加入和退出、興趣訂閱、降低帶寬流量等問題，實現(xiàn)物的聯(lián)接在空間上松耦合（雙方無需知道通信地址）、時間上松耦合和同步松耦合。
服務質(zhì)量（QoS）是物聯(lián)網(wǎng)通信中的重要考慮因素
在服務策略的幫助下，DDS能夠有效地控制和管理網(wǎng)絡帶寬、內(nèi)存空間等資源的使用，同時也能控制數(shù)據(jù)的可靠性、實時性和數(shù)據(jù)的生存時間，通過靈活使用這些服務質(zhì)量策略，DDS不僅能在窄帶的無線環(huán)境上，也能在寬帶的有線通信環(huán)境上開發(fā)出滿足實時性需求的數(shù)據(jù)分發(fā)系統(tǒng)。
