国产精品久久久aaaa,日日干夜夜操天天插,亚洲乱熟女香蕉一区二区三区少妇,99精品国产高清一区二区三区,国产成人精品一区二区色戒,久久久国产精品成人免费,亚洲精品毛片久久久久,99久久婷婷国产综合精品电影,国产一区二区三区任你鲁

0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
會員中心
創作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

通信協議解讀:CoAP/LWM2M協議和MQTT協議

電子設計 ? 來源:華為云IoT ? 作者:我是鹵蛋 ? 2020-12-04 14:09 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

當今物聯網的主流通信協議是CoAP/LWM2M協議和MQTT協議,本文將分別解讀這些協議的工作方式,了解它們的特點,助您選擇最適合您的設備的通信協議。

通信協議又稱為傳輸協議,用于定義多個設備之間傳播信息時的系統標準。通信協議定義了設備通信中的語法、語義、同步規則和發生錯誤時的處理原則,可以理解為機器之間使用的語言。

在物聯網場景中,通信主要發生在設備和物聯網平臺之間,由于大部分物聯網設備都是資源受限型設備,它們的物理資源和網絡資源都非常有限,直接使用現有的HTTP協議進行通信對它們來說要求實在是太高了。因此,物聯網場景中主要使用的通信協議都是輕量級的,為資源受限環境而設計的通信協議,例如CoAP/LWM2M協議和MQTT協議。

本文將分別解讀CoAP/LWM2M協議和MQTT協議,希望能幫助您了解這些協議,并選擇最適合您的設備的通信協議。

CoAP/LWM2M協議

CoAP(Constrained Application Protocol,受限制的應用協議)運行于UDP協議之上,設計上主要借鑒了HTTP協議的RESTful風格,簡化了協議包格式,一個最小的CoAP數據包僅4字節。CoAP協議采用了和HTTP協議相同的請求/響應模型,客戶端發出請求后,服務端處理請求并回復響應,是一種點對點的通信模型。CoAP和HTTP一樣都是通過URI指定要訪問的資源,但CoAP協議以“coap:”或“coaps:”開頭,其中coaps的s是指消息通過DTLS協議加密。CoAP的每一條消息都是一條二進制的報文,由以下部分組成:

VER:長度2位,用于表示CoAP協議的版本號。

T:長度2位,用于表示報文類型。CoAP協議定義了四種報文類型:

CON:需要應答的報文,接受者收到該消息后需要及時回復一個ACK報文。

NON:無需應答的報文。

ACK:應答報文。

RST:復位報文,當接受者無法解析收到的報文或收到的報文中含有錯誤時,可以回復RST報文。

TKL:長度4位,用于表示Token字段的長度。

Code:長度8位,在請求消息中用于表示請求方法(GET/POST/PUT/DELETE),在響應消息中表示響應碼(與HTTP的響應碼類似)。

Message ID:長度16位,用于標識報文。主要用途有兩個,一個是服務端收到CON報文后,需要返回相同Message ID的ACK報文;另一個是重發場景下,用相同的Message ID表示這是同一條報文的重復發送。

Token:可選字段,長度由TKL決定,同樣用來標識報文。例如,有時候服務端收到CON報文(攜帶了Token)后,請求的內容無法立刻處理完成,就只能先回復一個不帶響應數據的ACK報文,待請求處理完成后再通過一個CON或者NON報文將實際響應數據帶給客戶端;此時這個報文就必須攜帶和之前的CON報文相同的Token,告訴客戶端這個報文是之前的CON報文的響應。

同理,若客戶端發送NON報文進行請求,服務端也可同樣使用NON報文進行響應,兩個報文使用Token進行關聯。除此之外,Token還可用于消息防偽造等場景,此處不再展開說明。

Options:可選字段,長度不定,作用類似于HTTP協議中的消息頭。

1 1 1 1 1 1 1 1:隔離符,用于分隔Options和Payload

Payload:實際負載數據,即HTTP協議中的消息體,用于攜帶這條消息實際的內容,可以為空。

LWM2M協議

