嵌入式系統(tǒng)接入互聯(lián)網(wǎng)形成一個物聯(lián)網(wǎng)系統(tǒng)，協(xié)議是必不可少的關(guān)鍵技術(shù)。傳統(tǒng)上以解決人機對話為目標的互聯(lián)網(wǎng)協(xié)議遇到了物物相連的物聯(lián)網(wǎng)系統(tǒng)，顯得像大馬拉小車，有勁使不上，物聯(lián)網(wǎng)協(xié)議就此應(yīng)運而生。

毫無疑問，人類和嵌入式設(shè)備通過完全不同的方式使用互聯(lián)網(wǎng)。人類主要通過萬維網(wǎng)—運行在互聯(lián)網(wǎng)上的應(yīng)用集合—訪問互聯(lián)網(wǎng)。當然，網(wǎng)頁并不是互聯(lián)網(wǎng)人機交換的唯一選擇，我們還可以通過電子郵件、短信、手機應(yīng)用程序，以及一系列的社交媒體工具實現(xiàn)互聯(lián)。

與互聯(lián)網(wǎng)相比，在物聯(lián)網(wǎng)中，智能電子設(shè)備之間通過互聯(lián)網(wǎng)實現(xiàn)信息的交互，但這些設(shè)備上并沒有類似于網(wǎng)頁瀏覽器和社交媒體的工具，人們已經(jīng)著手開發(fā)這類工具和服務(wù)。

TCP/IP協(xié)議棧

TCP/IP協(xié)議棧是互聯(lián)網(wǎng)的核心。它可以通過OSI七層參考模型來表示，如圖1所示。圖中頂部的三層組合在一起，以簡化模型。

圖1 TCP/IP協(xié)議棧參考模型

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

嵌入式系統(tǒng)中最使用的物理層協(xié)議包括：

1）以太網(wǎng)（10，100，1G）

2）WiFi（802.11b，g，n）

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

4）GSM，3G，LTE，4G

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

網(wǎng)絡(luò)層是互聯(lián)網(wǎng)的基礎(chǔ)。該層提供了網(wǎng)絡(luò)間及物理層之間的連接。該層中，設(shè)備擁有人們隨處可見的IP地址。

3. 傳輸層

該層位于網(wǎng)絡(luò)層之上，具有TCP和UDP兩種傳輸協(xié)議。

TCP通常用于網(wǎng)絡(luò)間的人機交互（電子郵件、網(wǎng)頁瀏覽等），以致很多人認為TCP協(xié)議是傳輸層使用的唯一協(xié)議。TCP提供了邏輯連接、傳輸確認、丟包重傳和流控服務(wù)。

但對嵌入式系統(tǒng)而言，使用TCP有點小題大做了。盡管長期以來，UDP主要用于類似于DNS和DHCP的網(wǎng)絡(luò)服務(wù)，現(xiàn)在，在傳感器數(shù)據(jù)采集和遠程控制領(lǐng)域，它有了新的用武之地。

UDP也適合于實時數(shù)據(jù)應(yīng)用，例如音頻和視頻應(yīng)用。這是因為，TCP的包應(yīng)答和重傳特性對這類應(yīng)用是無效的，并且增加了額外的開銷。如果一個數(shù)據(jù)塊（例如一段對話）沒有按時到達目的地，也沒有必要重傳該包。如果重傳，它會破壞包的順序并導(dǎo)致信息錯誤。

設(shè)計物聯(lián)網(wǎng)設(shè)備時，必須考慮如何將本地設(shè)備連接到互聯(lián)網(wǎng)?？梢酝ㄟ^網(wǎng)關(guān)，或者將該功能集成到設(shè)備中以實現(xiàn)連接。目前，很多MCU集成了以太網(wǎng)控制器，簡化了聯(lián)網(wǎng)的工作。

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

你可以使用熟悉的Web技術(shù)來構(gòu)建物聯(lián)網(wǎng)系統(tǒng)嗎？答案是肯定，但沒有使用新的協(xié)議有效。

HTTP（S）和WebSocket是數(shù)據(jù)負載中傳送XML或JavaScript對象符號（JSON）的常用標準。JSON為網(wǎng)頁開發(fā)人員提供了一個抽象層，可以為Web應(yīng)用創(chuàng)建一個到Web服務(wù)器的持續(xù)、穩(wěn)定的連接。

1. HTTP

HTTP是用于Web服務(wù)的客戶端–服務(wù)器模型的基礎(chǔ)。實現(xiàn)HTTP連接的安全的方式是在物聯(lián)網(wǎng)設(shè)備中只包含一個客戶端，不包含服務(wù)器。換言之，設(shè)計一個只發(fā)起連接、不接收的物聯(lián)網(wǎng)設(shè)備比較安全。總之，不允許外部設(shè)備訪問你的局域網(wǎng)。

