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
架構
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，相反地，提供內置支持內容協商與發現，允許設備相互探測以找到交換數據的方式。
兩種協議各有優缺點，選擇合適的取決於自己的應用。
