iOS x IoT ( 2 ) — MQTT 簡介
本系列文旨在實驗一個用iOS App接收資料的微型物聯網(IoT)架構。
IoT 最重要的莫過於網路通訊了,機器與機器 ( M2M ) 間需要透過 HTTP 來傳輸資料,了解比較深入的人,可能還知道 CoAP 或 MQTT 等。
在使用 MQTT 前,我們來大致了解一下,它究竟是什麼吧!
📕 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
。
Subscriber
告知 Broker
想要訂閱的 Topic
,每當 Publisher
發布訊息時,Broker
會依照 Topic
,傳送給訂閱的 Subscriber
。
由於 Publisher/Subscriber
之間有 Broker
當作中繼站,所以兩邊並不需要知道彼此的 IP。
📘 Topic 主題格式
MQTT 的 Topic
是字串 ( String ),並支援階層式命名如下範例:
outside/temperature/temp_Device01inside/humidity/humid_Device07Taiwan/Taipei/Datong/ChengdeRoad/Traffic...
階層數沒有固定,但是要特別注意的是,英文的大小寫是有區別的,且長度不可超過 65536 個字元。
📙 品質 ( Qos ) 設定
MQTT 定義了三個層級的品質 ( Qos:0、1、2 ),適用於不同的情況:
📨 Qos 0:at most once 最多傳一次
在「Qos:0」的設定下,訊息送出後就不管了,由於 MQTT 是屬於網路架構中的應用層,它並不會知道底層的網路斷線與否,所以 Broker
是有可能沒收到訊息的。如果你的目標裝置接的是有線網路,或者,遺漏幾筆資料也不會對結果造成太大影響的情況下 ( 樣本數夠多 ),可以使用這個設定。
📨 Qos 1:at least once 至少傳一次
如果需要確實地接收每一段訊息,可以使用「Qos:1」。
Broker
從 Publisher
收到「Qos:1」的訊息之後,會回應一個 PUBACK
,以確認有收到訊息。如果連線中斷或其他狀況導致 Publisher
沒有收到 PUBACK
,Publisher
就會重新發送,保證訊息至少傳送至 Broker
一次。
然而,假設 Broker
有收到訊息,但在回應給 Publisher
時,中間發生斷線或故障。Publisher
會認為 Broker
沒有收到而重送,結果導致 Broker
重複收到同一份訊息。
如果你需要接收每一則訊息,而且用戶端程式可以自行篩選 ( 例如:篩選重複資料的程式 ),那可以使用「Qos:1」。
📨 Qos 2:exactly once 確實傳送一次
「Qos:2」設定比「Qos:1」更嚴謹了一些。它將發送訊息分成了幾段:
Broker
收到「Qos:2」的訊息之後,將回覆 PUBREC
給 Publisher
,表示收到了即將發布的訊息,並暫存訊息的封包識別碼,以防止因斷線或逾時,需重新傳送而造成的重複。
Publisher
如果收到了 PUBREC
,會再傳送 PUBREL
給 Broker
,告訴 Broker
可以釋放訊息了。此時 Broker
會把訊息傳送給 Subscriber
,然後回應 PUBCOMP
告訴 Publisher
已經發送完畢,並刪除暫存訊息。
相較於「Qos:1」,「Qos:2」會佔用比較多的網路和傳送時間,但能確實傳送一次訊息。
📝 最後,究竟為什麼要使用 MQTT?
在 IoT 的世界裡,末端的裝置動輒數百上千,一來一往的數據傳輸量很是驚人,流量那麼大的情況下,網路使用費計算起來也是相當可觀,並不是每個地方都可以享有吃到飽的服務,因此,封包傳輸量較小、能一對多的 MQTT 就成了主流之一。
除此之外,品質 Qos 的設計也可以讓不同的裝置甚至不同的架構需求,使用合適的品質設定來傳送資料,以符合最佳的應用情境。
📚 參考資料
本文為閱讀文章與書籍後,濃縮彙整,並盡量用自己的語言寫出、重繪示意圖,以下是參考的重點文章:
講了一大堆,還不如自己動手做來得容易理解,下一篇就要帶大家在 Google Cloud Platform 架一個雲端 Server ,用來運行 MQTT Broker。
如果您覺得這篇文章還不錯或有幫助請幫我按個一兩下[拍手👏]給我點鼓勵吧!另外,您對文章內容有任何問題或發現錯誤,請不吝指正,強烈歡迎留言討論💬!