物聯(lián)網(wǎng)IoT終端設(shè)備如何選擇接入?yún)f(xié)議

時間：2020-05-07 16:05:54

關(guān)鍵字：終端設(shè)備物聯(lián)網(wǎng) IoT 物聯(lián)網(wǎng)設(shè)備

手機看文章

掃描二維碼
隨時隨地手機看文章

[導(dǎo)讀]目前市面上大多數(shù)IoT模組都支持TCP、UDP、CoAP、LwM2M、MQTT等協(xié)議，這里面既有傳輸層的協(xié)議也有應(yīng)用層的協(xié)議，協(xié)議眾多，適用的場景也不同。但是設(shè)計產(chǎn)品時通常只需要運用一種協(xié)議，那么怎么來選擇一種符合自己產(chǎn)品的應(yīng)用場景的協(xié)議顯得尤為重要。本文將介紹

目前市面上大多數(shù)IoT模組都支持TCP、UDP、CoAP、LwM2M、MQTT等協(xié)議，這里面既有傳輸層的協(xié)議也有應(yīng)用層的協(xié)議，協(xié)議眾多，適用的場景也不同。但是設(shè)計產(chǎn)品時通常只需要運用一種協(xié)議，那么怎么來選擇一種符合自己產(chǎn)品的應(yīng)用場景的協(xié)議顯得尤為重要。本文將介紹 TCP、UDP、CoAP、LwM2M、MQTT這5個常用的協(xié)議的特點與區(qū)別，為設(shè)計產(chǎn)品時協(xié)議的選擇提供參考。

傳輸層協(xié)議TCP與UDP

TCP（傳輸控制協(xié)議，Transport Controll Protocol）、UDP（用戶數(shù)據(jù)報協(xié)議，User Data Protocol）同屬于傳輸層協(xié)議，為上層用戶提供級別的通信可靠性。

傳輸控制協(xié)議（TCP）：TCP（傳輸控制協(xié)議）定義了兩臺計算機之間進行可靠的傳輸而交換的數(shù)據(jù)和確認信息的格式，以及計算機為了確保數(shù)據(jù)的正確到達而采取的措施。協(xié)議規(guī)定了TCP軟件怎樣識別給定計算機上的多個目的進程如何對分組重復(fù)這類差錯進行恢復(fù)。協(xié)議還規(guī)定了兩臺計算機如何初始化一個TCP數(shù)據(jù)流傳輸以及如何結(jié)束這一傳輸。TCP最大的特點就是提供的是面向連接、可靠的字節(jié)流服務(wù)。

用戶數(shù)據(jù)報協(xié)議（UDP）：UDP（用戶數(shù)據(jù)報協(xié)議）是一個簡單的面向數(shù)據(jù)報的傳輸層協(xié)議。提供的是非面向連接的、不可靠的數(shù)據(jù)流傳輸。UDP不提供可靠性，也不提供報文到達確認、排序以及流量控制等功能。它只是把應(yīng)用程序傳給IP層的數(shù)據(jù)報發(fā)送出去，但是并不能保證它們能到達目的地。因此報文可能會丟失、重復(fù)以及亂序等。但由于UDP在傳輸數(shù)據(jù)報前不用在客戶和服務(wù)器之間建立一個連接，且沒有超時重發(fā)等機制，故而傳輸速度很快

TCP與UDP的區(qū)別

差異	TCP	UDP
是否連接	面向連接	面向非連接
傳輸可靠性	可靠	不可靠
應(yīng)用場合	少量數(shù)據(jù)	大量數(shù)據(jù)
速度	慢	快

1、TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接

2、TCP提供可靠的服務(wù)。也就是說，通過TCP連接傳送的數(shù)據(jù)，無差錯，不丟失，不重復(fù)，且按序到達;UDP盡最大努力交付，即不保證可靠交付

3、TCP面向字節(jié)流，實際上是TCP把數(shù)據(jù)看成一連串無結(jié)構(gòu)的字節(jié)流;UDP是面向報文的

UDP沒有擁塞控制，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會使源主機的發(fā)送速率降低（對實時應(yīng)用很有用，如IP電話，實時視頻會議等）

4、每一條TCP連接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通信

5、TCP首部開銷20字節(jié);UDP的首部開銷小，只有8個字節(jié) 6、TCP的邏輯通信信道是全雙工的可靠信道，UDP則是不可靠信道

那么傳輸層協(xié)議是否適合直接運用到物聯(lián)網(wǎng)設(shè)備終端上？

