物聯網數據傳輸協議說明

物聯網（IoT）和機器對機器（M2M）技術需要使用消息傳遞和連接協議，以便從遠程位置交換信息。

這種協議的一些可取的特點是：

·代碼占用空間?。ū阌谠谛⌒驮O備中實現）

·低功耗

·低帶寬消耗

·低延遲

使用發布/訂閱（“發布/訂閱”）模式

MQTT滿足了所有這些要求，并擁有大型公共云亞馬遜Web服務、Microsoft Azure和谷歌云平臺的動力。在本文中，我們將探討為什么MQTT是物聯網產品最流行的消息傳遞協議選擇。

什么是MQTT？

MQTT（消息隊列遙測傳輸）是由IBM開發并于1999年首次發布的輕量級消息傳遞協議。它使用pub/sub模式并在設備、服務器和應用程序之間轉換消息。

MQTT協議最初是為了將石油管道上的傳感器與通信衛星連接起來，重點是將電池損耗和帶寬消耗降至最低。

自成立以來，MQTT一直在進行開發，5.0版于2018年5月發布。版本3.1。1于2013年提交給OASIS財團，并被接受為ISO標準。

MQTT是如何工作的？

MQTT體系結構

MQTT協議中連接的設備稱為“客戶機”，它與稱為“代理”的服務器通信代理處理客戶端之間的數據傳輸任務。

每當客戶機（稱為“發布者”）想要發布信息時，它將發布到特定主題，然后代理將此信息發送給訂閱該主題的任何客戶機（稱為“訂閱者”）。

發布者不需要關于訂閱者數量或位置的任何數據。反過來，訂閱者不需要關于發布者的任何數據。任何客戶端都可以是發布服務器、訂閱服務器或兩者兼有?？蛻敉ǔ２恢缹Ψ?，只知道充當中介的經紀人。這種設置通常被稱為“發布/訂閱模型”

MQTT消息

當客戶機希望向代理發送數據時，這稱為“發布”當客戶機希望從代理接收數據時，它將“訂閱”一個或多個主題。當客戶端訂閱某個主題時，它將接收該主題上發布的所有消息。

除了消息本身，發布者還發送QoS（服務質量）級別。此級別定義消息的傳遞保證。這些QoS級別如下所示：

最多一次：消息發布時，代理將僅“最多一次”接收消息此級別不應用于任務關鍵型信息，因為它會帶來訂閱者無法接收消息的風險。

至少一次：發布者繼續重新發送消息，直到收到代理關于特定消息的確認。換句話說，接收消息比確保只接收一次更重要。這可能是最常用的QoS級別。

恰好一次：發布者和代理一起工作，以確保代理只接收一次消息并對其執行操作。這需要一些額外的開銷，如四部分握手。雖然這是最安全的QoS級別，但也是最慢的，因此僅在必要時使用。

MQTT如何在物聯網項目中工作？

在本節中，我們將以我們最近的一個客戶機為例，討論如何在物聯網項目中使用MQTT。

一家汽車電池公司希望向全國客戶提供“更新鮮”的電池。這意味著實施“先進先出”戰略，這樣電池就不會在貨架上放置太久。

當然，這要求公司跟蹤貨架上的存貨到達日期。由于需要一個值得信賴的物聯網合作伙伴，該公司與非常有影響力的客戶進行了接觸。

非常有幫助地將物聯網傳感器安裝在公司的電池和貨架上。這些傳感器通過MQTT將信息傳輸到云中的Amazon Web服務（AWS）。每個電池都有一個信號發射裝置，該裝置發送藍牙信號以傳達其在機架上的狀態。此外，單電池供電的集線器每天喚醒一次，以便使用MQTT（以及用于安全傳輸的TLS協議）向AWS傳輸信息。

MQTT的好處

MQTT的好處包括：

輕量級代碼占用：設備只需要幾行代碼就可以啟動并運行MQTT協議。

最小化數據包：MQTT非常節能。這是偉大的，如果一個設備是電池供電或有很少的CPU電源。

速度：MQTT實時運行，在QoS之外沒有延遲。

易于實現：MQTT已經有了Elixir和Python等編程語言的庫。

最后的遺囑：如果客戶端意外斷開連接，您可以設置發送給所有訂閱者的消息指令，以糾正這種情況。

保留消息：每個主題都可以有一條保留消息，客戶端在訂閱時會自動接收該消息（如社交媒體上的固定帖子）。

