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