通信協(xié)議解讀：CoAP/LWM2M協(xié)議和MQTT協(xié)議

當(dāng)今物聯(lián)網(wǎng)的主流通信協(xié)議是CoAP/LWM2M協(xié)議和MQTT協(xié)議，本文將分別解讀這些協(xié)議的工作方式，了解它們的特點(diǎn)，助您選擇最適合您的設(shè)備的通信協(xié)議。

通信協(xié)議又稱為傳輸協(xié)議，用于定義多個(gè)設(shè)備之間傳播信息時(shí)的系統(tǒng)標(biāo)準(zhǔn)。通信協(xié)議定義了設(shè)備通信中的語法、語義、同步規(guī)則和發(fā)生錯(cuò)誤時(shí)的處理原則，可以理解為機(jī)器之間使用的語言。

在物聯(lián)網(wǎng)場(chǎng)景中，通信主要發(fā)生在設(shè)備和物聯(lián)網(wǎng)平臺(tái)之間，由于大部分物聯(lián)網(wǎng)設(shè)備都是資源受限型設(shè)備，它們的物理資源和網(wǎng)絡(luò)資源都非常有限，直接使用現(xiàn)有的HTTP協(xié)議進(jìn)行通信對(duì)它們來說要求實(shí)在是太高了。因此，物聯(lián)網(wǎng)場(chǎng)景中主要使用的通信協(xié)議都是輕量級(jí)的，為資源受限環(huán)境而設(shè)計(jì)的通信協(xié)議，例如CoAP/LWM2M協(xié)議和MQTT協(xié)議。

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

CoAP/LWM2M協(xié)議

CoAP（Constrained Application Protocol，受限制的應(yīng)用協(xié)議）運(yùn)行于UDP協(xié)議之上，設(shè)計(jì)上主要借鑒了HTTP協(xié)議的RESTful風(fēng)格，簡(jiǎn)化了協(xié)議包格式，一個(gè)最小的CoAP數(shù)據(jù)包僅4字節(jié)。CoAP協(xié)議采用了和HTTP協(xié)議相同的請(qǐng)求/響應(yīng)模型，客戶端發(fā)出請(qǐng)求后，服務(wù)端處理請(qǐng)求并回復(fù)響應(yīng)，是一種點(diǎn)對(duì)點(diǎn)的通信模型。CoAP和HTTP一樣都是通過URI指定要訪問的資源，但CoAP協(xié)議以“coap：”或“coaps：”開頭，其中coaps的s是指消息通過DTLS協(xié)議加密。CoAP的每一條消息都是一條二進(jìn)制的報(bào)文，由以下部分組成：

VER：長(zhǎng)度2位，用于表示CoAP協(xié)議的版本號(hào)。

T：長(zhǎng)度2位，用于表示報(bào)文類型。CoAP協(xié)議定義了四種報(bào)文類型：

CON：需要應(yīng)答的報(bào)文，接受者收到該消息后需要及時(shí)回復(fù)一個(gè)ACK報(bào)文。

NON：無需應(yīng)答的報(bào)文。

ACK：應(yīng)答報(bào)文。

RST：復(fù)位報(bào)文，當(dāng)接受者無法解析收到的報(bào)文或收到的報(bào)文中含有錯(cuò)誤時(shí)，可以回復(fù)RST報(bào)文。

TKL：長(zhǎng)度4位，用于表示Token字段的長(zhǎng)度。

Code：長(zhǎng)度8位，在請(qǐng)求消息中用于表示請(qǐng)求方法（GET/POST/PUT/DELETE），在響應(yīng)消息中表示響應(yīng)碼（與HTTP的響應(yīng)碼類似）。

Message ID：長(zhǎng)度16位，用于標(biāo)識(shí)報(bào)文。主要用途有兩個(gè)，一個(gè)是服務(wù)端收到CON報(bào)文后，需要返回相同Message ID的ACK報(bào)文；另一個(gè)是重發(fā)場(chǎng)景下，用相同的Message ID表示這是同一條報(bào)文的重復(fù)發(fā)送。

Token：可選字段，長(zhǎng)度由TKL決定，同樣用來標(biāo)識(shí)報(bào)文。例如，有時(shí)候服務(wù)端收到CON報(bào)文（攜帶了Token）后，請(qǐng)求的內(nèi)容無法立刻處理完成，就只能先回復(fù)一個(gè)不帶響應(yīng)數(shù)據(jù)的ACK報(bào)文，待請(qǐng)求處理完成后再通過一個(gè)CON或者NON報(bào)文將實(shí)際響應(yīng)數(shù)據(jù)帶給客戶端；此時(shí)這個(gè)報(bào)文就必須攜帶和之前的CON報(bào)文相同的Token，告訴客戶端這個(gè)報(bào)文是之前的CON報(bào)文的響應(yīng)。

