【個人物聯網成長記7】物聯網主流通訊協議解讀【華爲雲分享】
【摘要】 當今物聯網的主流通訊協議是CoAP/LWM2M協議和MQTT協議，本文將會爲您分別解讀這些協議的工做方式，瞭解它們的特色，助您選擇最適合您的設備的通訊協議。javascript
通訊協議又稱爲傳輸協議，用於定義多個設備之間傳播信息時的系統標準。通訊協議定義了設備通訊中的語法、語義、同步規則和發生錯誤時的處理原則，能夠理解爲機器之間使用的語言。html
在物聯網場景中，通訊主要發生在設備和物聯網平臺之間，因爲大部分物聯網設備都是資源受限型設備，它們的物理資源和網絡資源都很是有限，直接使用現有的HTTP協議進行通訊對它們來講要求實在是過高了。所以，物聯網場景中主要使用的通訊協議都是輕量級的，爲資源受限環境而設計的通訊協議，例如CoAP/LWM2M協議和MQTT協議。java
本文將會爲您分別解讀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：應答報文。ui
-
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協議後，接下來咱們再瞭解下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的網站查看詳細協議。
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的官網查看詳細協議。
總結
在分別瞭解過CoAP/LWM2M協議和MQTT協議以後，咱們能夠得知，LWM2M協議是基於CoAP協議的一種具體規範，而MQTT協議是不一樣於CoAP協議的另外一種傳輸協議。
CoAP/LWM2M協議基於UDP協議，服務器和客戶端之間不保持鏈接；通訊基於請求/響應模型，與互聯網主流的HTTP協議相同，主要用於點對點的通訊。CoAP/LWM2M協議針對物聯網場景定義了各類類型和標籤，支持內容協商與發現，容許設備相互探測以找到交換數據的方式；報文爲極簡的二進制報文，長度更短，對設備和網絡的要求更低。
MQTT協議基於TCP協議，服務端和客戶端之間保持鏈接；通訊基於分佈/訂閱模型，能夠簡單實現多對多的通訊場景。MQTT協議設計簡單，易於理解和學習；報文消息基於文本，消息負載格式無限制，自由度更高，更便於調測和排障時查看和理解，但同時也須要服務提供商制定通訊規範（接口文檔），設備之間纔可進行有效通訊。
綜上所述，CoAP/LWM2M協議和MQTT協議各有其特色，並不存在誰優誰劣，您須要根據本身的設備的應用場景選擇最適合的協議。
若您但願進一步瞭解使用CoAP/LWM2M協議和MQTT協議的設備分別是如何接入華爲雲物聯網平臺的，可查看華爲雲幫助中心的開發指南。
做者：我是滷蛋