使用傳感器和連接的嵌入式系統(tǒng)對開發(fā)人員來說并不陌生。但是，將這些元素與多種其他 Internet 技術(shù)結(jié)合使用是可行的?；ヂ?lián)網(wǎng)協(xié)議 （IP） 并不新鮮，但物聯(lián)網(wǎng) （IoT） 的專用 IP 卻是，它們用于幫助塑造系統(tǒng)功能。TCP/IP 套接字之上有多個 IP 應用層協(xié)議。每一種都有其優(yōu)點和限制。了解它們有助于開發(fā)人員為產(chǎn)品做出最佳設(shè)計選擇。帶寬要求、實時性能和內(nèi)存占用是選擇物聯(lián)網(wǎng)協(xié)議時的一些主要標準。許多物聯(lián)網(wǎng)項目是由首席信息官 （CIO） 和 IT 部門推動的，他們推動開發(fā)人員使用他們開發(fā)的技術(shù)和協(xié)議了解物聯(lián)網(wǎng)設(shè)備。盡管如此，物聯(lián)網(wǎng)設(shè)備往往更接近運營技術(shù)（OT），將IT技術(shù)推入OT領(lǐng)域往往不是最優(yōu)選擇。

開發(fā)人員需要了解物聯(lián)網(wǎng)設(shè)備有比 IT 技術(shù)更好的協(xié)議選項。

IP有多種類別：

消費者與工業(yè)

網(wǎng)頁服務(wù)

物聯(lián)網(wǎng)服務(wù)

發(fā)布/訂閱

請求/響應

在設(shè)計新系統(tǒng)時必須考慮這些類別。讓我們看看物聯(lián)網(wǎng)的 IP 并定義選擇標準。

互聯(lián)網(wǎng)

互聯(lián)網(wǎng)是用于將 IP 數(shù)據(jù)包從源路由到目的地的所有網(wǎng)絡(luò)設(shè)備的總和。相比之下，萬維網(wǎng)是在互聯(lián)網(wǎng)上運行的應用系統(tǒng)。Web 是為人們交換信息而構(gòu)建的工具，在過去的 20 年中，Web 得到了發(fā)展和完善，因此普通的非技術(shù)人員可以輕松高效地使用 Internet。例如，互聯(lián)網(wǎng)的人機界面現(xiàn)在包括電子郵件、搜索引擎、瀏覽器、移動應用程序、Facebook 和 Twitter，以及其他流行的社交媒體。

相比之下，在物聯(lián)網(wǎng)中，這個想法是讓電子設(shè)備通過互聯(lián)網(wǎng)交換信息。但這些設(shè)備還沒有與瀏覽器和社交媒體相當?shù)臋C器來促進交流。由于物聯(lián)網(wǎng)設(shè)備協(xié)同工作所需的速度、規(guī)模和功能，物聯(lián)網(wǎng)也不同于網(wǎng)絡(luò)。這些要求遠遠超出了人們需要或使用的范圍。我們正處于為這些系統(tǒng)開發(fā)新工具和服務(wù)的初期，這也是難以確定物聯(lián)網(wǎng)定義的原因之一。許多關(guān)于它可以、可能或應該是什么的愿景相互碰撞。

TCP/IP 協(xié)議棧

TCP/IP 協(xié)議棧是 Internet 和 Web 的核心。它可以使用七層開放系統(tǒng)互連 （OSI） 參考模型來表示，如下圖所示（圖 1）。前三層組合在一起，簡化了模型。

【圖1 | 七層 OSI 參考模型。］

以下是從嵌入式系統(tǒng)集成角度對重要 OSI 層的快速描述：

1. 物理層和數(shù)據(jù)鏈路層

嵌入式系統(tǒng)最常用的物理層協(xié)議有：

以太網(wǎng)（10 Mbps、100 Mbps、1 Gbps）

無線網(wǎng)絡(luò) （802.11b/g/n）

串行點對點協(xié)議 （PPP）

GSM、3G、4G、LTE

2.網(wǎng)絡(luò)層

這就是互聯(lián)網(wǎng)生活的地方?；ヂ?lián)網(wǎng)——inter-network 的縮寫——之所以這樣命名，是因為它提供了網(wǎng)絡(luò)之間、物理層之間的連接。這是我們找到無處不在的IP地址的地方。