傳輸層，顧名思義，他只負責(zé)傳輸數(shù)據(jù)，就好比是一輛運貨的貨車，但是想讓貨物完好無損地運到目的地，那就還需要做打包、裝車、驗貨、入庫、簽回單等工作，這就需要做更多地工作，這些工作也就是應(yīng)用層協(xié)議要做的工作。所以物聯(lián)網(wǎng)設(shè)備終端要想對數(shù)據(jù)進行穩(wěn)定、可靠地交互，就需要使用應(yīng)用層的協(xié)議，而不能直接使用傳輸層的協(xié)議。以下將介紹MQTT、CoAP、LwM2M三種適合在物聯(lián)網(wǎng)設(shè)備終端上運用的應(yīng)用層協(xié)議。

應(yīng)用層協(xié)議MQTT 與CoAP

1、MQTT概述

MQTT(Message Queuing Telemetry Transport，消息隊列遙測傳輸)是IBM開發(fā)的一個即時通訊協(xié)議，有可能成為物聯(lián)網(wǎng)的重要組成部分。該協(xié)議支持所有平臺，幾乎可以把所有聯(lián)網(wǎng)物品和外部連接起來，被用來當(dāng)做傳感器和制動器(比如通過Twitter讓房屋聯(lián)網(wǎng))的通信協(xié)議。

2、MQTT協(xié)議特點

MQTT協(xié)議是為大量計算能力有限，且工作在低帶寬、不可靠的網(wǎng)絡(luò)的遠程傳感器和控制設(shè)備通訊而設(shè)計的協(xié)議，它具有以下主要的幾項特性：

1、使用發(fā)布/訂閱消息模式，提供一對多的消息發(fā)布，解除應(yīng)用程序耦合;

2、對負載內(nèi)容屏蔽的消息傳輸;

3、使用TCP/IP 提供網(wǎng)絡(luò)連接;

4、有三種消息發(fā)布服務(wù)質(zhì)量：

“至多一次”，消息發(fā)布完全依賴底層 TCP/IP 網(wǎng)絡(luò)。會發(fā)生消息丟失或重復(fù)。這一級別可用于如下情況，環(huán)境傳感器數(shù)據(jù)，丟失一次讀記錄無所謂，因為不久后還會有第二次發(fā)送?！爸辽僖淮巍保_保消息到達，但消息重復(fù)可能會發(fā)生?！爸挥幸淮巍保_保消息到達一次。這一級別可用于如下情況，在計費系統(tǒng)中，消息重復(fù)或丟失會導(dǎo)致不正確的結(jié)果。小型傳輸，開銷很小(固定長度的頭部是 2 字節(jié))，協(xié)議交換最小化，以降低網(wǎng)絡(luò)流量。

3、CoAP概述

由于物聯(lián)網(wǎng)中的很多設(shè)備都是資源受限型的，即只有少量的內(nèi)存空間和有限的計算能力，所以傳統(tǒng)的HTTP協(xié)議應(yīng)用在物聯(lián)網(wǎng)上就顯得過于龐大而不適用。IETF的CoRE工作組提出了一種基于REST架構(gòu)的CoAP協(xié)議。CoAP是工作在UDP協(xié)議族,采用的是二進制格式，相比起HTTP采用的文本格式，CoAP比HTTP更加緊湊。

4、CoAP協(xié)議特點

1、消息模型，以消息為數(shù)據(jù)通信載體，通過交換網(wǎng)絡(luò)消息來實現(xiàn)設(shè)備間數(shù)據(jù)通信

2、對云端設(shè)備資源操作都是通過請求與響應(yīng)機制來完成，類似HTTP，設(shè)備端可通過4個請求方法（GET, PUT, POST, DELETE）對服務(wù)器端資源進行操作。

3、協(xié)議包輕量級，最小長度僅為4B。

4、支持可靠傳輸，數(shù)據(jù)重傳，塊傳輸，確保數(shù)據(jù)可靠到達。

5、支持IP多播, 即可以同時向多個設(shè)備發(fā)送請求

6、非長連接通信，適用于低功耗物聯(lián)網(wǎng)場景

5、MQTT與CoAP的區(qū)別

類別	MQTT	CoAP
通信機制	異步	同步
連接方式	TCP	UDP
通信模式	多對多	多對一
使用場景	更適用于推送和IM	物聯(lián)網(wǎng)
功耗	功耗高	功耗低
反向控制	可用于反向控制	非長連接，不適合反向控制

那么MQTT和CoAP哪個更適合用于物聯(lián)網(wǎng)設(shè)備上呢？

