OpenHarmony啃論文計(jì)劃--一文遍歷主要的物聯(lián)網(wǎng)通信協(xié)議
??想了解更多關(guān)于開源的內(nèi)容，請(qǐng)?jiān)L問：??
萬字長文預(yù)警!一文了解主要的物聯(lián)網(wǎng)通信協(xié)議(MQTT、XMPP、AMQP、DDS、HTTP、CoAP)。
雖然我看不懂，但我大受震撼。
我來自O(shè)penHarmony開發(fā)者成長計(jì)劃：啃論文小隊(duì)，我們在歐建深教練的帶領(lǐng)下啃論文。我們是TCCS團(tuán)隊(duì)，全意為The Child Collecting Shells。本篇緒論主要作者為TCCS團(tuán)隊(duì)的張君豪，歡迎大家對(duì)文章提出建設(shè)性的意見或者批評(píng)!
“我并不知道我在世人眼中是什么模樣，對(duì)我來說，我似乎只像是一個(gè)在海邊玩耍的男孩，不時(shí)找一顆平滑的卵石，或是比較美麗的貝殼來取悅自己，而真理的大海則橫陳在我面前，一無發(fā)現(xiàn)。”——牛頓
本文一萬多字，這主要?dú)w功于原文獻(xiàn)作者的綜述論文質(zhì)量非常高，在這里也分享給大家，只憑一篇文章想搞懂這么多協(xié)議其實(shí)是遠(yuǎn)遠(yuǎn)不夠的，但是能讓大家對(duì)協(xié)議有一個(gè)初步的框架了解。
上一篇文章中分布式軟總線關(guān)鍵技術(shù)普適計(jì)算初探,我挖了一個(gè)關(guān)于物聯(lián)網(wǎng)通信協(xié)議的坑，現(xiàn)在終于自己來把這個(gè)坑填上了。我這次參考的論文是《A Survey of Communication Protocols for Internet of Things and Related Challenges of Fog and Cloud Computing Integration》，翻譯過來就是物聯(lián)網(wǎng)通信協(xié)議綜述及霧云計(jì)算融合相關(guān)挑戰(zhàn)，我將讀完整篇文章并從一個(gè)小白提煉的角度來帶著大家搞懂這篇論文，也希望通過這篇論文能讓大家(包括我)對(duì)物聯(lián)網(wǎng)通信協(xié)議有一個(gè)更清楚、更宏觀的了解，從知道是什么，到為什么，至于怎么用我想在這里看到這篇文章的讀者老爺們肯定都比我更會(huì)，怎么用我就不賣弄了。好下面進(jìn)入正題
一、全文綜述
由于原文獻(xiàn)質(zhì)量非常高，包括各個(gè)協(xié)議都寫得很清楚，我只是將其初步的加工理解了一下，也帶著大家一起學(xué)習(xí)，本文帶著大家首先構(gòu)建對(duì)物聯(lián)網(wǎng)通信協(xié)議的一個(gè)基礎(chǔ)框架的了解，知道為什么和是什么，至于怎么樣，我們下篇再說(畢竟這一篇已經(jīng)破萬字了)，在下一篇我?guī)е蠹依^續(xù)解讀文獻(xiàn)來從幾個(gè)方面對(duì)比這幾個(gè)協(xié)議，著急的老爺也可以先行下載文獻(xiàn)自行閱讀，文末有我已經(jīng)上傳的文獻(xiàn)資源可供大家下載，如果大家喜歡記得點(diǎn)贊哦!當(dāng)然如果有批評(píng)指正也歡迎大家提出來!我也會(huì)虛心接受并且積極改正!
以下是文章中經(jīng)常出現(xiàn)的縮寫：
IETF：互聯(lián)網(wǎng)工程任務(wù)組，成立于1985年底，是全球互聯(lián)網(wǎng)最具權(quán)威的技術(shù)標(biāo)準(zhǔn)化組織，主要任務(wù)是負(fù)責(zé)互聯(lián)網(wǎng)相關(guān)技術(shù)規(guī)范的研發(fā)和制定，當(dāng)前絕大多數(shù)國際互聯(lián)網(wǎng)技術(shù)標(biāo)準(zhǔn)出自IETF。
二、為什么?
1、為什么需要這么多協(xié)議?
首先我們應(yīng)該都知道協(xié)議是什么東西，啊?這都不知道?叉出去
網(wǎng)絡(luò)協(xié)議為計(jì)算機(jī)網(wǎng)絡(luò)中進(jìn)行數(shù)據(jù)交換而建立的規(guī)則、標(biāo)準(zhǔn)或約定的集合。
舉個(gè)栗子，你可以把網(wǎng)絡(luò)協(xié)議理解為計(jì)算機(jī)之間相互交流的語言，只有兩臺(tái)通信的主機(jī)在使用相同的協(xié)議時(shí)他們才能有效通信，假如協(xié)議不同就好比下圖。。。。!
而互聯(lián)網(wǎng)中的主機(jī)大部分都使用的是TCP/IP協(xié)議(使用TCP/IP相互交流)，那這個(gè)TCP/IP和我們常常聽到的什么HTTP是什么關(guān)系呢?
他們分別屬于網(wǎng)絡(luò)不同的層次，如上圖可以簡單的理解為HTTP是建立在TCP協(xié)議的基礎(chǔ)之上的。當(dāng)瀏覽器需要從服務(wù)器獲取網(wǎng)頁數(shù)據(jù)的時(shí)候，會(huì)發(fā)出一次http請(qǐng)求。Http通過TCP建立起一個(gè)到服務(wù)器的通道?？梢韵群唵蔚倪@么大致了解一下，因?yàn)槿绻归_說那么。。。。你懂
那我們都知道，任何事物既然存在，那么就必然有其存在的道理，那為什么HTTP協(xié)議已經(jīng)應(yīng)用這么流行和廣泛了，還要搞出來這么多不同的協(xié)議?
因?yàn)槲锫?lián)網(wǎng)需要涵蓋不同要求和領(lǐng)域，并且將傳感器、執(zhí)行器和計(jì)算能力的功能與安全性、連接性和無數(shù)其他功能相結(jié)合(總之就是要求很多很復(fù)雜)，因此對(duì)于參考架構(gòu)或采用的通信協(xié)議沒有統(tǒng)一的標(biāo)準(zhǔn)協(xié)議，因此系統(tǒng)工程師的一大挑戰(zhàn)之一就是為其特定的物聯(lián)網(wǎng)系統(tǒng)要求選擇合適的協(xié)議。
(也歡迎各位老爺在評(píng)論區(qū)以開發(fā)的視角分享為什么還需要這么多通信)
2、協(xié)議的大致如何分類?
一般來說，根據(jù)通信協(xié)議交互模型的不同，我們可以把通信協(xié)議分為request-reply(請(qǐng)求-應(yīng)答) 和 publish-subscribe(發(fā)布-訂閱)模型。請(qǐng)求-應(yīng)答通信模型是最基本的通信模型之一。它代表了一種在客戶端/服務(wù)器架構(gòu)中特別常見的消息交換模式。它允許客戶端向服務(wù)器請(qǐng)求信息，服務(wù)器接收請(qǐng)求消息，對(duì)其進(jìn)行處理并返回響應(yīng)消息。這種信息通常是集中管理和交換的?；谡?qǐng)求/回復(fù)模型的兩個(gè)最知名的協(xié)議是 REST HTTP 和 CoAP。圖一顯示了HTTP三個(gè)不同版本(v.1.0、v.1.1、v.2.0)以及CoAP的不同客戶端/服務(wù)器交互的例子。
(圖中：SYN：同步標(biāo)志，F(xiàn)IN：結(jié)束標(biāo)志，即一次會(huì)話的建立與結(jié)束的標(biāo)志)
在 HTTP 1.0 中，TCP 連接在單個(gè) HTTP 請(qǐng)求/回復(fù)對(duì)之后關(guān)閉。在 HTTP 1.1 中，引入了 keep-alive 機(jī)制，可以重用 TCP 連接來向服務(wù)器發(fā)送多個(gè)請(qǐng)求，而無需等待響應(yīng)(流水線)。一旦請(qǐng)求全部發(fā)送完畢，瀏覽器就會(huì)開始監(jiān)聽響應(yīng)，同時(shí) HTTP 1.1 規(guī)范要求服務(wù)器必須按照接收請(qǐng)求的順序回復(fù)對(duì)這些請(qǐng)求的響應(yīng)。新的 HTTP 2.0 引入了一種多路復(fù)用方法，通過該方法可以發(fā)送多個(gè) HTTP 請(qǐng)求，并且可以通過單個(gè) TCP 連接異步接收響應(yīng)。圖中第四個(gè)交互是針對(duì) CoAP 的，與其他交互不同，它不依賴于底層可靠的 TCP 連接來在客戶端和服務(wù)器之間交換請(qǐng)求/回復(fù)消息。另一方面，發(fā)布-訂閱模型的出現(xiàn)是為了在發(fā)送端和目的地之間提供分布式、異步、松散耦合的通信。該解決方案今天以眾多發(fā)布-訂閱的面向消息的中間件 (MoM) 的形式出現(xiàn)，并且最近已成為眾多研究工作的主題。
? 而發(fā)布-訂閱模型作為傳統(tǒng)的請(qǐng)求-回復(fù)(客戶端-服務(wù)器)模型的替代方案，它由三方組成，如圖2所示
在這種模型中，具有訂閱者角色的客戶端不必向服務(wù)器請(qǐng)求信息。有興趣接收消息的客戶端將訂閱系統(tǒng)內(nèi)的特定事件(主題)而不是發(fā)送請(qǐng)求。代理作為該架構(gòu)中的中心點(diǎn)，負(fù)責(zé)過濾所有傳入的消息并在發(fā)布者和訂閱者之間相應(yīng)地引導(dǎo)它們。第三方是作為信息提供者的發(fā)布者。當(dāng)某個(gè)主題的事件發(fā)生時(shí)，它會(huì)將其發(fā)布給代理，代理將請(qǐng)求主題的數(shù)據(jù)發(fā)送給訂閱者。由于這些原因，發(fā)布訂閱交互模型可以描述為基于事件的架構(gòu) 。這種交互模型能夠通過支持動(dòng)態(tài)、多對(duì)多和異步通信來提供可擴(kuò)展性并簡化不同設(shè)備之間的互連。
比較兩種基本模型，即請(qǐng)求-回復(fù)和發(fā)布-訂閱，我們可以發(fā)現(xiàn)發(fā)布-訂閱模型具有許多優(yōu)點(diǎn)：
(1)發(fā)布者和訂閱者不需要知道彼此的存在;
(2)一個(gè)訂閱者可以從許多不同的發(fā)布者接收信息，并且一個(gè)發(fā)布者可以向許多不同的訂閱者發(fā)送數(shù)據(jù)(支持多對(duì)多通信);
(3)發(fā)布者和訂閱者不需要同時(shí)處于活動(dòng)狀態(tài)來交換信息，因?yàn)榇?作為一種排隊(duì)系統(tǒng)工作)可以為當(dāng)前未連接的客戶端存儲(chǔ)消息。
目前有許多標(biāo)準(zhǔn)化的消息傳遞協(xié)議都實(shí)現(xiàn)了發(fā)布/訂閱交互模型，最著名的是MQTT、AMQP和DDS。但是請(qǐng)求-應(yīng)答模型也有一些優(yōu)勢。在服務(wù)器端處理多個(gè)客戶端請(qǐng)求不是問題的情況下，可靠的請(qǐng)求-回復(fù)交互更有意義。因此，模型的選擇取決于它將用于的應(yīng)用場景。最后，一些協(xié)議同時(shí)支持請(qǐng)求-回復(fù)和發(fā)布-訂閱交互模型。這包括XMPP協(xié)議和新版本的HTTP HTTP2.0，它支持服務(wù)器推送選項(xiàng)。IETF還發(fā)布了一份草案，描述了其他的協(xié)議的發(fā)布-訂閱協(xié)議，例如CoAP。在嘗試解決消息交換的過程中，隨著時(shí)間的推移，也出現(xiàn)了一些其他解決方案，例如WebSockets協(xié)議或使用Quic(Quick UDP Internet Connections)協(xié)議的HTTP。在WebSocket的情況下，盡管它用于將數(shù)據(jù)從服務(wù)器實(shí)時(shí)推送到Web客戶端，并實(shí)現(xiàn)同時(shí)雙向通信的持久連接，但它不是為資源受限的設(shè)備設(shè)計(jì)的。作為一種新的傳輸協(xié)議，Quic也創(chuàng)造了一波新的研究。但由于Quic尚未標(biāo)準(zhǔn)化，現(xiàn)在預(yù)測其在基于物聯(lián)網(wǎng)的解決方案中的可能應(yīng)用和影響可能還為時(shí)過早。出于這些原因，盡管WebSockets和Quic很新穎，但它們不在本次研究的范圍內(nèi)。
三、是什么
1、 各協(xié)議總體對(duì)比
(Req-Rep：請(qǐng)求-回復(fù)模型;Pub-Sub：發(fā)布-訂閱模型;Standard：標(biāo)準(zhǔn);Transport：傳輸;QoS：服務(wù)質(zhì)量;Security：安全機(jī)制)
如果一開始看不太懂，可以邊看下面詳細(xì)介紹邊看或者看完下面再看這幅圖
2、各協(xié)議介紹
（1） HTTP協(xié)議
該協(xié)議是用于Web的基本客戶端-服務(wù)器模型協(xié)議，也是目前Web開發(fā)人員日常使用的與現(xiàn)有網(wǎng)絡(luò)基礎(chǔ)設(shè)施最兼容的協(xié)議。目前該協(xié)議最廣泛接受的版本是HTTP/1.1?？蛻舳撕头?wù)器之間的通信通過請(qǐng)求/響應(yīng)消息進(jìn)行，其中客戶端發(fā)送HTTP請(qǐng)求消息，然后服務(wù)器返回響應(yīng)消息，這其中包含了在請(qǐng)求被接受的情況下所請(qǐng)求的資源。
最近，HTTP已經(jīng)與REST聯(lián)系在一起，REST是一種基于特定架構(gòu)風(fēng)格開發(fā)Web服務(wù)的指南，目的是定義不同組件之間的交互。是目前最流行的一種互聯(lián)網(wǎng)軟件架構(gòu)。它結(jié)構(gòu)清晰、符合標(biāo)準(zhǔn)、易于理解、擴(kuò)展方便， 所以正得到越來越多網(wǎng)站的采用。
圖中展示的是基于REST與HTTP的交互模型的一個(gè)示例。通過HTTP協(xié)議與REST的結(jié)合，設(shè)備可以通過標(biāo)準(zhǔn)化的方式來創(chuàng)建、讀取、更新和刪除數(shù)據(jù)(所謂的CRUD操作)，從而使它們的狀態(tài)信息很容易獲得。根據(jù)該映射，創(chuàng)建、更新、讀取和刪除資源的操作分別對(duì)應(yīng)于HTTP POST、GET、PUT和DELETE方法。對(duì)于開發(fā)人員來說，REST建立了這些CRUD操作與HTTP方法的映射，意味著他們可以輕松地為不同的物聯(lián)網(wǎng)設(shè)備構(gòu)建REST模型。
HTTP傳輸?shù)臄?shù)據(jù)的類型是任意的，最常見的是JSON和XML。在大多數(shù)情況下，物聯(lián)網(wǎng)通過HTTP圍繞JSON進(jìn)行標(biāo)準(zhǔn)化。REST HTTP客戶端的首要目的之一是想要在服務(wù)器端添加資源。為此，有必要在POST方法的標(biāo)頭中指定要添加的資源的*/resources*、HTTP版本、Content-type(在本例中是表示特定資源的JSON文件)，最后指定JSON對(duì)象本身。來自服務(wù)器的響應(yīng)通過指定HTTP標(biāo)準(zhǔn)狀態(tài)代碼(例如，201，resource created)來指定請(qǐng)求是否成功。對(duì)于要獲得這個(gè)新資源的第二個(gè)客戶端，必須使用特定的URI(例如*/Resources/1*)指定GET方法，該URI包含資源的根和資源本身的ID。服務(wù)器將返回表示資源的JSON對(duì)象。值得一提的是，除了REST HTTP提供的簡單通信外，它還擁有豐富的支持和可用的框架，使其成為默認(rèn)的Web通信方式，幾乎所有的服務(wù)器和客戶端驅(qū)動(dòng)程序都支持它。
關(guān)于使用的傳輸協(xié)議，HTTP使用TCP協(xié)議傳輸。使用TCP提供了大量數(shù)據(jù)的可靠傳輸，這在沒有嚴(yán)格延遲要求的連接中是一個(gè)優(yōu)勢，但是它在資源受限的環(huán)境中就有待商榷了。其中一個(gè)主要問題是，受約束的節(jié)點(diǎn)大多數(shù)時(shí)候會(huì)零星地發(fā)送少量數(shù)據(jù)，但建立一個(gè)TCP連接需要花費(fèi)時(shí)間并產(chǎn)生不必要的開銷。對(duì)于QoS(服務(wù)質(zhì)量)，HTTP不提供其他選擇，而是依賴于TCP，只要TCP連接不中斷，就能保證成功傳遞。
關(guān)于安全機(jī)制，HTTP使用非常著名的TLS來啟用安全加密通信通道，從而產(chǎn)生安全版本的HTTP，也稱為HTTPS。保護(hù)客戶端-服務(wù)器數(shù)據(jù)交換的第一部分是TLS握手，它被實(shí)現(xiàn)為“客戶端問候”和“服務(wù)器問候”消息的交換，其中它們必須就密m套件達(dá)成一致，該密m套件是它們將用來確保安全設(shè)置的算法的組合。之后，客戶端和服務(wù)器端根據(jù)約定的密鑰交換算法進(jìn)行密鑰交換。其結(jié)果是使用共享密鑰加密的消息交換。數(shù)據(jù)被加密，以防止任何人竊t和了解內(nèi)容。當(dāng)前的TLS實(shí)現(xiàn)(TLS版本1.2)通過其握手過程向每個(gè)連接建立增加了額外的流量，這可能會(huì)耗盡這些設(shè)備的計(jì)算能力。正在努力開發(fā)新的TLS 1.3版，使TLS握手更快、更輕，對(duì)物聯(lián)網(wǎng)來說更方便。
雖然一般來說HTTP是最穩(wěn)定的協(xié)議選擇之一，但由于HTTP的復(fù)雜性，仍有一些問題導(dǎo)致了人們對(duì)替代協(xié)議解決方案的探索，比如HTTP報(bào)頭字段較長，功耗較高。此外，HTTP使用的請(qǐng)求/回復(fù)模式不適合推送通知，因?yàn)樵谕扑屯ㄖ?，服?wù)器要在沒有客戶端請(qǐng)求的情況下將通知傳遞給客戶端。此外，在物聯(lián)網(wǎng)體系結(jié)構(gòu)中的簡單計(jì)算節(jié)點(diǎn)的情況下，TCP協(xié)議開銷可能太大(三次握手)。HTTP沒有明確定義服務(wù)質(zhì)量級(jí)別，因此需要對(duì)其提供額外支持。這導(dǎo)致了對(duì)HTTP的修改和擴(kuò)展，最顯著的是HTTP/2.0的形式，其引入了許多改進(jìn)，其中一些與物聯(lián)網(wǎng)環(huán)境強(qiáng)相關(guān)。2.0通過引入壓縮報(bào)頭、使用非常高效和低內(nèi)存壓縮格式以及允許在同一連接上進(jìn)行多個(gè)并發(fā)交換，HTTP/2.0能夠更有效地利用網(wǎng)絡(luò)資源并減少延遲。對(duì)于物聯(lián)網(wǎng)來說，這些功能特別有用，因?yàn)樗馕吨鴶?shù)據(jù)包大小要小得多，這使其成為了受限設(shè)備更合適的選擇。此外，它還引入了所謂的服務(wù)器推送，這意味著服務(wù)器可以不需要等待客戶端的請(qǐng)求即向客戶端發(fā)送內(nèi)容。這個(gè)版本的協(xié)議在基于物聯(lián)網(wǎng)的系統(tǒng)中的缺點(diǎn)尚不清楚，據(jù)我們所知，截至目前，還沒有文獻(xiàn)中報(bào)告的實(shí)施和測試的解決方案。然而，其中一個(gè)缺點(diǎn)很可能與HTTP1.1中的相同，即使用TLS協(xié)議作為安全機(jī)制。
（2）CoAP協(xié)議
該協(xié)議由 IETF的受限 RESTful 環(huán)境 (CoRE) 工作組設(shè)計(jì)，用于處理能力有限的受限設(shè)備。與 HTTP 類似，其最具代表性的特征之一是使用經(jīng)過測試且廣為接受的 REST 架構(gòu)。借助此功能，CoAP 支持請(qǐng)求/響應(yīng)實(shí)例，就像 REST HTTP 一樣，尤其適用于受限環(huán)境。 CoAP 被認(rèn)為是一種輕量級(jí)協(xié)議，因此標(biāo)頭、方法和狀態(tài)碼都是二進(jìn)制編碼的，與許多協(xié)議相比，減少了協(xié)議開銷。它還運(yùn)行在不太復(fù)雜的 UDP 傳輸協(xié)議 上，進(jìn)一步減少了開銷。當(dāng) CoAP 客戶端向服務(wù)器發(fā)送一個(gè)或多個(gè) CoAP 請(qǐng)求并獲得響應(yīng)時(shí)，此響應(yīng)不會(huì)通過先前建立的連接發(fā)送，而是通過 CoAP 消息異步交換。這種減少付出的代價(jià)是可靠性。此外，由于使用 UDP 時(shí)已知的可靠性特性降低，IETF 創(chuàng)建了一個(gè)額外的標(biāo)準(zhǔn)文檔，開啟了 CoAP 在 TCP 上運(yùn)行的可能。但是，目前此功能仍處于早期階段。
CoAP 依賴于一種結(jié)構(gòu)，該結(jié)構(gòu)分為兩個(gè)邏輯上不同的層。其中一層，即所謂的請(qǐng)求/響應(yīng)層，實(shí)現(xiàn)了 RESTful 范式，并允許 CoAP 客戶端在發(fā)送請(qǐng)求時(shí)使用類似 HTTP 的方法。換句話說，客戶端可以使用 GET、PUT、POST 或 DELETE 方法來管理網(wǎng)絡(luò)中 URI 標(biāo)識(shí)的資源。就像在 HTTP 中一樣，對(duì)于從服務(wù)器獲取數(shù)據(jù)的請(qǐng)求，例如在獲取傳感器值時(shí)，客戶端將使用帶有服務(wù)器 URL 的方法 GET，并且作為回復(fù)將接收包含該數(shù)據(jù)的數(shù)據(jù)包。請(qǐng)求和響應(yīng)通過令牌進(jìn)行匹配;響應(yīng)中的令牌必須與請(qǐng)求中定義的令牌相同。客戶端也可以使用 POST 方法將數(shù)據(jù)(例如，更新的傳感器數(shù)據(jù))推送到設(shè)備的 URL。正如我們所看到的，在這一層中，CoAP 使用與 REST HTTP 相同的方法。 COAP 與 HTTP 的不同之處在于第二層。由于 UDP 不能確?？煽康倪B接，CoAP 依靠其第二個(gè)結(jié)構(gòu)層來確?？煽啃裕Q為消息層，旨在重新傳輸丟失的數(shù)據(jù)包。該層定義了四種類型的消息：CON(Confirmable)、NON(non-confirmable)、ACK(Acknowledgment)和RST(reset)。 CON 消息用于確?？煽客ㄐ牛鼈円蠼邮辗酵ㄟ^ ACK 消息進(jìn)行確認(rèn)。盡管方式有限，但正是這個(gè)標(biāo)記消息是否需要確認(rèn)的特性使得 CoAP 中的 QoS 差異化成為可能。
CoAP 有一個(gè)可選功能，可以通過向 GET 請(qǐng)求添加觀察選項(xiàng)，允許客戶端繼續(xù)從服務(wù)器接收對(duì)請(qǐng)求資源的更改，從而改進(jìn)請(qǐng)求/響應(yīng)模型。使用此功能，服務(wù)器將客戶端添加到特定資源的觀察者列表中，這將允許客戶端在資源狀態(tài)更改時(shí)接收通知。與其依靠重復(fù)輪詢來檢查資源狀態(tài)的變化，不如在 CoAP 客戶端的 GET 請(qǐng)求中設(shè)置觀察標(biāo)志，從而允許與服務(wù)器在發(fā)生變化時(shí)提醒客戶端，這種交互更接近于發(fā)布-訂閱模式。為了更接近發(fā)布/訂閱范式，IETF 最近發(fā)布了發(fā)布-訂閱代理草案，該草案擴(kuò)展了 CoAP 的功能，以支持連接和/或正常運(yùn)行時(shí)間較長中斷的節(jié)點(diǎn)，初步性能評(píng)估顯示出有希望的結(jié)果。
關(guān)于安全機(jī)制，CoAP 在其 UDP 傳輸協(xié)議之上使用 DTLS。它基于 TLS 協(xié)議，并進(jìn)行了必要的更改以在不可靠的連接上運(yùn)行。結(jié)果是一個(gè)安全的 CoAPS 協(xié)議版本。與 TLS 相比，大多數(shù)修改都包括在丟失或亂序數(shù)據(jù)包的情況下停止連接終止的功能。例如，有可能重傳握手消息。握手過程與 TLS 中的握手過程非常相似，交換客戶端和服務(wù)器“hello”消息，但服務(wù)器還可以發(fā)送驗(yàn)證查詢以確?？蛻舳苏诎l(fā)送其“hello”消息來自真實(shí)的源地址。此機(jī)制有助于防止拒絕服務(wù)攻j。通過這些消息，客戶端和服務(wù)器還交換支持的密m組和密鑰，并同意雙方支持的，這將進(jìn)一步用于通信過程中的數(shù)據(jù)交換保護(hù)。
由于 DTLS 最初不是為物聯(lián)網(wǎng)和受限設(shè)備設(shè)計(jì)的，因此最近出現(xiàn)了針對(duì)輕量級(jí)設(shè)備優(yōu)化的新版本 。一些旨在使其更輕量級(jí)的 DTLS 優(yōu)化機(jī)制包括 IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) 報(bào)頭壓縮機(jī)制，以壓縮 DTLS 報(bào)頭。由于其局限性，為物聯(lián)網(wǎng)優(yōu)化 DTLS 仍然是一個(gè)懸而未決的問題。
（3）MQTT協(xié)議
MQTT 是遵循發(fā)布-訂閱范式的輕量級(jí)消息傳遞協(xié)議之一，這使得它非常適合資源受限的設(shè)備和非理想的網(wǎng)絡(luò)連接條件，例如低帶寬和高延遲。 MQTT 由 IBM 發(fā)布，其最新版本 MQTT v3.1 被 OASIS 用于物聯(lián)網(wǎng)。由于其簡單性和與其他消息傳遞協(xié)議相比非常小的消息頭，它通常被推薦為物聯(lián)網(wǎng)中的首選通信解決方案。 MQTT 運(yùn)行在 TCP 傳輸協(xié)議之上，確保了其可靠性。與 HTTP 等其他可靠協(xié)議相比，由于其更輕的標(biāo)頭，MQTT 具有更低的功耗要求，使其成為受限環(huán)境中最突出的協(xié)議解決方案之一。
MQTT 架構(gòu)中有兩個(gè)通信方，它們通常扮演發(fā)布者和訂閱者的角色——客戶端和服務(wù)器/代理?？蛻舳耸强梢园l(fā)布消息、訂閱接收消息或兩者兼有的設(shè)備。客戶端必須知道它連接到的代理，并且對(duì)于它的訂閱者角色，它必須知道它正在訂閱的主題?？蛻舳擞嗛喬囟ㄖ黝}，以便接收相應(yīng)的消息。但是，其他客戶端也可以訂閱相同的主題，并在新消息到達(dá)時(shí)從代理獲取更新。 Broker 作為一個(gè)中心組件，接受客戶端發(fā)布的消息，并在主題和過濾的幫助下，將它們傳遞給訂閱的客戶端。
在 MQTT 中，可以使用發(fā)布-訂閱交互模型，如圖 5 所示。通信發(fā)生在代理和兩個(gè) MQTT 客戶端(發(fā)布者和訂閱者)之間。對(duì)于具有代理角色的設(shè)備，必須安裝 MQTT 代理庫，例如 Mosquitto 代理，它是最著名的開源 MQTT 代理之一。應(yīng)該注意的是，還有各種其他 MQTT 協(xié)議代理可供使用，它們在 MQTT 協(xié)議的實(shí)現(xiàn)方式上有所不同。比如 Emqttd 、ActiveMQ、HiveMQ 、IBM MessageSight 、JoramMQ 、RabbitMQ 和 VerneMQ?？蛻舳耸峭ㄟ^安裝 MQTT 客戶端庫實(shí)現(xiàn)的。發(fā)布者將標(biāo)簽主題創(chuàng)建到代理中，如圖 5 所示。MQTT 中的主題被視為層次結(jié)構(gòu)，字符串由斜線分隔，表示主題級(jí)別。一個(gè) MQTT 發(fā)布者可以將消息發(fā)布到一組定義的主題。在這種情況下，客戶端將發(fā)布主題：topic/1。此信息將發(fā)布到代理，代理可以將其臨時(shí)存儲(chǔ)在本地?cái)?shù)據(jù)庫中。對(duì)此主題感興趣的訂閱者向代理發(fā)送訂閱消息，指定相同的主題。
對(duì)于 QoS，MQTT 定義了三個(gè) QoS 級(jí)別：QoS 0、1 和 2。級(jí)別的選擇可以在發(fā)布和訂閱消息體中定義。 QoS 0 盡最大努力交付，無需確認(rèn)消息接收。在某些傳感器在較長時(shí)間內(nèi)收集遙測信息并且傳感器值沒有明顯變化的情況下，這是一種選擇。如果有時(shí)消息丟失是可以接受的，因?yàn)榇蠖鄶?shù)消息更新已被接收，所以一般傳感器值仍然是已知的。下一級(jí)保證是 QoS 1，它保證消息將到達(dá)，因此消息確認(rèn)是必要的。這意味著接收者必須發(fā)送一個(gè)確認(rèn)，如果它沒有在定義的時(shí)間段內(nèi)到達(dá)，發(fā)布者將再次發(fā)送一個(gè)發(fā)布消息。第三個(gè)選項(xiàng) QoS 2 保證消息將只傳遞一次而不會(huì)重復(fù)。處理 MQTT 數(shù)據(jù)包所需的資源量隨著選擇的 QoS 級(jí)別的增加而增加，因此根據(jù)特定的網(wǎng)絡(luò)條件調(diào)整 QoS 選擇非常重要。
MQTT 提供的另一個(gè)重要特性是可以通過在已發(fā)布消息中設(shè)置“保留”標(biāo)志來為新訂閱者存儲(chǔ)一些消息。如果沒有人對(duì)發(fā)布者發(fā)送更新的主題感興趣，代理將丟棄已發(fā)布的消息。但是，在某些情況下，特別是當(dāng)關(guān)注主題的狀態(tài)不經(jīng)常變化時(shí)，讓新訂閱者能夠接收有關(guān)該主題的信息是有用的。在這種默認(rèn)情況下，新訂閱者必須等待狀態(tài)更改才能接收有關(guān)該主題的消息。通過將“保留”標(biāo)志設(shè)置為 true，代理會(huì)被告知它應(yīng)該存儲(chǔ)已發(fā)布的消息，以便可以將其傳遞給新的訂閱者。
MQTT 使用 TCP，這對(duì)于受限設(shè)備至關(guān)重要。為此已經(jīng)提出了一種解決方案，即 MQTT for Sensor Networks (MQTT-SN) 版本，它使用 UDP 并支持主題名稱索引。該解決方案不依賴于 TCP，而是使用 UDP 作為無線鏈路上更快、更簡單、更高效的傳輸選擇。另一個(gè)重要的改進(jìn)特性是有效載荷的減小。這是通過使用數(shù)字主題 id 而不是長主題名稱對(duì)數(shù)據(jù)包進(jìn)行編號(hào)來完成的。最大的缺點(diǎn)是目前 MQTT-SN 僅被少數(shù)幾個(gè)平臺(tái)支持，并且已知只有一種免費(fèi)的代理實(shí)現(xiàn)。
由于它被設(shè)計(jì)為輕量級(jí)，MQTT 不提供加密，而是以純文本形式交換數(shù)據(jù)，從安全角度來看，這顯然是一個(gè)問題。因此，加密需要作為一個(gè)單獨(dú)的功能來實(shí)現(xiàn)，例如通過 TLS，另一方面這會(huì)增加開銷。身份驗(yàn)證由許多 MQTT 代理通過一種 MQTT 控制類型消息包(稱為 CONNECT)來實(shí)現(xiàn)。 Broker 要求客戶端在發(fā)送 CONNECT 消息時(shí)，應(yīng)在驗(yàn)證連接之前定義用戶名/密m組合，或者在身份驗(yàn)證不成功時(shí)拒絕它。總體而言，安全性是 MQTT的一項(xiàng)持續(xù)努力，并且可能是最重要的一項(xiàng)，因?yàn)?MQTT 是最廣泛采用和最成熟的通信協(xié)議解決方案之一。與其他可用解決方案相比，解決安全問題將為 MQTT 創(chuàng)造重要且巨大的優(yōu)勢。
（4）DDS協(xié)議
DDS 是一種以數(shù)據(jù)為中心的實(shí)時(shí)互操作性標(biāo)準(zhǔn)，它使用由對(duì)象管理組 (OMG) 定義的發(fā)布-訂閱交互模型。與其他一些發(fā)布訂閱協(xié)議不同，DDS 是分散的并且基于對(duì)等通信，因此不依賴于代理組件。在 DDS 中，發(fā)布者和訂閱者可以通過數(shù)據(jù)總線作為對(duì)等方進(jìn)行通信，從而可以根據(jù)他們的興趣進(jìn)行異步數(shù)據(jù)交換。沒有代理人也降低了系統(tǒng)故障的可能性，因?yàn)檎麄€(gè)系統(tǒng)沒有單點(diǎn)故障，使系統(tǒng)更加可靠。通信雙方相互解耦，即使沒有感興趣的訂閱者，發(fā)布者也可以發(fā)布數(shù)據(jù)。數(shù)據(jù)使用基本上是匿名的，因?yàn)榘l(fā)布者不會(huì)詢問誰在使用他們的數(shù)據(jù)。
DDS 協(xié)議的顯著特點(diǎn)之一是它的可擴(kuò)展性，這來自于它對(duì)動(dòng)態(tài)發(fā)現(xiàn)的支持。通過 DDS 內(nèi)置發(fā)現(xiàn)協(xié)議實(shí)現(xiàn)的發(fā)現(xiàn)過程允許訂閱者找出存在哪些發(fā)布者，并使用定義的所需服務(wù)質(zhì)量指定他們感興趣的信息，并允許發(fā)布者發(fā)布他們的數(shù)據(jù)。 DDS 確保正確的發(fā)布和訂閱節(jié)點(diǎn)將被連接并且數(shù)據(jù)交換將是實(shí)時(shí)的。與大多數(shù)以消息為中心的協(xié)議不同，DDS 的另一個(gè)重要且獨(dú)特的特性是它的數(shù)據(jù)中心性。對(duì)于以數(shù)據(jù)為中心的特點(diǎn)，最重要的是客戶想要訪問的數(shù)據(jù)，因此重點(diǎn)是內(nèi)容信息本身。因此，DDS 實(shí)現(xiàn)了一種架構(gòu)，其中參與節(jié)點(diǎn)以一致的方式理解數(shù)據(jù)值。在 DDS 中，數(shù)據(jù)類型和內(nèi)容定義了通信，而在以消息為中心的協(xié)議中，重點(diǎn)在于傳遞該數(shù)據(jù)的操作和機(jī)制。當(dāng)系統(tǒng)架構(gòu)師定義所謂的主題時(shí)，可以使用 DDS 的以數(shù)據(jù)為中心的方法，通過將邏輯上相關(guān)的數(shù)據(jù)項(xiàng)分組在一起，以確保更好的可伸縮性和性能結(jié)果。
DDS 架構(gòu)中的主要實(shí)體包括域、域參與者、主題、發(fā)布者、訂閱者、數(shù)據(jù)寫入器和數(shù)據(jù)讀取器。發(fā)布者和訂閱者分為域，一個(gè)虛擬概念實(shí)體，允許隔離具有共同興趣的節(jié)點(diǎn)內(nèi)的通信。 Domain Participant (域參與者)是特定域中消息交換的入口點(diǎn)，它將發(fā)布者和訂閱者及其所屬的域關(guān)聯(lián)起來。它用于在域內(nèi)創(chuàng)建發(fā)布者、訂閱者、數(shù)據(jù)寫入者、數(shù)據(jù)讀取者和主題。 DDS 實(shí)現(xiàn)中間件以數(shù)據(jù)為主要定義交互的方式，定義了數(shù)據(jù)在抽象數(shù)據(jù)空間中的結(jié)構(gòu)、更改和訪問方式，目標(biāo)是創(chuàng)建全局共享數(shù)據(jù)。實(shí)現(xiàn)這一點(diǎn)的方法是通過數(shù)據(jù)空間抽象，所有客戶端都可以訪問以讀取或存儲(chǔ)他們的數(shù)據(jù)，稱為全局?jǐn)?shù)據(jù)空間 (GDS)。正是在 GDS 中，DDS 動(dòng)態(tài)發(fā)現(xiàn)功能通過允許加入 GDS 的發(fā)布者和訂閱者自動(dòng)發(fā)現(xiàn)他們的共同存在以及他們的興趣而發(fā)揮作用。 GDS中DDS節(jié)點(diǎn)之間的交換信息單元是Topic，由名稱、數(shù)據(jù)類型和一組QoS策略定義。發(fā)布者和訂閱者是數(shù)據(jù)分發(fā)和消費(fèi)的實(shí)體，它們通過 GDS 發(fā)布和接收數(shù)據(jù)，但不能單獨(dú)完成。相反，發(fā)布者使用數(shù)據(jù)寫入器發(fā)送數(shù)據(jù)，訂閱者使用數(shù)據(jù)讀取器接收數(shù)據(jù)，兩者通過主題進(jìn)行匹配;也就是說，為了相互通信，發(fā)布者和訂閱者必須使用相同的主題(相同的名稱、類型和兼容的 QoS)。
DDS 默認(rèn)使用 UDP，但也可以支持 TCP。 DDS 中的另一個(gè)重要協(xié)議是實(shí)時(shí)發(fā)布訂閱 (RTPS)有線協(xié)議，它代表 DDS 互操作性協(xié)議，允許在不同供應(yīng)商實(shí)現(xiàn)之間共享數(shù)據(jù)。使用 DDS 的優(yōu)點(diǎn)之一是提供了廣泛的 QoS 策略(標(biāo)準(zhǔn)定義的超過 20 種 QoS)。發(fā)送數(shù)據(jù)時(shí)，每個(gè)主題、數(shù)據(jù)寫入者和發(fā)布者的 QoS 策略控制數(shù)據(jù)發(fā)送到中間件的方式和時(shí)間。另一方面，主題 QoS、數(shù)據(jù)讀取器和訂閱者控制接收數(shù)據(jù)時(shí)的行為。這些不同的策略管理著無數(shù)的 DDS 功能，例如分布式遠(yuǎn)程實(shí)體的發(fā)現(xiàn)、數(shù)據(jù)傳遞、數(shù)據(jù)可用性、時(shí)間和資源利用率。
對(duì)于安全機(jī)制，DDS 實(shí)現(xiàn)了各種解決方案。根據(jù)選擇的傳輸協(xié)議，如果 TCP 是傳輸協(xié)議，則可以使用 TLS，如果使用 UDP，則可以使用 DTLS 協(xié)議。同樣，對(duì)于 TLS，DTLS 在受限環(huán)境中也帶來了過多的開銷，為此已經(jīng)提出了改進(jìn)的機(jī)制。為此，OMG DDS 安全規(guī)范定義了一個(gè)廣泛的安全模型和服務(wù)插件接口 (SPI) 架構(gòu)，專為適用于物聯(lián)網(wǎng)系統(tǒng)的 DDS 實(shí)現(xiàn)而設(shè)計(jì)。安全規(guī)范的問題目前對(duì)于 DDS 來說仍然是一個(gè)開放的問題，預(yù)計(jì)將來會(huì)實(shí)施新的補(bǔ)充。預(yù)期的新增功能之一是能夠在具有匹配安全分類的基于 DDS 的應(yīng)用程序之間建立安全傳輸流的安全發(fā)現(xiàn)機(jī)制。
DDS 是基于物聯(lián)網(wǎng)的環(huán)境的重要解決方案，因?yàn)樗哂蟹稚⒌陌l(fā)布/訂閱架構(gòu)，并且支持在功能強(qiáng)大的設(shè)備和受限設(shè)備中實(shí)現(xiàn)。 DDS 的一個(gè)挑戰(zhàn)是它尚未被廣泛使用，盡管這可能會(huì)隨著準(zhǔn)備測試的新興開源 DDS 實(shí)現(xiàn)而改變，例如 OpenDDS。
（5）AMQP協(xié)議
AMQP 是遵循 OASIS定義的發(fā)布-訂閱范式的開放標(biāo)準(zhǔn)協(xié)議，旨在實(shí)現(xiàn)各種不同應(yīng)用程序和系統(tǒng)之間的互操作性，而不管其內(nèi)部設(shè)計(jì)如何。最初它是為商業(yè)消息傳遞而開發(fā)的，其想法是提供一種非專有解決方案，可以管理系統(tǒng)中可能在短時(shí)間內(nèi)發(fā)生的大量消息交換。這種 AMQP 互操作性特性非常重要，因?yàn)樗试S以不同語言實(shí)現(xiàn)的不同平臺(tái)交換消息，這在異構(gòu)系統(tǒng)中可能特別有用。
AMQP 已經(jīng)在兩個(gè)非常不同的版本中實(shí)現(xiàn)，AMQP 0.9.1 和 AMQP 1.0，每個(gè)版本都具有完全不同的消息傳遞范例。 AMQP 0.9.1 實(shí)現(xiàn)了發(fā)布-訂閱范式，它圍繞兩個(gè)主要的 AMQP 實(shí)體，都是 AMQP 代理的一部分：交換和消息隊(duì)列。交換代表代理的一部分，用于引導(dǎo)從發(fā)布者接收到的消息。將消息發(fā)布到交換實(shí)體是該過程的第一步，然后將消息路由到一個(gè)或多個(gè)適當(dāng)?shù)年?duì)列中。這取決于是否有更多訂閱者對(duì)特定消息感興趣，在這種情況下，代理可以復(fù)制消息并將其副本發(fā)送到多個(gè)隊(duì)列。消息將保留在隊(duì)列中，直到被訂閱者接收。這個(gè)實(shí)際連接交換和隊(duì)列的路由過程依賴于所謂的綁定，它們是消息分發(fā)的預(yù)定義規(guī)則和條件。另一方面，較新版本的 AMQP 協(xié)議， AMQP 1.0 不依賴于任何特定的消息傳遞機(jī)制。雖然舊版本的協(xié)議專門使用上述發(fā)布-訂閱方法以及由交換和消息隊(duì)列組成的架構(gòu)，但新的 AMQP 實(shí)現(xiàn)遵循對(duì)等范式，并且可以在沒有中間代理的情況下使用。 Broker 僅存在于需要提供存儲(chǔ)轉(zhuǎn)發(fā)機(jī)制的通信中，而在其他情況下，直接消息傳遞是可能的。這種支持不同拓?fù)涞倪x項(xiàng)增加了可能的基于 AMQP 的解決方案的靈活性，支持不同的通信模式，例如客戶端到客戶端、客戶端到代理和代理到代理。應(yīng)該注意的是，大量的基礎(chǔ)設(shè)施仍然使用舊的 AMQP 0.9 版本。
AMQP 使用 TCP 進(jìn)行可靠傳輸，此外它還提供三個(gè)不同級(jí)別的 QoS，與 MQTT 相同。最后，AMQP 協(xié)議提供了互補(bǔ)的安全機(jī)制，通過使用 TLS 協(xié)議進(jìn)行加密來保護(hù)數(shù)據(jù)，并通過使用 SASL(簡單身份驗(yàn)證和安全層)進(jìn)行身份驗(yàn)證。
憑借其提供的所有功能，AMQP 具有相對(duì)較高的功率、處理和內(nèi)存相關(guān)要求，使其成為一個(gè)相當(dāng)繁重的協(xié)議，這一直是其在基于 IoT 的生態(tài)系統(tǒng)中的最大劣勢。該協(xié)議更適合系統(tǒng)中不受帶寬和延遲限制的部分，具有更強(qiáng)的處理能力。
（6）XMPP (可擴(kuò)展消息傳遞和存在協(xié)議)
XMPP 是由 IETF 形式化的開放標(biāo)準(zhǔn)消息傳遞協(xié)議，最初設(shè)計(jì)用于即時(shí)消息傳遞和應(yīng)用程序之間的消息交換。它是一個(gè)基于文本的協(xié)議，基于可擴(kuò)展標(biāo)記語言 (XML)，實(shí)現(xiàn)客戶端-服務(wù)器和發(fā)布訂閱交互，運(yùn)行在 TCP 上。在物聯(lián)網(wǎng)解決方案中，除了管理用戶的存在外，它還旨在允許用戶實(shí)時(shí)發(fā)送消息。 XMPP 允許即時(shí)消息傳遞應(yīng)用程序?qū)崿F(xiàn)所有基本功能，包括身份驗(yàn)證、端到端加密以及與其他協(xié)議的兼容性。
XMPP 支持客戶端-服務(wù)器交互模型，但也有新的擴(kuò)展支持使用通用的發(fā)布-訂閱模型。這些擴(kuò)展使 XMPP 實(shí)體能夠創(chuàng)建主題和發(fā)布信息;然后將事件通知廣播到已訂閱特定節(jié)點(diǎn)的所有實(shí)體。此功能對(duì)于 IoT-fog-cloud 場景非常重要，是需要事件通知的各種應(yīng)用程序的基礎(chǔ)。 XMPP 中的客戶端和服務(wù)器使用 XML 流相互通信，以 XML 節(jié)(語義結(jié)構(gòu)化數(shù)據(jù)單元)的形式交換數(shù)據(jù)。定義了三種類型的節(jié)：、、n d (信息/查詢)。消息節(jié)定義消息標(biāo)題和內(nèi)容，用于在 XMPP 實(shí)體之間發(fā)送數(shù)據(jù)。消息節(jié)不會(huì)收到接收實(shí)體的確認(rèn)，無論它是客戶端還是服務(wù)器。存在節(jié)顯示并通知實(shí)體狀態(tài)更新，在 XMPP 中具有訂閱的作用。如果對(duì)某個(gè) JID(Jaber ID - XMPP 中的節(jié)點(diǎn)地址)的存在感興趣，則客戶端訂閱他們的存在，并且每次節(jié)點(diǎn)發(fā)送存在更新時(shí)都會(huì)通知客戶端。 iq 節(jié)將消息發(fā)送者和接收者配對(duì)。它用于從服務(wù)器獲取一些信息(例如，有關(guān)服務(wù)器或其注冊客戶端的信息)，或?qū)⒁恍┰O(shè)置應(yīng)用于服務(wù)器。它的功能類似于 HTTP GET 和 POST 方法。
該協(xié)議最重要的特征之一是其安全特性，這使其成為所調(diào)查的更安全的消息傳遞協(xié)議之一。與所調(diào)查的其他協(xié)議(例如 MQTT 和 CoAP)不同，在協(xié)議規(guī)范中沒有內(nèi)置 TLS 和 DTLS 加密，XMPP 規(guī)范已經(jīng)包含 TLS 機(jī)制，它提供了一種可靠的機(jī)制來確保機(jī)密性和數(shù)據(jù)完整性。 XMPP 規(guī)范的新增內(nèi)容還包括與安全、身份驗(yàn)證、隱私和訪問控制相關(guān)的擴(kuò)展。除了 TLS，XMPP 還實(shí)現(xiàn)了 SASL，它通過特定于 XMPP 的配置文件來保證服務(wù)器驗(yàn)證。
表 2 概述了為使這些協(xié)議與受限環(huán)境更兼容的持續(xù)努力。
由于 XMPP 最初是為即時(shí)消息而設(shè)計(jì)的，因此存在一些明顯的潛在弱點(diǎn)。通過使用 XML，消息的大小使其在帶寬受限的網(wǎng)絡(luò)中變得不方便。另一個(gè)缺點(diǎn)是缺乏可靠的 QoS 保證。由于 XMPP 在持久的 TCP 連接之上運(yùn)行并且缺乏有效的二進(jìn)制編碼，因此在通常與物聯(lián)網(wǎng)技術(shù)相關(guān)的有損、低功耗無線網(wǎng)絡(luò)上使用它并不實(shí)用。然而，最近，為了使 XMPP 更適合物聯(lián)網(wǎng)，人們付出了很多努力。有研究人員針對(duì)資源受限的物聯(lián)網(wǎng)設(shè)備提出了一種輕量級(jí) XMPP 發(fā)布/訂閱方案，從而改進(jìn)和優(yōu)化了同一協(xié)議的現(xiàn)有版本。