LWM2M(Lightweight Machine-To-Machine,輕量級M2M)協議是由由OMA(Open Mobile Alliance)提出并定義的基于CoAP協議的物聯網通信協議。LWM2M協議在CoAP協議的基礎上定義了接口、對象等規范,使得物聯網設備和物聯網平臺之間的通信更加簡潔和規范。

LWM2M協議定義了三個邏輯實體:LWM2M Server(服務端),LWM2M Client(客戶端),LWM2M Bootstrap Server(引導服務),其中LWM2M Server和LWM2M Bootstrap Server可以是同一個服務器。在這些實體間,LWM2M協議定義了四個接口:

Bootstrap:引導接口。客戶端首次啟動后,可以通過該接口訪問引導服務(需要廠家提前把引導服務器的地址寫入設備),獲取服務端的地址。

Device Discovery and Registration:設備發現與注冊接口。客戶端通過該接口將自己的基本信息寫到服務端,包括自己支持哪些能力。該接口同時還可以用于升級注冊信息和注銷設備。

Device Management and Service Enablement:設備管理和業務實現接口。服務端通過該接口給客戶端下發指令,客戶端處理指令并返回響應。該接口定義了7種操作,分別是:

“Create”、“Read”、“Write”、“Delete”、“Execute”、“Write Attributes”和“Discover”。

Information Reporting:信息上報接口。LWM2M允許服務端向客戶端訂閱資源信息,客戶端被訂閱后按照接口約定的模式(事件觸發或定期)向服務端主動上報信息。

在上述接口中,服務端對客戶端進行操作時都需要指定一個具體的操作目標,例如讀某個屬性,寫某個屬性。在HTTP協議中,這種目標的指定是通過URI或者消息體內攜帶的文本消息進行指定。而LWM2M協議為了使通信消息更加簡潔,定義了對象和資源的概念。

對象是資源的集合,LWM2M協議定義了8個標準對象,給它們分別分配了0~7的對象ID,例如對象ID為5的是固件對象。考慮到拓展性,LWM2M協議也允許使用者自定義新的對象并分配對象ID。

每個對象在被使用之前必須先被實例化,因為對象都是抽象的模型,一個對象可以有多個實例,每個實例為一個單獨的邏輯實體。對象實例化時會被分配實例ID,從0開始遞增。

資源則可以理解為對象的屬性,是LWM2M協議中實際用于攜帶信息的實體。同一個對象的不同實例中的資源攜帶值可以是不同的。每個資源都需要被分配了一個資源ID,例如固件對象的固件包名稱的資源ID為6。和對象一樣,LWM2M協議也允許自定義資源。

至此,通過對象ID,實例ID和資源ID,我們就可以用三個數字指示一個具體的資源,例如5/0/6表示固件對象第一個實例的固件包名稱。在注冊階段,客戶端就會把自己支持的對象的示例寫入服務端,用于通知服務端自己支持的能力。

MQTT協議

MQTT(Message Queuing Telemetry Transport,消息隊列遙測傳輸)協議運行于TCP協議之上,是一種基于發布/訂閱模型的通信協議。在發布/訂閱模型模型中,我們需要一個代理服務器(通常稱之為Broker),所有客戶端都需要和服務器建立連接,然后進行訂閱和發布。若某個客戶端發布了其他客戶端已訂閱的主題(MQTT協議中稱之為topic),服務器就會將這個主題轉發給所有已訂閱的客戶端。例如有A、B、C三個客戶端都連上了同一個服務器,B和C訂閱了“test”主題,然后A發布了一個主題為“test”的消息,服務器就會把這條消息轉發給B和C。

在物聯網場景中,物聯網平臺既是一個服務器又是一個客戶端。平臺制定一套主題規則(我們可以稱之為MQTT接口),并訂閱數據上報類接口的主題,然后只要設備使用該接口上報數據,平臺就可以接收到數據。同理,設備若想要收到平臺下發的數據,需要先訂閱數據下發類接口的主題。

MQTT消息基于文本傳輸,主要有以下三類消息:

CONNECT:當客戶端想要和服務器建立連接時,需要發送一條CONNECT消息給服務器,消息內包含自己的用戶名、密碼等信息,服務器鑒權通過后,和客戶端建立連接。若雙方想要斷開連接,則需要遵循TCP協議的四次揮手規則,才能正常斷開連接。客戶端在發送CONNECT消息時,還可以指定“最后遺愿(last will)”消息,包括消息的主題和內容。當服務器檢測到客戶端異常斷開連接時,就會自動發布這條“最后遺愿”消息。

