TCP與UDP的區(qū)別
| 差異 | TCP | UDP |
|---|---|---|
| 是否連接 | 面向連接 | 面向非連接 |
| 傳輸可靠性 | 可靠 | 不可靠 |
| 應用場合 | 少量數據 | 大量數據 |
| 速度 | 慢 | 快 |
1、TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的，即發(fā)送數據之前不需要建立連接
2、TCP提供可靠的服務。也就是說，通過TCP連接傳送的數據，無差錯，不丟失，不重復，且按序到達;UDP盡最大努力交付，即不保證可靠交付
3、TCP面向字節(jié)流，實際上是TCP把數據看成一連串無結構的字節(jié)流;UDP是面向報文的
UDP沒有擁塞控制，因此網絡出現擁塞不會使源主機的發(fā)送速率降低（對實時應用很有用，如IP電話，實時視頻會議等）
4、每一條TCP連接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通信
5、TCP首部開銷20字節(jié);UDP的首部開銷小，只有8個字節(jié) 6、TCP的邏輯通信信道是全雙工的可靠信道，UDP則是不可靠信道
那么傳輸層協議是否適合直接運用到物聯網設備終端上？
傳輸層，顧名思義，他只負責傳輸數據，就好比是一輛運貨的貨車，但是想讓貨物完好無損地運到目的地，那就還需要做打包、裝車、驗貨、入庫、簽回單等工作，這就需要做更多地工作，這些工作也就是應用層協議要做的工作。所以物聯網設備終端要想對數據進行穩(wěn)定、可靠地交互，就需要使用應用層的協議，而不能直接使用傳輸層的協議。以下將介紹MQTT、CoAP、LwM2M三種適合在物聯網設備終端上運用的應用層協議。
應用層協議MQTT 與CoAP
MQTT(Message Queuing Telemetry Transport，消息隊列遙測傳輸)是IBM開發(fā)的一個即時通訊協議，有可能成為物聯網的重要組成部分。該協議支持所有平臺，幾乎可以把所有聯網物品和外部連接起來，被用來當做傳感器和制動器(比如通過Twitter讓房屋聯網)的通信協議。
2、MQTT協議特點
1、使用發(fā)布/訂閱消息模式，提供一對多的消息發(fā)布，解除應用程序耦合;
2、對負載內容屏蔽的消息傳輸;
3、使用TCP/IP 提供網絡連接;
4、有三種消息發(fā)布服務質量：
“至多一次”，消息發(fā)布完全依賴底層 TCP/IP 網絡。會發(fā)生消息丟失或重復。這一級別可用于如下情況，環(huán)境傳感器數據，丟失一次讀記錄無所謂，因為不久后還會有第二次發(fā)送?！爸辽僖淮巍?，確保消息到達，但消息重復可能會發(fā)生。“只有一次”，確保消息到達一次。這一級別可用于如下情況，在計費系統(tǒng)中，消息重復或丟失會導致不正確的結果。小型傳輸，開銷很小(固定長度的頭部是 2 字節(jié))，協議交換最小化，以降低網絡流量。
由于物聯網中的很多設備都是資源受限型的，即只有少量的內存空間和有限的計算能力，所以傳統(tǒng)的HTTP協議應用在物聯網上就顯得過于龐大而不適用。IETF的CoRE工作組提出了一種基于REST架構的CoAP協議。CoAP是工作在UDP協議族,采用的是二進制格式，相比起HTTP采用的文本格式，CoAP比HTTP更加緊湊。
4、CoAP協議特點
1、消息模型，以消息為數據通信載體，通過交換網絡消息來實現設備間數據通信
2、對云端設備資源操作都是通過請求與響應機制來完成，類似HTTP，設備端可通過4個請求方法（GET, PUT, POST, DELETE）對服務器端資源進行操作。
3、協議包輕量級，最小長度僅為4B。
4、支持可靠傳輸，數據重傳，塊傳輸，確保數據可靠到達。
5、支持IP多播, 即可以同時向多個設備發(fā)送請求
5、MQTT與CoAP的區(qū)別
| 類別 | MQTT | CoAP |
|---|---|---|
| 通信機制 | 異步 | 同步 |
| 連接方式 | TCP | UDP |
| 通信模式 | 多對多 | 多對一 |
| 使用場景 | 更適用于推送和IM | 物聯網 |
| 功耗 | 功耗高 | 功耗低 |
| 反向控制 | 可用于反向控制 | 非長連接，不適合反向控制 |
那么MQTT和CoAP哪個更適合用于物聯網設備上呢？
隨著物聯網興起，萬物互聯的時代終將到來。但鑒于成本和性能的考慮，設備的資源往往受限，那么就需要一種專門為資源受限的物聯網設備設計的協議來滿足萬物互聯的需求，這就是LwM2M協議。
1、LwM2M概述：
OMA是一家國際組織，最初定義了一套 OMA-DM的協議，用來遠程管理移動終端設備，比如手機開戶，版本升級，等等。OMA-DM有著非常廣泛的應用，很多運營商比如Verizon Wireless, Sprint都有自己的OMA-DM服務并要求手機/模塊入網的時候通過自定義的OMA-DM入網測試。因為物聯網的興起，OMA在傳統(tǒng)的OMA-DM協議基礎之上，提出了LwM2M協議。2013年底，OMA發(fā)布了LwM2M規(guī)范。
LwM2M 定義了三個邏輯實體:
在這三個邏輯實體之間有4個邏輯接口：
Device Discovery and Registration：這個接口讓客戶端注冊到服務器并通知服務器客戶端所支持的能力(簡單說就是支持哪些資源Resource和對象Object
Bootstrap：Bootstrap server:通過這個接口來配置Clinet - 比如說LwM2M server的URL地址 Device Management and Service Enablement：這個就是最主要的業(yè)務接口了。LwM2M Server 發(fā)送指令給 Client 并收到回應.
Information Reporting：這個接口是 LwM2M Client 來上報其資源信息的，比如傳感器溫度。上報方式可以是事件觸發(fā)，也可以是周期性的。
這三個邏輯實體與四個邏輯接口之間的關系如下圖：
3、LwM2M 協議棧：
LwM2M 協議棧結構如下圖所示：
| LwM2M Objects | |
| LwM2M Protocol | |
| CoAP | |
| DTLS | |
| UDP | SMS |
urn:oma:lwm2m:oma:2; (LwM2M Server Object)
urn:oma:lwm2m:oma:3; (LwM2M Access Control Object)
每個object下可以有很多resource. 比如Firmware object可以有Firmware版本號，size等resource.
LwM2M Protocol: 定義了一些邏輯操作，比如Read, Write, Execute, Create or Delete.
CoAP: 是IETF 定義的Constrained Application Protocol 用來做LwM2M的傳輸層，下層可以是 UDP 或SMS .UDP 是必須支持的，SMS是可選的。CoAP有自己的消息頭，重傳機制等。
LwM2M的消息沒有對稱的反饋消息，由于LwM2M承載在CoAP協議上，使用CoAP的get、post、put、delete方式，對于相應消息成功或失敗的反饋是通過CoAP協議本身的交互來實現的。LwM2M載荷支持四種格式 plain text、Opaque、TLV、JSON,這四種協議要求服務器端必須都要支持，而在客戶端必須支持TLV格式。1
猜你喜歡：
【Linux筆記】pc機_開發(fā)板_ubuntu互ping實驗
【Linux筆記】掛載網絡文件系統(tǒng)
后臺回復：加群。添加ZhengN微信，加入【嵌入式大雜燴】交流群
點個贊，證明你還愛我
免責聲明：本文內容由21ic獲得授權后發(fā)布，版權歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯系我們，謝謝！
下載文檔