MQTT的常見替代方案

XMPP

XMPP（可擴展消息和狀態協議）是一種基于XML語言的通信協議，用于存儲和傳輸數據。它經常用于支持即時消息服務，如Jabber。

XMPP和MQTT之間的一些差異是：

XMPP代碼占用的空間稍重一些，您需要一個XML解析器來編碼和解碼信息。

默認情況下，XMPP不支持發布/訂閱模型（盡管可以使用擴展）。

XMPP比MQTT占用更多帶寬。

HTTP（S）

HTTP（超文本傳輸協議）及其擴展HTTPS（超文本傳輸協議安全）是萬維網的基礎通信協議。但是，它們是無狀態的，每次傳輸的開銷比MQTT要大。此外，HTTPS的吞吐量低于MQTT，這意味著您無法在同一時間段內發送盡可能多的消息。

結論

MQTT在使物聯網項目在技術規范方面更加“低提升”，同時實現設備、服務器和應用程序之間所需的連接方面起著至關重要的作用。

什么是CoAP協議？

CoAP受限應用協議是RFC 7252中定義的用于受限設備的專用互聯網應用協議。它使設備能夠通過Internet進行通信。它被定義為約束應用程序協議，是一種用于非常簡單的硬件中的協議。該協議特別適用于受限硬件，如8位微控制器、低功耗傳感器和無法在HTTP或TLS上運行的類似設備。它簡化了UDP上運行的HTTP協議，有助于節省帶寬。它設計用于同一受限網絡（例如，低功耗、有損網絡）上的設備之間、Internet上的設備和一般節點之間以及由Internet連接的不同受限網絡上的設備之間。CoAP還通過其他機制使用，例如移動通信網絡上的SMS。

Internet工程任務組受限RESTful環境（IETF核心）工作組為CoAP做了主要的標準化工作。協議的核心在RFC 7252中指定，這意味著CoAP仍然不是標準協議。

RFC 7252中規定了CoAP協議。它是一種用于受限節點或網絡（如WSN、IoT、M2M等）的web傳輸協議，因此被稱為受限應用協議。該協議的目標是物聯網（IoT）設備具有較少的內存和功率規格。

由于它是為web應用程序設計的，因此也被稱為“物聯網協議”。它可以用于通過web應用程序將數據從幾個字節傳輸到1000字節。它存在于UDP層和應用層之間。

以下是CoAP協議的特點：

?它是非常高效的RESTful協議。

?易于代理到/從HTTP。

?它是開放的IETF標準

?它是嵌入式web傳輸協議（coap://）

?它使用異步事務模型。

?UDP綁定具有可靠性和多播支持。

?使用GET、POST、PUT和DELETE方法。

?支持URI。

?它使用小而簡單的4字節頭。

?支持綁定到UDP、SMS和TCP。

?使用基于DTLS的PSK、RPK和證書安全性。

?使用MIME類型和HTTP響應代碼的子集。

?使用內置的發現機制。

圖1描述了CoAP體系結構。如圖所示，它將普通HTTP客戶端擴展到具有資源約束的客戶端。這些客戶機稱為CoAP客戶機。代理設備在固定環境和基于HTTP協議的典型internet環境之間架起了橋梁。同一臺服務器負責HTTP和CoAP協議消息。

在CoAP客戶端和CoAP服務器之間交換CoAP協議消息有兩種模式，即。沒有單獨的響應和單獨的響應。

通過單獨的響應，服務器通知客戶端收到請求消息。這將增加處理時間，但有助于避免不必要的重新傳輸。

由于使用UDP，CoAP IoT協議不可靠。因此，CoAP消息到達目的地時會無序或丟失。

為了使CoAP協議成為可靠的協議，協議中加入了具有指數退避重傳特性的停止等待。本文還介紹了重復檢測。

專為物聯網和M2M設計的兩項新功能是：

觀察傳感器或執行器上發生的新事件。

設備管理和外部設備的可發現性。

該協議的主要特點是：

需求受限的M2M中使用的Web協議

異步消息交換

低開銷和非常簡單的解析

URI和內容類型支持

代理和緩存功能

何時使用

CoAP有用的一些具體情況包括：

