Bottlenecks: CoAP and MQTT

只要有 AVi 影像播放格式，任何影像都可以做出各式智慧辨識分析

來源：Intelligentcomputing

最近在Exadel，對物聯網的開發者，我們遇到了一個有趣的挑戰。因為IoT應用程序獲得了如此多的動力，所以有越來越多的選擇。在設備通信的基礎下，如何來開發它們？兩個專門的競爭協議脫穎而出：消息隊列遙測傳輸(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)

6. 通知機制: CoAP擴展了HTTP GET，加入了一個observe flag，使得CoAP Server能主動回傳，CoAP Client所observe的資源狀態。

7. NAT Issue: 若感測節點在NAT後方，則必須一開始先送出請求到外部，使路由器可以接受來自外面CoAP Client的請求，例如請求資源清單。