為了方便，將物聯(lián)網(wǎng)通信協(xié)議分為兩大類，一類是接入?yún)f(xié)議，一類是通訊協(xié)議。接入?yún)f(xié)議一般負責子網(wǎng)內(nèi)設(shè)備間的組網(wǎng)及通信；通訊協(xié)議主要是運行在傳統(tǒng)互聯(lián)網(wǎng)TCP/IP協(xié)議之上的設(shè)備通訊協(xié)議，負責設(shè)備通過互聯(lián)網(wǎng)進行數(shù)據(jù)交換及通信。本文介紹以通訊協(xié)議為主。

先說接入?yún)f(xié)議

市場上常見的有zigbee、藍牙以及wifi協(xié)議等。

一、zigbee

zigbee目前在工業(yè)控制領(lǐng)域應(yīng)用廣泛，在智能家居領(lǐng)域也有一定應(yīng)用。它有以下主要優(yōu)勢：

1. 低成本。zigbee協(xié)議數(shù)據(jù)傳輸速率低，協(xié)議簡單，所以開發(fā)成本也比較低。并且zigbee協(xié)議還免收專利費用~

2. 低功耗。由于zigbee協(xié)議傳輸速率低，節(jié)點所需的發(fā)射功率僅1mW，并采用休眠+喚醒模式，功耗極低。

3. 自組網(wǎng)。通過zigbee協(xié)議自帶的mesh功能，一個子網(wǎng)絡(luò)內(nèi)可以支持多達65000個節(jié)點連接，可以快速實現(xiàn)一個大規(guī)模的傳感網(wǎng)絡(luò)。

4. 安全性。使用crc校驗數(shù)據(jù)包的完整性，支持鑒權(quán)和認證，并且采用aes-128對傳輸數(shù)據(jù)進行加密。

zigbee協(xié)議的最佳應(yīng)用場景是無線傳感網(wǎng)絡(luò)，比如水質(zhì)監(jiān)測、環(huán)境控制等節(jié)點之間需要自組網(wǎng)傳輸數(shù)據(jù)的工業(yè)場景中。在這些場景中zigbee協(xié)議的優(yōu)勢發(fā)揮的非常明顯。

為什么廠商會拋棄使用比較廣泛的wifi及藍牙協(xié)議，而采用zigbee呢，主要有以下原因：

1. 剛才提到zigbee協(xié)議有很強的自組網(wǎng)能力，可以支持幾萬設(shè)備，特別對于小米這種想構(gòu)建智能家居生態(tài)鏈的企業(yè)，wifi和藍牙的設(shè)備連接數(shù)量目前都是硬傷。

2. 目前zigbee協(xié)議還很難輕易被破解，而其他協(xié)議在安全性上一直為人詬病。

3. 很多智能家居產(chǎn)品如門磁為了使用方便，一般采用內(nèi)置電池。此時zigbee的超低功耗大大提升了產(chǎn)品體驗。

但是zigbee協(xié)議也有不足，主要就是它雖然可以方便的組網(wǎng)但不能接入互聯(lián)網(wǎng)，所以zigbee網(wǎng)絡(luò)中必須有一個節(jié)點充當路由器的角色（比如小米智能家居套裝中的智能網(wǎng)關(guān)），這提高了成本并且增加了用戶使用門檻。同時由于zigbee協(xié)議數(shù)據(jù)傳輸速率低，對于大流量應(yīng)用如流媒體、視頻等，基本是不可能。

相對wifi和藍牙協(xié)議這些年的快速發(fā)展和商業(yè)普及，zigbee協(xié)議盡管在技術(shù)設(shè)計和架構(gòu)上擁有很大優(yōu)勢，但是技術(shù)更新太慢，同時在市場推廣中也被競爭對手拉開了差距。后續(xù)zigbee協(xié)議在行業(yè)領(lǐng)域還是有很大空間，但是家用及消費領(lǐng)域要挑戰(zhàn)wifi及藍牙協(xié)議不是那么容易了。

