圖片來源：iotforall.com
對(duì)于開發(fā)者來說，在嵌入式系統(tǒng)設(shè)計(jì)中使用傳感器和通信是最平常不過的事情。但在這些系統(tǒng)中使用互聯(lián)網(wǎng)技術(shù)則是最新的潮流，也是大多數(shù)物聯(lián)網(wǎng)（IoT）的直接表現(xiàn)形式?；ヂ?lián)網(wǎng)協(xié)議（IP）并不是新技術(shù)，應(yīng)用于物聯(lián)網(wǎng)（IoT）的IP網(wǎng)絡(luò)則有所不同，它們重塑了廣域網(wǎng)絡(luò)的各種功能。TCP/IP套接字上面有多個(gè)IP應(yīng)用層協(xié)議，每一種都有自己的優(yōu)勢(shì)和限制。了解這些協(xié)議，有助于開發(fā)人員為產(chǎn)品做出最佳設(shè)計(jì)。選擇IoT協(xié)議時(shí)，對(duì)帶寬要求、實(shí)時(shí)性能和內(nèi)存占用則是需要考慮的主要標(biāo)準(zhǔn)。許多物聯(lián)網(wǎng)項(xiàng)目由首席信息官（CIO）和IT部門推動(dòng)，他們要求開發(fā)人員使用他們所知的技術(shù)和協(xié)議。但是我們要知道，IoT設(shè)備的管理更接近運(yùn)營技術(shù)（OT），或者稱為資產(chǎn)管理，將IT直接套用于OT，很多時(shí)候并不是最優(yōu)選項(xiàng)。
開發(fā)人員需要了解物聯(lián)網(wǎng)設(shè)備有比IT技術(shù)更好的專有協(xié)議選項(xiàng)。
應(yīng)用IP技術(shù)的網(wǎng)絡(luò)有多種類別：
? 消費(fèi)者與工業(yè)
? 網(wǎng)頁服務(wù)
? 物聯(lián)網(wǎng)服務(wù)
? 發(fā)布/訂閱
? 請(qǐng)求/響應(yīng)
在設(shè)計(jì)新系統(tǒng)時(shí)必須考慮這些類別。讓我們看一下物聯(lián)網(wǎng)應(yīng)用的IP網(wǎng)絡(luò)，并定義選擇標(biāo)準(zhǔn)。
Internet是將IP數(shù)據(jù)包從數(shù)據(jù)源路由到目的地的、所有網(wǎng)絡(luò)設(shè)備的總和。相比之下，萬維網(wǎng)是一種在互聯(lián)網(wǎng)上運(yùn)行的應(yīng)用系統(tǒng)。Web是人們?yōu)榻粨Q信息構(gòu)建的工具，在過去的20年中，Web已經(jīng)趨于完善，即便是普通的非技術(shù)人員也可以輕松高效地使用Internet。例如，因特網(wǎng)的人機(jī)界面現(xiàn)在包括電子郵件、搜索引擎、瀏覽器、移動(dòng)應(yīng)用程序、Facebook和Twitter、以及其他流行的社交媒體。
相比之下，在物聯(lián)網(wǎng)中，我們最基本的想法是電子設(shè)備之間通過互聯(lián)網(wǎng)交換信息。但是這些設(shè)備并沒有瀏覽器或社交媒體一樣的機(jī)器來促進(jìn)溝通。由于物聯(lián)網(wǎng)設(shè)備需要協(xié)同工作，在速度、規(guī)模和功能的需求上，物聯(lián)網(wǎng)也與Web不同。這些要求遠(yuǎn)遠(yuǎn)超出了人們的需求或使用范圍。我們正處于為這些系統(tǒng)開發(fā)新工具和服務(wù)的初始階段，這也是難以鎖定物聯(lián)網(wǎng)定義的原因之一。在現(xiàn)實(shí)應(yīng)用中，存在許多愿景相互沖突，包括如何定義它能夠做什么，可能做什么或應(yīng)該做什么，等等。
TCP / IP協(xié)議棧是Internet和Web的核心。它使用七層開放系統(tǒng)互連參考模型（OSI）來表示，如下所示（圖1）。最頂端的三層組合在一起，簡化了模型。
圖1 七層OSI參考模型
以下是從嵌入式系統(tǒng)集成角度對(duì)重要OSI層的快速描述：
1.物理和數(shù)據(jù)鏈路層
嵌入式系統(tǒng)使用的最常見的物理層協(xié)議是：
? 以太網(wǎng)（10 Mbps，100 Mbps，1 Gbps）
? Wi-Fi（802.11b / g / n）
? 串行點(diǎn)對(duì)點(diǎn)協(xié)議（PPP）
? GSM，3G，4G，LTE
2.網(wǎng)絡(luò)層
這是互聯(lián)網(wǎng)的生活方式。互聯(lián)網(wǎng) - 網(wǎng)絡(luò)間的簡稱 - 之所以如此命名，是因?yàn)樗峁┝司W(wǎng)絡(luò)之間、物理層之間的連接。這是我們找到無處不在的IP地址的地方。
3.傳輸層
在IP之上，我們有傳輸控制協(xié)議（TCP）和用戶數(shù)據(jù)報(bào)協(xié)議（UDP）這兩種傳輸協(xié)議。由于TCP用于我們與Web的大多數(shù)人工交互（電子郵件，Web瀏覽等），因此人們普遍認(rèn)為TCP應(yīng)該是傳輸層使用的唯一協(xié)議。TCP提供了邏輯連接的概念、傳輸?shù)臄?shù)據(jù)包的確認(rèn)、丟失的數(shù)據(jù)包的重傳以及流量控制 - 所有這些都是很棒的事情。但對(duì)于嵌入式系統(tǒng)，TCP可能是過度的要求。因此，即使UDP長期以來已經(jīng)被降級(jí)，僅應(yīng)用于域名服務(wù)器（DNS）和動(dòng)態(tài)主機(jī)配置協(xié)議（DHCP）等網(wǎng)絡(luò)服務(wù)，現(xiàn)在也在物聯(lián)網(wǎng)的傳感器數(shù)據(jù)獲取和遠(yuǎn)程控制領(lǐng)域找到了自己的位置。對(duì)于語音和視頻等實(shí)時(shí)數(shù)據(jù)應(yīng)用，如果您需要某種類型的數(shù)據(jù)管理，UDP也比TCP更適合。原因是TCP的數(shù)據(jù)包確認(rèn)和重傳功能對(duì)這些應(yīng)用程序來說是無用的開銷。如果一段數(shù)據(jù)（例如一些語音音頻）沒有及時(shí)到達(dá)其目的地，則重傳該分組是沒有意義的，因?yàn)樗鼘⒉话错樞虻竭_(dá)并使語音亂碼。
TCP有時(shí)優(yōu)先于UDP，因?yàn)樗峁┏志眠B接。要使用UDP啟用相同功能，必須在UDP上方的協(xié)議層中實(shí)現(xiàn)此功能。
當(dāng)您決定如何將數(shù)據(jù)從“物”通過本地網(wǎng)絡(luò)連接到IP網(wǎng)絡(luò)，您有多種選擇。由于所使用的技術(shù)是成熟的，并且可以開源獲得——通過網(wǎng)關(guān)鏈接兩個(gè)網(wǎng)絡(luò)，或者可以將網(wǎng)關(guān)構(gòu)建到“物”本身。現(xiàn)在，許多微控制器（MCU）都在芯片上安裝了以太網(wǎng)控制器，這使得這項(xiàng)工作變得更加容易。
圖片來源：https://entrepreneurshiptalk.wordpress.com/2014/01/29/the-internet-of-thing-protocol-stack-from-sensors-to-business-value/
使用現(xiàn)有的Web技術(shù)構(gòu)建物聯(lián)網(wǎng)系統(tǒng)是可能的，即使它不如新協(xié)議那么高效。超文本傳輸協(xié)議（HTTP / S）和WebSockets是有效載荷的通用標(biāo)準(zhǔn)，以及可擴(kuò)展標(biāo)記語言（XML）或JavaScript對(duì)象表示法（JSON）。使用標(biāo)準(zhǔn)Web瀏覽器（HTTP客戶端）時(shí)，JSON為Web開發(fā)人員提供了一個(gè)抽象層，通過保持打開兩個(gè)HTTP連接，創(chuàng)建一個(gè)具有到Web服務(wù)器（HTTP服務(wù)器）的持久雙工連接的、有狀態(tài)Web應(yīng)用程序。
HTTP是用于Web的客戶端 - 服務(wù)器模型的基礎(chǔ)。在IoT設(shè)備中實(shí)施HTTP的最安全方法是僅包括客戶端，而不是服務(wù)器。換句話說，當(dāng)IoT設(shè)備可以啟動(dòng)與Web服務(wù)器的連接，但不必是接收連接請(qǐng)求時(shí)則更安全; 我們不希望外部計(jì)算機(jī)訪問安裝了IoT設(shè)備的本地網(wǎng)絡(luò)。
WebSocket是一種通過單個(gè)TCP連接提供全雙工通信的協(xié)議，通過該連接可以在客戶端和服務(wù)器之間發(fā)送消息。它是超文本標(biāo)記語言5（HTML5）規(guī)范的一部分。WebSocket標(biāo)準(zhǔn)簡化了雙向Web通信和連接管理的復(fù)雜性。
可擴(kuò)展消息傳遞和在線協(xié)議（XMPP）是現(xiàn)有Web技術(shù)在物聯(lián)網(wǎng)領(lǐng)域?qū)ふ倚掠猛镜囊粋€(gè)很好的例子。
XMPP來源于即時(shí)消息和狀態(tài)信息，并已擴(kuò)展到語音和視頻調(diào)用、協(xié)作、輕量級(jí)中間件、內(nèi)容聯(lián)合以及XML數(shù)據(jù)的通用路由。它是管理大規(guī)模白色家電（如洗衣機(jī)，烘干機(jī)，冰箱等）的有力競(jìng)爭(zhēng)者。
XMPP的優(yōu)勢(shì)在于其尋址、安全性和可擴(kuò)展性。這使其成為面向消費(fèi)者的物聯(lián)網(wǎng)應(yīng)用的理想選擇。
HTTP，WebSocket和XMPP是為物聯(lián)網(wǎng)服務(wù)的技術(shù)示例。其他團(tuán)隊(duì)也在IoT領(lǐng)域，努力向我們展示新的解決方案。
許多物聯(lián)網(wǎng)專家將IoT設(shè)備稱為受約束系統(tǒng)，因?yàn)樗麄冋J(rèn)為物聯(lián)網(wǎng)設(shè)備應(yīng)盡可能便宜，并使用可用的最小MCU，同時(shí)仍然運(yùn)行通信堆棧。
目前，為物聯(lián)網(wǎng)調(diào)整互聯(lián)網(wǎng)是許多全球標(biāo)準(zhǔn)化機(jī)構(gòu)的主要優(yōu)先事項(xiàng)之一。表1包含當(dāng)前活動(dòng)的簡短摘要。
表1 受約束系統(tǒng)標(biāo)準(zhǔn)化工作
如果您的系統(tǒng)不需要TCP的功能并且可以使用更有限的UDP功能，則刪除TCP模塊將顯著減小產(chǎn)品總代碼占用空間的大小。這就是為物聯(lián)網(wǎng)領(lǐng)域帶來的，用于無線傳感器網(wǎng)絡(luò)（WSN）和約束應(yīng)用協(xié)議（CoAP），輕型互聯(lián)網(wǎng)協(xié)議的低功耗無線個(gè)域網(wǎng)（6LoWPAN）的IPv6網(wǎng)絡(luò)。
雖然Web基礎(chǔ)架構(gòu)可用于物聯(lián)網(wǎng)設(shè)備，但對(duì)于大多數(shù)物聯(lián)網(wǎng)應(yīng)用來說，它太龐大了。2013年7月，Internet Engineering Task Forcce（IETF）發(fā)布了CoAP，用于低功耗和有損節(jié)點(diǎn)網(wǎng)絡(luò)（LLN）。與HTTP一樣，CoAP是RESTful（Representational state transfer, 通過統(tǒng)一的應(yīng)用程序編程接口（API）協(xié)議操作資源和資源標(biāo)識(shí)符的能力）。
CoAP在語義上與HTTP對(duì)齊，甚至與HTTP進(jìn)行一對(duì)一映射。網(wǎng)絡(luò)設(shè)備受限于閃存和RAM、或較小MCU的限制，而本地網(wǎng)絡(luò)的約束來源于高的分組錯(cuò)誤率和低吞吐量（幾十kbps）。CoAP可以是用于電池或能量收集的設(shè)備的良好協(xié)議。
CoAP的特點(diǎn)：
? 由于CoAP使用UDP，因此某些TCP功能可直接在CoAP中復(fù)制。例如，CoAP區(qū)分可確認(rèn)（需要確認(rèn)）和不可確認(rèn)消息。
? 請(qǐng)求和響應(yīng)通過CoAP消息異步交換（與使用現(xiàn)有TCP連接的HTTP不同）。
? 所有標(biāo)頭，方法和狀態(tài)代碼都是二進(jìn)制編碼的，這樣可以減少協(xié)議開銷。但是，這需要使用協(xié)議分析器來解決網(wǎng)絡(luò)問題。
? 與HTTP不同，緩存CoAP響應(yīng)的能力不依賴于請(qǐng)求方法，而是依賴于響應(yīng)代碼。
? CoAP完全解決了對(duì)極輕協(xié)議的需求，該協(xié)議表現(xiàn)出類似于永久連接的行為。它對(duì)HTTP具有語義熟悉，并且是RESTful。如果您有網(wǎng)絡(luò)背景，使用CoAP相對(duì)容易。
消息隊(duì)列遙測(cè)傳輸（MQTT）是一種開源協(xié)議，針對(duì)受限設(shè)備和低帶寬，高延遲或不可靠網(wǎng)絡(luò)而開發(fā)和優(yōu)化。它是一種發(fā)布/訂閱消息傳輸，非常輕量級(jí)，非常適合以較小的帶寬將小型設(shè)備連接到網(wǎng)絡(luò)。MQTT具有帶寬效率、與數(shù)據(jù)無關(guān)，并且具有連續(xù)的會(huì)話感知，因?yàn)樗褂肨CP。它旨在最大限度地減少設(shè)備資源需求，同時(shí)還試圖確保可靠性和一定程度的服務(wù)等級(jí)交付保證。
MQTT針對(duì)需要從Internet上的后端服務(wù)器進(jìn)行監(jiān)視或控制的大型小型設(shè)備網(wǎng)絡(luò)。它不是為設(shè)備到設(shè)備傳輸而設(shè)計(jì)的，也不是為了將數(shù)據(jù)“多播”到許多接收器而設(shè)計(jì)的。MQTT很簡單，幾乎沒有控制選項(xiàng)。使用MQTT的應(yīng)用程序通常很慢，因?yàn)樵谶@種情況下“實(shí)時(shí)”的定義通常以秒為單位進(jìn)行測(cè)量。
MQTT發(fā)布/訂閱可以很好地?cái)U(kuò)展，并且已經(jīng)證明了該架構(gòu)的優(yōu)點(diǎn)。在最新的IETF評(píng)論請(qǐng)求（RFC）中，CoAP引入了對(duì)發(fā)布/訂閱的支持。
CoAP的輕型有效載荷非常適合無線傳感器網(wǎng)絡(luò)。傳感器網(wǎng)絡(luò)的MQTT（MQTT-SN）采用了這一想法并對(duì)其進(jìn)行了再現(xiàn)。
兩個(gè)主要的專用物聯(lián)網(wǎng)協(xié)議是相互借鑒的。這兩個(gè)協(xié)議是否能成為主流？我們相信，至少需要五到十年。
思科(CISCO)是互聯(lián)網(wǎng)的核心; 它的IP設(shè)備無處不在。思科積極參與物聯(lián)網(wǎng)的發(fā)展，并看到了連接物理對(duì)象，從我們的環(huán)境獲取數(shù)據(jù)以及處理這些數(shù)據(jù)以提高我們的生活水平的潛力（表2）。
表2 思科在物聯(lián)網(wǎng)標(biāo)準(zhǔn)方面的工作
表2中所示的特定于因特網(wǎng)的IoT協(xié)議已經(jīng)開發(fā)出來，以滿足低存儲(chǔ)能力、低帶寬和高延遲的網(wǎng)絡(luò)的設(shè)備的要求。圖2提供了這些協(xié)議為物聯(lián)網(wǎng)帶來的性能優(yōu)勢(shì)的另一個(gè)很好的總結(jié)。
圖2 Web和IoT協(xié)議的比較。 資料來源：Zach Shelby，Micro：bit Foundation [1]
連接傳感器和對(duì)象打開了一個(gè)可能的、全新的用例世界——正是這些用例將確定何時(shí)為正確的應(yīng)用程序使用正確的協(xié)議。
每種協(xié)議的高級(jí)定位都是類似的。除了HTTP之外，所有提到的協(xié)議都被定位為實(shí)時(shí)發(fā)布/訂閱IoT協(xié)議，支持?jǐn)?shù)百萬臺(tái)設(shè)備。根據(jù)您定義“實(shí)時(shí)”（秒，毫秒或微秒）和“物”（無線傳感器網(wǎng)絡(luò)WSN節(jié)點(diǎn)、多媒體設(shè)備、個(gè)人可穿戴設(shè)備，醫(yī)療掃描儀、引擎控制等）的方式，針對(duì)這些產(chǎn)品，協(xié)議選擇至關(guān)重要。從根本上說，這些協(xié)議絕對(duì)不會(huì)是相同的。
今天，Web運(yùn)行在數(shù)百種協(xié)議之上；物聯(lián)網(wǎng)將支持?jǐn)?shù)百個(gè)。在設(shè)計(jì)系統(tǒng)時(shí)需要做的是非常精確地定義系統(tǒng)需求，并選擇正確的協(xié)議集來解釋?；ヂ?lián)網(wǎng)協(xié)議是一個(gè)載體; 它可以為IoT封裝盡可能多的協(xié)議，就像今天的Web一樣。
許多行業(yè)專家都在尋求協(xié)議標(biāo)準(zhǔn)化但是如果有很多協(xié)議用于網(wǎng)絡(luò)，為什么物聯(lián)網(wǎng)的協(xié)議數(shù)量不會(huì)那么多呢？您可以選擇符合要求的協(xié)議。唯一的區(qū)別是物聯(lián)網(wǎng)協(xié)議仍然很年輕，必須證明其可靠性。請(qǐng)注意，當(dāng)互聯(lián)網(wǎng)成為現(xiàn)實(shí)時(shí)，IPv4才出現(xiàn)。我們現(xiàn)在正在大規(guī)模部署IPv6，物聯(lián)網(wǎng)是電信運(yùn)營商一直在等待證明所需投資的殺手級(jí)應(yīng)用。
Which IoT protocol should I use for my system?
CHRISTIAN LEGARE, MICRIUM | APRIL 11, 2017
原文地址：https://www.embedded-computing.com/embedded-computing-design/which-iot-protocol-should-i-use-for-my-system
Christian Légaré is Vice President and Chief Technology Officer for Micrium, part of the Silicon Laboratories Portfolio
Micrium
www.micrium.com@micrium
LinkedIn: www.linkedin.com/company/micrium-inc-YouTube: www.youtube.com/micrium
Silicon Laboratories
www.silabs.com@siliconlabsLinkedIn: www.linkedin.com/company-beta/165971/Facebook: www.facebook.com/siliconlabsGoogle : plus.google.com/117130120420400445098YouTube: www.youtube.com/user/ViralSilabs
1. Zdshelby Follow. “Standards Drive the Internet of Things.” LinkedIn SlideShare. May 22, 2013. Accessed April 11, 2017. https://www.slideshare.net/zdshelby/standards-drive-the-internet-of-things.
聯(lián)系客服
