<meter id="pryje"><nav id="pryje"><delect id="pryje"></delect></nav></meter>
          <label id="pryje"></label>

          新聞中心

          EEPW首頁(yè) > 物聯(lián)網(wǎng)與傳感器 > 設(shè)計(jì)應(yīng)用 > 物聯(lián)網(wǎng)通信協(xié)議的詳解及選擇建議

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

          作者: 時(shí)間:2017-10-24 來(lái)源:網(wǎng)絡(luò) 收藏

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

          本文引用地址:http://www.ex-cimer.com/article/201710/368036.htm

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

            本文羅列下市面上,總結(jié)下它們各自特點(diǎn)、特定的物聯(lián)網(wǎng)應(yī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ú)線通信), Zigbee, 6LoWPAN(IPV6低速無(wú)線版本),Bluetooth, GSM, GPRS, GPS, 3G, 4G等網(wǎng)絡(luò),而每一種通信應(yīng)用協(xié)議都有一定適用范圍。AMQP、JMS、REST/HTTP都是工作在以太網(wǎng),COAP協(xié)議是專門(mén)為資源受限設(shè)備開(kāi)發(fā)的協(xié)議,而DDS和的兼容性則強(qiáng)很多。

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

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

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

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

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

            REST/HTTP(松耦合服務(wù)調(diào)用)

            REST (Representational State Transfer),表征狀態(tài)轉(zhuǎn)換,是基于HTTP協(xié)議開(kāi)發(fā)的一種通信風(fēng)格,目前還不是標(biāo)準(zhǔn);

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

            特點(diǎn):

            · REST 指的是一組架構(gòu)約束條件和原則。滿足這些約束條件和原則的應(yīng)用程序或設(shè)計(jì)就是RESTful

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

            · 在服務(wù)器端,應(yīng)用程序狀態(tài)和功能可以分為各種資源,它向客戶端公開(kāi)。資源的例子有:應(yīng)用程序?qū)ο?、?shù)據(jù)庫(kù)記錄、算法等等。每個(gè)資源都使用 URI (Universal Resource Identifier) 得到一個(gè)惟一的地址。所有資源都共享統(tǒng)一的界面,以便在客戶端和服務(wù)器之間傳輸狀態(tài)

            · 使用的是標(biāo)準(zhǔn)的 HTTP 方法,比如 GET、PUT、POST 和 DELETE

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

            協(xié)議

            · (Constrained Application Protocol),受限應(yīng)用協(xié)議,應(yīng)用于無(wú)線傳感網(wǎng)中協(xié)議。

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

            特點(diǎn):

            報(bào)頭壓縮:CoAP包含一個(gè)緊湊的二進(jìn)制報(bào)頭和擴(kuò)展報(bào)頭。它只有短短的4B的基本報(bào)頭,基本報(bào)頭后面跟擴(kuò)展選項(xiàng)。一個(gè)典型的請(qǐng)求報(bào)頭為10~20B。

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

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

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

            支持資源發(fā)現(xiàn):為了自主的發(fā)現(xiàn)和使用資源,它支持內(nèi)置的資源發(fā)現(xiàn)格式,用于發(fā)現(xiàn)設(shè)備上的資源列表,或者用于設(shè)備向服務(wù)目錄公告自己的資源。它支持RFC5785中的格式,在CoRE中用/.well—known/core的路徑表示資源描述。

            支持緩存:CoAP協(xié)議支持資源描述的緩存以優(yōu)化其性能。

            協(xié)議主要實(shí)現(xiàn):

            · libcoap(C語(yǔ)言實(shí)現(xiàn))

            · Californium(java語(yǔ)言實(shí)現(xiàn))

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

            協(xié)議(低帶寬)

             (Message Queuing Telemetry Transport ),消息隊(duì)列遙測(cè)傳輸,由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è)設(shè)備關(guān)注的通訊內(nèi)容,負(fù)責(zé)將設(shè)備與設(shè)備之間消息的轉(zhuǎn)發(fā)。

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

            適用范圍:在低帶寬、不可靠的網(wǎng)絡(luò)下提供基于云平臺(tái)的遠(yuǎn)程設(shè)備的數(shù)據(jù)傳輸和監(jiān)控。

            特點(diǎn):

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

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

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

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

            協(xié)議主要實(shí)現(xiàn)和應(yīng)用:

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

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

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

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

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

            DDS(Data Distribution Service for Real-Time Systems),面向?qū)崟r(shí)系統(tǒng)的數(shù)據(jù)分布服務(wù),這是大名鼎鼎的OMG組織提出的協(xié)議,其權(quán)威性應(yīng)該能證明該協(xié)議的未來(lái)應(yīng)用前景。

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

            特點(diǎn):

            · 以數(shù)據(jù)為中心

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

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

            協(xié)議主要實(shí)現(xiàn):

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

            · OpenSplice DDS

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

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

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

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

            特點(diǎn):

            · Wire級(jí)的協(xié)議,它描述了在網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)的格式,以字節(jié)為流

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

            協(xié)議實(shí)現(xiàn):

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

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

            · Apache Qpid

            · stormMQ

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

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

            適用范圍:即時(shí)通信的應(yīng)用程序,還能用在網(wǎng)絡(luò)管理、內(nèi)容供稿、協(xié)同工具、檔案共享、游戲、遠(yuǎn)端系統(tǒng)監(jiān)控等。

            特點(diǎn):

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

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

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

            · 標(biāo)準(zhǔn)通用標(biāo)記語(yǔ)言的子集XML的數(shù)據(jù)格式

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

            · JMS (Java Message Service),JAVA消息服務(wù),這是JAVA平臺(tái)中著名的消息隊(duì)列協(xié)議。

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

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

            協(xié)議應(yīng)用的側(cè)重方向

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

            以智能家居為例,說(shuō)明下這些協(xié)議側(cè)重應(yīng)用方向。智能家居中智能燈光控制,可以使用XMPP協(xié)議控制燈的開(kāi)關(guān);智能家居的電力供給,發(fā)電廠的發(fā)動(dòng)機(jī)組的監(jiān)控可以使用DDS協(xié)議;當(dāng)電力輸送到千家萬(wàn)戶時(shí),電力線的巡查和維護(hù),可以使用MQTT協(xié)議;家里的所有電器的電量消耗,可以使用AMQP協(xié)議,傳輸?shù)皆贫嘶蚣彝ゾW(wǎng)關(guān)中進(jì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ā)現(xiàn)、動(dòng)態(tài)擴(kuò)展、事件過(guò)濾的特點(diǎn),它解決了物聯(lián)網(wǎng)系統(tǒng)在應(yīng)用層的數(shù)據(jù)源快速獲取、物的加入和退出、興趣訂閱、降低帶寬流量等問(wèn)題,實(shí)現(xiàn)物的聯(lián)接在空間上松耦合(雙方無(wú)需知道通信地址)、時(shí)間上松耦合和同步松耦合。

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

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



          評(píng)論


          相關(guān)推薦

          技術(shù)專區(qū)

          關(guān)閉
          看屁屁www成人影院,亚洲人妻成人图片,亚洲精品成人午夜在线,日韩在线 欧美成人 (function(){ var bp = document.createElement('script'); var curProtocol = window.location.protocol.split(':')[0]; if (curProtocol === 'https') { bp.src = 'https://zz.bdstatic.com/linksubmit/push.js'; } else { bp.src = 'http://push.zhanzhang.baidu.com/push.js'; } var s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(bp, s); })();