同理，若客戶端發(fā)送NON報(bào)文進(jìn)行請(qǐng)求，服務(wù)端也可同樣使用NON報(bào)文進(jìn)行響應(yīng)，兩個(gè)報(bào)文使用Token進(jìn)行關(guān)聯(lián)。除此之外，Token還可用于消息防偽造等場(chǎng)景，此處不再展開說明。

Options：可選字段，長(zhǎng)度不定，作用類似于HTTP協(xié)議中的消息頭。

1 1 1 1 1 1 1 1：隔離符，用于分隔Options和Payload。

Payload：實(shí)際負(fù)載數(shù)據(jù)，即HTTP協(xié)議中的消息體，用于攜帶這條消息實(shí)際的內(nèi)容，可以為空。

LWM2M協(xié)議

LWM2M（Lightweight Machine-To-Machine，輕量級(jí)M2M）協(xié)議是由由OMA（Open Mobile Alliance）提出并定義的基于CoAP協(xié)議的物聯(lián)網(wǎng)通信協(xié)議。LWM2M協(xié)議在CoAP協(xié)議的基礎(chǔ)上定義了接口、對(duì)象等規(guī)范，使得物聯(lián)網(wǎng)設(shè)備和物聯(lián)網(wǎng)平臺(tái)之間的通信更加簡(jiǎn)潔和規(guī)范。

LWM2M協(xié)議定義了三個(gè)邏輯實(shí)體：LWM2M Server（服務(wù)端），LWM2M Client（客戶端），LWM2M Bootstrap Server（引導(dǎo)服務(wù)），其中LWM2M Server和LWM2M Bootstrap Server可以是同一個(gè)服務(wù)器。在這些實(shí)體間，LWM2M協(xié)議定義了四個(gè)接口：

Bootstrap：引導(dǎo)接口?？蛻舳耸状螁?dòng)后，可以通過該接口訪問引導(dǎo)服務(wù)（需要廠家提前把引導(dǎo)服務(wù)器的地址寫入設(shè)備），獲取服務(wù)端的地址。

Device Discovery and Registration：設(shè)備發(fā)現(xiàn)與注冊(cè)接口?？蛻舳送ㄟ^該接口將自己的基本信息寫到服務(wù)端，包括自己支持哪些能力。該接口同時(shí)還可以用于升級(jí)注冊(cè)信息和注銷設(shè)備。

Device Management and Service Enablement：設(shè)備管理和業(yè)務(wù)實(shí)現(xiàn)接口。服務(wù)端通過該接口給客戶端下發(fā)指令，客戶端處理指令并返回響應(yīng)。該接口定義了7種操作，分別是：

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

Information Reporting：信息上報(bào)接口。LWM2M允許服務(wù)端向客戶端訂閱資源信息，客戶端被訂閱后按照接口約定的模式（事件觸發(fā)或定期）向服務(wù)端主動(dòng)上報(bào)信息。

在上述接口中，服務(wù)端對(duì)客戶端進(jìn)行操作時(shí)都需要指定一個(gè)具體的操作目標(biāo)，例如讀某個(gè)屬性，寫某個(gè)屬性。在HTTP協(xié)議中，這種目標(biāo)的指定是通過URI或者消息體內(nèi)攜帶的文本消息進(jìn)行指定。而LWM2M協(xié)議為了使通信消息更加簡(jiǎn)潔，定義了對(duì)象和資源的概念。

對(duì)象是資源的集合，LWM2M協(xié)議定義了8個(gè)標(biāo)準(zhǔn)對(duì)象，給它們分別分配了0~7的對(duì)象ID，例如對(duì)象ID為5的是固件對(duì)象?？紤]到拓展性，LWM2M協(xié)議也允許使用者自定義新的對(duì)象并分配對(duì)象ID。

每個(gè)對(duì)象在被使用之前必須先被實(shí)例化，因?yàn)閷?duì)象都是抽象的模型，一個(gè)對(duì)象可以有多個(gè)實(shí)例，每個(gè)實(shí)例為一個(gè)單獨(dú)的邏輯實(shí)體。對(duì)象實(shí)例化時(shí)會(huì)被分配實(shí)例ID，從0開始遞增。

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

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

MQTT協(xié)議

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

在物聯(lián)網(wǎng)場(chǎng)景中，物聯(lián)網(wǎng)平臺(tái)既是一個(gè)服務(wù)器又是一個(gè)客戶端。平臺(tái)制定一套主題規(guī)則（我們可以稱之為MQTT接口），并訂閱數(shù)據(jù)上報(bào)類接口的主題，然后只要設(shè)備使用該接口上報(bào)數(shù)據(jù)，平臺(tái)就可以接收到數(shù)據(jù)。同理，設(shè)備若想要收到平臺(tái)下發(fā)的數(shù)據(jù)，需要先訂閱數(shù)據(jù)下發(fā)類接口的主題。

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

