網際網路協議棧

網際網路是所有網路裝置的總和， 用來將 IP 包從源路由到目的地。 相比之下， Web只是一個在網際網路上執行的應用系統。 網路是一個交流資訊工具。

相對而言， 物聯網是讓電子裝置通過網際網路交換資訊。 但是這些裝置還不能像瀏覽器和社交媒體那樣來促進交流。 物聯網也不同於網路，因為物聯網裝置為了協同工作所需要的速度、規模和功能不同於網際網路， 需求千姿百態，這也是物聯網定義難以明確的原因之一。

協議棧是網際網路和網路的核心，離不開OSI七層開放系統互連的表示。

我們需要從IoT的角度來快速理解一下OSI層。

下三層：物理層、資料鏈路層 和網路層

網際網路中常用的物理層和資料鏈路層協議有：

Ethernet （10 Mbps， 100 Mbps， 1 Gbps）

Wi-Fi （802.11b/g/n）

點對點協議（PPP）

GSM， 3G， 4G， LTE 3G， 4G， LTE

但是對IoT而言，採用的無線協議更加豐富，例如 802.15.*等，甚至都會網路乃至其他廣域網的相關協議也紛紛被引入。

網路層是網際網路生存的地方。 網際網路之所以被命名， 是因為它提供了網路之間、物理層之間的連線。 這就是我們找到無處不在 IP 地址的地方。

傳輸層

在 IP 之上， 網際網路有兩個傳輸協議——TCP和UDP。 TCP 用於網路中的互動（電子郵件、網頁瀏覽等） ， 甚至被認為 是傳輸層中唯一的協議。 TCP 提供了邏輯連線的概念， 傳輸包的確認， 丟失資料包的重傳， 以及流量控制。 但是對於IoT系統而言， TCP 可能有點重。 因此， 儘管 UDP 長期以來一直被降級到DNS和 DHCP等網路服務， 現在已經在感測器採集和遠端控制領域佔據了一席之地。 如果需要對資料進行某種型別的管理， 甚至可以在 UDP 之上編寫自己的輕量級協議， 以避免 TCP的開銷。

對於語音和視訊等實時資料應用， UDP 比 TCP 可能更適合。 TCP 的資料包確認和重傳功能對於這些應用可能是無用的開銷。 如果一段資料（比如一段口語音訊）沒有及時到達目的地， 那麼重新傳輸資料包可能意義不大。有時選擇TCP是因為它提供了一個持久的連線。 為了實現類似的功能， 必須在 UDP 上面的協議層中實現該特性。

當決定如何將資料從“事物”本地網路轉移到一個 IP 網路時， 可以通過閘道器將兩個網路連線起來， 或者可以把這個功能構建在“事物”本身上。 許多微控制器（MCUs）現在都有一個乙太網控制器， 這使得這個任務更加容易。

用於物聯網的無線協議

雖然大部分物聯網依賴於傳統的嵌入式開發技術， 但是對始終擁有對連線性的需求，這要求我們不僅對無線方法做出選擇， 還要選擇相應的通訊協議。 因此， 不同的協議都在試圖建立為從邊緣節點向雲服務提供資料通訊的基礎。 每種協議都希望被看作是對某些型別的資料或資料交換方法的最佳選擇。

從計算機網路演進的IoT無線協議

Nest Labs 在智慧恆溫器和煙霧探測器產品中使用了Thread Group 協議， 在2015年被谷歌收購併獲得了迅速的發展。 隨著合作伙伴和使用者群體的不斷增長， Thread Group的潛力使其成為 ZigBee、 Z-Wave 和低耗電藍芽（BLE）等技術的可行替代品。 其成功的主要原因是谷歌沒有開發一個全新的協議， 而是把它建立在 IEEE 802.15.4無線標準的基礎上。

Thread Group的目標是家用電器、接入和氣候控制、能源管理、照明、安全等。

