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