MQTT和CoAP其實都比較適用于物聯(lián)網(wǎng)設(shè)備上，但是還是要根具實際場景來選擇使用。比如設(shè)備運行在一個不需要考慮功耗，但是需要實時被控制的場景，例如充電樁、快遞柜等場景，則使用MQTT協(xié)議比較合適。如果設(shè)備通常只有上報數(shù)據(jù)，且對功耗很敏感的場景，例如水表、燃氣表等場景，則使用CoAP協(xié)議比較合適。

隨著物聯(lián)網(wǎng)興起，萬物互聯(lián)的時代終將到來。但鑒于成本和性能的考慮，設(shè)備的資源往往受限，那么就需要一種專門為資源受限的物聯(lián)網(wǎng)設(shè)備設(shè)計的協(xié)議來滿足萬物互聯(lián)的需求，這就是LwM2M協(xié)議。

1、LwM2M概述：

OMA是一家國際組織，最初定義了一套 OMA-DM的協(xié)議，用來遠程管理移動終端設(shè)備，比如手機開戶，版本升級，等等。OMA-DM有著非常廣泛的應(yīng)用，很多運營商比如Verizon Wireless, Sprint都有自己的OMA-DM服務(wù)并要求手機/模塊入網(wǎng)的時候通過自定義的OMA-DM入網(wǎng)測試。因為物聯(lián)網(wǎng)的興起，OMA在傳統(tǒng)的OMA-DM協(xié)議基礎(chǔ)之上，提出了LwM2M協(xié)議。2013年底，OMA發(fā)布了LwM2M規(guī)范。

OMA Lightweight M2M 主要動機是定義一組輕量級的協(xié)議適用于各種物聯(lián)網(wǎng)設(shè)備，因為M2M設(shè)備通常是資源非常有限的嵌入式終端，無UI,計算能力和網(wǎng)絡(luò)通信能力都有限。同時也因為物聯(lián)網(wǎng)終端的巨大數(shù)量，節(jié)約網(wǎng)絡(luò)資源變得很重要。

2、LwM2M 協(xié)議邏輯實體與邏輯接口

LwM2M 定義了三個邏輯實體:

1、LwM2M Server 服務(wù)器

2、LwM2M client 客戶端負責(zé)執(zhí)行服務(wù)器的命令和上報執(zhí)行結(jié)果

3、LwM2M 引導(dǎo)服務(wù)器 Bootstrap server 負責(zé)配置LwM2M客戶端.

在這三個邏輯實體之間有4個邏輯接口：

Device Discovery and Registration：這個接口讓客戶端注冊到服務(wù)器并通知服務(wù)器客戶端所支持的能力(簡單說就是支持哪些資源Resource和對象Object

Bootstrap：Bootstrap server:通過這個接口來配置Clinet - 比如說LwM2M server的URL地址 Device Management and Service Enablement：這個就是最主要的業(yè)務(wù)接口了。LwM2M Server 發(fā)送指令給 Client 并收到回應(yīng).

Information Reporting：這個接口是 LwM2M Client 來上報其資源信息的，比如傳感器溫度。上報方式可以是事件觸發(fā)，也可以是周期性的。

這三個邏輯實體與四個邏輯接口之間的關(guān)系如下圖：

3、LwM2M 協(xié)議棧：

LwM2M 協(xié)議棧結(jié)構(gòu)如下圖所示：

LwM2M Objects
LwM2M Protocol
CoAP
DTLS
UDP	SMS

LwM2M Objects: 每個對象對應(yīng)客戶端的某個特定功能實體. LwM2M 規(guī)范定義了一下標準Objects，比如

urn:oma:lwm2m:oma:2; (LwM2M Server Object)

urn:oma:lwm2m:oma:3; (LwM2M Access Control Object)

每個object下可以有很多resource. 比如Firmware object可以有Firmware版本號，size等resource.

Vendor可以自己定義object

LwM2M Protocol: 定義了一些邏輯操作，比如Read, Write, Execute, Create or Delete.

CoAP: 是IETF 定義的Constrained Application Protocol 用來做LwM2M的傳輸層，下層可以是 UDP 或SMS .UDP 是必須支持的，SMS是可選的。CoAP有自己的消息頭，重傳機制等。

DTLS: 是用來保證客戶端和服務(wù)器間的安全性的.

4、LwM2M與CoAP的關(guān)系:

LwM2M的消息沒有對稱的反饋消息，由于LwM2M承載在CoAP協(xié)議上，使用CoAP的get、post、put、delete方式，對于相應(yīng)消息成功或失敗的反饋是通過CoAP協(xié)議本身的交互來實現(xiàn)的。LwM2M載荷支持四種格式 plain text、Opaque、TLV、JSON,這四種協(xié)議要求服務(wù)器端必須都要支持，而在客戶端必須支持TLV格式。1