3.傳輸層

在 IP 之上，我們有傳輸控制協(xié)議 （TCP） 和用戶數(shù)據(jù)報協(xié)議 （UDP），這兩個傳輸協(xié)議。由于 TCP 用于我們與 Web 的大多數(shù)人類交互（電子郵件、Web 瀏覽等），因此人們普遍認為 TCP 應該是傳輸層使用的唯一協(xié)議。TCP 提供了邏輯連接、已傳輸數(shù)據(jù)包確認、丟失數(shù)據(jù)包重傳和流量控制的概念——所有這些都是很棒的東西。但是對于嵌入式系統(tǒng)，TCP 可能是多余的。因此，UDP，即使長期以來被歸類為域名服務(wù)器 （DNS） 和動態(tài)主機配置協(xié)議 （DHCP） 等網(wǎng)絡(luò)服務(wù)，現(xiàn)在也在傳感器采集和遠程控制領(lǐng)域找到了自己的位置。如果您需要某種類型的數(shù)據(jù)管理，

對于語音和視頻等實時數(shù)據(jù)應用，UDP 也比 TCP 更適合。原因是 TCP 的數(shù)據(jù)包確認和重傳功能對于這些應用程序來說是無用的開銷。如果一段數(shù)據(jù)（例如一段語音）沒有及時到達其目的地，則重新傳輸數(shù)據(jù)包是沒有意義的，因為它會亂序到達并混淆消息。

TCP 有時比 UDP 更受歡迎，因為它提供了持久連接。要使用 UDP 啟用相同功能，您必須在 UDP 之上的協(xié)議層中實現(xiàn)此功能。

當您決定如何將數(shù)據(jù)從“事物”本地網(wǎng)絡(luò)移動到 IP 網(wǎng)絡(luò)時，您有多種選擇。因為使用的技術(shù)是熟悉的并且可以從廣泛的來源獲得，所以您可以通過網(wǎng)關(guān)鏈接兩個網(wǎng)絡(luò)，或者您可以將此功能構(gòu)建到“事物”本身中。許多微控制器 （MCU） 現(xiàn)在都具有片上以太網(wǎng)控制器，這使得這項任務(wù)變得更容易。

物聯(lián)網(wǎng)協(xié)議

使用現(xiàn)有的 Web 技術(shù)構(gòu)建物聯(lián)網(wǎng)系統(tǒng)是可能的，即使它不如新協(xié)議高效。超文本傳輸協(xié)議/安全 （HTTP/S） 和 WebSockets 以及有效負載中的可擴展標記語言 （XML） 或 JavaScript 對象表示法 （JSON） 是通用標準。當使用標準 Web 瀏覽器（HTTP 客戶端）時，JSON 為 Web 開發(fā)人員提供了一個抽象層，通過保持兩個 HTTP 連接打開，創(chuàng)建一個有狀態(tài)的 Web 應用程序，該應用程序具有到 Web 服務(wù)器（HTTP 服務(wù)器）的持久雙工連接。

HTTP

HTTP 是用于 Web 的客戶端-服務(wù)器模型的基礎(chǔ)。在 IoT 設(shè)備中實現(xiàn) HTTP 的最安全方法是僅包含客戶端，而不包含服務(wù)器。換句話說，當物聯(lián)網(wǎng)設(shè)備可以發(fā)起與 Web 服務(wù)器的連接但無法接收連接請求時，會更安全；我們不想讓外部機器訪問安裝 IoT 設(shè)備的本地網(wǎng)絡(luò)。

網(wǎng)絡(luò)套接字

WebSocket 是一種通過單個 TCP 連接提供全雙工通信的協(xié)議，通過該 TCP 連接可以在客戶端和服務(wù)器之間發(fā)送消息。它是超文本標記語言 5 （HTML5） 規(guī)范的一部分。WebSocket 標準簡化了雙向 Web 通信和連接管理的大部分復雜性。

XMPP

可擴展消息傳遞和存在協(xié)議 （XMPP） 是現(xiàn)有 Web 技術(shù)在物聯(lián)網(wǎng)領(lǐng)域找到新用途的一個很好的例子。

