IoT物聯網需要標準協議，針對小設備最有前景的兩種是MQTT和CoAP。

MQTT和CoAP兩者均：

開放標準；

比HTTP更適合于受限環境；

提供異步傳輸機制；

在IP上運行；

有很多種實現

MQTT在傳輸模式上更為靈活，對二進制數據而言就像是管道，CoAP為面向網絡的設計。

MQTT

為輕量M2M通訊設計的一種發布/訂閱消息協議，起初由IBM研發，現在是一種開放標準。

架構

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

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

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

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

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

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

主題匹配

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

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

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

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

應用級QoS

支持三種服務質量等級：觸發而遺忘、至少傳送一次、僅僅傳送一次。

遺愿遺囑

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

持久化

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

不像消息隊列，MQTT代理不允許持久化消息在服務器內部備用。

安全

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

MQTT-SN

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

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

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

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

CoAP

來自CoRE(受限資源環境)IETF 組的受限應用協議

架構

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

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

CoAP運行在UDP上，而不是TCP。客戶端與服務器通過無連接的數據報進行通訊，在應用棧內實現重傳與重排序。無需TCP也許會使得小型微處理器全部IP網絡化，CoAP允許使用UDP廣播與多播用于地址。

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

CoAP用于通過簡單代理與HTTP、RESTFUL網絡交互。

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

應用級QoS

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

非確認的消息是觸發而忘記的。

內容協商

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

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

安全

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

觀察

CoAP拓展了HTTP請求模型，有能力觀察資源。當觀察標記在CoAP GET請求之上設定時，服務器會繼續應答在初始文檔已經傳輸過后。這使得服務器能夠將狀態變化發生時流向客戶端。兩邊一方結束會取消觀察。

資源發現

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

NAT問題

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

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

對比

MQTT和CoAP作為IoT協議都很有用，但是也有重要的區別。

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

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

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

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

兩種協議各有優缺點，選擇合適的取決于自己的應用

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。