上一講聊到 MQTT 因為 Pub-Sub Pattern 以及輕量化等等的特性，頗為適合作為 IoT 設備的資料傳輸協定。

今天我們來聊聊一個問題，既然是 IoT 的設備，該如保持連線的存在？資料的傳輸要怎麼保證可靠性呢，又或者有需要保證嗎？

Keep Alive

一般來說，要監測某個裝置是否還活著，我們會請被監測的裝置每隔時間都說點話，就有點像是「心跳」似的，假如每隔個一段時間都有聽到心跳聲，那麼這個裝置就還活著，這種機制就稱作 Heartbeat（心跳機制）。

在 MQTT 中也同樣有這種行為，而心多久跳一次，就取決於 MQTT Client 在怎麼樣的網路環境和使用需求。如果在頻寬的成本比較高的情況下，例如衛星通訊，就會等久一點再送；若是需要比較 Realtime 的服務，就送的頻繁一點。

這個長短的數值，就是 MQTT 的 Keep Alive 所設定的。例如某個 Client 設定連線的 Keep Alive 為 30 秒，那麼 30 秒內此 Client 都沒有送封包的話，就會送一個 PINGREQ 封包給 Broker，告訴他我還活著，Broker 也會送回一個 PINGREQ 封包給 Client 來彼此確認。

*MQTT Keep Alive 機制

而通常 Broker 在建立連線之後，會等 1.5 倍的 Keep Alive 時間，期間都沒收到 Client 來的任何訊息，才判斷這台裝置失聯。

QoS

再來，聊到 MQTT，也不能不提 QoS（Quality of Service），中文翻譯為服務品質。

在不同的使用場景中，資料有時可以掉，有時則掉了資料會很嚴重。例如一些傳感器的資料，像是智能溫度計，由於溫度變化不會太劇烈，偶爾掉了沒什麼關係；但若是和涉及金流的交易有關，這些資料可就掉不得了。

因此，針對不一樣的情況，MQTT 也採用了 QoS 理念，將資料傳輸的服務品質分成以下三種

1. QoS 0 - At most once（最多一次傳送）

2. QoS 1 - At least once（至少一次傳送）

3. QoS 2 - Exactly once（正好一次傳送）

可靠性從 0 是最低到 2 是最高，相對的成本也是從 0 是最低到 2 是最高。

那麼這些最多、至少、正好的傳送，到底意味著什麼？

QoS 0 最多一次傳送，代表將訊息送出就不理了，也不等待對方的回覆，也因此可想而知此封包很可能會掉，因為掉了與否我們其實並不知道。

QoS 1 至少一次傳送，訊息送出後會等待回覆，所以在一定時間之內如果沒有得到回覆，我們就可以知道封包掉了，再次傳送，這也是「至少」一次傳送的意思。然而 QoS 1 會有的問題是收到重複的訊息，因為當我們遲遲等不到回覆於是再送訊息後，可能才發現對方的回覆因為網路壅塞等原因晚了點到，但如此一來對方就收到了重複的訊息了。

*QoS 1 重複收到訊息

QoS 2 正好一次傳送，就是為了解決 QoS 1 收到重複訊息，所以採用了 4-Way Handshake 的手法。

簡單來說，就是 Client 會第一次「傳送」，然後再來「確認」（實際的傳送和確認有專門的名詞 PUBLISH 及 PUBREC，這邊僅簡化說明），在 Broker 收到「確認」之前，都不會當作這次的傳輸成功。

*QoS 2 避免重複收到訊息

所以當 Broker 回覆延遲導致 Client 再傳送第二次時，由於 Broker 已經有收到了，就會把這個第二次的封包給丟掉。

如此就能確認這次的訊息傳輸只會讓對方收到一次訊息，但缺點就是傳輸的成本較前兩個 Level 高了不少。

參考資料

1. Wiki - MQTT

2. Cedalo - MQTT Keep Alive Timer to Keep Your Devices Connected

3. Wiki - 服務品質