對(duì)于物聯(lián)網(wǎng)，最重要的是在互聯(lián)網(wǎng)中設(shè)備與設(shè)備的通訊，現(xiàn)在物聯(lián)網(wǎng)在internet通信中比較常見的通訊協(xié)議包括：HTTP、websocket、XMPP、COAP、MQTT
1、HTTP和websocket
在互聯(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é)議由于開發(fā)成本低，開放程度高，幾乎占據(jù)大半江山，所以很多廠商在構(gòu)建物聯(lián)網(wǎng)系統(tǒng)時(shí)也基于http協(xié)議進(jìn)行開發(fā)。包括google主導(dǎo)的physic web項(xiàng)目，都是期望在傳統(tǒng)web技術(shù)基礎(chǔ)上構(gòu)建物聯(lián)網(wǎng)協(xié)議標(biāo)準(zhǔn)。
HTTP協(xié)議是典型的CS通訊模式，由客戶端主動(dòng)發(fā)起連接，向服務(wù)器請(qǐng)求XML或JSON數(shù)據(jù)。該協(xié)議最早是為了適用web瀏覽器的上網(wǎng)瀏覽場景和設(shè)計(jì)的，目前在PC、手機(jī)、pad等終端上都應(yīng)用廣泛，但并不適用于物聯(lián)網(wǎng)場景。在物聯(lián)網(wǎng)場景中其有三大弊端：
1. 由于必須由設(shè)備主動(dòng)向服務(wù)器發(fā)送數(shù)據(jù)，難以主動(dòng)向設(shè)備推送數(shù)據(jù)。對(duì)于單單的數(shù)據(jù)采集等場景還勉強(qiáng)適用，但是對(duì)于頻繁的操控場景，只能推過設(shè)備定期主動(dòng)拉取的的方式，實(shí)現(xiàn)成本和實(shí)時(shí)性都大打折扣。
2. 安全性不高。web的不安全都是婦孺皆知，HTTP是明文協(xié)議，在很多要求高安全性的物聯(lián)網(wǎng)場景，如果不做很多安全準(zhǔn)備工作（如采用https等），后果不堪設(shè)想…
3. 不同于用戶交互終端如pc、手機(jī)，物聯(lián)網(wǎng)場景中的設(shè)備多樣化，對(duì)于運(yùn)算和存儲(chǔ)資源都十分受限的設(shè)備，http協(xié)議實(shí)現(xiàn)、XML/JSON數(shù)據(jù)格式的解析，都是“mission impossible”
HTTP的連接問題，HTTP客戶端和服務(wù)器之間的交互是采用請(qǐng)求/應(yīng)答模式，在客戶端請(qǐng)求時(shí)，會(huì)建立一個(gè)HTTP連接，然后發(fā)送請(qǐng)求消息，服務(wù)端給出應(yīng)答消息，然后連接就關(guān)閉了。（后來的HTTP1.1支持持久連接）
因?yàn)門CP連接的建立過程是有開銷的，如果使用了SSL/TLS開銷就更大。
在瀏覽器里，一個(gè)網(wǎng)頁包含許多資源，包括HTML，CSS，JavaScript，圖片等等，這樣在加載一個(gè)網(wǎng)頁時(shí)要同時(shí)打開連接到同一服務(wù)器的多個(gè)連接。
HTTP消息頭問題，現(xiàn)在的客戶端會(huì)發(fā)送大量的HTTP消息頭，由于一個(gè)網(wǎng)頁可能需要50-100個(gè)請(qǐng)求，就會(huì)有相當(dāng)大的消息頭的數(shù)據(jù)量。
HTTP通信方式問題，HTTP的請(qǐng)求/應(yīng)答方式的會(huì)話都是客戶端發(fā)起的，缺乏服務(wù)器通知客戶端的機(jī)制，在需要通知的場景，如聊天室，游戲，客戶端應(yīng)用需要不斷地輪詢服務(wù)器。
當(dāng)然，依然有不少廠商由于開發(fā)方便的原因，選擇基于HTTP協(xié)議構(gòu)架物聯(lián)網(wǎng)系統(tǒng)，在設(shè)備資源允許的情況下，怎么避免上面提到的數(shù)據(jù)推送實(shí)時(shí)性低的問題呢？
websocket是一個(gè)可行的辦法。websocket是HTML5提出的基于TCP之上的可支持全雙工通信的協(xié)議標(biāo)準(zhǔn)，其在設(shè)計(jì)上基本遵循HTTP的思路，對(duì)于基于HTTP協(xié)議的物聯(lián)網(wǎng)系統(tǒng)是一個(gè)很好的補(bǔ)充。
但是問題是：http+websocket的方式，協(xié)議開銷代價(jià)太大。如果讓一個(gè)單片機(jī)去實(shí)現(xiàn)這樣的協(xié)議，性能會(huì)很吃力。
2、XMPP
由于物聯(lián)網(wǎng)設(shè)備通信的模式和互聯(lián)網(wǎng)中的即時(shí)通訊應(yīng)用非常相似，互聯(lián)網(wǎng)中常用的即時(shí)通訊協(xié)議也被大量運(yùn)用于物聯(lián)網(wǎng)系統(tǒng)構(gòu)建中，這其中的典型是XMPP。
XMPP是基于XML的協(xié)議，由于其開放性和易用性，在互聯(lián)網(wǎng)及時(shí)通訊應(yīng)用中運(yùn)用廣泛。相對(duì)HTTP，XMPP在通訊的業(yè)務(wù)流程上是更適合物聯(lián)網(wǎng)系統(tǒng)的，開發(fā)者不用花太多心思去解決設(shè)備通訊時(shí)的業(yè)務(wù)通訊流程，相對(duì)開發(fā)成本會(huì)更低。但是HTTP協(xié)議中的安全性以及計(jì)算資源消耗的硬傷并沒有得到本質(zhì)的解決。前段時(shí)間報(bào)出的黑客輕松破解的TCL洗衣機(jī)，正是采用XMPP協(xié)議。
無論是HTTP、websocket還是XMPP，在設(shè)計(jì)時(shí)都是根據(jù)互聯(lián)網(wǎng)應(yīng)用場景設(shè)計(jì)的，雖然很多廠商把他們應(yīng)用在物聯(lián)網(wǎng)系統(tǒng)中，但是必然會(huì)水土不服，這些協(xié)議的通病就是根本無法適用物聯(lián)網(wǎng)設(shè)備的多樣性，無法適用很多物聯(lián)網(wǎng)設(shè)備對(duì)低功耗、低成本的需求，難以在極低資源的物聯(lián)網(wǎng)設(shè)備中運(yùn)用。能不能有協(xié)議既可以借用web技術(shù)的設(shè)計(jì)思想，同時(shí)又能適應(yīng)惡劣的物聯(lián)網(wǎng)設(shè)備運(yùn)行環(huán)境呢？
3、COAP
COAP協(xié)議的設(shè)計(jì)目標(biāo)就是在低功耗低速率的設(shè)備上實(shí)現(xiàn)物聯(lián)網(wǎng)通信。coap和HTTP協(xié)議一樣，采用URL標(biāo)示需要發(fā)送的數(shù)據(jù)，在協(xié)議格式的設(shè)計(jì)上也基本是參考HTTP協(xié)議，非常容易理解。同時(shí)做了以下幾點(diǎn)優(yōu)化：
1. 采用UDP而不是TCP。這省去了TCP建立連接的成本及協(xié)議棧的開銷。
2. 將數(shù)據(jù)包頭部都采用二進(jìn)制壓縮，減小數(shù)據(jù)量以適應(yīng)低網(wǎng)絡(luò)速率場景。
3. 發(fā)送和接收數(shù)據(jù)可以異步進(jìn)行，這樣提升了設(shè)備響應(yīng)速度。
COAP協(xié)議就像一個(gè)針對(duì)物聯(lián)網(wǎng)場景的http移植品，很多設(shè)計(jì)保留了HTTP協(xié)議的影子，擁有web背景的開發(fā)者也能快速上手。但是由于很多物聯(lián)網(wǎng)設(shè)備隱藏在局域網(wǎng)內(nèi)部，coap設(shè)備作為服務(wù)器無法被外部設(shè)備尋址，在ipv6沒有普及之前，coap只能適用于局域網(wǎng)內(nèi)部（如wifi）通信，這也很大限制了它的發(fā)展。
4、MQTT協(xié)議
MQTT協(xié)議就很好的解決了coap存在的問題。MQTT協(xié)議是由IBM開發(fā)的即時(shí)通訊協(xié)議，相比來說比較適合物聯(lián)網(wǎng)場景的通訊協(xié)議。MQTT協(xié)議采用發(fā)布/訂閱模式，所有的物聯(lián)網(wǎng)終端都通過TCP連接到云端，云端通過主題的方式管理各個(gè)設(shè)備關(guān)注的通訊內(nèi)容，負(fù)責(zé)將設(shè)備與設(shè)備之間消息的轉(zhuǎn)發(fā)。
使用發(fā)布/訂閱消息模式，提供一對(duì)多的消息發(fā)布，解除應(yīng)用程序耦合。
對(duì)負(fù)載內(nèi)容屏蔽的消息傳輸。
使用 TCP/IP 提供網(wǎng)絡(luò)連接。
有三種消息發(fā)布服務(wù)質(zhì)量：
'至多一次'，消息發(fā)布完全依賴底層 TCP/IP 網(wǎng)絡(luò)。會(huì)發(fā)生消息丟失或重復(fù)。這一級(jí)別可用于如下情況，環(huán)境傳感器數(shù)據(jù)，丟失一次讀記錄無所謂，因?yàn)椴痪煤筮€會(huì)有第二次發(fā)送。
'至少一次'，確保消息到達(dá)，但消息重復(fù)可能會(huì)發(fā)生。
'只有一次'，確保消息到達(dá)一次。這一級(jí)別可用于如下情況，在計(jì)費(fèi)系統(tǒng)中，消息重復(fù)或丟失會(huì)導(dǎo)致不正確的結(jié)果。
小型傳輸，開銷很?。ü潭ㄩL度的頭部是 2 字節(jié)），協(xié)議交換最小化，以降低網(wǎng)絡(luò)流量。
使用 Last Will 和 Testament 特性通知有關(guān)各方客戶端異常中斷的機(jī)制。
MQTT在協(xié)議設(shè)計(jì)時(shí)就考慮到不同設(shè)備的計(jì)算性能的差異，所以所有的協(xié)議都是采用二進(jìn)制格式編解碼，并且編解碼格式都非常易于開發(fā)和實(shí)現(xiàn)。最小的數(shù)據(jù)包只有2個(gè)字節(jié)，對(duì)于低功耗低速網(wǎng)絡(luò)也有很好的適應(yīng)性。有非常完善的QOS機(jī)制，根據(jù)業(yè)務(wù)場景可以選擇最多一次、至少一次、剛好一次三種消息送達(dá)模式。運(yùn)行在TCP協(xié)議之上，同時(shí)支持TLS（TCP+SSL）協(xié)議，并且由于所有數(shù)據(jù)通信都經(jīng)過云端，安全性得到了較好地保障。
當(dāng)前的物聯(lián)網(wǎng)通信協(xié)議真的是百花齊放，沒有任何協(xié)議能夠在市場上占有統(tǒng)治地位。但要實(shí)現(xiàn)物聯(lián)網(wǎng)設(shè)備互聯(lián)互通（不同廠商、不同平臺(tái)、不同架構(gòu)），關(guān)鍵點(diǎn)并不在上述接入?yún)f(xié)議或通訊協(xié)議的統(tǒng)一，而在于上層業(yè)務(wù)應(yīng)用層協(xié)議的統(tǒng)一。無論是wifi、藍(lán)牙、亦或是mqtt、http都是設(shè)備進(jìn)行數(shù)據(jù)通訊和交換的通道，規(guī)定的是通訊的格式；而通訊的內(nèi)容的統(tǒng)一才是實(shí)現(xiàn)互聯(lián)互通的關(guān)鍵。
5、DDS
DDS（Data Distribution Service for Real-Time Systems），面向?qū)崟r(shí)系統(tǒng)的數(shù)據(jù)分布服務(wù)，這是大名鼎鼎的OMG組織提出的協(xié)議，其權(quán)威性應(yīng)該能證明該協(xié)議的未來應(yīng)用前景。
適用范圍：分布式高可靠性、實(shí)時(shí)傳輸設(shè)備數(shù)據(jù)通信。目前DDS已經(jīng)廣泛應(yīng)用于國防、民航、工業(yè)控制等領(lǐng)域。
特點(diǎn)：
· 以數(shù)據(jù)為中心
· 使用無代理的發(fā)布/訂閱消息模式，點(diǎn)對(duì)點(diǎn)、點(diǎn)對(duì)多、多對(duì)多
· 提供多大21種QoS服務(wù)質(zhì)量策略
協(xié)議主要實(shí)現(xiàn)：
· OpenDDS 是一個(gè)開源的 C++ 實(shí)現(xiàn)
· OpenSplice DDS
DDS很好地支持設(shè)備之間的數(shù)據(jù)分發(fā)和設(shè)備控制，設(shè)備和云端的數(shù)據(jù)傳輸，同時(shí)DDS的數(shù)據(jù)分發(fā)的實(shí)時(shí)效率非常高，能做到秒級(jí)內(nèi)同時(shí)分發(fā)百萬條消息到眾多設(shè)備。DDS在服務(wù)質(zhì)量（QoS）上提供非常多的保障途徑，這也是它適用于國防軍事、工業(yè)控制這些高可靠性、可安全性應(yīng)用領(lǐng)域的原因。但這些應(yīng)用都工作在有線網(wǎng)絡(luò)下，在無線網(wǎng)絡(luò)，特別是資源受限的情況下，沒有見到過實(shí)施案例。
聯(lián)系客服
