對物聯網的開發者，我們遇到了一個有趣的挑戰：因爲物聯網應用越來越多，也有越來越多技術選擇——基礎通信協議方面就有兩個專門的競爭協議：消息隊列遙測傳輸( MQTT )，和受約束的應用協議(CoAP)。
它們都設計爲輕量級，並仔細使用稀缺的網路資源。兩者都在正確的環境中使用，但問題是，由於物聯網的快速發展，一般人們不知道這些協議是什麼？或何時使用？
這些不是每個人使用的標準Web協議。首先，我們來看看這些協議是什麼？
什麼是MQTT?
MQTT的全名爲Message Queuing Telemetry Transport，爲IBM和Eurotech共同制定出來的protocol，在MQTT的官網可以看到一開始它對MQTT的介紹：
MQTT is a machine-to-machine (M2M)/"Internet of Things" connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport.
簡單來說，它是爲了物聯網而設計的protocol，並且它是透過publish/subscribe的方式來做訊息傳送。由於是爲了物聯網而設計的協定，因此它所需要的網路頻寬是很低的，而所需要的硬體資源也是低的。
對於外行人來說，MQTT很像Twitter。這是一個「發佈和訂閱」協議。
Publish/Subscribe：
在看MQTT之前，最好要先知道Publish/Subscribe的訊息傳送機制爲何，這樣之後在看其協定時，纔會更快上手。
Publish/Subscribe有三種主要的組成元件，分別爲Publisher、Subscriber以及Topic。
Publisher爲訊息的來源，它會將訊息發送給Topic，而Subscriber向Topic註冊，表示他們想要接收此Topic的訊息；因此當有某個Publisher對Topic發送訊息時，只要是有對此Topic註冊的Subscriber，都會收到此則訊息。
它們的關係如下圖：
MQTT特性
瞭解了Publish/Subscribe的機制之後，讓我們來看看MQTT有哪些特性：
1. Publish/Subscribe的訊息傳送模式，來提供一對多的訊息分配。
2. 使用TCP/IP來提供基本的網路連結。
3. 三種訊息傳送服務的qualities：
- "At most once"，最多一次，訊息遺失或是重複發送的狀況可能會發生；這種quality適合應用在環境感測，不在意資料是否會遺失，因爲下一次的資料取樣很快就會被published出來。
- "At least once"，至少一次，這種quality保證訊息會送達，只是可能會發生重複發送訊息的狀況。
- "Exactly once"，確定一次，確認訊息只會送到一次。這種quality適合用在計費系統，系統只要有重複收到資料、或是資料遺失狀況發生，就會造成系統錯誤。
4. 由於他的header固定長度爲2byte，因此可以減少封包傳送時的額外負載，並減少所需的網路頻寬。
5. 當異常斷線發生時，會使用最後遺囑(Last Will and Testament)的機制，通知各個感興趣的client。
MQTT現況：
MQTT現階段，並不是一個標準化的Protocol，還在持續改進中，目前爲MQTT V3.1。不過IBM已於2013年，已經將它交給OASIS進行標準化了，並且一直以來IBM對此協定採開放、免授權費的方式，讓它能夠被散佈，因此相信不久的將來，會成爲一個主流的Protocol。
而目前支援MQTT的Client API，有Eclipse Phno Project有對MQTT client支援，其支援C、Java、Javascript、C++等等的語言，可說是支援度很高的Project。而目前已經在應用MQTT的，最知名的應該就是Facebook Message App了吧，可以參考此篇文章。
小結：
上面提到的，低頻寬、低硬體需求的特性，訊息傳遞爲Publish/Subscribe的方式，正好可以用來實現Push Notification的機制，並且能達到手持裝置省電的需求，接下來會先從其Protocol開始瞭解，並用Client Api跑些範例來應用此Protocol。
什麼是CoAP？
CoAP(The Constrained Application Protocol) 目前已是IETF標準(RFC 7252) ，提出一個類似HTTP/TCP設計，但是屬於輕量版的HTTP/UDP，使得其有利於感測節點進行網路傳輸。
CoAP主要特點：
1. CoAP是主從(Client/Server)架構，感測節點多半爲CoAP Server提供資源，由CoAP Client請求讀取/控制資源狀態。CoAP使用UDP (port: 5683)，對於資料是否要重傳或傳送順序(Reordering)全交由上層應用層來決定，對於資源有限的MCU則不需要有完整TCP/IP協定實作
2. 而CoAP同HTTP一樣具有REST(Representational State Transfer)設計風格，也支援GET/PUT/POST/DELETE及URIs的請求方式。
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)
DTLS加密過程使用預設密鑰PSK或橢圓曲線Diffie-Hellman ECDH算法，這種方法同樣也是DLMS中使用的加密方法。存在的問題是，在使用ECDH時會受到DDoS的攻擊，使用大的證書使得服務端癱瘓。
6. 通知機制: CoAP擴展了HTTP GET，加入了一個observe flag，使得CoAP Server能主動回傳，CoAP Client所observe的資源狀態。
7. NAT Issue:若感測節點在NAT後方，則必須一開始先送出請求到外部，使路由器可以接受來自外面CoAP Client的請求，例如請求資源清單。
CoAP vs MQTT 比較
1. 都是公開標準且都是基於IP層的協定
2. 封包標頭小且採用binary格式
3. CoAP屬於一對一通訊，MQTT則是多對多
4. 若考慮感測節點在NAT後方的情況，由於MQTT的架構因爲有中央broker的角色，MQTT Client本來就持續連接在broker，所以可以直接推播訊息，沒有NAT問題。
物聯網應用層通訊協定標準比較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協定，故將選擇此兩種協定來進行說明與比較。
然而CoAP Client要取得位於NAT後方的感測節點資料，則須要在路由器上，設上設定virtual server，或port forwarding之類才能使用，不然就必須另外有第三方伺服器存在，讓感測節點先連出才行。
我們看到了本文的第一個圖，CoAP的網絡層只有IPv6，所以如果沒有物聯網網關Gateway，一個IPv4的雲端是無法直接訪問CoAP終端的，只能由終端發起去訪問固定的雲端服務器。在大量的物聯網終端情況下，保持連接或者會話是不現實的。因此物聯網Gateway就非常重要了，需要服務器通過Gateway集成專有的尋址應用，反向建立與在NAT後的終端連接。
你什麼時候使用它們？
你可能都在問的問題是，「如果他們很相似，我應該在什麼時候使用哪一個；又在什麼時候，使用哪一個？」
