TCP、UDP、CoAP、LwM2M、MQTT簡單對比

參考

https://iot.51cto.com/art/202002/610997.htm

目前市面上大多數IoT模組都支持TCP、UDP、CoAP、LwM2M、MQTT等協議，這裏面既有傳輸層的協議也有應用層的協議，協議衆多，適用的場景也不同。但是設計產品時通常只需要運用一種協議，那麼怎麼來選擇一種符合自己產品的應用場景的協議顯得尤爲重要。本文將介紹TCP、UDP、CoAP、LwM2M、MQTT這5個常用的協議的特點與區別，爲設計產品時協議的選擇提供參考。

一、傳輸層協議TCP與UDP

TCP(傳輸控制協議，Transport Controll Protocol)、UDP(用戶數據報協議，User Data Protocol)同屬於傳輸層協議，爲上層用戶提供級別的通信可靠性。

1. 傳輸控制協議(TCP)：

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

2. 用戶數據報協議(UDP)：

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

3. TCP與UDP的區別
   
   物聯網IoT終端設備如何選擇通信協議

TCP面向連接(如打電話要先撥號建立連接);UDP是無連接的，即發送數據之前不需要建立連接
TCP提供可靠的服務。也就是說，通過TCP連接傳送的數據，無差錯，不丟失，不重複，且按序到達;UDP盡最大努力交付，即不保證可靠交付
TCP面向字節流，實際上是TCP把數據看成一連串無結構的字節流;UDP是面向報文的UDP沒有擁塞控制，因此網絡出現擁塞不會使源主機的發送速率降低(對實時應用很有用，如IP電話，實時視頻會議等)
每一條TCP連接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通信
TCP首部開銷20字節;UDP的首部開銷小，只有8個字節 6、TCP的邏輯通信信道是全雙工的可靠信道，UDP則是不可靠信道
二、那麼傳輸層協議是否適合直接運用到物聯網設備終端上?

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

三、應用層協議MQTT 與CoAP

1. MQTT概述

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

2. MQTT協議特點

MQTT協議是爲大量計算能力有限，且工作在低帶寬、不可靠的網絡的遠程傳感器和控制設備通訊而設計的協議，它具有以下主要的幾項特性：

使用發佈/訂閱消息模式，提供一對多的消息發佈，解除應用程序耦合;
對負載內容屏蔽的消息傳輸;
使用TCP/IP 提供網絡連接;
有三種消息發佈服務質量：
“至多一次”，消息發佈完全依賴底層 TCP/IP 網絡。會發生消息丟失或重複。這一級別可用於如下情況，環境傳感器數據，丟失一次讀記錄無所謂，因爲不久後還會有第二次發送。“至少一次”，確保消息到達，但消息重複可能會發生。“只有一次”，確保消息到達一次。這一級別可用於如下情況，在計費系統中，消息重複或丟失會導致不正確的結果。小型傳輸，開銷很小(固定長度的頭部是 2 字節)，協議交換最小化，以降低網絡流量。

3. CoAP概述

由於物聯網中的很多設備都是資源受限型的，即只有少量的內存空間和有限的計算能力，所以傳統的HTTP協議應用在物聯網上就顯得過於龐大而不適用。IETF的CoRE工作組提出了一種基於REST架構的CoAP協議。CoAP是工作在UDP協議族,採用的是二進制格式，相比起HTTP採用的文本格式，CoAP比HTTP更加緊湊。

4. CoAP協議特點

消息模型，以消息爲數據通信載體，通過交換網絡消息來實現設備間數據通信
對雲端設備資源操作都是通過請求與響應機制來完成，類似HTTP，設備端可通過4個請求方法(GET, PUT, POST, DELETE)對服務器端資源進行操作。
協議包輕量級，最小長度僅爲4B。
支持可靠傳輸，數據重傳，塊傳輸，確保數據可靠到達。
支持IP多播, 即可以同時向多個設備發送請求
非長連接通信，適用於低功耗物聯網場景
5. MQTT與CoAP的區別

物聯網IoT終端設備如何選擇通信協議

四、那麼MQTT和CoAP哪個更適合用於物聯網設備上呢?

MQTT和CoAP其實都比較適用於物聯網設備上，但是還是要根據實際場景來選擇使用。比如設備運行在一個不需要考慮功耗，但是需要實時被控制的場景，例如充電樁、快遞櫃等場景，則使用MQTT協議比較合適。如果設備通常只有上報數據，且對功耗很敏感的場景，例如水錶、燃氣表等場景，則使用CoAP協議比較合適。

物聯網IoT終端設備如何選擇通信協議

隨着物聯網興起，萬物互聯的時代終將到來。但鑑於成本和性能的考慮，設備的資源往往受限，那麼就需要一種專門爲資源受限的物聯網設備設計的協議來滿足萬物互聯的需求，這就是LwM2M協議。

1. LwM2M概述：

OMA是一家國際組織，最初定義了一套 OMA-DM的協議，用來遠程管理移動終端設備，比如手機開戶，版本升級，等等。OMA-DM有着非常廣泛的應用，很多運營商比如Verizon Wireless, Sprint都有自己的OMA-DM服務並要求手機/模塊入網的時候通過自定義的OMA-DM入網測試。因爲物聯網的興起，OMA在傳統的OMA-DM協議基礎之上，提出了LwM2M協議。2013年底，OMA發佈了LwM2M規範。

OMA Lightweight M2M 主要動機是定義一組輕量級的協議適用於各種物聯網設備，因爲M2M設備通常是資源非常有限的嵌入式終端，無UI,計算能力和網絡通信能力都有限。同時也因爲物聯網終端的巨大數量，節約網絡資源變得很重要。

2. LwM2M 協議邏輯實體與邏輯接口
   
   LwM2M 定義了三個邏輯實體：
   
   LwM2M Server 服務器
   LwM2M client 客戶端 負責執行服務器的命令和上報執行結果
   LwM2M 引導服務器 Bootstrap server 負責配置LwM2M客戶端.
   在這三個邏輯實體之間有4個邏輯接口：

Device Discovery and Registration：這個接口讓客戶端註冊到服務器並通知服務器客戶端所支持的能力(簡單說就是支持哪些資源Resource和對象Object
Bootstrap：Bootstrap server:通過這個接口來配置Clinet - 比如說LwM2M server的URL地址 Device Management and Service Enablement：這個就是最主要的業務接口了。LwM2M Server 發送指令給 Client 並收到迴應.
Information Reporting：這個接口是 LwM2M Client 來上報其資源信息的，比如傳感器溫度。上報方式可以是事件觸發，也可以是週期性的。
這三個邏輯實體與四個邏輯接口之間的關係如下圖：

物聯網IoT終端設備如何選擇通信協議

3. LwM2M 協議棧

LwM2M 協議棧結構如下圖所示：

物聯網IoT終端設備如何選擇通信協議

LwM2M Objects: 每個對象對應客戶端的某個特定功能實體. LwM2M 規範定義了一下標準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: 是用來保證客戶端和服務器間的安全性的。

4. LwM2M與CoAP的關係

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