Bottlenecks: CoAP and MQTT
 |
|
|
來源：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的請求， 例如請求資源清單。
 |
| Clemens Vasters |
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之類才能使用，不然就必須另外有第三方伺服器存在，讓感測節點先連出才行
你什麼時候使用它們？
你可能都在問的問題是，「如果他們很相似，我應該在什麼時候使用哪一個；又在什麼時候，使用哪一個？」
沒有留言:
張貼留言