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。
如果您覺得這篇文章還不錯或有幫助請幫我按個一兩下[拍手👏]給我點鼓勵吧!另外，您對文章內容有任何問題或發現錯誤，請不吝指正，強烈歡迎留言討論💬！