BLE 可能是Thread Group 的最大競爭對手， 但是 BLE 尚不能形成一個自我修復的網路， 而這個網路正逐漸成為物聯網應用的先決條件。 可靠性是基於感測器任何形式通訊的關鍵， 如恆溫器、安全警報器， 當然也適用於安全第一的工業應用。儘管如此， BLE 當然還沒有退出物聯網的協議競爭。受益於多年來不斷增強的功能， 現在一些藍芽技術聯盟（藍芽 SIG）的參與者， 如 Broadcom、 Qualcomm 和其他行業領導者， 正在努力提高 BLE 的能力， 使其適用於物聯網應用。

藍芽 SIG 也為連線網際網路鋪平了道路，推出了藍芽智慧網路工作組（目前已有80多家公司支援該工作組） ， 目標是建立標準化藍芽網路網路的架構。

IPv6， IEEE 802.15.4， 以及一個叫做 IPv6的個人區域網路相對於Thread Group、 ZigBee 和 Z-Wave 所使用的低功耗無線個人區域網（6LoWPAN）的是互補的， 因為後兩種網路是明確為處理能力有限、資料率低、射頻輸出功率極低、電源或電池耗電量極低的裝置。 這將使裝置和網路設計相對簡單， 成本效益較高。

由於 Thread 的低延遲（通常為100毫秒， 一般比 Wi-Fi 要少得一些）特性 ， 它可以在一個網路上容納300個裝置， 提供 AES 128位的安全性， 以及一個網狀網路方法將其定位為適合在物聯網應用中使用的協議。 但是， 沒有證據表明 Thread 將成為物聯網連線的主導者。 隨著物聯網的增長 ， 很多協議顯然要建立自己的空間， 也許在特定的應用程式中找準自己的位置。

遠距離的IoT無線協議

LPWAN技術是為了滿足物聯網需求應運而生的遠距離無線通訊技術。

對於電信運營商而言，車聯網、智慧醫療、智慧家居等物聯網應用將產生海量連線，遠遠超過人與人之間的通訊需求。基於蜂窩的窄帶物聯網（Narrow Band Internet of Things， NB-IoT）成為萬物網際網路絡的一個重要分支。NB-IoT構建於蜂窩網路，只消耗大約180KHz的頻寬，可直接部署於GSM網路、UMTS網路或LTE網路，以降低部署成本、實現平滑升級。

NB-IOT聚焦於低功耗廣覆蓋（LPWA）物聯網（IOT）市場，是一種可在全球範圍內廣泛應用的新興技術。其具有覆蓋廣、連線多、速率低、成本低、功耗低、架構優等特點。NB-IOT使用授權頻段，可採取帶內、保護帶或獨立載波三種部署方式，與現有網路共存。

在非授權頻段，也有應用於IoT的相關無線協議。對應於NB-IoT，LP-WAN在非授權頻譜中的協議主要有LoRa、SigFox等技術。網路部署拓撲佈局可以根據具體應用和和場景設計部署方案。 例如，LoRa適合於通訊頻次低，資料量不大的應用。

其他的那些常見協議

那麼 zigbee / zigbee Pro， Z-Wave， AllJoyn， CSR Mesh， 和 IoTIvity 那些協議是怎樣的呢？

Zigbee 3.0在2.4 GHz 的頻率執行， 最大資料速率為250千兆位元， 已經獲得了大約400個供應商的廣泛支援， 並且可以使用一個完善的網路協議支援數以千計的節點。 它的連結距離約為100英尺， 支援 IPv6， 並提供128位的 AES 加密安全。 這個最新版本包含了多年來所有過往的ZigBee 應用配置， ZigBee 聯盟因此受到了批評。

和 ZigBee 一樣， ZigBee Pro 是一個相對較新的規範。 這種網格網路協議顯然對物聯網進行了優化， 它不僅可以在2.4 GHz 頻譜上執行， 而且可以在800-900 MHz 無需授權的頻譜中執行。 使用擴頻調製方法， 可以超過16個通道， 除廣播傳輸選項外， 還支援星狀拓撲。 和大多數物聯網節點應用一樣， 節約能源是首要考慮因素， 因此協議滿足通過各種機電、光或運動方法獲取能量的無電池的裝置。

與此同時， Z-Wave 只在800-900 MHz 頻帶上執行，仍然得到了超過375個組織的支援。

