通信對物聯網來說十分常用且關鍵，無論是近距離無線傳輸技術還是移動通信技術，都影響著物聯網的發展。而在通信中，通信協議尤其重要，是指雙方實體完成通信或服務所必須遵循的規則和約定。那么物聯網都有哪些通信協議呢?
我們將物聯網協議分為兩大類，一類是傳輸協議，一類是通信協議。傳輸協議一般負責子網內設備間的組網及通信，之前我們已經為大家做了一次的科普，文章《物聯網常見的無線傳輸協議類型》有詳細介紹。通信協議則主要是運行在傳統互聯網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開放物聯網中資源，實現服務被其他應用所調用。
特點：
1. REST 指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程序或設計就是RESTful
2.客戶端和服務器之間的交互在請求之間是無狀態的
3. 在服務器端，應用程序狀態和功能可以分為各種資源，它向客戶端公開。資源的例子有：應用程序對象、數據庫記錄、算法等等。每個資源都使用 URI (Universal Resource Identifier) 得到一個惟一的地址。所有資源都共享統一的界面，以便在客戶端和服務器之間傳輸狀態
4.使用的是標準的 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協議支持資源描述的緩存以優化其性能。
協議主要實現：
1. libcoap(C語言實現)
2.Californium(java語言實現)
點評：CoAP和6LowPan，這分別是應用層協議和網絡適配層協議，其目標是解決設備直接連接到IP網絡，也就是IP技術應用到設備之間、互聯網與設備之間的通信需求。因為IPV6技術帶來巨大尋址空間，不光解決了未來巨量設備和資源的標識問題，互聯網上應用可以直接訪問支持IPV6的設備，而不需要額外的網關。
MQTT協議(低帶寬)
MQTT (Message Queuing Telemetry Transport )，消息隊列遙測傳輸，由IBM開發的即時通訊協議，相比來說比較適合物聯網場景的通訊協議。MQTT協議采用發布/訂閱模式，所有的物聯網終端都通過TCP連接到云端，云端通過主題的方式管理各個設備關注的通訊內容，負責將設備與設備之間消息的轉發。
MQTT在協議設計時就考慮到不同設備的計算性能的差異，所以所有的協議都是采用二進制格式編解碼，并且編解碼格式都非常易于開發和實現。最小的數據包只有2個字節，對于低功耗低速網絡也有很好的適應性。有非常完善的QOS機制，根據業務場景可以選擇最多一次、至少一次、剛好一次三種消息送達模式。運行在TCP協議之上，同時支持TLS(TCP+SSL)協議，并且由于所有數據通信都經過云端，安全性得到了較好地保障。
適用范圍：在低帶寬、不可靠的網絡下提供基于云平臺的遠程設備的數據傳輸和監控。
特點：
1.使用基于代理的發布/訂閱消息模式，提供一對多的消息發布
2.使用 TCP/IP 提供網絡連接
3.小型傳輸，開銷很小(固定長度的頭部是 2 字節)，協議交換最小化，以降低網絡流量
4.支持QoS，有三種消息發布服務質量：“至多一次”， “至少一次”， “只有一次”
協議主要實現和應用：
1.已經有PHP，JAVA，Python，C，C#等多個語言版本的協議框架
2.IBM Bluemix 的一個重要部分是其 IoT Foundation 服務，這是一項基于云的 MQTT 實例
3.移動應用程序也早就開始使用MQTT，如 Facebook Messenger 和com等
點評：MQTT協議一般適用于設備數據采集到端(Device-》Server，Device-》Gateway)，集中星型網絡架構(hub-and-spoke)，不適用設備與設備之間通信，設備控制能力弱，另外實時性較差，一般都在秒級。
DDS協議(高可靠性、實時)
DDS(Data Distribution Service for Real-Time Systems)，面向實時系統的數據分布服務，這是大名鼎鼎的OMG組織提出的協議，其權威性應該能證明該協議的未來應用前景。
適用范圍：分布式高可靠性、實時傳輸設備數據通信。目前DDS已經廣泛應用于國防、民航、工業控制等領域。
特點：
1.以數據為中心
2.使用無代理的發布/訂閱消息模式，點對點、點對多、多對多
3.提供多大21種QoS服務質量策略
協議主要實現：
1.OpenDDS 是一個開源的 C++ 實現
2.OpenSplice DDS
點評：DDS很好地支持設備之間的數據分發和設備控制，設備和云端的數據傳輸，同時DDS的數據分發的實時效率非常高，能做到秒級內同時分發百萬條消息到眾多設備。DDS在服務質量(QoS)上提供非常多的保障途徑，這也是它適用于國防軍事、工業控制這些高可靠性、可安全性應用領域的原因。但這些應用都工作在有線網絡下，在無線網絡，特別是資源受限的情況下，沒有見到過實施案例。
AMQP協議(互操作性)
AMQP(Advanced Message Queuing Protocol)，先進消息隊列協議，這是OASIS組織提出的，該組織曾提出OSLC(Open Source Lifecyle)標準，用于業務系統例如PLM，ERP，MES等進行數據交換。
適用范圍：最早應用于金融系統之間的交易消息傳遞，在物聯網應用中，主要適用于移動手持設備與后臺數據中心的通信和分析。
特點：
1.Wire級的協議，它描述了在網絡上傳輸的數據的格式，以字節為流
2.面向消息、隊列、路由(包括點對點和發布/訂閱)、可靠性、安全
協議實現：
1.Erlang中的實現有 RabbitMQ
2.AMQP的開源實現，用C語言編寫OpenAMQ
3.Apache Qpid
4.stormMQ
XMPP協議(即時通信)
XMPP(Extensible Messaging and Presence Protocol)可擴展通訊和表示協議，XMPP的前身是Jabber，一個開源形式組織產生的網絡即時通信協議。XMPP目前被IETF國際標準組織完成了標準化工作。
適用范圍：即時通信的應用程序，還能用在網絡管理、內容供稿、協同工具、檔案共享、游戲、遠端系統監控等。
特點：
1.客戶機/服務器通信模式
2.分布式網絡
3.簡單的客戶端，將大多數工作放在服務器端進行
4.標準通用標記語言的子集XML的數據格式
點評：XMPP是基于XML的協議，由于其開放性和易用性，在互聯網及時通訊應用中運用廣泛。相對HTTP，XMPP在通訊的業務流程上是更適合物聯網系統的，開發者不用花太多心思去解決設備通訊時的業務通訊流程，相對開發成本會更低。但是HTTP協議中的安全性以及計算資源消耗的硬傷并沒有得到本質的解決。
JMS (Java Message Service)
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服務。
-20241213094735.png)
