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

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

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

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

CoAP/LWM2M協(xié)議

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

VER：長度2位，用于表示CoAP協(xié)議的版本號。

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

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

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

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

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

TKL：長度4位，用于表示Token字段的長度。

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

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

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

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

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

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

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

LWM2M協(xié)議

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

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

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

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

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

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

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

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

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

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

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

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

MQTT協(xié)議

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

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

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