在 Linux 基金會內部， 有 AllJoyn 框架的 AllSeen 聯盟。 Alljoyn 是一個開源、協作軟體框架， 允許開發者為物聯網編寫應用程式， 無論品牌、類別、傳輸媒介和作業系統， 都可以為物聯網編寫應用程式， 而無需使用雲端計算， 甚至不需要網際網路（但這兩者都得到了支援）。 它支援 Wi-Fi、乙太網、串列埠乃至電力線傳輸媒體。 支援的作業系統包括 RTOS， Arduino， Linux， Android， iOS， Windows 和 Mac。 該框架同樣使用128位 AES 加密， 目前有120多家公司支援。

另一個在 Linux 基金會內部執行的協議是 IoTIvity， 它專注於提高互操作性和定義物聯網的連線需求。 它使用一個通用的通訊框架， 管理個人計算機和新興物聯網裝置之間的資訊流， 而不考慮形式因素、作業系統或服務提供者。

可應用在物聯網中的網際網路高層協議

儘管不像新的協議那樣有效，但使用web 技術建立物聯網系統仍然是可能的。 http/https和 websocket 是常用的標準， 以及負載中的 XML或 JSON。

HTTP

Http 是 Web 客戶端-伺服器模型的基礎。 在物聯網裝置中實現 HTTP 的最安全且簡單的方法是隻包含一個客戶端， 而不是伺服器。 換句話說， 當物聯網裝置能夠啟動與網路伺服器的連線， 但無法接收連線請求時， 它會更安全; 一般不希望外部機器訪問裝有物聯網裝置的本地網路。

WebSocket

Websocket 是一個協議， 通過一個單一的 TCP 連線提供全雙工通訊， 通過這種連線可以在客戶端和伺服器之間傳送訊息。 它是HTML5規範的一部分。 Websocket 標準簡化了雙向網路通訊和連線管理的大部分複雜性。

XMPP

XMPP 是現有 Web 技術在物聯網領域中應用的一個好例子。Xmpp 的根源在於即時通訊和儲存資訊， 並且已經擴充套件到語音和視訊通話、協作、輕量級中介軟體、內容聚合和 XML 資料的廣義路由。 它能夠大規模管理消費者產品，如洗衣機、烘乾機、冰箱等等。

XMPP 的優勢在於地址、安全性和可伸縮性，成為面向消費者物聯網應用的良好選擇之一。

HTTP， WebSocket， 和XMPP 只是其中的一些例子，很多組織也在努力尋找解決物聯網新挑戰的解決方案。

面向物聯網的高層協議

許多物聯網專家把物聯網裝置稱為受限系統， 因為物聯網裝置應該儘可能的便宜， 並且執行協議棧的同時使用最小能力的MCU。

如果系統不需要 TCP 的特性， 並且可以使用更有限的 UDP 功能， 那麼刪除 TCP 模組將大大減少產品的總程式碼量， 這就是 6LoWPAN 和 CoAP 在物聯網領域的應用。

CoAP

雖然網路基礎設施對物聯網裝置來說是可用的， 但是對於大多數物聯網應用來說還是太重了。 2013年7月， IETF 釋出了 CoAP， 用於低功耗節點網路。 與 HTTP 一樣， CoAP 也具有 RESTful操作資源和資源識別符號的能力。

CoAP 與 HTTP 語義對齊， 甚至有一對一的 HTTP 對映。 網路裝置受到較小的MCU約束， 只有少量的快閃記憶體和 RAM， 而對區域性網路的限制是高資料包錯誤率和低吞吐量（幾十kb/秒）。 對於在電池或能量採集元件上執行的裝置來說， CoAP 是一個很好的協議。

CoAP 的特點：

由於 CoAP 使用 UDP， 一些 TCP 功能在 CoAP 中被直接複製。 例如， CoAP 區分了可確認（需要確認）和非確認訊息

請求和響應在 CoAP 訊息上非同步交換（與使用現有 TCP 連線的 HTTP 不同）

所有的標題、方法和狀態程式碼都是二進位制編碼， 可以減少協定開銷。 然而， 這需要使用協議分析器來debug網路問題。

