【我的物聯網成長記7】物聯網主流通信協議解讀

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

在物聯網場景中，通信主要發生在設備和物聯網平臺之間，由于大部分物聯網設備都是資源受限型設備，它們的物理資源和網絡資源都非常有限，直接使用現有的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協議中的消息體，用于攜帶這條消息實際的內容，可以為空。

若您希望了解更多CoAP協議的內容，可訪問IETF的網站查看詳細協議。

>>點擊查看CoAP協議規范

了解過CoAP協議后，接下來我們再了解下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表示固件對象第一個實例的固件包名稱。在注冊階段，客戶端就會把自己支持的對象的示例寫入服務端，用于通知服務端自己支持的能力。

若您希望了解更多LWM2M協議的內容，可訪問OMA的網站查看詳細協議。

>>點擊查看LWM2M協議規范

----------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需要根據實際狀況選擇。

若您希望了解更多MQTT協議的內容，可訪問MQTT的官網查看詳細協議。

>>點擊查看MQTT協議規范

----------總結----------

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

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

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

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

若您希望進一步了解使用CoAP/LWM2M協議和MQTT協議的設備分別是如何接入華為云物聯網平臺的，可查看華為云幫助中心的開發指南。

>>點擊訪問華為云幫助中心

IoT 物聯網 IoT

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。