XMPP 起源于即時消息和狀態(tài)信息，并已擴展到語音和視頻呼叫、協(xié)作、輕量級中間件、內(nèi)容聯(lián)合和 XML 數(shù)據(jù)的通用路由。它是洗衣機、烘干機、冰箱等消費類白色家電大規(guī)模管理的有力競爭者。

XMPP 的優(yōu)勢在于其尋址、安全性和可擴展性。這使其成為面向消費者的物聯(lián)網(wǎng)應用的理想選擇。

HTTP、WebSocket 和 XMPP 是為物聯(lián)網(wǎng)服務(wù)的技術(shù)示例。其他團體也在努力為物聯(lián)網(wǎng)給我們帶來的新挑戰(zhàn)開發(fā)解決方案。

想要的通用協(xié)議

許多物聯(lián)網(wǎng)專家將物聯(lián)網(wǎng)設(shè)備稱為受限系統(tǒng)，因為他們認為物聯(lián)網(wǎng)設(shè)備應該盡可能便宜，并在運行通信堆棧的同時使用可用的最小 MCU。

目前，使互聯(lián)網(wǎng)適應物聯(lián)網(wǎng)是許多全球標準化機構(gòu)的主要優(yōu)先事項之一。表 1 包含當前活動的簡短摘要。

［表 1 | 受約束的系統(tǒng)標準化工作。］

如果您的系統(tǒng)不需要 TCP 的功能并且可以使用更有限的 UDP 功能運行，那么刪除 TCP 模塊會顯著有助于減少產(chǎn)品的總代碼占用空間的大小。這就是用于無線傳感器網(wǎng)絡(luò) （WSN） 的低功耗無線個人區(qū)域網(wǎng)絡(luò) （6LoWPAN） 的 IP 版本 6 （IPv6） 和受限應用協(xié)議 （CoAP） 輕型互聯(lián)網(wǎng)協(xié)議為物聯(lián)網(wǎng)世界帶來的內(nèi)容。

輔酶AP

盡管 Web 基礎(chǔ)架構(gòu)可用于 IoT 設(shè)備，但它對于大多數(shù) IoT 應用程序來說太重了。2013 年 7 月，互聯(lián)網(wǎng)工程任務(wù)組 （IETF） 發(fā)布了用于低功耗和有損節(jié)點和網(wǎng)絡(luò) （LLN） 的 CoAP。CoAP 與 HTTP 一樣，是一種 RESTful（通過統(tǒng)一的應用程序編程接口 （API） 操作資源和資源標識符的能力）協(xié)議。

CoAP 在語義上與 HTTP 一致，甚至具有與 HTTP 的一對一映射。網(wǎng)絡(luò)設(shè)備受到具有少量閃存和 RAM 的小型 MCU 的限制，而本地網(wǎng)絡(luò)的限制是由于高數(shù)據(jù)包錯誤率和低吞吐量（數(shù)十 kbps）。CoAP 對于使用電池或能量收集的設(shè)備來說是一個很好的協(xié)議。

CoAP的特點：

因為 CoAP 使用 UDP，所以一些 TCP 功能直接在 CoAP 中復制。例如，CoAP 區(qū)分可確認（需要確認）和不可確認消息。

請求和響應通過 CoAP 消息異步交換（與使用現(xiàn)有 TCP 連接的 HTTP 不同）。

所有的標頭、方法和狀態(tài)碼都是二進制編碼的，這減少了協(xié)議開銷。但是，這需要使用協(xié)議分析器來解決網(wǎng)絡(luò)問題。

與 HTTP 不同，緩存 CoAP 響應的能力不取決于請求方法，而是響應代碼。

CoAP 完全解決了對表現(xiàn)出類似于永久連接的行為的極輕協(xié)議的需求。它對 HTTP 語義熟悉，并且是 RESTful。如果你有網(wǎng)絡(luò)背景，使用 CoAP 相對容易。

MQTT

消息隊列遙測傳輸 （MQTT） 是一種開源協(xié)議，專為受限設(shè)備和低帶寬、高延遲或不可靠的網(wǎng)絡(luò)而開發(fā)和優(yōu)化。它是一種發(fā)布/訂閱消息傳輸，非常輕量級，非常適合以最小帶寬將小型設(shè)備連接到網(wǎng)絡(luò)。MQTT 具有帶寬效率、與數(shù)據(jù)無關(guān)，并且具有持續(xù)的會話感知能力，因為它使用 TCP。它旨在最大限度地減少設(shè)備資源需求，同時還試圖確保可靠性和一定程度的服務(wù)等級交付保證。

