IoT物聯(lián)網(wǎng)需要標準協(xié)議，針對小設(shè)備最有前景的兩種是MQTT和CoAP。

MQTT和CoAP兩者均：

開放標準；

比HTTP更適合于受限環(huán)境；

提供異步傳輸機制；

在IP上運行；

有很多種實現(xiàn)

MQTT在傳輸模式上更為靈活，對二進制數(shù)據(jù)而言就像是管道，CoAP為面向網(wǎng)絡(luò)的設(shè)計。

MQTT

為輕量M2M通訊設(shè)計的一種發(fā)布/訂閱消息協(xié)議，起初由IBM研發(fā)，現(xiàn)在是一種開放標準。

架構(gòu)

客戶端/服務(wù)器模型，其中每一個傳感器為一個客戶端，通過TCP連接到服務(wù)器，也稱為代理。

MQTT以消息為導向，每個消息是具體的一組數(shù)據(jù)，對代理是透明的。

每個消息發(fā)布至一個地址，稱為主題，客戶端也許會訂閱多種主題，訂閱某個主題的每一個客戶端會收到所有發(fā)布到主題的消息。舉個例子說明，設(shè)想一個簡單的網(wǎng)絡(luò)，有一個中間代理和三個客戶端。

所有三個客戶端與代理建立TCP連接，客戶端B、C訂閱溫度主題

稍后，客戶端A給溫度主題發(fā)布了一個值22.5，代理轉(zhuǎn)發(fā)消息給所有訂閱客戶端。

發(fā)布/訂閱模型允許MQTT客戶端以一對一、一對多和多對一方式進行通訊。

主題匹配

MQTT中，主題是層次結(jié)構(gòu)的，像文件系統(tǒng)（例如：kitchen/oven/temperature）。當注冊訂閱時允許通配符，但不是發(fā)布時，允許整個層次結(jié)構(gòu)被客戶端觀察。

通配符+匹配任意單個目錄名稱，#匹配任意數(shù)量任意名稱目錄。

例如：主題kitchen/+/temperature可以匹配kitchen/foo/temperature，但是不能匹配

kitchen/foo/bar/temperature，而kitchen/# 可以匹配 kitchen/fridge/compressor/valve1/temperature。

應(yīng)用級QoS

支持三種服務(wù)質(zhì)量等級：觸發(fā)而遺忘、至少傳送一次、僅僅傳送一次。

遺愿遺囑

MQTT客戶端可以注冊一個典型的遺愿遺囑消息，如果它們斷開連接，由代理發(fā)送。這些消息可以用于向訂閱者發(fā)出信號，當設(shè)備斷開連接時。

持久化

MQTT支持在代理上存儲持久化消息，當發(fā)布消息時，客戶端也許會要求代理能夠持久化消息。只有最近的持久消息會被存儲。當客戶端訂閱一個主題時，任何持久化消息會被發(fā)送至客戶端。

不像消息隊列，MQTT代理不允許持久化消息在服務(wù)器內(nèi)部備用。

安全

MQTT代理也許會要求用戶名、密碼認證，為確保隱私，TCP連接也許會用SSL/TLS加密。

MQTT-SN

雖然MQTT設(shè)計為輕量的，但是對于受限設(shè)備來說，有兩個缺點。

每一個MQTT客戶端必須支持TCP，任何時候都要求保持連接到代理。對于丟包很嚴重或者計算資源稀缺的環(huán)境來說，這會是一個問題。

MQTT主題名稱通常是長字符串，使得其對802.15.4不切實際。

MQTT-SN協(xié)議解決這些問題，定義MQTT UDP映射，增加代理支持主題名稱索引。

CoAP

來自CoRE(受限資源環(huán)境)IETF 組的受限應(yīng)用協(xié)議

架構(gòu)

類似HTTP，CoAP是文本輸出協(xié)議，但是不像HTTP，CoAP為受限制的設(shè)備設(shè)計。

CoAP數(shù)據(jù)包比HTTP TCP流小得多，比特域與從字符串映射到整型廣泛運用以節(jié)省空間。數(shù)據(jù)包易于生成，可以原位解析，不用消耗受限制設(shè)備內(nèi)的額外RAM。

CoAP運行在UDP上，而不是TCP。客戶端與服務(wù)器通過無連接的數(shù)據(jù)報進行通訊，在應(yīng)用棧內(nèi)實現(xiàn)重傳與重排序。無需TCP也許會使得小型微處理器全部IP網(wǎng)絡(luò)化，CoAP允許使用UDP廣播與多播用于地址。

