再論 - 微型物聯網 (IoT) 架構 - MQTT

IoT 最重要的莫過於網路通訊了，機器與機器 ( M2M ) 間需要透過 HTTP 來傳輸資料，了解比較深入的人，可能還知道 CoAP 或 MQTT 等。

MQTT 是一種物聯網的通訊協定，最初是由 IBM 和 Eurotech 主導開發，並已在 2014 年正式成為了 OASIS 國際標準，開發的目的是為了在窄寬帶以及低耗能條件下，傳送與接收處理訊息，採用 Publish／Subscribe 的方式，透過 Broker 做訊息溝通。

MQTT 的標頭 ( header )，僅佔 2 個 bytes ，縮小了傳輸量。整體來說，資料封包也比要傳送同等訊息的 HTTP 來的小，這種特性讓 MQTT 非常適合運用在現行的 IoT 架構中。

Publisher、Subscriber、Broker 又是什麼？

Publish / Subscribe 為一種訊息規範的模式 ：

發布者：Publisher，不會將訊息直接傳送給訂閱者：Subscriber，而是將訊息分為不同的主題：Topic，訂閱者只接收已訂閱的主題。

MQTT 即是採用 Publish／Subscribe 模式，其中 Publisher 和 Subscriber 都是用戶端(Client)，Broker是伺服器端(Server) 負責轉發 Topic。

Publish / Subscribe 示意圖

Subscriber 告知 Broker 想要訂閱的 Topic，每當 Publisher 發布訊息時，Broker 會依照 Topic，傳送給訂閱的 Subscriber。

由於 Publisher／Subscriber 之間有 Broker 當作中繼站，所以兩邊並不需要知道彼此的 IP。

IBM Watson IoT Platform from https://www.ibm.com/developerworks/

Topic 主題格式

MQTT 的 Topic 是字串 ( String )，並支援階層式命名如下範例：

outside/temperature/temp_Device01
inside/humidity/humid_Device07
Taiwan/Taipei/Datong/ChengdeRoad/Traffic
...

階層數沒有固定，但是要特別注意的是，英文的大小寫是有區別的，且長度不可超過 65536 個字元。

品質 ( Qos ) 設定

MQTT 定義了三個層級的品質 ( Qos：0、1、2 )，分別適用於不同的情況：

Qos 0：at most once 最多傳一次
在「Qos：0」的設定下，訊息送出後就不管了，由於 MQTT 是屬於網路架構中的應用層，它並不會知道底層的網路斷線與否，所以 Broker 是有可能沒收到訊息的。如果你的目標裝置接的是有線網路，或者，遺漏幾筆資料也不會對結果造成太大影響的情況下 ( 樣本數夠多 )，可以使用這個設定。

Qos 0：示意圖

Qos 1：at least once 至少傳一次
Broker 從 Publisher 收到「Qos：1」的訊息之後，會回應一個 PUBACK，以確認有收到訊息。如果連線中斷或其他狀況導致 Publisher 沒有收到 PUBACK，Publisher 就會重新發送，保證訊息至少傳送至 Broker 一次。

Qos 1：示意圖

然而，假設 Broker 有收到訊息，但在回應給 Publisher 時，中間發生斷線或故障。Publisher 會認為 Broker 沒有收到而重送，結果導致 Broker 重複收到同一份訊息。

QoS1：Broker 有收到訊息 但 Publisher 沒收到 PUBACK

Qos 2：exactly once 確實傳送一次
「Qos：2」設定比「Qos：1」更嚴謹了一些。它將發送訊息分成了幾段：

Broker 收到「Qos：2」的訊息之後，將回覆 PUBREC 給 Publisher，表示收到了即將發布的訊息，並暫存訊息的封包識別碼，以防止因斷線或逾時，需重新傳送而造成的重複。

Publisher 如果收到了 PUBREC，會再傳送 PUBREL 給 Broker，告訴 Broker 可以釋放訊息了。此時 Broker 會把訊息傳送給 Subscriber，然後回應 PUBCOMP 告訴 Publisher 已經發送完畢，並刪除暫存訊息。

Qos 2：示意圖

相較於「Qos：1」，「Qos：2」會佔用比較多的網路和傳送時間，但能確實傳送一次訊息。

最後，究竟為什麼要使用 MQTT？

IoT picture from https://www.freepik.com/

在 IoT 的世界裡，末端的裝置動輒數百上千，一來一往的數據傳輸量很是驚人，流量那麼大的情況下，網路使用費計算起來也是相當可觀，並不是每個地方都可以享有吃到飽的服務，因此，封包傳輸量較小、能一對多的 MQTT 就成了主流之一。

除此之外，品質 Qos 的設計也可以讓不同的裝置甚至不同的架構需求，使用合適的品質設定來傳送資料，以符合最佳的應用情境。