SUBSCRIBE:當客戶端訂閱主題時,需要發送一條SUBSCRIBE消息給服務器,指定要訂閱的主題。MQTT協議的主題表示為層次結構,類似文件系統,例如“/huawei/v1/devices”這種格式。同理,客戶端可以通過UNSUBSCRIBE消息取消訂閱指定主題。

PUBLISH:當客戶端發布消息時,需要發送一條PUBLISH消息給服務器,指定消息的主題和內容。MQTT對發布消息的內容格式不做限制,需要由各個服務提供商自行制定規范。客戶端發布消息時可以指定該消息是否需要保留,一個主題只能保留一條消息,被保留的消息會被代理服務器記錄,以后每個新訂閱這個主題的客戶端都會先接收到這條保留消息。

在可靠傳輸方面,MQTT協議提供三種QoS等級的實現:

QoS=0表示消息只會被發送一次,但該消息可能會丟失。

QoS=1表示確保消息會到達至少一次,但可能會造成訂閱者收到多條重復消息。

QoS=2表示確保消息會到達且僅到達一次。

QoS等級越高,消息傳輸的可靠度越高,但實現也會越復雜,對網絡和設備資源的占用也會變多,所以傳輸時選用哪個級別的QoS需要根據實際狀況選擇。

總結

在分別了解過CoAP/LWM2M協議和MQTT協議之后,我們可以得知,LWM2M協議是基于CoAP協議的一種具體規范,而MQTT協議是不同于CoAP協議的另一種傳輸協議。

CoAP/LWM2M協議基于UDP協議,服務器和客戶端之間不保持連接;通信基于請求/響應模型,與互聯網主流的HTTP協議相同,主要用于點對點的通信。CoAP/LWM2M協議針對物聯網場景定義了各種類型和標簽,支持內容協商與發現,允許設備相互探測以找到交換數據的方式;報文為極簡的二進制報文,長度更短,對設備和網絡的要求更低。

MQTT協議基于TCP協議,服務端和客戶端之間保持連接;通信基于分布/訂閱模型,可以簡單實現多對多的通信場景。MQTT協議設計簡單,易于理解和學習;報文消息基于文本,消息負載格式無限制,自由度更高,更便于調測和排障時查看和理解,但同時也需要服務提供商制定通信規范(接口文檔),設備之間才可進行有效通信。

綜上所述,CoAP/LWM2M協議和MQTT協議各有其特點,并不存在誰優誰劣,您需要根據自己的設備的應用場景選擇最適合的協議。
編輯:hfy

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。 舉報投訴
  • 通信協議
    +關注

    關注

    28

    文章

    1092

    瀏覽量

    42150
  • 物聯網
    +關注

    關注

    2945

    文章

    47818

    瀏覽量

    414814
  • HTTP
    +關注

    關注

    0

    文章

    537

    瀏覽量

    35345
  • MQTT協議
    +關注

    關注

    0

    文章

    104

    瀏覽量

    6531