CONNECT：當(dāng)客戶端想要和服務(wù)器建立連接時(shí)，需要發(fā)送一條CONNECT消息給服務(wù)器，消息內(nèi)包含自己的用戶名、密碼等信息，服務(wù)器鑒權(quán)通過后，和客戶端建立連接。若雙方想要斷開連接，則需要遵循TCP協(xié)議的四次揮手規(guī)則，才能正常斷開連接?？蛻舳嗽诎l(fā)送CONNECT消息時(shí)，還可以指定“最后遺愿（last will）”消息，包括消息的主題和內(nèi)容。當(dāng)服務(wù)器檢測(cè)到客戶端異常斷開連接時(shí)，就會(huì)自動(dòng)發(fā)布這條“最后遺愿”消息。

SUBSCRIBE：當(dāng)客戶端訂閱主題時(shí)，需要發(fā)送一條SUBSCRIBE消息給服務(wù)器，指定要訂閱的主題。MQTT協(xié)議的主題表示為層次結(jié)構(gòu)，類似文件系統(tǒng)，例如“/huawei/v1/devices”這種格式。同理，客戶端可以通過UNSUBSCRIBE消息取消訂閱指定主題。

PUBLISH：當(dāng)客戶端發(fā)布消息時(shí)，需要發(fā)送一條PUBLISH消息給服務(wù)器，指定消息的主題和內(nèi)容。MQTT對(duì)發(fā)布消息的內(nèi)容格式不做限制，需要由各個(gè)服務(wù)提供商自行制定規(guī)范?？蛻舳税l(fā)布消息時(shí)可以指定該消息是否需要保留，一個(gè)主題只能保留一條消息，被保留的消息會(huì)被代理服務(wù)器記錄，以后每個(gè)新訂閱這個(gè)主題的客戶端都會(huì)先接收到這條保留消息。

在可靠傳輸方面，MQTT協(xié)議提供三種QoS等級(jí)的實(shí)現(xiàn)：

QoS=0表示消息只會(huì)被發(fā)送一次，但該消息可能會(huì)丟失。

QoS=1表示確保消息會(huì)到達(dá)至少一次，但可能會(huì)造成訂閱者收到多條重復(fù)消息。

QoS=2表示確保消息會(huì)到達(dá)且僅到達(dá)一次。

QoS等級(jí)越高，消息傳輸?shù)目煽慷仍礁?，但?shí)現(xiàn)也會(huì)越復(fù)雜，對(duì)網(wǎng)絡(luò)和設(shè)備資源的占用也會(huì)變多，所以傳輸時(shí)選用哪個(gè)級(jí)別的QoS需要根據(jù)實(shí)際狀況選擇。

總結(jié)

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

CoAP/LWM2M協(xié)議基于UDP協(xié)議，服務(wù)器和客戶端之間不保持連接；通信基于請(qǐng)求/響應(yīng)模型，與互聯(lián)網(wǎng)主流的HTTP協(xié)議相同，主要用于點(diǎn)對(duì)點(diǎn)的通信。CoAP/LWM2M協(xié)議針對(duì)物聯(lián)網(wǎng)場(chǎng)景定義了各種類型和標(biāo)簽，支持內(nèi)容協(xié)商與發(fā)現(xiàn)，允許設(shè)備相互探測(cè)以找到交換數(shù)據(jù)的方式；報(bào)文為極簡(jiǎn)的二進(jìn)制報(bào)文，長(zhǎng)度更短，對(duì)設(shè)備和網(wǎng)絡(luò)的要求更低。

MQTT協(xié)議基于TCP協(xié)議，服務(wù)端和客戶端之間保持連接；通信基于分布/訂閱模型，可以簡(jiǎn)單實(shí)現(xiàn)多對(duì)多的通信場(chǎng)景。MQTT協(xié)議設(shè)計(jì)簡(jiǎn)單，易于理解和學(xué)習(xí)；報(bào)文消息基于文本，消息負(fù)載格式無限制，自由度更高，更便于調(diào)測(cè)和排障時(shí)查看和理解，但同時(shí)也需要服務(wù)提供商制定通信規(guī)范（接口文檔），設(shè)備之間才可進(jìn)行有效通信。

綜上所述，CoAP/LWM2M協(xié)議和MQTT協(xié)議各有其特點(diǎn)，并不存在誰優(yōu)誰劣，您需要根據(jù)自己的設(shè)備的應(yīng)用場(chǎng)景選擇最適合的協(xié)議。
編輯：hfy