<button id="yg2zl"><tr id="yg2zl"><kbd id="yg2zl"></kbd></tr></button>
  1. <nav id="yg2zl"><big id="yg2zl"></big></nav>

      1. <button id="yg2zl"><acronym id="yg2zl"><menuitem id="yg2zl"></menuitem></acronym></button>
        傳感器
        M2M 云計算
        智慧城市
        電子標簽
        二維碼
        IPV6

        未來
        物聯網
        讓一切想象變成現實!

        未來物聯網為您提供物聯網資訊,物聯網新聞,物聯網技術,物聯網會議,

        物聯網企業,物聯網行業資訊網站,全球物聯網技術及物聯網應用最新動態。

        打印 上一主題 下一主題

        在物聯網應用開發中是否該用MQTT v5.0?

        [復制鏈接]
        anan   發表于 2022-2-23 07:37:55   查看: 269 帖子

        【51CTO.com快譯】于1999年面市的MQTT,最初被用于油氣管道與遠程衛星之間的通信。目前它作為一種工具,被廣泛地用在各種規模的部署中,以連接多種類型的物聯網(IoT)設備。由于是基于TCP/IP的網絡協議,因此MQTT采用的是發布方-訂閱方(publisher-subscriber)的通信模型。它的輕量級特性足以讓其運行在IoT設備上,而其強大的功能又確保了它能夠在不穩定的網絡條件下工作。
        MQTT的工作原理

        MQTT協議是由如下元素構成:

        • 發布方(Publisher):設備通過主題將消息發送給訂閱方。
        • 主題(Topic):每個資源都有一個唯一的標識符。發布方將消息發送至主題,然后將其傳遞給訂閱方。
        • 訂閱方(Subscriber):作為終端設備,訂閱方通過主題從發布方處接收消息。
        • 代理(Broker):服務器作為中央樞紐,負責發布方和訂閱方之間的組織級通信。
        下圖展示了簡單的MQTT通信邏輯。


        如果某個云平臺不適合使用MQTT的通信方式來開發系統,則可以改用hbmqtt、gmqtt和paho-mqtt lib。
        服務質量級別(QoS)是MQTT協議的關鍵功能,作為消息發送方和接收方之間的約定,它定義了系統傳遞特定消息的能力。
        客戶端可以選擇與其所處網絡的可靠性,以及應用程序的邏輯,相匹配的服務級別。由于MQTT能夠通過重新傳輸的機制,來管理并保證消息的傳遞(即使是底層的傳輸并不可靠),因此QoS可以讓不可靠網絡中的通信更加安全。
        為何在物聯網的開發中要用到MQTT?

        憑借其“節能(energy-efficient)”的數據傳輸方式,MQTT往往被用在CPU和內存(RAM)功率有限的低功耗設備上,以及如下場景用例中:

        • 高效的通信。MQTT的低數據量和低能耗特性,使其成為實時的、基于文本的消息傳遞應用的首選。
        • 安全性。在家庭安防系統中,MQTT系統的QoS機制可以確保重要消息的成功傳遞,進而確保危險警告能夠發送給居民。
        • 消息匯總。MQTT使得組織能夠有效地,從諸如智能手機或汽車傳感器等多個來源收集數據。
        • 同步傳感器。例如,多個火災報警探測器可以相互通信,以辨別危險是否真的存在。
        • 醫療物聯網應用。通過多個傳感器去監控出院患者的健康參數。
        • 車聯網。與HTTP不同,MQTT能夠在客戶端和代理之間保持持久性的會話。該特性對于車聯網特別實用。例如,當車輛離開了蜂窩網絡的盲區,會話能夠重新連接,繼續平穩地收發數據,而無需進行復雜的HTTP握手。
        MQTT的優勢


        • 效率是MQTT的一大亮點,它通過諸如AMQP的競爭協議,讓數據的傳輸更加順暢。用戶可以快速、輕松地實現輕量級的MQTT協議架構。
        • 發送的數據包越少,網絡的使用率就越低。
        • 其低功耗特性非常適合連接物聯網設備。
        • MQTT可以實現更有效的數據分發。
        • 該協議可以更輕松地實現遙感(remote sensing)和控制。
        MQTT的劣勢

        當然,MQTT并非在所有場景中都是理想選擇。MQTT協議在客觀上存在著如下劣勢:

        • 對于擁有250個以上設備的系統而言,快速傳輸周期是至關重要的。不過它與CoAP(Constrained Application Protocol)相比,會在傳輸周期上慢一些。
        • MQTT可以運行在靈活的主題訂閱系統上。而CoAP使用的是穩定的資源發現系統。
        • MQTT雖然用到了TLS/SSL,可是它缺乏安全加密能力。
        • 與其他競品相比,MQTT協議難以創建全局性的可擴展網絡。
        MQTT v5.0的功能概述

        通過各種新功能,MQTT v5.0可以實現如下目標:

        • 提高大型系統的性能。MQTT v5.0以一種適當的架構,簡化并協調上萬臺設備之間的通信。
        • 錯誤報告。MQTT v5.0協議將返回碼重命名為原因碼(reason code),以指示更多類型的錯誤。
        • 實現常規交互。MQTT v5.0規范化了設備間交互的重復方式,并定義了它們如何響應請求的能力。
        • 增加了可擴展的機制。MQTT v5.0新的功能包括:添加自定義的屬性,指定內容的類型或負載的格式。
        • 更好的支持。特別是對于希望通過MQTT來提高生產率的小型用戶而言,能夠從中受益。
        MQTT v5.0與MQTT 3.1.1的基本功能

        1.通信功能


        • 可以通過負載內部的身份驗證方法,以及身份驗證類數據的屬性,來實現增強的身份驗證。
        • 可以使用“會話過期間隔”屬性。例如,可以在主題內包括訂閱的時間,消息會被存儲的時限等。
        • 可以內置化地限制客戶端和服務器端的最大數據包的體積(待傳輸的字節數)和最大接收量(客戶端或服務器同時發送消息的數量)。
        • 通過“待延遲的間隔”屬性,實現對消息的延遲發送。
        • “服務器參考”或“服務器重定向”屬性,可以協助將數據包傳輸到不同的代理或服務器處。
        2.發布功能


        • 消息到期間隔,可用于設置消息的保留期限。
        • 負載格式標識符和內容類型屬性,可被定義為二進制字節、UTF-8或MIME類型。
        • 支持主題別名。例如,通過將topic/v1/device/賦予別名“1”,可以最大程度地減少所需的數據包的數量。
        • MQTT協議的“響應主題”,類似HTTP協議的響應請求方案(response-request scheme)。
        3.訂閱功能


        • 非本地發布,可以讓用戶選擇不接收客戶端發布的消息。
        • 留存消息控制可以控制消息的排序。
        • 訂閱標識符,可用于在訂閱中識別服務器。
        • 共享訂閱,可通過其他標志和過濾功能,來實現更靈活的訂閱。
        4.一般特征


        • 在MQTT v3.1.1中,服務器無法提供有關在建立通信、發布消息、以及訂閱主題等不同階段的問題與錯誤原因。但是,v5.0可以提供所有ACK消息的原因碼。
        • 與MQTT 3.1不同,在MQTT v5.0中,客戶端和服務器端可以彼此傳遞有關掉線信息的數據包。
        • 不同的用戶屬性可以被存儲在各種鍵值中。
        MQTT v5.0在小型系統部署中的示例

        下面讓我們來看一個帶有基于Python的客戶端利用MQTT v5.0本地網絡的示例。在客觀總結其優缺點的同時,我們還會將其與MQTT v3.1.1的網絡進行比較。


        場景簡述

        假設有一棟實現了局域網(LAN)覆蓋的建筑物。其中某些房間被安裝了三種設備--獨立的運動傳感器、照相傳感器和音頻傳感器。其主機設備位于LAN之中,并通過無線或網線的方式連接到路由器上。它能夠定期從獨立的設備上收集或處理數據,并且將這些數據存儲在本地數據庫中。目前,我們使用SQLLite數據庫或更簡單的替代方法,僅在收到三種傳感器的消息后,才會被激活工作。
        目標

        保證主機設備與獨立設備之間的通信,并在主機端提供本地數據庫的部署和通信。
        應用要求


        • 從傳感器到主機設備的所有消息,都必須遵從MQTT v5.0附加屬性的限制(包括:傳輸給主題消息的字節數限制等)。
        • 來自主題的消息必須是MIME類型,以便于在主機端進行快速編碼。
        • 消息必須存儲在本地數據庫的實例中。
        設備要求


        • 獨立設備:帶有已連接的傳感器,而且能夠訪問本地網絡的x86或基于ARM的設備(如,Raspberry Pi)。
        • 主機設備:具有MQTT代理、且能夠處理來自獨立設備消息的基于x86或基于ARM的設備。
        支持MQTT v5.0和Python的代理

        雖然paho-mqtt是兩種常見的代理。但是,由于它們并無內置的MQTT v5.0代理,因此無法實現網絡的本地部署。對此,我們采用支持MQTT v5.0的Mosquitto作為代理。其配套的文檔鏈接為--https://mosquitto.org/。它能夠代理大約200到300個設備,且一次性僅支持一個連接。
        基于Python的系統如何與MQTT v5.0一起使用

        在Python開發人員看來,MQTT v5.0協議里的庫和文檔并不多。其唯一的Python 客戶端便是上面提到的gmqtt和paho-mqtt。
        MQTT v5.0本地網絡的優缺點

        優點


        • 無需諸如GCP(Google Cloud Platform)或AWS之類的云服務提供商,也不需要用于本地IoT系統的WAN連接,便可實現LAN內自主設備的全面交互。
        • 網絡延遲和數據傳輸速度。傳輸速度僅取決于本地設備的硬件功能。在LAN環境中,通過放置設備可以最大程度地減少延遲。
        • 與競品相比,MQTT的能效更高。
        • 網絡安全性高。由于本地網絡不會暴露到WAN中,因此帶有消息的數據包不會被本地網絡之外實體捕獲或跟蹤到。同時,MQTT v5.0協議提供了服務器與客戶端之間的相互身份驗證。此外,MQTT還可以使用TLS證書的安全連接和數據傳輸。
        • 可以將數據包的各種限制,作用于網絡內的代理上。
        • 其容器化特征更易于模擬和調試。
        缺點


        • 用于處理消息的線程應當實現并行管理,以確保設備的正常運行。
        • 開發人員必須定期進行調試和排障,并且必須使用安全的SSH,來保護主機和獨立設備之間的WAN連接。
        • MQTT協議不支持流式傳輸。
        • 由于無法實現大型的文件傳輸,因此需要專用的bucket上傳或HTTP協議。
        • 代理無法智能地管理數據。當然,在斷開連接期間,數據可以被存儲一段時間。
        MQTT v5.0較v3.1.1的改進之處


        • 存儲附加數據的屬性
        • 載荷格式的指示符類型包括:字節、UTF-8或UTF-8字符串對
        • 請求/響應模式
        • 客戶端連接和斷開的原因碼
        • 會話到期與控制
        MQTT v5.0可以簡化數據負載的處理和解析,具有對消息、連接和會話進行單獨且精確控制的能力。而且,它能夠通過屬性來傳輸附加數據,開發者可以據此創建更為復雜的IoT解決方案。
        MQTT v5.0的挑戰


        • 在生產環境中,開發者需要管理那些用于在獨立設備上,并行發布和偵聽消息的進程與線程。
        • 在paho-mqtt之類的代碼包中,各種類的實現過程并不清晰,而且可參考的文檔十分有限。
        • 由于文檔匱乏,因此開發者很難安裝代理,并將其升級到MQTT v5.0。
        • 為了識別網絡中的設備,我們需要將IP發現器添加到系統中。
        到底是否該選用MQTT v5.0?

        總的說來,如果您擁有在設備與主機之間進行消息通信的托管式代理設備,而且物聯網的規模不大,那么將MQTT v5.0用于本地IoT設備間的通信則為首選。
        原文標題:MQTT 5 vs. MQTT v3.1.1 for IoT App Development,作者:Daniil Liadov
        【51CTO譯稿,合作站點轉載請注明原文譯者和出處為51CTO.com】
         鄭重聲明:本文僅代表作者個人觀點,與未來物聯網(wlit.cn)無關。其原創性以及文中陳述文字和內容未經本站證實,對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾,請讀者僅作參考,并請自行核實相關內容。
        回復

        使用道具 舉報

        QQ|Archiver|手機版|未來物聯網 ( 魯ICP備17019744號-2 ) 百度統計

        GMT+8, 2022-3-22 02:13 , Processed in 0.371706 second(s), 22 queries .

        Powered by Discuz! X3.4

        © 2001-2013 Comsenz Inc.

        快速回復 返回頂部 返回列表
        中文字字幕人妻中文
          <button id="yg2zl"><tr id="yg2zl"><kbd id="yg2zl"></kbd></tr></button>
        1. <nav id="yg2zl"><big id="yg2zl"></big></nav>

            1. <button id="yg2zl"><acronym id="yg2zl"><menuitem id="yg2zl"></menuitem></acronym></button>