物聯網應用層通訊協定標準比較 CoAP vs MQTT

機器對機器 (Machine-to-Machine， M2M)通訊是物聯網的一個重要運作概念。隨著物聯網的應用日益興盛，M2M流量會持續增加，故針對M2M Traffic特徵及其應用，M2M通訊技術應運而生。由於物聯網架構下，感測節點本身多半採用MCU且以電池供電，故這些新的M2M協定必須考量在有限的硬體能力及功耗等條件下，使得M2M Traffic在進行網路傳輸時，有較高的Throughput、低延遲、低電力耗損，甚至提供不同的 QoS (Quality of Service)。

目前各家提供連結物聯網裝置的雲端資料服務平台，包含
AWS IoT(https://aws.amazon.com/tw/iot/)、Evrythng(https://evrythng.com/)、Xively(https://www.xively.com/)、ThingSpeak(https://thingspeak.com/)、ThingWorx(https://www.thingworx.com/)等及晶片廠提供的雲平台，如聯發科的MCS(https://mcs.mediatek.com/)、ARM mbed Device Connector(https://connector.mbed.com/)等，都廣泛支援CoAP及MQTT協定，故將選擇此兩種協定來進行說明與比較。

M2M協定介紹

CoAP

CoAP(The Constrained Application Protocol) 目前已是IETF標準(RFC 7252) ，提出一個類似HTTP/TCP設計，但是屬於輕量版的HTTP/UDP，使得其有利於感測節點進行網路傳輸。

CoAP主要特點:

1. CoAP同HTTP一樣具有REST(Representational State Transfer)設計風格，也支援GET/PUT/POST/DELETE及URIs的請求方式。
2. CoAP是主從(Client/Server)架構，感測節點多半為CoAP Client 上傳(PUT)感測資訊或節點狀態到CoAP Server。CoAP Server使用UDP (port: 5683)，對於資料是否要重傳或傳送順序(Reordering) 全交由上層應用層來決定，對於資源有限的MCU則不需要TCP協定實作。感測節點多半為CoAP Client, 因為感測節點通常是On-Off (Duty-cycled)工作模式, 只有醒來時才工作以節省能耗。若反過感測節點為CoAP Server, 則由Cloud 作為CoAP Client , 執行Get 以存取節點狀態資訊。
3. CoAP採用二進位整數格式且封包標頭4 個byte而非HTTP使用字串格式(ASCII code)，所以封包傳送時的額外負擔小且不必像HTTP一樣得進行耗時的字串解析處理。
4. CoAP QoS : CoAP訊息分為Confirmable或Non-Confirmable。Confirmable要求接收端須回送ACK，若沒有收到ACK則重送一次。若送的是Non-Confirmable訊息，則送出端不在乎接收端是否收到。
5. CoAP使用DTLS (Datagram Transport Layer Security) 進行加密
6. 通知機制: CoAP擴展了HTTP GET，加入了一個observe flag，用來主動回報所observe到的狀態，而不必像原本HTTP需要一直polling,如此可節省不必要的通訊。實作上MCU 為CoAP Client, 一旦狀態改變時主動發出CoAP GET 即可將資料丟到server
7. NAT Issue: 若感測節點在NAT後方，則必須一開始先送出請求到外部，使路由器可以接受來自外面CoAP Client的請求， 例如請求資源清單。

MQTT

MQTT（Message Queuing Telemetry Transport）是IBM開發的一個即時通訊協定，2010年IBM釋出免授權版本(v3.1)。MQTT是機器對機器（M2M）物聯網的連接協定。它被設計成一個非常輕量級的發布/訂閱消息傳輸。對於感測節點擁有很少的記憶體和或網路頻寬很小的情況下， MQTT非常適合。MQTT已經是ISO（ISO / IEC 20922：2016）和OASIS標準。另外，Facebook Messenger即是採用MQTT協定。

MQTT的主要特點:

1. 訊息傳遞為Publish/Subscribe的方式，以提供一對多的訊息分派

1. Client B及Client C先向Broker訂閱(Subscribe)一個Temperature主題, 而Client A向Broker發佈(Publish)在該主題Temperature發佈訊息(22.5)，則Client B及Client C 都會收到此訊息。 

1. 使用TCP port 1883作為通訊傳輸層 
2.  Header固定長度為2 byte，因此可以減少封包傳送時的額外負載，並減少所需的網路頻寬 
3. Publish 和Broker 中間發生異常斷線時，會使用最後遺囑(Last Will )的機制，通知所有Subscriber 
4. 3種傳送服務QoS (0,1,2)：

   Publisher <----> Broker <----> Subscriber

                  <QoS>           <QoS>

兩段所設定的QoS ，其作用的結果取兩段最小QoS值

1.)   QoS=0   "At most once": 最多送一次 ,但可能沒收到，"Fire and Forget"

•      Publisher不會Re-Publish訊息給Broker。因為使用底層是TCP, 所以Broker 一定會收到，而剩下的問題為 Broker 和Subscriber 兩者間的傳輸問題。

•      這適合應用在環境感測， Subscriber並不會在意Publisher是否會再重送，因為下一次的資料取樣很快就會再丟出來

2.)   QoS=1   "At least once": 可能收到一次以上 >=1

•      如果時間內Publisher沒收到來自Broker的PUBACK, Publisher會Re-Publish訊息。如此Broker很有能收到2次以的重覆的訊息，因此Subscriber 就可能跟著會重覆收到相同訊息。

3.)   QoS=2   "Exactly once":只會收到一次=1。

•     為避免像QoS 1,  Subscriber有可能收到重覆的訊息。因此Publisher 會有Message ID, 使得Broker 能夠判別這是Publisher 所送的重覆資料, 才不致於送給Subscriber重複的資料。

•      這適合用在計費系統，系統只要有重複收到資料、或是資料遺失狀況發生，就會造成系統錯誤。

CoAP vs MQTT 比較

1. 都是公開標準且都是基於IP層的協定 
2. 封包標頭小且採用binary格式 
3. CoAP屬於一對一通訊，MQTT則是多對多 
4. 若考慮感測節點在NAT後方的情況，由於MQTT的架構因為有中央broker的角色，MQTT Client本來就持續連接在broker，所以可以直接推播訊息，沒有NAT問題。然而CoAP Client要取得位於NAT後方的感測節點資料，則須要在路由器上設上設定virtual server或port forwarding之類才能使用，不然就必須另外有第三方伺服器存在，讓感測節點先連出才行

Raspberry Pico W 使用 MQTT publish

References:

 

Observing Resources in the Constrained Application Protocol (CoAP)