MQTT 針對需要從 Internet 上的后端服務(wù)器監(jiān)視或控制的小型設(shè)備的大型網(wǎng)絡(luò)。它不是為設(shè)備到設(shè)備的傳輸而設(shè)計的，也不是為將數(shù)據(jù)“多播”到許多接收器而設(shè)計的。MQTT 很簡單，提供的控制選項很少。使用 MQTT 的應用程序通常很慢，因為在這種情況下“實時”的定義通常以秒為單位。

MQTT 與 CoAP

MQTT 發(fā)布/訂閱的擴展性很好，這種架構(gòu)的優(yōu)勢已經(jīng)得到體現(xiàn)。在最新的 IETF 征求意見 （RFC） 中，CoAP 引入了對發(fā)布/訂閱的支持。

CoAP 的輕負載非常適合無線傳感器網(wǎng)絡(luò)。用于傳感器網(wǎng)絡(luò)的 MQTT （MQTT-SN） 采用了該想法并對其進行了復制。

兩個主要的專用物聯(lián)網(wǎng)協(xié)議相互借鑒。這兩種協(xié)議會保持主流嗎？我們相信，至少 5 到 10 年。

潛在物聯(lián)網(wǎng)協(xié)議的比較

思科是互聯(lián)網(wǎng)的核心；它的IP設(shè)備無處不在。思科積極參與物聯(lián)網(wǎng)的發(fā)展，并看到了連接物理對象、從我們的環(huán)境中獲取數(shù)據(jù)并處理這些數(shù)據(jù)以提高我們的生活水平的潛力（表 2）。

［表 2 | 思科在物聯(lián)網(wǎng)標準方面的工作。］

表 2 所示的特定于 Internet 的 IoT 協(xié)議的開發(fā)旨在滿足內(nèi)存量小設(shè)備以及低帶寬和高延遲網(wǎng)絡(luò)的需求。圖 2 提供了這些協(xié)議為物聯(lián)網(wǎng)帶來的性能優(yōu)勢的另一個很好的總結(jié)。

【圖2 | Web 和 IoT 協(xié)議的比較。資料來源：Zach Shelby，Micro:bit 基金會。］

選擇正確的物聯(lián)網(wǎng)協(xié)議

連接傳感器和對象開辟了一個全新的可能用例世界——正是這些用例將決定何時為正確的應用程序使用正確的協(xié)議。

這些協(xié)議中的每一個的高層定位都是相似的。除了 HTTP，所有提到的協(xié)議都被定位為支持數(shù)百萬設(shè)備的實時發(fā)布/訂閱物聯(lián)網(wǎng)協(xié)議。根據(jù)您如何定義“實時”（秒、毫秒或微秒）和“事物”（WSN 節(jié)點、多媒體設(shè)備、個人可穿戴設(shè)備、醫(yī)療掃描儀、引擎控制等），您的產(chǎn)品的協(xié)議選擇至關(guān)重要。從根本上說，這些協(xié)議非常不同。

今天，Web 運行在數(shù)百種協(xié)議上。物聯(lián)網(wǎng)將支持數(shù)百個。在設(shè)計系統(tǒng)時，您需要做的是非常精確地定義系統(tǒng)要求并選擇正確的協(xié)議集來解決它們?；ヂ?lián)網(wǎng)協(xié)議是載體；它可以為 IoT 封裝與今天為 Web 封裝的協(xié)議一樣多的協(xié)議。

許多行業(yè)專家都在要求協(xié)議標準化 但是，如果網(wǎng)絡(luò)有這么多協(xié)議，為什么物聯(lián)網(wǎng)沒有那么多呢？您選擇滿足您要求的協(xié)議。唯一的區(qū)別是物聯(lián)網(wǎng)協(xié)議還很年輕，必須證明它們的可靠性。請記住，當互聯(lián)網(wǎng)成為現(xiàn)實時，IP 版本 4 （IPv4） 使之成為可能。我們現(xiàn)在正在大規(guī)模部署 IPv6，而物聯(lián)網(wǎng)是電信運營商一直在等待證明所需投資的殺手級應用。

審核編輯：郭婷