物聯網通訊協議介紹

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

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

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

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

3. 自組網。通過zigbee協議自帶的mesh功能，乙個子網路內可以支援多達65000個節點連線，可以快速實現乙個大規模的感測網路。

4. 安全性。使用crc校驗資料報的完整性，支援鑑權和認證，並且採用aes-128對傳輸資料進行加密。

zigbee協議的最佳應用場景是無線感測網路，比如水質監測、環境控制等節點之間需要自組網傳輸資料的工業場景中。在這些場景中zigbee協議的優勢發揮的非常明顯。目前國內外很多廠商也將zigbee運用在智慧型家居方案中，比如今年年初小公尺發布的「小公尺智慧型家居套裝」。

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

1. 剛才提到zigbee協議有很強的自組網能力，可以支援幾萬裝置，特別對於小公尺這種想構建智慧型家居生態鏈的企業，wifi和藍芽的裝置連線數量目前都是硬傷。

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

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

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

藍芽目前已經成為智慧型手機的標配通訊元件，其迅速發展的原因包括：

1. 低功耗。我認為這是藍芽4.0的大殺器~使用鈕扣電池的藍芽4.0裝置可執行一年以上，這對不希望頻繁充電的可穿戴裝置具有十分大的吸引力。當前基本世面上的可穿戴裝置基本都選用藍芽4.0方案。

2. 智慧型手機的普及。近年來支援藍芽協議基本成為智慧型手機的標配，使用者無需購買額外的接入模組。

值得關注的是藍芽4.2版本近期推出，加入mesh組網功能，向zigbee發出了強有力的挑戰。

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

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

誰將一統江湖？

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

在網際網路時代，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協議的物聯網系統是乙個很好的補充。

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

coap協議應運而生了。

coap協議的設計目標就是在低功耗低速率的裝置上實現物聯網通訊。coap和http協議一樣，採用url標示需要傳送的資料，在協議格式的設計上也基本是參考http協議，非常容易理解。同時做了以下幾點優化：

1. 採用udp而不是tcp。這省去了tcp建立連線的成本及協議棧的開銷。

2. 將資料報頭部都採用二進位制壓縮，減小資料量以適應低網路速率場景。

3. 傳送和接收資料可以非同步進行，這樣提公升了裝置響應速度。

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

mqtt在協議設計時就考慮到不同裝置的計算效能的差異，所以所有的協議都是採用二進位制格式編譯碼，並且編譯碼格式都非常易於開發和實現。最小的資料報只有2個位元組，對於低功耗低速網路也有很好的適應性。有非常完善的qos機制，根據業務場景可以選擇最多一次、至少一次、剛好一次三種訊息送達模式。執行在tcp協議之上，同時支援tls（tcp+ssl）協議，並且由於所有資料通訊都經過雲端，安全性得到了較好地保障。

如果把通訊協議比作聲音，光有通訊協議，任何人之間還是無法交流。只有統一語言，大家才能順暢溝通。

**：

物聯網通訊協議介紹

物聯網通訊協議介紹

物聯網通訊協議介紹

物聯網通訊協議之MQTT

相關推薦