簡談MQTT和CoAP對比

MQTT是IBM開發的一個即時通訊協定，基于TCP的，号稱是可以支援所有的平台。

CoAP是運作于UDP之上，采用資料報方式，并且非常小巧，最小隻有4個位元組。

可以說兩者都是營運物聯網大趨勢和為了适應M2M而生的，相比于其他的通信協定也有較大的優勢。

原文連結：https://www.zhihu.com/question/34767514/answer/87340564 CoAP和MQTT的協定除了考慮裝置的TCP/UDP堆棧實作能力和對裝置的壓力之外，更加注重的考慮點是：

1. 伺服器架構和開發成本；
2. 應用本身資料流向，流量，頻率，持久的需求；
3. 長連接配接還是短連接配接；
4. 資料分享API的需求；

    MQTT，基于TCP的，其實就是IBM把伺服器間異步通訊用的消息隊列Message Queue（MQ）中間件前置到IOT接入而已。天生适合多對多（伺服器對伺服器，裝置對伺服器，裝置對APP），異步，背景應用，以及即時通訊（多用戶端對等）場景。不過就是約定了封包頭而已，用Redis PubSub/MQ也可以建構。

如果不需要存儲資料，最簡單的IOT架構：Device+MQTT+APP

如果需要資料持久存儲，IOT架構可以是：Device+MQTT+Web+DB（NoSQL/NewSQL/BigData/Lambda）+APP

    CoAP，基于UDP接口，參考HTTP上的REST API，适合資料采集這種多（裝置）對一（伺服器）場景，系統架構類似于傳統Web。但是由于CoAP UDP不是面對連接配接的，是以方向控制需要高層建構協定。CoAP支援多點傳播，也可以實作一對多場景，但是好像和MQTT不一樣。應該是區域網路内的多點傳播？了解的兄弟請提點一下。

但總的網站架構迎來類似于傳統Web：CoAP+Web+DB+APP。

是以，不足之處就是資料必須流經DB轉給第三方。當然，如果Web内部有MQ，可以通過REST API暴露給第三方。變成：

CoAP + Web + DB + APP

     + Redis/MQ + REST + APP

    CoAP大體上是采用資料報方式，可以基于UDP，短消息，以及6LowPAN等傳輸層。而且大體上在WSN内部可以使用。不過由于CoAP也可以用于網關與雲之間通訊，是以現在出現了CoAP over TCP的草案。不過，總覺得該草案受到CoAP RFC7252的限制太大。

    觀察最近的BAT動向，都把MQTT作為物聯網前置接入套件單列出來作為标準雲服務提供。阿裡雲物聯網套件，百度開放雲物聯網服務IOT，騰訊QQ物聯平台，中移動OneNet開放雲，Amazon IOT服務......更别提環信，野狗之類原來做IM雲服務的，都将MQTT作為IM/IOT共享的接入服務了。 另外，選擇采用長連接配接（TCP）的MQTT，還是無連接配接（UDP）的CoAP，與應用資料屬性有關。對于是維持大量非活動長連接配接的開銷大，還是大量UDP包對于伺服器的開銷大，我一直沒有得到結論。

    MQTT是非常流行的裝置的接入協定，包括IBM、亞馬遜、微軟的IoT托管服務都有支援，而CoAP在這方面幾乎沒有露面的機會。感覺以下幾點是MQTT優于CoAP的主要原因：

• MQTT基于TCP，在做反控裝置的時候比UDP更可靠，比如CoAP走3G、4G的時候甚至需要實作CoAP over TCP，否則反控很不穩定甚至無法聯通。
• MQTT異步Pub/Sub實作，好比發個微信，無需等待對方确認便可以繼續，而不像CoAP那樣必須等待對方應答才能傳回的同步模式。
• MQTT為物聯網提供了許多體貼的設計，比如QoS，比如“遺言”的設計。