充分考慮到這是一種極其輕微的協議， 其行為類似於永久連線。 它對 HTTP 語義很類似， 並且是 RESTful 的。 如果有網路程式設計背景， 使用 CoAP 是相對容易的。

MQTT

MQTT是針對受限裝置和低頻寬、高延遲或不可靠網路開發和優化的開源協議。 它是一種釋出/訂閱傳輸模型， 非常輕便， 非常適合將小型裝置與頻寬小的網路連線起來。 MQTT 是頻寬效率高、資料不可知的， 並且在使用 TCP 時具有連續的會話意圖。 其目的是儘量減少裝置所需資源， 同時努力確保服務等級的可靠性和某種程度上的保證。

MQTT的目標是小型裝置的大型網路， 這些裝置需要在網際網路的後端伺服器上進行監控。 它不是為裝置間傳輸設計的， 也不是為許多接收機“多播”資料而設計的。 使用MQTT的應用程式有時是緩慢的， 因為在這種情況下，“實時”的定義通常以秒計量。

MQTT 與 CoAP 的簡要對比

MQTT 的釋出/訂閱模型很好， 這種體系結構的優點已經得到證明。 在 IETF 最新的RFC中， CoAP 引入了對釋出/訂閱的支援。CoAP 的輕型有效負載非常適合無線感測器網路。感測器MQTT網路已經採納並複製了這個想法。

兩個主要的物聯網專用協議互相借鑑。 但這兩個協議是否是主流？ 尚需時間檢驗。

物聯網協議的選擇

連線感測器和事物物件打開了一個全新的世界， 這些應用場景將決定何時為應用使用怎樣的協議。

這些協議的層位置都是相似的。 除了 HTTP 之外， 所有這些協議都被定位為實時釋出/訂閱的物聯網協議， 支援數百萬的裝置。 根據如何定義“實時”（秒、毫秒或微秒）和“事物”（WSN 節點、多媒體裝置、個人可穿戴裝置、醫療掃描器、引擎控制等） ， 對產品的協議選擇至關重要。 從根本上講， 這些協議是非常不同的。

在設計系統時， 需要做的是非常精確地定義系統需求， 並選擇正確的協議來解決問題。 網路協議是一個載體，可以像Web 一樣封裝物聯網的許多協議。

一旦協議或協議集被認為滿足應用的部署、管理和支援， 就應該理解每個協議的最佳實現。 鑑於此， 設計需要為系統選擇每個協議的最佳實現， 然後從這些協議中選擇系統的最佳協議實現。

協議選擇問題與協議的實現密切相關， 而支援協議的元件在最終設計中往往是必不可少的。 這使得這個決定非常複雜。 部署、操作、管理和安全的所有方面都必須被視為包括實現環境在內的協議選擇因素。

為了滿足具有少記憶體、低頻寬、高延遲的物聯網裝置的需求，面向網際網路的物聯網協議已有很多。 

此外， 對於特定的應用程式沒有任何統一的標準， 這些標準通常是由市場選擇的。 作為一個開發者， 利用環境的特定特性， 滿足系統的要求， 這反過來又依賴於協議的細節， 應對未來的變化會變得非常困難。

協議棧的選擇與供應商的關係

物聯網的高階協議具有多種特點， 提供了不同的功能。 大多數協議是由特定的供應商開發的， 這些供應商通常會推廣自己的協議選擇， 沒有明確地定義他們的假設， 而且忽略了其他的替代方案。 由於這個原因， 依靠供應商資訊來選擇物聯網協議是有問題的， 而且大多數已經產生的比較都不足以理解權衡。

物聯網協議常常繫結到業務模型。 有時這些協議是不完整的和 / 或用於支援現有的業務模式和方法。 有些時候， 它們提供了一個更完整的解決方案， 但是對於較小的感測器來說， 資源需求是不可接受的。 此外， 沒有明確說明使用議定書背後的關鍵假設， 因此難以進行比較。

物聯網應用的基本假設如下：

將使用各種無線連線

裝置從微型微控制器到高效能系統都有， 重點是小型的 MCU

安全是核心要求

資料將儲存在雲中， 並可能在雲中處理

需要將連線到雲端儲存

需要通過無線和有線連線將資訊傳送到雲端儲存中