2. WebSocket

WebSocket是一個全雙工通信協(xié)議，它在客戶端和服務(wù)器之間，通過一個TCP連接實現(xiàn)全雙工通信。它是HTML 5規(guī)范的一部分，WebSocket標準簡化了雙向Web通信和連接管理方面的復(fù)雜度。

3. XMPP

XMPP（可擴展通信與表示協(xié)議）是現(xiàn)有Web技術(shù)在物聯(lián)網(wǎng)領(lǐng)域開發(fā)新用途的一個很好的實例。

XMPP最初用于即時消息與現(xiàn)場信息?，F(xiàn)在已經(jīng)擴展到支持VoIP信令、協(xié)作、輕量級中間件、內(nèi)容聚合及廣義的XML數(shù)據(jù)路由等領(lǐng)域。它是家用電器大規(guī)模管理的競爭者，這些白色家電包括洗衣機、干衣機、冰箱等。

4. CoAP

盡管Web協(xié)議可用于物聯(lián)網(wǎng)設(shè)備，對大多數(shù)物聯(lián)網(wǎng)應(yīng)用來說，它的體積太龐大。IETF制定的資源受限的應(yīng)用協(xié)議（CoAP），可用于低功耗和資源受限的網(wǎng)絡(luò)。CoAP是一個REST類型的協(xié)議，采用了與HTTP類似的語法，其語義可以與HTTP的語義一一對應(yīng)。

對基于電池供電或能量收集供電的設(shè)備來說，CoAP協(xié)議是一個很好的選擇。其部分特性如下：

1）CoAP運行在UDP協(xié)議之上。

2）由于UDP傳輸不可靠，CoAP重現(xiàn)了一些TCP的功能。例如，CoAP可以識別需要確認的請求和無需確認的請求。

3）CoAP報文采用異步請求/響應(yīng)模式。

4）所有的報文頭、方法和狀態(tài)碼基于二進制編碼，以減少協(xié)議開銷。

5）不同于HTTP，緩存CoAP響應(yīng)的能力不依賴請求方式，取決于應(yīng)答碼。

6）CoAP面向需要輕量級協(xié)議和建立永久連接的需求。如果擁有Web應(yīng)用背景，使用CoAP會比較容易。

5. MQTT

MQ（消息隊列）遙測傳輸是一個開源的協(xié)議棧（MQTT），面向資源受限的設(shè)備和低帶寬、高延遲的網(wǎng)絡(luò)。它采用發(fā)布/訂閱消息傳輸模式，是一個輕量級的協(xié)議，適合將小型設(shè)備連接到資源受限的網(wǎng)絡(luò)。

MQTT帶寬利用率高，數(shù)據(jù)不可知，并具有連續(xù)的會話意識?？梢詭椭锫?lián)網(wǎng)設(shè)備減少資源消耗，還可以確?？煽啃院鸵欢ǔ潭鹊姆?wù)等級。

MQTT面向大型網(wǎng)絡(luò)中的小型設(shè)備，這些設(shè)備需要通過互聯(lián)網(wǎng)中的后臺服務(wù)器來監(jiān)視和控制。它不是一個設(shè)備到設(shè)備的傳輸，也不是“組播”數(shù)據(jù)到多個接收器的傳輸。MQTT非常簡單，僅提供了一些控制選項。

協(xié)議比較

表1概述了所有的物聯(lián)網(wǎng)協(xié)議，開發(fā)這些互聯(lián)網(wǎng)定義的物聯(lián)網(wǎng)協(xié)議的目的是滿足低存儲空間、低帶寬和高延遲設(shè)備的聯(lián)網(wǎng)需求。

表1超越MQTT：從思科的視角看物聯(lián)網(wǎng)協(xié)議（Paul Duffy，2013.4.30）

互聯(lián)網(wǎng)和物聯(lián)網(wǎng)協(xié)議比較如下，圖2提供了將互聯(lián)網(wǎng)協(xié)議與物聯(lián)網(wǎng)中的性能優(yōu)勢比較。資料來源于Zach Shelby的報告“物聯(lián)網(wǎng)驅(qū)動標準”。

圖2互聯(lián)網(wǎng)和物聯(lián)網(wǎng)協(xié)議比較

如圖2左側(cè)所示，Web應(yīng)用的協(xié)議?？梢院苋菀椎厣蓭装俚綆浊ё止?jié)的數(shù)據(jù)開銷。比較而言，物聯(lián)網(wǎng)協(xié)議針對受限制的設(shè)備和網(wǎng)絡(luò)進行了優(yōu)化，僅生成幾十個字節(jié)的數(shù)據(jù)開銷。