前言

MQTT v5.0 中的 Clean Start 與 Session Expiry Interval，對於有 MQTT v3.1.1 版本協議使用經驗的朋友，一定不會感覺陌生，因為這兩個欄位與之前版本中的 Clean Session 非常相似。但它們在實際使用中遠比 Clean Session 靈活，下文將詳細介紹這幾個欄位的作用與區別。

MQTT v3.1.1 版本的 Clean Session

如果 Clean Session 設定為 0，服務端必須使用與 Client ID 關聯的會話來恢復與客戶端的通訊。如果不存在這樣的會話，伺服器必須建立一個新會話。客戶端和伺服器在斷開連線後必須儲存會話的狀態。

如果 Clean Session 設定為 1，客戶端和伺服器必須丟棄任何先前的會話並建立一個新的會話。該會話的生命週期將和網路連線保持一致，其會話狀態一定不能被之後的任何會話重用。

可以看出，MQTT 期望通過這種持久會話的機制避免客戶端掉線重連後訊息的丟失，並且免去客戶端連線後重復的訂閱流程。這一功能在頻寬小，網路不穩定的物聯網場景中非常實用。但 Clean Session 同時限定了客戶端和伺服器在連線和斷開連線兩種狀態下的行為，這並不是一個很好的實現。此外，在某些場景下會話並不需要伺服器永久保留自己的狀態時，這個機制將會導致伺服器資源的浪費。

MQTT v5.0 版本的 Clean Start 與 Session Expiry Interval

如果 CONNECT 報文中的 Clean Start 為 1，客戶端和服務端必須丟棄任何已存在的會話，並開始一個新的會話。

如果 CONNECT 報文中的 Clean Start 為 0 ，並且存在一個關聯此客戶端識別符號的會話，服務端必須基於此會話的狀態恢復與客戶端的通訊。如果不存在任何關聯此客戶端識別符號的會話，服務端必須建立一個新的會話。

Session Expiry Interval 以秒為單位，如果 Session Expiry Interval 設定為 0 或者未指定，會話將在網路連線關閉時結束。

如果 Session Expiry Interval 為 0xFFFFFFFF ，則會話永不過期。

如果網路連線關閉時（DISCONNECT 報文中的 Session Expiry Interval 可以覆蓋 CONNECT 報文中的設定） Session Expiry Interval 大於0，則客戶端與服務端必須儲存會話狀態 。

現在，Clean Start 替代了原先的 Clean Session，但不再用於指示是否儲存會話狀態，僅用於指示服務端在連線時應該嘗試恢復之前的會話還是直接建立全新的會話。會話狀態在服務端的儲存時長則完全交給 Session Expiry Interval 決定。

前面還提到，MQTT v5.0 支援客戶端在斷開連線時重新指定 Seesion Expiry Interval。這樣我們可以非常容易地滿足類似客戶端網路連線異常斷開時會話狀態被伺服器保留，客戶端正常下線時會話則隨著連線關閉而結束的場景，只需要客戶端在斷開連線時將 Session Expiry Interval 設定為 0 即可。即便是一個已經永不過期的會話，客戶端也可以在下一次連線中通過設定 Clean Start 為 1 來 "反悔"。

Clean Start 與 Session Expiry Interval 不僅解決了 Clean Session 的遺留問題，同時也擴充套件了客戶端的使用場景，使 MQTT 協議在受限的網路環境下更加實用。

---

更多資訊請訪問我們的官網 emqx.io，或關注我們的開源專案 github.com/emqx/emqx ，詳細文件請訪問

相關推薦