其他假設需要更深入的調查， 並將對他們的選擇需要深入瞭解。 通過檢視這些協議的主要特點， 並審視關鍵的實現要求， 設計者可以更清楚地瞭解在協議領域和支援特性領域需要什麼， 以改進其設計。

協議選擇中的關鍵特性

物聯網通訊是基於 Internet tcp / udp 協議和相關的網際網路協議。 對於基本的通訊， 這意味著要麼 UDP 資料包的 TCP 流套接字。 小型裝置的開發者聲稱 UDP 在效能和尺寸方面有很大的優勢， 這反過來會減少成本。 雖然這是真的， 但在很多情況下它並不重要。

儘管Stream Socket 受到效能的影響， 但它們確實保證了所有資料的有序傳輸。 在167mhz 的 STM32F4上傳輸感測器資料的效能受到影響， 不到16.7% （用2kb 的資料包測量）。 通過採用流套接字的方法， 也可以使用標準安全協議來簡化環境（儘管如果可用的話， DTLS 可以與 UDP 一起使用）。

類似地， 增加20 KB 的快閃記憶體和8kb 記憶體升級到 TCP 的記憶體成本差異通常很小。 對於大量的微型應用和感測器來說， 這可能是有意義的， 但通常不會影響 ARM Cortex-M3的設計， 也不會影響其他架構， 如 RX， PIC32和 ARM Cortex-Ax。

訊息模型

資訊傳遞通用物聯網的方法非常重要， 許多協議已經遷移到一個釋出/訂閱模型。 由於許多節點連線和斷開， 而且這些節點需要連線到雲中的各種應用程式， 因此， 釋出/訂閱請求 / 響應模型具有優勢。 它對隨機的開/關操作作出動態響應， 並能支援多節點。

CoAP 和 HTTP都是基於請求響應的，而沒采用釋出/訂閱方法（CoAP在新的RFC中已引入）。 在 CoAP 的情況下， 使用6LoWPAN 和IPv6的自動地址被用來唯一地識別節點。 在HTTP的例子中， 這種方法是不同的， 因為請求可以是任何東西， 包括髮布請求或者訂閱請求， 所以事實上，這種方式的設計是一般情況。 今天， 這些協議被合併以提供一個完整的釋出/訂閱請求 / 響應模型。

拓撲架構

系統架構是多種多樣的， 包括CS、樹或星、匯流排和 P2P。 大多數人使用CS， 但也有人使用匯流排和 P2P 方法。 星狀結構是一種樹的方法。 對於這些拓撲架構， 效能問題通常存在於 P2P 和匯流排體系結構中。 模擬或原型方法在設計的早期需被採納， 以防止意外發生。

可伸縮性

可伸縮性取決於在欄位中新增多個節點， 並增加雲資源以服務這些新的節點。 不同的架構有不同的特性，對於客戶端伺服器架構來說， 增加可用伺服器的池是容易的。 對於匯流排和 P2P 架構， 規模在架構中是固有的， 但是沒有云服務。 對於與樹或星相連線的架構來說， 可能存在與在樹上增加額外的葉子有關的問題， 這會加重通訊節點的負擔。

可伸縮性的另一個方面是處理大量不斷變化的節點， 並將這些節點與雲應用程式聯絡起來。 正如所討論的， 釋出/訂閱請求 / 響應系統是為了可伸縮性， 因為需要處理出於各種原因離線的節點， 這些節點允許應用在決定訂閱和請求資料時接收特定資料， 從而實現精細的資料流量控制。 不健壯的方法也不能很好地擴充套件。

自修復性

低功耗和無損網路是有節點層級移動的。 這種動態行為可能會影響網路的整體， 所以協議是為多路徑動態重構設計的。 在 ZigBee、 ZigBee IP （使用6LoWPAN）和 6LoWPAN 中發現的動態路由協議確保了網路的適應性。 如果沒有這些特性， 處理這些節點就會變成一個不連續的操作， 使得節點的資源需求更高。

資源需求