收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關推薦
    熱點推薦

    機器人通信協議EtherCAT和CAN如何選擇

    當下,雖然行業中存在許多通信協議,但業內人士普遍認為,EtherCAT和CAN兩大協議,是機器人行業未來最重要的兩大協議
    的頭像 發表于 01-27 15:54 ?2479次閱讀

    基于FPGA的I2C通信協議設計

    I2C(Inter-Integrated Circuit)是一種由飛利浦半導體(現為恩智浦半導體)在1980年代初開發的同步、串行、半雙工的總線型通信協議。主要用于近距離(同一塊印刷電路板(PCB
    的頭像 發表于 12-26 09:44 ?6114次閱讀
    基于FPGA的I<b class='flag-5'>2</b>C<b class='flag-5'>通信協議</b>設計

    SWD調試通信協議

    調試器和目標芯片的 DAP 調試模塊通過 SWD 包傳輸協議進行通信,包傳輸協議2 線同步串行協議,使用SWCLK 時鐘信號和 SWDI
    發表于 12-22 14:46

    MQTT協議為什么成為物聯網協議

    不穩定環境下的通信需求。以下是具體分析: 1. 輕量級設計,適配資源受限設備 極簡協議頭 :MQTT協議頭最小僅2字節,遠低于HTTP(通常
    的頭像 發表于 12-10 09:15 ?444次閱讀

    Xilinx FPGA串行通信協議介紹

    Xilinx FPGA因其高性能和低延遲,常用于串行通信接口設計。本文深入分析了Aurora、PCI Express和Serial RapidIO這三種在Xilinx系統設計中關鍵的串行通信協議。介紹了它們的特性、優勢和應用場景,以及如何在不同需求下選擇合適的
    的頭像 發表于 11-14 15:02 ?2532次閱讀
    Xilinx FPGA串行<b class='flag-5'>通信協議</b>介紹

    SIP協議和私有協議廣播區別

    電子發燒友網站提供《SIP協議和私有協議廣播區別.docx》資料免費下載
    發表于 11-06 16:31 ?1次下載

    創龍 瑞芯微 RK3588 國產2.4GHz八核 工業開發板—MQTT通信協議案例

    本文圍繞創龍科技研發的評估板,提供 MQTT 通信協議開發案例指導。涵蓋 MQTT 協議核心概念,詳解案例功能(如數據發布與訂閱)、環境搭建(MQT
    的頭像 發表于 10-28 15:23 ?2489次閱讀
    創龍 瑞芯微 RK3588 國產2.4GHz八核 工業開發板—<b class='flag-5'>MQTT</b><b class='flag-5'>通信協議</b>案例

    分布式能源并網的通信協議有哪些?

    在分布式能源(如光伏、儲能、微電網)并網場景中,通信協議需滿足 設備互聯、數據傳輸、遠程控制、調度協同 等核心需求,不同協議因設計目標不同,適用于從設備層到調度層的不同層級。以下按 “國際標準協議
    的頭像 發表于 09-18 16:40 ?1570次閱讀
    分布式能源并網的<b class='flag-5'>通信協議</b>有哪些?

    數據采集網關的多協議兼容能力體現在哪

    、Ethernet/IP),兼容PLC、傳感器、儀器儀表、CNC機床、機器人等設備。 物聯網協議 :適配MQTTCoAPLwM2M等輕
    的頭像 發表于 09-17 11:22 ?682次閱讀

    工業通信協議都有哪些?#三格電子

    通信協議
    三格電子科技
    發布于 :2025年08月28日 10:35:26

    哪些協議是工業通信協議?#三格電子

    通信協議
    三格電子科技
    發布于 :2025年08月27日 14:16:07

    GraniStudio :MQTT 協議的深度剖析

    在工業物聯網(IIoT)的通信協議體系中,MQTT(Message Queuing Telemetry Transport)憑借其輕量級、發布 - 訂閱模式和低帶寬占用等特性,成為連接邊緣設備與云端
    的頭像 發表于 08-04 09:48 ?1021次閱讀
    GraniStudio :<b class='flag-5'>MQTT</b> <b class='flag-5'>協議</b>的深度剖析

    MQTT為何成為物聯網協議

    MQTT(Message Queuing Telemetry Transport)即消息隊列遙測傳輸協議,已成為物聯網領域廣泛應用的協議,這主要得益于其在資源占用、通信效率、可靠性、擴
    的頭像 發表于 05-20 09:54 ?831次閱讀

    DLT645協議和Modbus協議有什么區別

    與數據采集設備間的通信,是電表通信的基礎標準,廣泛應用于電力系統的智能電表數據采集、遠程抄表、參數設置和設備控制等場景。 Modbus協議 :為工業控制領域設計的通用通信協議,適用于多
    的頭像 發表于 05-15 17:47 ?1788次閱讀

    淺談HART協議和RS485協議的區別

    HART協議和RS485協議都是用于工業領域通信協議,但它們有不同的應用場景和特點。
    的頭像 發表于 03-27 10:07 ?2747次閱讀
    淺談HART<b class='flag-5'>協議和</b>RS485<b class='flag-5'>協議</b>的區別