通(tong)信(xin)對物聯(lian)(lian)網來說十分(fen)關(guan)鍵(jian)，無論是近距(ju)離無線傳輸技(ji)術(shu)(shu)還是移動通(tong)信(xin)技(ji)術(shu)(shu)，甚至(zhi)是LPWAN都影響著物聯(lian)(lian)網的發展。通(tong)信(xin)協(xie)議是指雙方實(shi)體完成通(tong)信(xin)或服務所必須遵(zun)循的規則和約(yue)定。那么物聯(lian)(lian)網都有哪些(xie)通(tong)信(xin)協(xie)議？眾多的協(xie)議該如何選擇？
我們將物聯網通信(xin)協(xie)議分為兩大(da)類，一(yi)(yi)類是(shi)接入協(xie)議，一(yi)(yi)類是(shi)通訊協(xie)議。接入協(xie)議一(yi)(yi)般負責子網內(nei)設備間的(de)組網及通信(xin)；通訊協(xie)議主(zhu)要(yao)是(shi)運行在(zai)傳統互(hu)聯網TCP/IP協(xie)議之上的(de)設備通訊協(xie)議，負責設備通過(guo)互(hu)聯網進行數據交換及通信(xin)。
本文羅列(lie)下市面上物聯(lian)(lian)網協議，總結下它們各(ge)自特點、特定的物聯(lian)(lian)網應用場景等(deng)。
物聯網(wang)聯接的問題空間
上(shang)圖為物聯網(wang)(wang)聯接的(de)問題空間，其中物聯網(wang)(wang)的(de)通信環境有Ethernet， Wi-Fi， RFID， NFC（近(jin)距離無線通信）， Zigbee， 6LoWPAN（IPV6低速(su)無線版本），Bluetooth， GSM， GPRS， GPS， 3G， 4G等網(wang)(wang)絡，而每(mei)一(yi)種通信應用協議都(dou)有一(yi)定適用范圍(wei)。AMQP、JMS、REST/HTTP都(dou)是工作在以太網(wang)(wang)，COAP協議是專門(men)為資源受限設(she)備開發的(de)協議，而DDS和MQTT的(de)兼容(rong)性(xing)則強很多。
互聯(lian)(lian)網(wang)時代(dai)，TCP/IP協(xie)議已經一統(tong)江(jiang)湖，現在(zai)(zai)(zai)的(de)物(wu)聯(lian)(lian)網(wang)的(de)通(tong)信架構也是(shi)構建(jian)在(zai)(zai)(zai)傳(chuan)統(tong)互聯(lian)(lian)網(wang)基礎(chu)架構之上。在(zai)(zai)(zai)當(dang)前的(de)互聯(lian)(lian)網(wang)通(tong)信協(xie)議中，HTTP協(xie)議由于開(kai)發(fa)成本低(di)，開(kai)放程度高，幾乎(hu)占據大半(ban)江(jiang)山，所以(yi)很(hen)多廠商在(zai)(zai)(zai)構建(jian)物(wu)聯(lian)(lian)網(wang)系(xi)統(tong)時也基于http協(xie)議進行開(kai)發(fa)。包括google主導的(de)physic web項目(mu)，都(dou)是(shi)期望在(zai)(zai)(zai)傳(chuan)統(tong)web技術基礎(chu)上構建(jian)物(wu)聯(lian)(lian)網(wang)協(xie)議標(biao)準。
HTTP協(xie)議是(shi)典型的(de)(de)CS通訊(xun)模式(shi)，由客戶端主動發起連接，向服務器請求XML或JSON數(shu)據。該協(xie)議最(zui)早(zao)是(shi)為(wei)了適用(yong)web瀏覽(lan)器的(de)(de)上(shang)網瀏覽(lan)場(chang)景(jing)(jing)和(he)設計(ji)的(de)(de)，目前在(zai)PC、手機(ji)、pad等(deng)終端上(shang)都(dou)應用(yong)廣泛，但并不(bu)適用(yong)于物(wu)聯網場(chang)景(jing)(jing)。在(zai)物(wu)聯網場(chang)景(jing)(jing)中(zhong)其有三大弊端：
由(you)于(yu)必須由(you)設(she)備(bei)主動(dong)向服務器發送(song)數(shu)據，難以主動(dong)向設(she)備(bei)推送(song)數(shu)據。對(dui)于(yu)單單的數(shu)據采(cai)集等場景還(huan)勉(mian)強適用，但是對(dui)于(yu)頻(pin)繁的操控場景，只能推過設(she)備(bei)定期(qi)主動(dong)拉取的的方式，實(shi)現成本和實(shi)時性都大打折扣(kou)。
安全(quan)性不高。web的(de)不安全(quan)都是(shi)婦(fu)孺(ru)皆知(zhi)，HTTP是(shi)明文協議(yi)，在很多(duo)(duo)要(yao)求高安全(quan)性的(de)物(wu)聯(lian)網場景(jing)，如(ru)果(guo)不做(zuo)很多(duo)(duo)安全(quan)準(zhun)備工作（如(ru)采用https等），后(hou)果(guo)不堪設想。
不同于用戶交互終端(duan)如pc、手機，物聯網場景中的(de)(de)(de)設(she)備(bei)多樣化，對于運算(suan)和存儲資源都(dou)十分受限的(de)(de)(de)設(she)備(bei)，http協議(yi)實現、XML/JSON數據格(ge)式的(de)(de)(de)解析，都(dou)是不可能的(de)(de)(de)任務。
REST/HTTP（松耦合服務調用）
REST （Representational State Transfer），表征狀(zhuang)態(tai)轉換，是基于HTTP協(xie)議(yi)開發的(de)一種通信風格，目(mu)前還不是標準；
適用(yong)范圍：REST/HTTP主(zhu)要為了簡化互聯(lian)網中(zhong)的(de)系統架(jia)構，快速實現客(ke)戶端和(he)服務(wu)器(qi)之(zhi)間(jian)交互的(de)松耦合，降低了客(ke)戶端和(he)服務(wu)器(qi)之(zhi)間(jian)的(de)交互延(yan)遲。因此(ci)適合在物(wu)聯(lian)網的(de)應用(yong)層面，通過(guo)REST開放物(wu)聯(lian)網中(zhong)資(zi)源，實現服務(wu)被(bei)其(qi)他應用(yong)所調用(yong)。
特點：
· REST 指的是一組(zu)架構(gou)約(yue)束(shu)(shu)條(tiao)件和(he)原(yuan)則。滿足這些約(yue)束(shu)(shu)條(tiao)件和(he)原(yuan)則的應用程(cheng)序或設計就是RESTful
· 客戶(hu)端和服(fu)務器之間(jian)的交互在(zai)請求之間(jian)是(shi)無狀態的
· 在(zai)服(fu)務器(qi)端，應用(yong)(yong)程序狀(zhuang)態和(he)功能可以分為(wei)各種(zhong)資(zi)源(yuan)，它向客戶端公開。資(zi)源(yuan)的例(li)子(zi)有：應用(yong)(yong)程序對象、數據庫記錄、算法等等。每個資(zi)源(yuan)都使用(yong)(yong) URI （Universal Resource Identifier） 得到(dao)一(yi)個惟一(yi)的地址。所有資(zi)源(yuan)都共享統一(yi)的界面，以便在(zai)客戶端和(he)服(fu)務器(qi)之間(jian)傳(chuan)輸狀(zhuang)態
· 使用的是(shi)標準(zhun)的 HTTP 方法(fa)，比如(ru) GET、PUT、POST 和 DELETE
點評： REST/HTTP其(qi)(qi)實是互(hu)聯(lian)(lian)網(wang)(wang)中服務調用(yong)API封裝風格(ge)，物(wu)(wu)聯(lian)(lian)網(wang)(wang)中數據(ju)采集(ji)到(dao)物(wu)(wu)聯(lian)(lian)網(wang)(wang)應(ying)用(yong)系(xi)統(tong)中，在物(wu)(wu)聯(lian)(lian)網(wang)(wang)應(ying)用(yong)系(xi)統(tong)中，可以通過開(kai)放REST API的方式(shi)，把數據(ju)服務開(kai)放出去，被(bei)互(hu)聯(lian)(lian)網(wang)(wang)中其(qi)(qi)他(ta)應(ying)用(yong)所(suo)調用(yong)。
CoAP協議
· CoAP （Constrained Application Protocol），受限應用(yong)協議，應用(yong)于(yu)無線傳感(gan)網中協議。
適用(yong)范(fan)圍：CoAP是簡化了(le)HTTP協議(yi)的RESTful API，CoAP是6LowPAN協議(yi)棧中的應用(yong)層協議(yi)，它適用(yong)于在資源受限的通(tong)信的IP網絡(luo)。
特點：
報(bao)頭壓縮：CoAP包含一個緊湊的二進制報(bao)頭和擴展報(bao)頭。它只(zhi)有短短的4B的基(ji)本報(bao)頭，基(ji)本報(bao)頭后面跟擴展選(xuan)項。一個典型(xing)的請求(qiu)報(bao)頭為10～20B。
方法和URIs：為了實現客戶(hu)端訪問(wen)服務器上的資源，CoAP支持(chi)GET、PUT、POST和DELETE等(deng)方法。CoAP還支持(chi)URIs，這是Web架構的主要特點。
傳輸(shu)(shu)層使用UDP協(xie)議(yi)：CoAP協(xie)議(yi)是建立在UDP協(xie)議(yi)之上，以(yi)減少開銷和支持(chi)組(zu)播(bo)功(gong)能。它也支持(chi)一(yi)個簡單的停止和等待的可靠性傳輸(shu)(shu)機制(zhi)。
支持異(yi)步通(tong)(tong)信：HTTP對M2M（Machine-to-Machine）通(tong)(tong)信不適用，這是由于事(shi)務(wu)總是由客戶端發起。而CoAP協議(yi)支持異(yi)步通(tong)(tong)信，這對M2M通(tong)(tong)信應用來說是常見的休眠(mian)／喚醒機(ji)制(zhi)。
支(zhi)(zhi)持資(zi)(zi)(zi)源(yuan)發現：為(wei)了(le)自主(zhu)的(de)(de)(de)發現和使用(yong)(yong)資(zi)(zi)(zi)源(yuan)，它(ta)支(zhi)(zhi)持內置(zhi)的(de)(de)(de)資(zi)(zi)(zi)源(yuan)發現格(ge)(ge)式(shi)(shi)，用(yong)(yong)于發現設備上的(de)(de)(de)資(zi)(zi)(zi)源(yuan)列表(biao)，或(huo)者用(yong)(yong)于設備向服務目錄公(gong)告自己的(de)(de)(de)資(zi)(zi)(zi)源(yuan)。它(ta)支(zhi)(zhi)持RFC5785中的(de)(de)(de)格(ge)(ge)式(shi)(shi)，在CoRE中用(yong)(yong)／．well—known／core的(de)(de)(de)路徑表(biao)示資(zi)(zi)(zi)源(yuan)描(miao)述。
支(zhi)持緩(huan)存：CoAP協議支(zhi)持資(zi)源(yuan)描述的緩(huan)存以優化其性能。
協議主要實現：
· libcoap（C語(yu)言(yan)實(shi)現）
· Californium（java語言實現）
點評：CoAP和(he)6LowPan，這分別是(shi)應用(yong)層協議(yi)和(he)網(wang)絡適配層協議(yi)，其目標(biao)是(shi)解決(jue)設備直接(jie)連接(jie)到(dao)IP網(wang)絡，也就是(shi)IP技(ji)術(shu)應用(yong)到(dao)設備之間(jian)、互聯網(wang)與(yu)設備之間(jian)的(de)通信需求。因(yin)為IPV6技(ji)術(shu)帶來巨大(da)尋址(zhi)空(kong)間(jian)，不光解決(jue)了未來巨量設備和(he)資(zi)源的(de)標(biao)識問題，互聯網(wang)上應用(yong)可以直接(jie)訪問支持IPV6的(de)設備，而不需要額外的(de)網(wang)關。
MQTT協議（低帶寬）
MQTT （Message Queuing Telemetry Transport ），消息(xi)(xi)隊(dui)列遙測傳輸，由IBM開發的即時通(tong)訊(xun)協(xie)(xie)議，相比(bi)(bi)來說(shuo)比(bi)(bi)較適合物聯(lian)網(wang)場(chang)景的通(tong)訊(xun)協(xie)(xie)議。MQTT協(xie)(xie)議采(cai)用發布/訂(ding)閱(yue)模式(shi)，所有的物聯(lian)網(wang)終端(duan)都通(tong)過TCP連接到云(yun)端(duan)，云(yun)端(duan)通(tong)過主題的方式(shi)管理各個設備(bei)關注的通(tong)訊(xun)內容，負責將(jiang)設備(bei)與設備(bei)之間消息(xi)(xi)的轉發。
MQTT在協議(yi)設計(ji)時就考慮(lv)到不同設備的(de)(de)計(ji)算性能(neng)的(de)(de)差異，所(suo)以所(suo)有(you)(you)的(de)(de)協議(yi)都是采用(yong)二進制(zhi)格式編(bian)解(jie)碼(ma)，并且編(bian)解(jie)碼(ma)格式都非常(chang)易(yi)于(yu)開發和實現(xian)。最小的(de)(de)數(shu)據包只(zhi)有(you)(you)2個字(zi)節，對于(yu)低功耗低速網絡(luo)也有(you)(you)很好的(de)(de)適應(ying)性。有(you)(you)非常(chang)完善的(de)(de)QOS機制(zhi)，根據業務(wu)場景可(ke)以選(xuan)擇最多一(yi)次(ci)、至少一(yi)次(ci)、剛好一(yi)次(ci)三種消息送達(da)模式。運行在TCP協議(yi)之(zhi)上，同時支持TLS（TCP+SSL）協議(yi)，并且由于(yu)所(suo)有(you)(you)數(shu)據通信都經過(guo)云端，安全性得到了較好地保障。
適用(yong)范圍：在(zai)低帶寬、不可靠的網絡下提供(gong)基(ji)于云平(ping)臺的遠程設備的數據傳輸(shu)和監控(kong)。
特點：
· 使用(yong)基于代理的發(fa)布/訂(ding)閱消息模式，提供一對(dui)多的消息發(fa)布
· 使用 TCP/IP 提供網絡連接(jie)
· 小(xiao)型(xing)傳輸，開銷很小(xiao)（固定長度(du)的(de)頭部是 2 字節(jie)），協議(yi)交(jiao)換最小(xiao)化，以降低網絡流量(liang)
· 支持(chi)QoS，有三種消息發布服務質量：“至多(duo)一次”， “至少一次”， “只有一次”
協議(yi)主要實(shi)現(xian)和(he)應用(yong)：
· 已經有PHP，JAVA，Python，C，C#等多個語(yu)言版(ban)本(ben)的協議框架
· IBM Bluemix 的一(yi)個重要部分(fen)是(shi)其 IoT Foundation 服務(wu)，這是(shi)一(yi)項基于云的 MQTT 實例
· 移動應用(yong)程序也早就(jiu)開始使用(yong)MQTT，如 Facebook Messenger 和com等
點(dian)評：MQTT協議一般適(shi)用(yong)于設(she)備數據采集到(dao)端（Device-》Server，Device-》Gateway），集中星型(xing)網絡架構（hub-and-spoke），不適(shi)用(yong)設(she)備與設(she)備之(zhi)間通信，設(she)備控(kong)制能力(li)弱，另外實時性(xing)較(jiao)差，一般都在秒級。
DDS協(xie)議（高可靠性、實時）
DDS（Data Distribution Service for Real-Time Systems），面(mian)向實時系統的數(shu)據(ju)分布服務(wu)，這是大名鼎(ding)鼎(ding)的OMG組(zu)織提出(chu)的協(xie)議，其權威性應(ying)該能證明該協(xie)議的未來應(ying)用前(qian)景。
適(shi)用(yong)范(fan)圍：分布(bu)式高可靠(kao)性、實時傳輸(shu)設備(bei)數據通(tong)信。目前DDS已(yi)經廣(guang)泛應(ying)用(yong)于國防(fang)、民航、工業(ye)控制等領域。
特點：
· 以數據為中心
· 使用(yong)無(wu)代理的發(fa)布(bu)/訂閱消息模式，點對(dui)點、點對(dui)多(duo)、多(duo)對(dui)多(duo)
· 提(ti)供(gong)多大21種QoS服務質量(liang)策略
協議主要實現：
· OpenDDS 是一個開源的 C++ 實現
· OpenSplice DDS
點評：DDS很好地支持設(she)備(bei)(bei)之間的(de)(de)數(shu)據(ju)分發和設(she)備(bei)(bei)控(kong)制，設(she)備(bei)(bei)和云(yun)端的(de)(de)數(shu)據(ju)傳輸，同時(shi)DDS的(de)(de)數(shu)據(ju)分發的(de)(de)實時(shi)效(xiao)率非常(chang)高，能做(zuo)到秒級內同時(shi)分發百(bai)萬條消息到眾(zhong)多設(she)備(bei)(bei)。DDS在服務質量（QoS）上提供非常(chang)多的(de)(de)保障途(tu)徑，這(zhe)也(ye)是(shi)它(ta)適用(yong)(yong)于國(guo)防軍(jun)事(shi)、工(gong)業控(kong)制這(zhe)些(xie)高可(ke)靠性、可(ke)安(an)全性應用(yong)(yong)領(ling)域的(de)(de)原(yuan)因。但(dan)這(zhe)些(xie)應用(yong)(yong)都工(gong)作(zuo)在有(you)線網絡下，在無線網絡，特別是(shi)資源受限(xian)的(de)(de)情(qing)況下，沒有(you)見到過實施案例。
AMQP協(xie)議（互(hu)操(cao)作性）
· AMQP（Advanced Message Queuing Protocol），先進消息隊列(lie)協議，這是OASIS組(zu)織提出(chu)的，該(gai)組(zu)織曾提出(chu)OSLC（Open Source Lifecyle）標準，用于業務系統例(li)如PLM，ERP，MES等進行數據交換。
適用(yong)范圍：最早應用(yong)于(yu)金融(rong)系統之間的交(jiao)易消息傳遞(di)，在物聯網應用(yong)中，主要適用(yong)于(yu)移(yi)動手(shou)持設備(bei)與后(hou)臺數據中心的通信(xin)和分(fen)析。
特點：
· Wire級的協議(yi)，它(ta)描述了在(zai)網絡上傳輸(shu)的數據的格式，以字節(jie)為流
· 面向消息(xi)、隊列、路由（包括點對點和(he)發布/訂閱）、可靠性、安全
協議實現：
· Erlang中(zhong)的(de)實現有 RabbitMQ
· AMQP的開源(yuan)實現，用C語(yu)言(yan)編寫OpenAMQ
· Apache Qpid
· stormMQ
XMPP協議（即時通信）
XMPP（Extensible Messaging and Presence Protocol）可擴展通(tong)訊和表(biao)示(shi)協(xie)議，XMPP的前(qian)身是Jabber，一個開源形式組織(zhi)產生的網絡即時通(tong)信協(xie)議。XMPP目前(qian)被IETF國(guo)際標準組織(zhi)完成(cheng)了標準化工作。
適用(yong)(yong)范圍(wei)：即時通(tong)信的(de)應(ying)用(yong)(yong)程序，還能用(yong)(yong)在網絡(luo)管(guan)理、內容供(gong)稿(gao)、協同工(gong)具、檔案共享(xiang)、游戲(xi)、遠端(duan)系(xi)統監控(kong)等。
特點：
· 客戶機/服務(wu)器通信(xin)模式
· 分布式網絡
· 簡單的客戶端(duan)(duan)，將大多數工(gong)作放在服務(wu)器端(duan)(duan)進行
· 標(biao)準(zhun)通用標(biao)記語言的子集XML的數據格式
點評：XMPP是基(ji)于XML的(de)(de)(de)協議(yi)，由于其(qi)開放(fang)性和(he)易用(yong)(yong)性，在互聯網及時(shi)通訊(xun)(xun)應用(yong)(yong)中運用(yong)(yong)廣(guang)泛。相(xiang)對(dui)HTTP，XMPP在通訊(xun)(xun)的(de)(de)(de)業務流程(cheng)上是更適合物聯網系統的(de)(de)(de)，開發者不(bu)用(yong)(yong)花太(tai)多心(xin)思去解決設備通訊(xun)(xun)時(shi)的(de)(de)(de)業務通訊(xun)(xun)流程(cheng)，相(xiang)對(dui)開發成本(ben)會(hui)更低。但是HTTP協議(yi)中的(de)(de)(de)安全性以及計算(suan)資源消(xiao)耗的(de)(de)(de)硬傷并沒有得到本(ben)質的(de)(de)(de)解決。
· JMS （Java Message Service），JAVA消息(xi)服(fu)務(wu)，這是(shi)JAVA平臺中著名(ming)的消息(xi)隊列協議。
Java消(xiao)(xiao)息(xi)服務(wu)（Java Message Service）應用程(cheng)序接口，是一個Java平臺(tai)中(zhong)關于面向消(xiao)(xiao)息(xi)中(zhong)間(jian)(jian)件（MOM）的API，用于在兩個應用程(cheng)序之間(jian)(jian)，或分布式系統中(zhong)發送(song)消(xiao)(xiao)息(xi)，進行異步通信。Java消(xiao)(xiao)息(xi)服務(wu)是一個與具體平臺(tai)無關的API，絕大(da)多(duo)數MOM提供商都(dou)對JMS提供支持(chi)。
JMS是一種(zhong)與(yu)廠商無(wu)關(guan)的(de)(de)(de) API，用(yong)來訪(fang)(fang)問(wen)消(xiao)息(xi)(xi)(xi)收發系統消(xiao)息(xi)(xi)(xi)，它(ta)類似于JDBC（Java Database Connectivity）。這里(li)，JDBC 是可(ke)以用(yong)來訪(fang)(fang)問(wen)許多(duo)不同(tong)關(guan)系數(shu)據(ju)(ju)庫的(de)(de)(de) API，而 JMS 則提供同(tong)樣(yang)與(yu)廠商無(wu)關(guan)的(de)(de)(de)訪(fang)(fang)問(wen)方法，以訪(fang)(fang)問(wen)消(xiao)息(xi)(xi)(xi)收發服務(wu)。許多(duo)廠商都支持(chi) JMS，包括 IBM 的(de)(de)(de) MQSeries、BEA的(de)(de)(de) Weblogic JMS service和 Progress 的(de)(de)(de) SonicMQ。 JMS 能夠通(tong)過消(xiao)息(xi)(xi)(xi)收發服務(wu)（有(you)(you)時稱為消(xiao)息(xi)(xi)(xi)中介程序(xu)或路由(you)器(qi)）從一個 JMS 客(ke)戶(hu)機向另一個 JMS客(ke)戶(hu)機發送消(xiao)息(xi)(xi)(xi)。消(xiao)息(xi)(xi)(xi)是 JMS 中的(de)(de)(de)一種(zhong)類型(xing)對象，由(you)兩部(bu)分(fen)組(zu)成：報頭和消(xiao)息(xi)(xi)(xi)主體。報頭由(you)路由(you)信息(xi)(xi)(xi)以及有(you)(you)關(guan)該消(xiao)息(xi)(xi)(xi)的(de)(de)(de)元數(shu)據(ju)(ju)組(zu)成。消(xiao)息(xi)(xi)(xi)主體則攜帶(dai)著(zhu)應用(yong)程序(xu)的(de)(de)(de)數(shu)據(ju)(ju)或有(you)(you)效(xiao)負(fu)載。根據(ju)(ju)有(you)(you)效(xiao)負(fu)載的(de)(de)(de)類型(xing)來劃分(fen)，可(ke)以將消(xiao)息(xi)(xi)(xi)分(fen)為幾(ji)種(zhong)類型(xing)，它(ta)們分(fen)別攜帶(dai)：簡單文本（TextMessage）、可(ke)序(xu)列化的(de)(de)(de)對象 （ObjectMessage）、屬(shu)性集合 （MapMessage）、字節流 （BytesMessage）、原始值流 （StreamMessage），還有(you)(you)無(wu)有(you)(you)效(xiao)負(fu)載的(de)(de)(de)消(xiao)息(xi)(xi)(xi) （Message）。
物聯網協議對比：
協議應用的側重方向
MQTT、 DDS、 AMQP、XMPP、 JMS、 REST、 CoAP這幾種(zhong)協議都已被廣泛應(ying)用，并且(qie)每種(zhong)協議都有(you)至少10種(zhong)以上的代碼實(shi)(shi)現，都宣稱(cheng)支持實(shi)(shi)時的發布/訂閱的物聯網協議，但是在(zai)具(ju)體物聯網系統架構(gou)設(she)計時，需(xu)考慮實(shi)(shi)際場景的通(tong)信需(xu)求，選(xuan)擇合(he)適的協議。
以(yi)(yi)智能家(jia)居為例，說(shuo)明下(xia)這些協議側重應(ying)用方(fang)向。智能家(jia)居中智能燈光控(kong)制(zhi)，可以(yi)(yi)使用XMPP協議控(kong)制(zhi)燈的(de)開關；智能家(jia)居的(de)電(dian)(dian)(dian)力供給，發電(dian)(dian)(dian)廠(chang)的(de)發動機組的(de)監控(kong)可以(yi)(yi)使用DDS協議；當電(dian)(dian)(dian)力輸(shu)送到(dao)千家(jia)萬戶時，電(dian)(dian)(dian)力線的(de)巡查(cha)和維護，可以(yi)(yi)使用MQTT協議；家(jia)里的(de)所有電(dian)(dian)(dian)器的(de)電(dian)(dian)(dian)量消耗，可以(yi)(yi)使用AMQP協議，傳(chuan)輸(shu)到(dao)云端或(huo)家(jia)庭網關中進(jin)行分(fen)析；最后(hou)用戶想把自家(jia)的(de)能耗查(cha)詢服(fu)務公(gong)布到(dao)互聯(lian)網上，那么可以(yi)(yi)使用REST/HTTP來開放API服(fu)務。
物聯網協議的選擇
發布/訂閱(yue)服務更(geng)適合物聯(lian)網環(huan)境(jing)下通信
DDS、MQTT、AMQP和(he)(he)JMS都是基于發布/訂閱(yue)(yue)(yue)模式，發布/訂閱(yue)(yue)(yue)框架具(ju)有(you)服務自發現、動態擴展、事件(jian)過濾的(de)特點(dian)，它解決了物(wu)聯網(wang)系統在(zai)應用層的(de)數據源快(kuai)速獲(huo)取、物(wu)的(de)加入(ru)和(he)(he)退出(chu)、興趣訂閱(yue)(yue)(yue)、降低(di)帶(dai)寬流量等(deng)問題，實現物(wu)的(de)聯接(jie)在(zai)空間(jian)上松耦合（雙方無(wu)需知道(dao)通信地址）、時間(jian)上松耦合和(he)(he)同步松耦合。
服務質量（QoS）是物聯網通信中(zhong)的重要考慮因(yin)素
在(zai)服(fu)務(wu)策略(lve)(lve)的幫助下，DDS能夠有效地控制(zhi)和管理(li)網絡帶寬、內存空(kong)間等資(zi)源(yuan)的使用(yong)，同(tong)時(shi)(shi)也能控制(zhi)數(shu)據(ju)的可靠性、實(shi)時(shi)(shi)性和數(shu)據(ju)的生存時(shi)(shi)間，通過(guo)靈活使用(yong)這些(xie)服(fu)務(wu)質量策略(lve)(lve)，DDS不僅能在(zai)窄帶的無線(xian)(xian)環境(jing)(jing)上，也能在(zai)寬帶的有線(xian)(xian)通信環境(jing)(jing)上開發出滿足實(shi)時(shi)(shi)性需(xu)求的數(shu)據(ju)分發系統(tong)。
