為了方便，將物聯網通信協議分為兩大類，一類是接入協議，一類是通訊協議。接入協議一般負責子網內設備間的組網及通信；通訊協議主要是運行在傳統互聯網TCP/IP協議之上的設備通訊協議，負責設備通過互聯網進行數據交換及通信。本文介紹以通訊協議為主。

先說接入協議

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

一、zigbee

zigbee目前在工業控制領域應用廣泛，在智能家居領域也有一定應用。它有以下主要優勢：

1. 低成本。zigbee協議數據傳輸速率低，協議簡單，所以開發成本也比較低。并且zigbee協議還免收專利費用~

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

3. 自組網。通過zigbee協議自帶的mesh功能，一個子網絡內可以支持多達65000個節點連接，可以快速實現一個大規模的傳感網絡。

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

zigbee協議的最佳應用場景是無線傳感網絡，比如水質監測、環境控制等節點之間需要自組網傳輸數據的工業場景中。在這些場景中zigbee協議的優勢發揮的非常明顯。

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

1. 剛才提到zigbee協議有很強的自組網能力，可以支持幾萬設備，特別對于小米這種想構建智能家居生態鏈的企業，wifi和藍牙的設備連接數量目前都是硬傷。

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

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

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

相對wifi和藍牙協議這些年的快速發展和商業普及，zigbee協議盡管在技術設計和架構上擁有很大優勢，但是技術更新太慢，同時在市場推廣中也被競爭對手拉開了差距。后續zigbee協議在行業領域還是有很大空間，但是家用及消費領域要挑戰wifi及藍牙協議不是那么容易了。

二、藍牙

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

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

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

三、、wifi

wifi協議和藍牙協議一樣，目前也得到了非常大的發展。由于前幾年家用wifi路由器以及智能手機的迅速普及，wifi協議在智能家居領域也得到了廣泛應用。wifi協議最大的優勢是可以直接接入互聯網。相對于zigbee，采用wifi協議的智能家居方案省去了額外的網關，相對于藍牙協議，省去了對手機等移動終端的依賴。

相當于藍牙和zigbee，wifi協議的功耗成為其在物聯網領域應用的一大瓶頸。但是隨著現在各大芯片廠商陸續推出低功耗、低成本的wifi soc（如esp8266），這個問題也在逐漸被解決。

誰將一統江湖？

wifi協議和藍牙協議誰會在物聯網領域一統江湖？這是目前討論比較多的一個話題。wifi和藍牙的各自在技術的優勢雙方都可以在協議升級的過程中互相完善，目前兩個協議都在往“各取所長”的方向發展。最終誰能占據主導，可能更重要的是商業力量和市場決定的。短期內各個協議肯定是適用不同的場景，都有存在的價值。

再說通訊協議

對于物聯網，最重要的是在互聯網中設備與設備的通訊，現在物聯網在internet通信中比較常見的通訊協議包括：HTTP、websocket、XMPP、COAP、MQTT

1、HTTP和websocket

在互聯網時代，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數據格式的解析，都是“mission impossible”

所以，攀多物聯團隊在設計物聯網云平臺時，也只是在針對手機或PC的用戶時，采用HTTP協議，針對設備的物聯網接入沒有采用HTTP協議。

當然，依然有不少廠商由于開發方便的原因，選擇基于HTTP協議構架物聯網系統，在設備資源允許的情況下，怎么避免上面提到的數據推送實時性低的問題呢？

websocket是一個可行的辦法。websocket是HTML5提出的基于TCP之上的可支持全雙工通信的協議標準，其在設計上基本遵循HTTP的思路，對于基于HTTP協議的物聯網系統是一個很好的補充。

2、XMPP

由于物聯網設備通信的模式和互聯網中的即時通訊應用非常相似，互聯網中常用的即時通訊協議也被大量運用于物聯網系統構建中，這其中的典型是XMPP。

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

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

COAP協議應運而生了。

3、COAP

COAP協議的設計目標就是在低功耗低速率的設備上實現物聯網通信。coap和HTTP協議一樣，采用URL標示需要發送的數據，在協議格式的設計上也基本是參考HTTP協議，非常容易理解。同時做了以下幾點優化：

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

2. 將數據包頭部都采用二進制壓縮，減小數據量以適應低網絡速率場景。

3. 發送和接收數據可以異步進行，這樣提升了設備響應速度。

COAP協議就像一個針對物聯網場景的http移植品，很多設計保留了HTTP協議的影子，擁有web背景的開發者也能快速上手。但是由于很多物聯網設備隱藏在局域網內部，coap設備作為服務器無法被外部設備尋址，在ipv6沒有普及之前，coap只能適用于局域網內部（如wifi）通信，這也很大限制了它的發展。

4、MQTT協議

MQTT協議就很好的解決了coap存在的問題。MQTT協議是由IBM開發的即時通訊協議，相比來說比較適合物聯網場景的通訊協議。MQTT協議采用發布/訂閱模式，所有的物聯網終端都通過TCP連接到云端，云端通過主題的方式管理各個設備關注的通訊內容，負責將設備與設備之間消息的轉發。

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

當前的物聯網通信協議真的是百花齊放，沒有任何協議能夠在市場上占有統治地位。但要實現物聯網設備互聯互通（不同廠商、不同平臺、不同架構），關鍵點并不在上述接入協議或通訊協議的統一，而在于上層業務應用層協議的統一。無論是wifi、藍牙、亦或是mqtt、http都是設備進行數據通訊和交換的通道，規定的是通訊的格式；而通訊的內容的統一才是實現互聯互通的關鍵。

5、DDS

DDS（Data Distribution Service for Real-Time Systems），面向實時系統的數據分布服務，這是大名鼎鼎的OMG組織提出的協議，其權威性應該能證明該協議的未來應用前景。

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

特點：

• 以數據為中心

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

• 提供多大21種QoS服務質量策略

協議主要實現：

• OpenDDS 是一個開源的 C++ 實現

• OpenSplice DDS

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