軟體和硬體領域技術的發展、新通訊協定的出現導致了物聯網（IoT）的擴展。 設備的數量日益增長，並產生大量數據。 因此，需要一種能夠處理、儲存和傳輸這些資料的方便的系統架構。
現在雲端服務用於這些目的。 然而，日益流行的霧運算範式（Fog）可以透過擴展和優化物聯網基礎設施來補充雲端解決方案。
雲端能夠滿足大多數物聯網請求。 例如，提供服務監控、快速處理設備產生的任意數量的資料及其視覺化。 霧計算在解決即時問題時更加有效。 它們提供對請求的快速回應和最小的資料處理延遲。 也就是說，Fog 補充了「雲」並擴展了其功能。
然而，主要問題是不同的：所有這些應該如何在物聯網背景下相互作用？ 在物聯網-霧-雲組合系統中工作時，哪些通訊協定最有效？
儘管 HTTP 佔據了明顯的主導地位，但物聯網、霧和雲端系統中也使用了大量其他解決方案。 這是因為物聯網必須將各種裝置感測器的功能與使用者的安全性、相容性和其他要求結合。
但關於參考架構和通訊標準根本沒有單一的想法。 因此，針對特定物聯網任務創建新協定或修改現有協定是 IT 社群面臨的最重要任務之一。
目前正在使用哪些協議以及它們可以提供什麼？ 讓我們弄清楚一下。 但首先，讓我們先討論一下雲、霧和物聯網相互作用的生態系統的原理。
物聯網霧到雲 (F2C) 架構
您可能已經注意到，人們付出了多少努力來探索與物聯網、雲和霧的智慧和協調管理相關的優勢和好處。 如果沒有，那麼這裡有三個標準化措施： , и .
如果以前只考慮雲端和終端設備這兩個級別，那麼所提出的架構引入了一個新級別——霧運算。 在這種情況下，霧級別可以分為幾個子級別，具體取決於資源的具體情況或確定這些子級別中不同設備的使用的一組策略。
這個抽象可能是什麼樣的呢？ 這是一個典型的物聯網-霧-雲生態系統。 物聯網設備將資料傳送到更快的伺服器和運算設備，以解決需要低延遲的問題。 在同一個系統中，雲端負責解決需要大量運算資源或資料儲存空間的問題。
智慧型手機、智慧型手錶和其他小工具也可以成為物聯網的一部分。 但此類設備通常使用大型開發商的專有通訊協定。 產生的物聯網資料透過 REST HTTP 協定傳輸到霧層，這在建立 RESTful 服務時提供了靈活性和互通性。 鑑於需要確保與本機電腦、伺服器或伺服器叢集上運行的現有運算基礎設施向後相容，這一點非常重要。 本地資源（稱為“霧節點”）過濾接收到的資料並在本地進行處理或將其發送到雲端進行進一步計算。
雲端支援不同的通訊協議，最常見的是 AMQP 和 REST HTTP。 由於 HTTP 眾所周知並且是為互聯網量身定制的，因此可能會出現這樣的問題：“我們不應該使用它來處理物聯網和霧嗎？” 然而，該協定存在效能問題。 稍後會詳細介紹這一點。
一般來說，有2種通訊協定模型適合我們需要的系統。 這些是請求-回應和發布-訂閱。 第一個模型更廣為人知，尤其是在伺服器-客戶端架構中。 客戶端向伺服器請求訊息，伺服器接收請求、處理請求並傳回回應訊息。 REST HTTP 和 CoAP 協定在此模型上運行。
第二種模型源自於在產生資料的來源和該資料的接收者之間提供非同步、分散式、鬆散耦合的需要。
此模型假設三個參與者：發布者（資料來源）、代理程式（調度者）和訂閱者（接收者）。 這裡，充當訂閱者的客戶端不必向伺服器請求資訊。 它不發送請求，而是透過代理訂閱系統中的某些事件，代理負責過濾所有傳入訊息並在發布者和訂閱者之間路由它們。 當有關某個主題的事件發生時，發布者將其發佈到代理，代理將有關所請求主題的資料發送給訂閱者。
本質上，該架構是基於事件的。 這種互動模型對於物聯網、雲、霧中的應用很有趣，因為它能夠提供可擴展性並簡化不同設備之間的互連，支援動態多對多通訊和非同步通訊。 一些使用發布-訂閱模型的最著名的標準化訊息傳遞協定包括 MQTT、AMQP 和 DDS。
顯然，發布訂閱模式有許多優點：
- 發布者和訂閱者不需要知道彼此的存在；
- 一個訂閱者可以從多個不同的發布者接收訊息，一個發布者可以向多個不同的訂閱者發送資料（多對多原則）；
- 發布者和訂閱者不必同時處於活動狀態才能進行通信，因為代理（作為排隊系統工作）將能夠為當前未連接到網路的用戶端儲存訊息。
然而，請求-回應模型也有其優點。 如果伺服器端處理多個客戶端請求的能力不是問題，那麼使用經過驗證的可靠解決方案是有意義的。
還有支持這兩種模型的協定。 例如，XMPP和HTTP 2.0，它們支援「伺服器推送」選項。 IETF 也發布了 CoAP。 為了解決訊息傳遞問題，人們還創建了其他幾種解決方案，例如 WebSockets 協定或透過 QUIC（快速 UDP 網際網路連線）使用 HTTP 協定。
就 WebSocket 而言，儘管它用於從伺服器到 Web 用戶端即時傳輸資料並提供持續連接和同步雙向通信，但它不適用於計算資源有限的設備。 QUIC 也值得關注，因為新的傳輸協定提供了許多新的機會。 但由於 QUIC 尚未標準化，因此預測其可能的應用及其對物聯網解決方案的影響還為時過早。 因此，我們著眼於未來，牢記 WebSockets 和 QUIC，但現在我們不會更詳細地研究它。
誰是世界上最可愛的人：比較協議
現在讓我們來談談協議的優點和缺點。 展望未來，讓我們立即做出保留，沒有一個明確的領導者。 每個協議都有一些優點/缺點。
響應時間
通訊協定最重要的特徵之一是回應時間，尤其是與物聯網相關的協定。 但在現有協議中，沒有明顯的贏家能夠證明在不同條件下工作時的最低延遲水平。 但對協議功能進行了大量的研究和比較。
例如， 在使用 IoT 時，對 HTTP 和 MQTT 的有效性進行比較表明，MQTT 請求的回應時間比 HTTP 短。 什麼時候 MQTT 和 CoAP 的往返時間 (RTT) 表明，CoAP 的平均 RTT 比 MQTT 低 20%。
其他 MQTT 和 CoAP 協定的 RTT 在本地網路和物聯網網路兩種場景中進行。 事實證明，物聯網網路中的平均 RTT 高出 2-3 倍。 與 CoAP 相比，具有 QoS0 的 MQTT 顯示出較低的結果，而由於應用層和傳輸層的 ACK，具有 QoS1 的 MQTT 顯示了更高的 RTT。 對於不同的 QoS 級別，無擁塞的網路延遲對於 MQTT 為毫秒級，對於 CoAP 為數百微秒。 然而，值得記住的是，當在不太可靠的網路上工作時，運行在 TCP 之上的 MQTT 將顯示完全不同的結果。
透過增加有效負載，AMQP 和 MQTT 協定的回應時間表明，輕負載時，延遲水準幾乎相同。 但當傳輸大量資料時，MQTT 表現出更短的回應時間。 又一個 在機器對機器通訊場景中將 CoAP 與 HTTP 進行比較，其中設備部署在配備有氣體感測器、天氣感測器、位置感測器 (GPS) 和行動網路介面 (GPRS) 的車輛頂部。 透過行動網路傳輸 CoAP 訊息所需的時間幾乎比使用 HTTP 訊息所需的時間短三倍。
已經進行的研究不是比較兩個協議，而是三個協議。 例如， 使用網路模擬器在醫療應用場景中評估物聯網協定 MQTT、DDS 和 CoAP 的效能。 在各種較差的網路條件下測試的遙測延遲方面，DDS 的效能優於 MQTT。 基於 UDP 的 CoAP 對於需要快速回應時間的應用程式效果很好，但是，由於它是基於 UDP 的，因此存在嚴重的不可預測的封包遺失。
容量
MQTT 和 CoAP 在頻寬效率方面是透過計算每個訊息傳輸的資料總量來進行的。 在傳輸小訊息時，CoAP 的吞吐量低於 MQTT。 但是，當根據有用資訊位元組數與傳輸位元組總數的比率來比較協定效率時，CoAP 更為有效。
在 使用MQTT、DDS（以TCP 作為傳輸協定）和CoAP 頻寬，發現CoAP 通常表現出相對較低的頻寬消耗，並且不會隨著網路丟包或網路延遲的增加而增加，這與MQTT 和DDS 不同，其中上述場景中頻寬利用率的增加。 另一個場景涉及大量設備同時傳輸數據，這在物聯網環境中很常見。 結果表明，為了獲得更高的利用率，最好使用 CoAP。
在輕負載下，CoAP 使用的頻寬最少，其次是 MQTT 和 REST HTTP。 然而，當有效負載的大小增加時，REST HTTP 具有最佳結果。
功耗
能源消耗問題始終非常重要，尤其是在物聯網系統中。 如果 MQTT 和 HTTP 都消耗電力，但 HTTP 消耗的電力更多。 CoAP 更 與 MQTT 相比，允許電源管理。 然而，在簡單的場景中，MQTT更適合在物聯網網路中交換訊息，特別是在沒有功率限制的情況下。
在行動或不穩定的無線網路測試台上比較 AMQP 和 MQTT 功能的實驗發現，AMQP 提供更多安全功能，而 MQTT 更節能。
安全
安全性是研究物聯網和霧/雲端運算主題時提出的另一個關鍵問題。 安全機制通常基於 HTTP、MQTT、AMQP 和 XMPP 中的 TLS 或 CoAP 中的 DTLS，並支援這兩種 DDS 變體。
TLS 和 DTLS 從在客戶端和伺服器端之間建立通訊以交換支援的密碼套件和金鑰的過程開始。 雙方協商設定以確保進一步的通訊在安全通道上進行。 兩者之間的區別在於一些小的修改，允許基於 UDP 的 DTLS 在不可靠的連接上工作。
在 TLS 和 DTLS 的幾種不同實作發現 TLS 做得更好。 由於其容錯能力，對 DTLS 的攻擊更加成功。
然而，這些協定的最大問題是它們最初並不是為物聯網而設計的，也不適合在霧或雲端中工作。 透過握手，它們會在每次連接建立時增加額外的流量，從而耗盡計算資源。 平均而言，與沒有安全層的通訊相比，TLS 的開銷平均增加了 6,5%，DTLS 的開銷增加了 11%。 在資源豐富的環境中，通常位於 在物聯網層面，這不會是一個問題，但在物聯網和霧層面的連結中，這成為一個重要的限制。
選擇什麼？ 沒有明確的答案。 MQTT 和 HTTP 似乎是最有前景的協議，因為與其他協議相比，它們被認為是相對更成熟、更穩定的物聯網解決方案。
基於統一通訊協定的解決方案
單協議解決方案的實踐有很多缺點。 例如，適合受限環境的協定可能無法在具有嚴格安全要求的網域中運作。 考慮到這一點，我們只能放棄物聯網霧到雲端生態系統中幾乎所有可能的單協定解決方案，除了 MQTT 和 REST HTTP。
REST HTTP 作為單一協定解決方案
有一個很好的範例說明 REST HTTP 請求和回應如何在 IoT-to-Fog 空間中互動： 。 這些動物配備了可穿戴感測器（物聯網客戶端，C），並由智慧農業系統（霧伺服器，S）透過雲端運算進行控制。
POST 方法的標頭指定要修改的資源 (/farm/animals) 以及 HTTP 版本和內容類型，在本例中是一個 JSON 對象，表示系統要管理的動物農場 (Dulcinea/cow) 。 伺服器的回應透過傳送 HTTPS 狀態碼 201（資源已建立）表示請求成功。 GET 方法必須僅在 URI 中指定請求的資源（例如，/farm/animals/1），這會從伺服器傳回具有該 ID 的動物的 JSON 表示形式。
當需要更新某些特定資源記錄時，使用 PUT 方法。 在這種情況下，資源指定要變更的參數的 URI 和目前值（例如，指示牛目前正在行走，/farm/animals/1? state=walking）。 最後，DELETE 方法與 GET 方法的用法相同，但只是刪除操作結果的資源。
MQTT 作為單一協議解決方案
讓我們採用相同的智慧農場，但我們使用 MQTT 協定而不是 REST HTTP。 安裝了 Mosquitto 庫的本機伺服器充當代理。 在此範例中，一台簡單的電腦（稱為場伺服器）Raspberry Pi 充當 MQTT 用戶端，透過安裝 Paho MQTT 庫實現，該程式庫與 Mosquitto 代理完全相容。
此客戶端對應於代表具有感測和運算能力的設備的物聯網抽象層。 另一方面，中介者對應於更高層次的抽象，代表具有更大處理和儲存能力的霧運算節點。
在所提出的智慧農場場景中，Raspberry Pi 連接到加速度計、GPS 和溫度感測器，並將這些感測器的數據發佈到霧節點。 您可能知道，MQTT 將主題視為層次結構。 單一 MQTT 發布者可以將訊息發佈到一組特定的主題。 在我們的例子中，有三個。 對於測量動物穀倉溫度的感測器，客戶選擇一個主題（動物農場/棚/溫度）。 對於透過加速度計測量 GPS 位置和動物運動的感測器，客戶端將發布更新至 (animalfarm/animal/GPS) 和 (animalfarm/animal/movement)。
這些資訊將傳遞給經紀人，經紀人可以將其暫時儲存在本地資料庫中，以防稍後出現另一個有興趣的訂閱者。
除了在霧中充當 MQTT 代理並由充當 MQTT 用戶端的 Raspberry Pi 向其發送感測器資料的本機伺服器之外，還可以在雲端層級存在另一個 MQTT 代理。 在這種情況下，傳輸到本地代理的資訊可以暫時儲存在本地資料庫中和/或發送到雲端。 在這種情況下，霧 MQTT 代理用於將所有資料與雲端 MQTT 代理程式關聯起來。 透過這種架構，行動應用程式用戶可以訂閱兩個經紀商。
如果與其中一個代理程式（例如雲端）的連線失敗，最終用戶將收到來自另一個代理程式（例如雲端）的訊息。 這是霧和雲端運算相結合的系統的一個特徵。 預設情況下，行動應用程式可以配置為首先連接到霧 MQTT 代理，如果失敗，則連接到雲端 MQTT 代理。 該解決方案只是 IoT-F2C 系統中的眾多解決方案之一。
多協定解決方案
單一協議解決方案因其更易於實施而廣受歡迎。 但很明顯，在 IoT-F2C 系統中，結合不同的協定是有意義的。 這個想法是不同的協議可以在不同的層級上運行。 以三個抽象為例：物聯網、霧、雲端運算層。 物聯網等級的設備通常被認為是有限的。 在本概述中，我們將物聯網層視為最受約束的層，將雲層視為受約束最小的層，將霧運算視為「中間的某個位置」。 事實證明，在物聯網和霧抽象之間，目前的協定解決方案包括 MQTT、CoAP 和 XMPP。 另一方面，在霧和雲端之間，AMQP 是使用的主要協定之一，也有 REST HTTP，由於其靈活性，也在物聯網和霧層之間使用。
這裡的主要問題是協定的互通性以及將訊息從一種協定傳輸到另一種協定的便利性。 理想情況下，未來雲霧資源的物聯網系統架構將獨立於所使用的通訊協議，並確保不同協議之間良好的互通性。
由於目前情況並非如此，因此將沒有顯著差異的協議組合起來是有意義的。 為此，一種潛在的解決方案是基於遵循相同架構風格的兩種協定的組合：REST HTTP 和 CoAP。 另一個提議的解決方案是基於提供發布-訂閱通訊的兩種協議的組合：MQTT 和 AMQP。 使用類似的概念（MQTT 和 AMQP 都使用代理，CoAP 和 HTTP 使用 REST）使得這些組合更容易實現，並且需要更少的整合工作。
圖 (a) 顯示了兩種基於請求-回應的模型：HTTP 和 CoAP，以及它們在 IoT-F2C 解決方案中的可能位置。 由於 HTTP 是現代網路上最知名和採用的協定之一，因此它不太可能被其他訊息傳遞協定完全取代。 在代表雲與霧之間強大設備的節點中，REST HTTP 是一種智慧解決方案。
另一方面，對於在霧層和物聯網層之間通訊的運算資源有限的設備，使用CoAP會更有效。 CoAP 的一大優點實際上是它與 HTTP 的兼容性，因為這兩種協定都基於 REST 原則。
圖(b)展示了同一場景下的兩種發布-訂閱通訊模型，包括MQTT和AMQP。 儘管假設這兩種協定都可以用於每個抽象層的節點之間的通信，但它們的位置應根據效能來確定。 MQTT 被設計為針對計算資源有限的設備的輕量級協議，因此可用於 IoT-Fog 通訊。 AMQP 更適合更強大的設備，這將理想地將其定位在霧和雲節點之間。 XMPP 協定可以取代 MQTT 用於物聯網，因為它被認為是輕量級的。 但在此類場景中應用並不那麼廣泛。
發現
所討論的協議之一不太可能足以覆蓋系統中的所有通信，從計算資源有限的設備到雲端伺服器。 研究發現，開發人員最常使用的兩個最有前景的選項是 MQTT 和 RESTful HTTP。 這兩個協議不僅是最成熟和穩定的，而且還包括許多有據可查且成功的實現和線上資源。
由於其穩定性和簡單的配置，MQTT 是一種協議，隨著時間的推移，在設備有限的物聯網層級使用時，它已經證明了其卓越的性能。 在系統中通訊有限且電池消耗不成問題的部分（例如某些霧域和大多數雲端運算）中，RESTful HTTP 是一個簡單的選擇。 CoAP 也應該被考慮在內，因為它作為物聯網訊息傳遞標準也在快速發展，並且很可能在不久的將來達到類似於 MQTT 和 HTTP 的穩定性和成熟度。 但該標準目前正在不斷發展，這就帶來了短期相容性問題。
您還可以在博客上閱讀什麼？
→
→
→
→
→
訂閱我們的 -頻道，以免錯過下一篇文章！ 我們每週寫信不超過兩次，而且僅限於公務。
來源： www.habr.com