隨著應用數量的增加， 資源需求是關鍵。 微控制器以非常低的成本處理上面列出的問題。 有些協議過於資源密集， 不適用於小的節點。 除非包括大量的快閃記憶體或其他儲存介質， 否則不連續操作和大資料儲存將受到限制。 隨著資源的增加， 為了減少整個系統的成本， 可能需要新增聚合節點，來提供額外的共享儲存資源。

互操作性

互操作性對於未來的大多數裝置來說是必不可少的。 迄今為止， 已經看到了一系列的點解決方案， 但終端使用者希望感測器和裝置能夠協同工作。 通過使用一套標準化的協議和標準化的訊息， 裝置可以與支援它們的雲服務分開。 這種方法可以提供完整的裝置互操作性。 此外， 使用智慧釋出/訂閱選項， 不同的裝置甚至可以使用相同的雲服務， 並提供不同的功能。 使用開放的方法， 應用標準將會出現， 但目前還沒有。

安全性

使用標準資訊保安解決方案是大多數提供安全性的協議核心安全機制。 這些安全辦法的基礎是：

TLS

PSec/VPN

SSH

SFTP

SecurebootloaderandautomaTIcfallback

Filtering

HTTPS

SNMPv3

Encryptionanddecryption

DTLS（forUDP-onlysecurity）

由於這些技術已使用多年， 因此將安全作為一攬子計劃的一部分至關重要。

協議選擇時的實施考量

隱私是一個必不可少的實現要求，幾乎所有系統都需要對雲進行安全通訊， 以確保個人資料無法被訪問或修改。 此外， 雲中顯示的裝置和資料的管理需要單獨管理。 如果沒有這個功能， 使用者的關鍵個人資訊就不能得到適當的保護， 任何有管理許可權的人都可以獲得。

管理平臺一般還包括：

系統初始化

遠端欄位服務選項（如欄位升級、重置為預設引數和遠端測試）

控制帳戶用途（例如帳戶禁用、帳戶啟用及帳單功能）

為防盜目的而進行控制（相當於把裝置弄壞）

考慮到這種型別的體系結構， 還有一些附加的協議和程式需要考慮：

自定義開發的雲系統管理應用程式

Snmp 管理的感測器節點集合

執行的 SQLite 來儲存和有選擇地更新資料到雲

計費是商業系統的一個重要方面。 電信運營商已經證明， 包月模式是最佳的收入選擇。 此外， 自動化服務的選擇和整合對於無縫計費也很重要。 此外， 信用卡依賴性也會產生問題， 包括超過限額的問題， 過期的信用卡和被刪除的賬戶。

使用者自服務也是實現成功的關鍵。 這包括遠端現場服務， 這樣裝置就不會返回工廠， 智慧或自動配置， 線上幫助， 社群幫助和非常直觀的產品都是關鍵。

應用整合也很重要。 如今， 點系統佔據了主導地位， 但是未來的關鍵將是使感測器可以用於使用者選擇的廣泛應用。 準確性和可靠性可以對結果應用結果產生重大影響， 一旦出現標準介面， 預計將在這一領域開展競爭。 通過伺服器的間接訪問可以確保安全性、沒有應用程式更改的進化和計費控制。

不連續的操作和大資料是緊密相連的。 隨著裝置的隨機連線和斷開， 需要為感測器儲存資料並在稍後更新雲端計算。 由於電力和成本的原因， 儲存限制是存在的。 如果某些資料是關鍵的， 它可以在其他資料被丟棄的時候被儲存。 所有的資料都可以儲存下來， 並選擇性地更新以後執行的雲。 處理資料的演算法可以執行在雲或感測器或任何中間節點。 所有這些選項都給感測器、雲、通訊和外部應用帶來了特殊的挑戰。

多連線感測器訪問也是一個需求， 使感測器真正可用於一系列廣泛的應用程式。 這種連線最有可能通過伺服器進行， 以簡化感測器並消除重複訊息的功率需求。

綜上所述，許多協議都被吹捧為物聯網（IoT）的理想解決方案。 通常正確的協議選擇會被那些在他們的產品中有既得利益的供應商所掩蓋。 使用者必須瞭解他們的具體要求和限制， 並有一個精確的系統規範， 以確保為各種管理、應用程式和通訊功能選擇正確的協議， 並確保所有的實現規範都得到滿足。