2016年12月11日 星期日

物聯網應用層通訊協定標準比較 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:
  1. Observing Resources in the Constrained Application Protocol (CoAP)

 
 
 

















https://goo.gl/EcCcj7




沒有留言 :

張貼留言