二、藍牙

藍牙目前已經(jīng)成為智能手機的標配通信組件，其迅速發(fā)展的原因包括：

1. 低功耗。我認為這是藍牙4.0的大殺器~使用紐扣電池的藍牙4.0設(shè)備可運行一年以上，這對不希望頻繁充電的可穿戴設(shè)備具有十分大的吸引力。

2. 智能手機的普及。近年來支持藍牙協(xié)議基本成為智能手機的標配，用戶無需購買額外的接入模塊。

三、、wifi

wifi協(xié)議和藍牙協(xié)議一樣，目前也得到了非常大的發(fā)展。由于前幾年家用wifi路由器以及智能手機的迅速普及，wifi協(xié)議在智能家居領(lǐng)域也得到了廣泛應(yīng)用。wifi協(xié)議最大的優(yōu)勢是可以直接接入互聯(lián)網(wǎng)。相對于zigbee，采用wifi協(xié)議的智能家居方案省去了額外的網(wǎng)關(guān)，相對于藍牙協(xié)議，省去了對手機等移動終端的依賴。

相當于藍牙和zigbee，wifi協(xié)議的功耗成為其在物聯(lián)網(wǎng)領(lǐng)域應(yīng)用的一大瓶頸。但是隨著現(xiàn)在各大芯片廠商陸續(xù)推出低功耗、低成本的wifi soc（如esp8266），這個問題也在逐漸被解決。

誰將一統(tǒng)江湖？

wifi協(xié)議和藍牙協(xié)議誰會在物聯(lián)網(wǎng)領(lǐng)域一統(tǒng)江湖？這是目前討論比較多的一個話題。wifi和藍牙的各自在技術(shù)的優(yōu)勢雙方都可以在協(xié)議升級的過程中互相完善，目前兩個協(xié)議都在往“各取所長”的方向發(fā)展。最終誰能占據(jù)主導，可能更重要的是商業(yè)力量和市場決定的。短期內(nèi)各個協(xié)議肯定是適用不同的場景，都有存在的價值。

再說通訊協(xié)議