CoAP遵循客戶端/服務(wù)器模型，客戶端向服務(wù)器請求，服務(wù)器回送響應(yīng)，客戶端可以GET、PUT、POST和DELETE資源。

CoAP用于通過簡單代理與HTTP、RESTFUL網(wǎng)絡(luò)交互。

因為CoAP基于數(shù)據(jù)報文，也許會用于SMS或者其他基于分組的通訊協(xié)議之上。

應(yīng)用級QoS

請求與響應(yīng)也許會被標記為可確認的或者非確認的，可確認的消息必須由接收方通過ACK包進行確認。

非確認的消息是觸發(fā)而忘記的。

內(nèi)容協(xié)商

像HTTP，CoAP支持內(nèi)容協(xié)商，客戶端使用Accept選項表達傾向的資源表示，服務(wù)器回復Content-Type選項告知客戶端它們接收的東西。和HTTP一樣，這允許客戶端與服務(wù)器獨立演進，增加新的表達方式，而互不影響。

CoAP請求也許會使用查詢字符串形式如?a=b&c=d，這些可以用于給客戶端提供搜索、分頁與其他特性。

安全

因為CoAP建立在UDP而不是TCP之上，SSL/TLS不可用于提供安全性。DTLS數(shù)據(jù)報傳輸層安全提供了與TLS同樣的保證機制，但是針對UDP之上數(shù)據(jù)傳輸。通常來說，具備DTLS能力的CoAP設(shè)備支持RSA、AES或者ECC、AES。

觀察

CoAP拓展了HTTP請求模型，有能力觀察資源。當觀察標記在CoAP GET請求之上設(shè)定時，服務(wù)器會繼續(xù)應(yīng)答在初始文檔已經(jīng)傳輸過后。這使得服務(wù)器能夠?qū)顟B(tài)變化發(fā)生時流向客戶端。兩邊一方結(jié)束會取消觀察。

資源發(fā)現(xiàn)

CoAP為資源發(fā)現(xiàn)定義標準機制，服務(wù)端提供資源列表（同時包括相關(guān)的元數(shù)據(jù)）在/.well-known/core。這些鏈接以應(yīng)用/鏈接格式媒介形式，允許客戶端發(fā)現(xiàn)提供什么樣的資源，并且它們是什么媒介形式。

NAT問題

CoAP, 傳感器節(jié)點一般是一個服務(wù)器，而不是一個客戶端（雖然有可能兩者都是）。傳感器（或者）提供客戶端可以訪問的資源，或者改變傳感器狀態(tài)。

雖然CoAP傳感器是服務(wù)器，它們必須能夠接收數(shù)據(jù)包。NAT后合理運行，設(shè)備也許會先發(fā)送一個請求，像在LWM2M中做的，允許路由器關(guān)聯(lián)兩者。雖然CoAP不需要IPV6，在設(shè)備直接路由的IP環(huán)境內(nèi)最易于使用。

對比

MQTT和CoAP作為IoT協(xié)議都很有用，但是也有重要的區(qū)別。

MQTT是多對多通訊協(xié)議用于在不同客戶端之間通過中間代理傳送消息，解耦生產(chǎn)者與消費者，通過使得客戶端發(fā)布，讓代理決定路由并且拷貝消息。雖然MQTT支持一些持久化，最好還是作為實時數(shù)據(jù)通訊總線。

CoAP主要是一個點對點協(xié)議，用于在客戶端與服務(wù)器之間傳輸狀態(tài)信息。雖然支持觀察資源，CoAP最好適合狀態(tài)傳輸模型，不是完全基于事件。

MQTT客戶端建立長連接TCP，這通常表示沒有問題，CoAP客戶端與服務(wù)器都發(fā)送與接收UDP數(shù)據(jù)包，在NAT環(huán)境中，隧道或者端口轉(zhuǎn)發(fā)可以用于允許CoAP，或者像LWM2M，設(shè)備也許會先初始化前端連接。

MQTT不提供支持消息打類型標記或者其他元數(shù)據(jù)幫助客戶端理解，MQTT消息可用于任何目的，但是所有的客戶端必須知道向上的數(shù)據(jù)格式以允許通訊，CoAP，相反地，提供內(nèi)置支持內(nèi)容協(xié)商與發(fā)現(xiàn)，允許設(shè)備相互探測以找到交換數(shù)據(jù)的方式。

兩種協(xié)議各有優(yōu)缺點，選擇合適的取決于自己的應(yīng)用

總結(jié)

以上是生活随笔為你收集整理的IoT -- (六) MQTT和CoAP对比分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。