建立一個 MQTT 連線是使用 MQTT 協議進行通訊的第一步。為了保證高可擴充套件性，在建立連線時 MQTT 協議提供了豐富的連線引數，以方便開發者能建立滿足不同業務需求的物聯網應用。本文將詳細講解 MQTT 中各個連線引數的作用，幫助開發者邁出使用 MQTT 的第一步。

## MQTT 連線的基本概念

MQTT 連線由客戶端向伺服器端發起。任何執行了 MQTT 客戶端庫的程式或裝置都是一個 [MQTT 客戶端](http://mqttx.app/zh)，而 [MQTT 伺服器](https://www.emqx.com/zh/mqtt/public-mqtt5-broker)則負責接收客戶端發起的連線，並將客戶端傳送的訊息轉發到另外一些符合條件的客戶端。

客戶端與伺服器建立網路連線後，需要先傳送一個 `CONNECT` 資料包給伺服器。伺服器收到 `CONNECT` 包後會回覆一個 `CONNACK` 給客戶端，客戶端收到 `CONNACK` 包後表示 MQTT 連線建立成功。如果客戶端在超時時間內未收到伺服器的 `CONNACK` 資料包，就會主動關閉連線。

大多數場景下，MQTT 透過 TCP/IP 協議進行網路傳輸，但是 MQTT 同時也支援透過 WebSocket 或者 UDP 進行網路傳輸。

### MQTT over TCP

TCP/IP 應用廣泛，是一種面向連線的、可靠的、基於位元組流的傳輸層通訊協議。它透過 ACK 確認和重傳機制，能夠保證傳送的所有位元組在接收時是完全一樣的，並且位元組順序也是正確的。

MQTT 通常基於 TCP 進行網路通訊，它繼承了 TCP 的很多優點，能穩定執行在低頻寬、高延時、及資源受限的環境下。

### MQTT over WebSocket

近年來隨著 Web 前端的快速發展，瀏覽器新特性層出不窮，越來越多的應用可以在瀏覽器端透過瀏覽器渲染引擎實現，Web 應用的即時通訊方式 WebSocket 也因此得到了廣泛的應用。

很多物聯網應用需要以 Web 的方式被使用，比如很多裝置監控系統需要使用瀏覽器實時顯示裝置資料。但是瀏覽器是基於 HTTP 協議傳輸資料的，也就無法使用 MQTT over TCP。

MQTT 協議在建立之初便考慮到了 Web 應用的重要性，它支援透過 MQTT over WebSocket 的方式進行 MQTT 通訊。關於如何使用 MQTT over WebSocket，讀者可檢視部落格[使用 WebSocket 連線 MQTT 伺服器](https://www.emqx.com/zh/blog/connect-to-mqtt-broker-with-websocket)。

## MQTT 連線引數的使用

### 連線地址

MQTT 的連線地址通常包含 ：伺服器 IP 或者域名、伺服器埠、連線協議。

**基於 TCP 的 MQTT 連線**

`mqtt` 是普通的 TCP 連線，埠一般為 1883。

`mqtts` 是基於 TLS/SSL 的安全連線，埠一般為 8883。

比如 `mqtt://broker.emqx.io:1883` 是一個基於普通 TCP 的 MQTT 連線地址。

**基於 WebSocket 的連線**

`ws` 是普通的 WebSocket 連線，埠一般為 8083。

`wss` 是基於 WebSocket 的安全連線，埠一般為 8084。

當使用 WebSocket 連線時，連線地址還需要包含 Path，[EMQX](http://www.emqx.io/) 預設配置的 Path 是 `/mqtt`。比如 `ws://broker.emqx.io:8083/mqtt` 是一個基於 WebSocket 的 MQTT 連線地址。

### 客戶端 ID（Client ID）

MQTT 伺服器使用 Client ID 識別客戶端，連線到伺服器的每個客戶端都必須要有唯一的 Client ID。Client ID 的長度通常為 1 至 23 個位元組的 UTF-8 字串。

**如果客戶端使用一個重複的 Client ID 連線至伺服器，將會把已使用該 Client ID 連線成功的客戶端踢下線。**

### 使用者名稱與密碼（Username & Password）

MQTT 協議可以透過使用者名稱和密碼來進行相關的認證和授權，但是如果此資訊未加密，則使用者名稱和密碼將以明文方式傳輸。如果設定了使用者名稱與密碼認證，那麼最好要使用 `mqtts` 或 `wss` 協議。

大多數 MQTT 伺服器預設為匿名認證，匿名認證時使用者名稱與密碼設定為空字串即可。

### 連線超時（Connect Timeout）

連線超時時長，收到伺服器連線確認前的等待時間，等待時間內未收到連線確認則為連線失敗。

### 保活週期（Keep Alive）

保活週期，是一個以秒為單位的時間間隔。客戶端在無報文傳送時，將按 Keep Alive 設定的值定時向服務端傳送心跳報文，確保連線不被服務端斷開。

在連線建立成功後，如果伺服器沒有在 Keep Alive 的 1.5 倍時間內收到來自客戶端的任何包，則會認為和客戶端之間的連線出現了問題，此時伺服器便會斷開和客戶端的連線。

更多細節可檢視部落格：[MQTT 協議中的 Keep Alive 機制](https://www.emqx.com/zh/blog/mqtt-keep-alive)。

### 清除會話（Clean Session）

為 `false` 時表示建立一個[持久會話](https://www.emqx.com/zh/blog/mqtt-session)，在客戶端斷開連線時，會話仍然保持並儲存離線訊息，直到會話超時登出。為 `true` 時表示建立一個新的臨時會話，在客戶端斷開時，會話自動銷燬。

持久會話避免了客戶端掉線重連後訊息的丟失，並且免去了客戶端連線後重復的訂閱開銷。這一功能在頻寬小，網路不穩定的物聯網場景中非常實用。

伺服器為持久會話儲存的訊息數量取決於伺服器的配置，比如 EMQ 提供的[免費的公共 MQTT 伺服器](https://www.emqx.com/zh/mqtt/public-mqtt5-broker)設定的離線訊息儲存時間為 5 分鐘，最大訊息數為 1000 條，且不儲存 QoS 0 訊息。

> **注意：** 持久會話恢復的前提是客戶端使用固定的 Client ID 再次連線，如果 Client ID 是動態的，那麼連線成功後將會建立一個新的持久會話。

### 遺囑訊息（Last Will）

遺囑訊息是 MQTT 為那些可能出現**意外斷線**的裝置提供的將**遺囑**優雅地傳送給其他客戶端的能力。設定了遺囑訊息訊息的 MQTT 客戶端異常下線時，MQTT 伺服器會發布該客戶端設定的遺囑訊息。

> **意外斷線包括**：因網路故障，連線被服務端關閉；裝置意外掉電；裝置嘗試進行不被允許的操作而被服務端關閉連線等。

遺囑訊息可以看作是一個簡化版的 MQTT 訊息，它也包含 Topic、Payload、QoS、Retain 等資訊。

- 當裝置意外斷線時，遺囑訊息將被髮送至遺囑 Topic；
- 遺囑 Payload 是待傳送的訊息內容；
- 遺囑 QoS 與普通 MQTT 訊息的 QoS 一致；
- 遺囑 Retain 為 `true` 時表明遺囑訊息是保留訊息。MQTT 伺服器會為每個主題儲存最新一條保留訊息，以方便訊息釋出後才上線的客戶端在訂閱主題時仍可以接收到該訊息。

更多關於遺囑訊息的介紹可檢視部落格：[MQTT 遺囑訊息（Will Message）的使用](https://www.emqx.com/zh/blog/use-of-mqtt-will-message)。

### 協議版本

使用較多的 MQTT 協議版本有 MQTT v3.1、MQTT v3.1.1 及 MQTT v5.0。目前，MQTT 5.0 已成為絕大多數物聯網企業的首選協議，我們建議初次接觸 MQTT 的開發者直接使用該版本。

感興趣的讀者可檢視 EMQ 提供的 [MQTT 5.0](https://www.emqx.com/zh/mqtt/mqtt5) 系列文章，瞭解 MQTT 5.0 相關特性的使用。

### MQTT 5.0 新增連線引數

**Clean Start & Session Expiry Interval**

MQTT 5.0 中將 Clean Session 拆分成了 Clean Start 與 Session Expiry Interval。

Clean Start 用於指定連線時是建立一個全新的會話還是嘗試複用一個已存在的會話。為 `true` 時表示必須丟棄任何已存在的會話，並建立一個全新的會話；為 `false` 時表示必須使用與 Client ID 關聯的會話來恢復與客戶端的通訊（除非會話不存在）。

Session Expiry Interval 用於指定網路連線斷開後會話的過期時間。設定為 0 或未設定，表示斷開連線時會話即到期；設定為大於 0 的數值，則表示會話在網路連線關閉後會保持多少秒；設定為 0xFFFFFFFF 表示會話永遠不會過期。

更多細節可檢視部落格：[Clean Start 與 Session Expiry Interval](https://www.emqx.com/zh/blog/mqtt5-new-feature-clean-start-and-session-expiry-interval)。

**連線屬性（Connect Properties）**

MQTT 5.0 還新引入了連線屬性的概念，進一步增強了協議的可擴充套件性。更多細節可檢視部落格：[MQTT 5.0 連線屬性](https://www.emqx.com/zh/blog/mqtt5-connect-properties)。

## 如何建立一個安全的 MQTT 連線？

雖然 MQTT 協議提供了使用者名稱、密碼、Client ID 等認證機制，但是這對於物聯網安全來說還遠遠不夠。基於傳統的 TCP 通訊使用明文傳輸，資訊的安全性很難得到保證，資料也會存在被**竊聽**、**篡改**、**偽造**、**冒充**的風險。

SSL/TLS 的出現很好的解決了通訊中的風險問題，其以非對稱加密技術為主幹，混合了不同模式的加密方式，既保證了通訊中訊息都以密文傳輸，避免了被竊聽的風險，同時也透過簽名防止了訊息被篡改。

不同 MQTT 伺服器啟用 SSL/TLS 的步驟都各有不同，EMQX 內建了對 TLS/SSL 的支援，包括支援單/雙向認證、X.509 證書、負載均衡 SSL 等多種安全認證。

單向認證是一種僅透過驗證伺服器證書來建立安全通訊的方式，它能保證通訊是加密的，但是不能驗證客戶端的真偽，通常需要與使用者名稱、密碼、Client ID 等認證機制結合。讀者可參考部落格[EMQX MQTT 伺服器啟用 SSL/TLS 安全連線](https://www.emqx.com/zh/blog/emqx-server-ssl-tls-secure-connection-configuration-guide)來建立一個安全的單向認證 MQTT 連線。

雙向認證是指在進行通訊認證時要求服務端和客戶端都提供證書，雙方都需要進行身份認證，以確保通訊中涉及的雙方都是受信任的。 雙方彼此共享其公共證書，然後基於該證書執行驗證、確認。一些對安全性要求較高的應用場景，就需要開啟雙向 SSL/TLS 認證。讀者檢視部落格[EMQX 啟用雙向 SSL/TLS 安全連線](https://www.emqx.com/zh/blog/enable-two-way-ssl-for-emqx)瞭解如何建立一個安全的雙向認證 MQTT 連線。

> **注意：** 如果在瀏覽器端使用 MQTT over WebSocket 進行安全連線的話，目前還暫不支援雙向認證通訊。

## 結語

至此，相信讀者已對 MQTT 連線的建立及各個連線引數的作用有了深刻的理解。接下來，可訪問 EMQ 提供的 [MQTT 入門與進階](https://www.emqx.com/zh/mqtt)系列文章學習 MQTT 主題及萬用字元、保留訊息、遺囑訊息等相關概念，探索 MQTT 的更多高階應用，開啟 MQTT 應用及服務開發。

>版權宣告： 本文為 EMQ 原創，轉載請註明出處。
>
>原文連結：[https://www.emqx.com/zh/blog/how-to-set-parameters-when-establishing-an-mqtt-connection](https://www.emqx.com/zh/blog/how-to-set-parameters-when-establishing-an-mqtt-connection)

建立 MQTT 連線時如何設定引數？

相關文章