對于物聯(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)時代，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)之上。在當前的互聯(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技術(shù)基礎(chǔ)上構(gòu)建物聯(lián)網(wǎng)協(xié)議標準。

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

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

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

3. 不同于用戶交互終端如pc、手機，物聯(lián)網(wǎng)場景中的設(shè)備多樣化，對于運算和存儲資源都十分受限的設(shè)備，http協(xié)議實現(xiàn)、XML/JSON數(shù)據(jù)格式的解析，都是“mission impossible”

所以，攀多物聯(lián)團隊在設(shè)計物聯(lián)網(wǎng)云平臺時，也只是在針對手機或PC的用戶時，采用HTTP協(xié)議，針對設(shè)備的物聯(lián)網(wǎng)接入沒有采用HTTP協(xié)議。

當然，依然有不少廠商由于開發(fā)方便的原因，選擇基于HTTP協(xié)議構(gòu)架物聯(lián)網(wǎng)系統(tǒng)，在設(shè)備資源允許的情況下，怎么避免上面提到的數(shù)據(jù)推送實時性低的問題呢？

websocket是一個可行的辦法。websocket是HTML5提出的基于TCP之上的可支持全雙工通信的協(xié)議標準，其在設(shè)計上基本遵循HTTP的思路，對于基于HTTP協(xié)議的物聯(lián)網(wǎng)系統(tǒng)是一個很好的補充。

2、XMPP

由于物聯(lián)網(wǎng)設(shè)備通信的模式和互聯(lián)網(wǎng)中的即時通訊應(yīng)用非常相似，互聯(lián)網(wǎng)中常用的即時通訊協(xié)議也被大量運用于物聯(lián)網(wǎng)系統(tǒng)構(gòu)建中，這其中的典型是XMPP。

XMPP是基于XML的協(xié)議，由于其開放性和易用性，在互聯(lián)網(wǎng)及時通訊應(yīng)用中運用廣泛。相對HTTP，XMPP在通訊的業(yè)務(wù)流程上是更適合物聯(lián)網(wǎng)系統(tǒng)的，開發(fā)者不用花太多心思去解決設(shè)備通訊時的業(yè)務(wù)通訊流程，相對開發(fā)成本會更低。但是HTTP協(xié)議中的安全性以及計算資源消耗的硬傷并沒有得到本質(zhì)的解決。前段時間報出的黑客輕松破解的TCL洗衣機，正是采用XMPP協(xié)議。

無論是HTTP、websocket還是XMPP，在設(shè)計時都是根據(jù)互聯(lián)網(wǎng)應(yīng)用場景設(shè)計的，雖然很多廠商把他們應(yīng)用在物聯(lián)網(wǎng)系統(tǒng)中，但是必然會水土不服，這些協(xié)議的通病就是根本無法適用物聯(lián)網(wǎng)設(shè)備的多樣性，無法適用很多物聯(lián)網(wǎng)設(shè)備對低功耗、低成本的需求，難以在極低資源的物聯(lián)網(wǎng)設(shè)備中運用。能不能有協(xié)議既可以借用web技術(shù)的設(shè)計思想，同時又能適應(yīng)惡劣的物聯(lián)網(wǎng)設(shè)備運行環(huán)境呢？

COAP協(xié)議應(yīng)運而生了。

3、COAP

COAP協(xié)議的設(shè)計目標就是在低功耗低速率的設(shè)備上實現(xiàn)物聯(lián)網(wǎng)通信。coap和HTTP協(xié)議一樣，采用URL標示需要發(fā)送的數(shù)據(jù)，在協(xié)議格式的設(shè)計上也基本是參考HTTP協(xié)議，非常容易理解。同時做了以下幾點優(yōu)化：

1. 采用UDP而不是TCP。這省去了TCP建立連接的成本及協(xié)議棧的開銷。

2. 將數(shù)據(jù)包頭部都采用二進制壓縮，減小數(shù)據(jù)量以適應(yīng)低網(wǎng)絡(luò)速率場景。

3. 發(fā)送和接收數(shù)據(jù)可以異步進行，這樣提升了設(shè)備響應(yīng)速度。

COAP協(xié)議就像一個針對物聯(lián)網(wǎng)場景的http移植品，很多設(shè)計保留了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ā)的即時通訊協(xié)議，相比來說比較適合物聯(lián)網(wǎng)場景的通訊協(xié)議。MQTT協(xié)議采用發(fā)布/訂閱模式，所有的物聯(lián)網(wǎng)終端都通過TCP連接到云端，云端通過主題的方式管理各個設(shè)備關(guān)注的通訊內(nèi)容，負責將設(shè)備與設(shè)備之間消息的轉(zhuǎn)發(fā)。

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

當前的物聯(lián)網(wǎng)通信協(xié)議真的是百花齊放，沒有任何協(xié)議能夠在市場上占有統(tǒng)治地位。但要實現(xiàn)物聯(lián)網(wǎng)設(shè)備互聯(lián)互通（不同廠商、不同平臺、不同架構(gòu)），關(guān)鍵點并不在上述接入?yún)f(xié)議或通訊協(xié)議的統(tǒng)一，而在于上層業(yè)務(wù)應(yīng)用層協(xié)議的統(tǒng)一。無論是wifi、藍牙、亦或是mqtt、http都是設(shè)備進行數(shù)據(jù)通訊和交換的通道，規(guī)定的是通訊的格式；而通訊的內(nèi)容的統(tǒng)一才是實現(xiàn)互聯(lián)互通的關(guān)鍵。

5、DDS

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

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

特點：

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

• 使用無代理的發(fā)布/訂閱消息模式，點對點、點對多、多對多

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

協(xié)議主要實現(xiàn)：

• OpenDDS 是一個開源的 C++ 實現(xiàn)

• OpenSplice DDS

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