您的硬件無法運行HTTP或TLS：如果是這種情況，那么運行CoAP和DTLS實際上可以與HTTP做相同的事情。如果您是HTTP API方面的專家，那么遷移將很簡單。您收到GET用于讀取和發布，PUT和DELETE用于突變，安全性在DTL上運行。

您的硬件使用電池：如果這是一個問題，那么與TCP/IP上的HTTP相比，運行CoAP將提高電池性能。UDP節省了一些帶寬，使協議更加高效。

訂閱是必要的：如果不能運行MQTT并且HTTP輪詢是不可能的，那么CoAP就是一個解決方案

CoAP Prtocols的某些功能與HTTP非常相似，即使CoAP不能被視為壓縮HTTP協議，因為它是專為物聯網設計的，更詳細地說，是為M2M設計的，因此它非常適合此任務。

從抽象協議層來看，CoAP可以表示為：

在上圖中，您可以看到構成CoAp協議的兩個不同層：消息層和請求/響應層。消息層處理UDP和異步消息。請求/響應層基于請求/響應消息管理請求/響應交互。

CoAP協議支持四種不同的消息類型：

可證實

不可證實

致謝

重置

現在我們討論一些術語相關的CoAP協議。

端點：參與CoAP協議的實體。通常，端點由主機標識

發送者：發送消息的實體

收件人：郵件的目的地

客戶端：發送請求和響應目標的實體

服務器：從客戶端接收請求并將響應發送回客戶端的實體

CoAP消息模型

CoAP消息是最底層，處理端點之間的UDP交換消息。CoAP消息具有唯一ID和三個部分：

二進制報頭

一個緊湊的選項

有效載荷

CoAP協議使用兩種消息：

可證實消息

不可確認消息

CoAP可確認消息是可靠消息。在兩個端點之間交換消息期間，這些消息可能是可靠的。在CoAP協議中，使用可確認消息（CON）獲得可靠消息。使用這種消息，客戶機可以確保消息將到達服務器。CoAP可確認消息會一次又一次地發送，直到另一方發送確認消息（ACK）。確認信息（確認信息的確認信息包含相同的確認信息）。

COAP與MQTT

MQTT和CoAP：

這些都是開放的標準

比HTTP更適合受約束的環境

提供異步通信機制

在IP上運行

有一系列的實現

HTTP是最流行和最廣泛使用的協議。但在過去幾年中，MQTT迅速獲得了吸引力。當我們談論物聯網開發時，開發人員必須在兩者之間進行選擇。

設計和消息傳遞

MQTT以數據為中心，而HTTP以文檔為中心。HTTP是用于客戶端-服務器計算的請求-響應協議，并不總是針對移動設備進行優化。在這些方面，MQTT的主要優勢是輕量級（MQTT將數據傳輸為字節數組）和發布/訂閱模型，這使其非常適合資源受限的設備，并有助于節省電池。

此外，發布/訂閱模式為客戶端提供了相互獨立的存在，提高了整個系統的可靠性。當一個客戶端出現故障時，整個系統可以繼續正常工作。

速度和交付

根據3G網絡中的測量，MQTT的吞吐量是HTTP的93倍。

此外，與HTTP相比，MQTT協議確保了高交付保證。服務質量分為三個級別：

-最多一次：保證盡最大努力交付。

-至少一次：保證消息至少傳遞一次。但信息也可以傳遞不止一次。

-恰好一次：保證每個消息只被對方接收一次

MQTT還為用戶提供了最后遺囑和遺囑以及保留消息的選項。第一種方法是，在客戶端意外斷開連接的情況下，所有訂閱的客戶端都將從代理收到一條消息。保留消息意味著新訂閱的客戶端將立即獲得狀態更新。

HTTP協議沒有這些功能。

復雜性和消息大小

MQTT的規范非常簡短。只有連接、發布、訂閱、取消訂閱和斷開連接類型對開發人員非常重要。而HTTP規范要長得多。

MQTT有一個非常短的消息頭，最小的數據包消息大小為2字節。通過HTTP協議使用文本消息格式，它可以編寫冗長的標題和消息。它有助于消除麻煩，因為它可以被人類讀取，但同時它對于資源受限的設備來說是不必要的。

結論

MQTT協議易于使用。當響應時間、吞吐量、較低的電池和帶寬使用率成為未來解決方案的首要目標時，這一點至關重要。在間歇性連接的情況下，它也是完美的。

HTTP是值得擴展的。但當涉及物聯網開發時，MQTT更合適。