> **引言：首個將 QUIC 引入 MQTT 的開創性產品**
>
> 不久前，開源的大規模分散式物聯網 MQTT 訊息伺服器 EMQX 釋出了[5.0版本](https://www.emqx.com/zh/blog/emqx-v-5-0-released)。EMQX 5.0 不僅是全球首個實現單叢集支援 1 億連線的分散式 MQTT 訊息伺服器，還開創性地引入了 QUIC 支援。
>
> QUIC 是下一代網際網路協議 HTTP/3 的底層傳輸協議，與 TCP/TLS 協議相比，它**在減少連線開銷與訊息延遲的同時，為現代移動網際網路提供了有效靈活的傳輸層。**
>
> 基於 QUIC 這些極適用於物聯網訊息傳輸場景的優勢，EMQX 5.0 引入 QUIC 支援（MQTT over QUIC）並設計了獨特的訊息傳輸機制和管理方式。

本文將透過對 MQTT over QUIC 的詳細解析，為大家展現這一領先技術實現對於物聯網場景的優勢與價值，幫助大家更有效地藉助 EMQX 5.0 對 QUIC 的支援能力，在各類 MQTT 應用場景中進行更加高效、低成本的物聯網資料傳輸。

## 什麼是 QUIC

[QUIC](https://datatracker.ietf.org/doc/html/rfc9000) 是一種建立在 UDP 之上通用的傳輸層網路協議，最初由 Google 提出，作為 TCP+TLS 的替代方案，旨在改善使用者體驗。

與現有的 TLS over TCP 方案相比，QUIC 有很多優勢：

- 快速建立低延遲連線（1 RTT 或者 0 RTT）
- 端到端加密，握手透過 TLS 1.3 進行身份驗證
- 避免隊頭阻塞的多路複用
- 改進的擁塞控制，可插拔的擁塞控制策略
- 多路徑支援，連線平滑遷移
- 無狀態負載均衡
- 現有網路無需改造升級即可支援

因其高效的傳輸效率和多路併發的能力，QUIC 已經成為下一代網際網路協議 HTTP/3 的底層傳輸協議。

> **HTTP/3 協議介紹**
>
> 2018 年 10 月，IETF 的 HTTP 和 QUIC 工作組聯合決定將 QUIC 上的 HTTP 對映稱為 [HTTP/3](https://en.wikipedia.org/wiki/HTTP/3)，以提前使其成為全球標準。2022 年 6 月 6 日，IETF 將 HTTP/3 標準化為[RFC ](https://en.wikipedia.org/wiki/RFC_(identifier))[9114](https://datatracker.ietf.org/doc/html/rfc9114)。
>
> HTTP/3 的目標是透過解決 HTTP/2 的傳輸相關問題，在所有形式的裝置上提供快速、可靠和安全的 Web 連線。HTTP/3 使用與 HTTP/2 版本類似的語義，包括相同的請求方法、狀態程式碼和訊息欄位，兩者根本區別在於，HTTP/2 底層使用的是 TCP/TLS 協議，而 HTTP/3 使用的是 QUIC 協議。
>
> 根據 [W3Techs 統計](https://w3techs.com/technologies/details/ce-http3)，網際網路至少 40% 的流量是基於 QUIC 的，前 1000 萬個網站中的 25% 已經支援 HTTP/3 協議，包括 Google，Youtube，Facebook 等頂流站點。

## QUIC 在 MQTT 通訊場景中的應用前景

MQTT 是基於 TCP 的物聯網通訊協議，緊湊的報文結構能夠在嚴重受限的硬體裝置和低頻寬、高延遲的網路上實現穩定傳輸；心跳機制、遺囑訊息、QoS 質量等級等諸多特效能夠應對各種物聯網場景。

儘管如此，由於底層 TCP 傳輸協議限制，某些複雜網路環境下 MQTT 協議存在固有的弊端：

- 網路切換導致經常性連線中斷
- 斷網後重新建立連線困難：斷網後作業系統釋放資源較慢，且應用層無法及時感知斷開狀態，重連時 Server/Client 開銷較大
- 弱網環境下資料傳輸受限於擁塞、丟包偵測和重傳機制

例如車聯網使用者通常會面對類似的問題：車輛可能會執行在山區、礦場、隧道等地方，當進入到訊號死角或被動切換基站時會導致連線中斷，頻繁連線中斷與較慢的連線恢復速度會導致使用者體驗變差。在一些對資料傳輸實時性和穩定性要求較高的業務，如 L4 級別的無人駕駛中，客戶需要花費大量的成本來緩解這一問題。

在上述這類場景中，QUIC 低連線開銷和多路徑支援的特性就顯示出了其優勢。經過更深入的探索，我們認為 MQTT Over QUIC 可以非常好地解決這一困境 —— 基於 QUIC 0 RTT/1 RTT 重連/新建能力，能夠在弱網與不固定的網路通路中有效提升使用者體驗。

## EMQX 5.0 的 MQTT over QUIC 實現

EMQX 目前的實現將傳輸層換成 QUIC Stream，由客戶端發起連線和建立 Stream，EMQX 和客戶端在一個雙向 Stream 上實現互動。

考慮到複雜的網路環境，如果客戶端因某種原因未能透過 QUIC 握手，建議客戶端自動退回到傳統 TCP 上，避免系統無法建立跟伺服器的通訊。

[![MQTT over QUIC](http://img.blog.itpub.net/blog/2022/07/29/01b6f523ae39ca00.png?x-oss-process=style/bb "MQTT over QUIC")](https://www.emqx.com/zh/blog/mqtt-over-quic "MQTT over QUIC")

目前 EMQX 5.0 中已經實現了以下特性：

- **更高階的擁塞控制：**有效降低資料丟包率，在測試中在網路波動的情況下仍能持續穩定傳輸資料
- **運維友好：**減少大規模重連導致的開銷（時間開銷、客戶端/伺服器效能開銷），減少不必要的應用層狀態遷移而引發的系統過載（0 RTT）
- **更靈活的架構創新：**比如 Direct server return (DSR，伺服器直接返回模式)，只有入口/請求流量經過 LB，出口和響應流量繞過 LB 直接回到客戶端，減少 LB 的瓶頸
- **減少握手延遲 （1 RTT）**
- **多路徑支援，連線平滑遷移：**從 4G 切換到 WIFI, 或者因為 NAT Rebinding 導致五元組發生變化，QUIC 依然可以在新的五元組上繼續進行連線狀態，尤其適用於網路經常性變化的移動裝置
- **更敏捷的開發部署：**協議棧的實現在 userspace，能夠開發快速迭代
- **端到端加密：**未加密的包頭帶有極少資訊， 減少傳輸路徑中中間節點的影響，帶來更好的安全性和更可控的使用者體驗

同時還有以下更多能力有待進一步探索：

- **不同主題的流：**對於獨立主題，每個主題可以有獨立的 Streams 以消除其他主題長阻塞帶來的影響，比如接收端長阻塞或流量控制，亦可以實現優先順序主題功能。
- **不同 QoS 的流：**比如在「流量控制」中，QoS 0 傳輸應該讓位給高 QoS 傳輸。
- **將控制訊息分成不同的流：**MQTT 控制訊息可以單向或雙向傳送。如客⼾端可以透過「控制流」非同步傳送 UNSUBSCRIBE 請求，以要求伺服器端停⽌傳送不再感興趣的資料。
- **更細粒度的收發端協同流量控制：**面對每一個流進行流控且對整個連線進行流控，實現更細粒度的流量控制。

## QUIC vs TCP/TLS 測試對比

我們在實驗室環境下，基於 EMQX 5.0 版本對不同的場景下 QUIC 與 TCP/TLS 的效能表現進行了模擬測試。

**測試環境**

- 測試平臺：EMQX 5.0 單節點
- 伺服器規格：AWS EC2 M4.2xlarge (8 核 32GB)
- 作業系統：Ubuntu 20.04
- 客戶端數：5000
- loadgen 並行數：8
- latency 取值：P95

### 客戶端連線時延

測試在不同網路時延下握手、建立連線、完成訂閱的時延。相較於 TLS，在網路時延較高時 QUIC 有一定的優勢。

[![1ms 延遲](http://img.blog.itpub.net/blog/2022/07/29/aa292cfdf2173da8.png?x-oss-process=style/bb "1ms 延遲")](https://www.emqx.com/zh/blog/mqtt-over-quic "1ms 延遲")

[![10ms 延遲](http://img.blog.itpub.net/blog/2022/07/29/69466e67e4b39387.png?x-oss-process=style/bb "10ms 延遲")](https://www.emqx.com/zh/blog/mqtt-over-quic "10ms 延遲")

[![30ms 延遲](http://img.blog.itpub.net/blog/2022/07/29/e5e1187975f731a0.png?x-oss-process=style/bb "30ms 延遲")](https://www.emqx.com/zh/blog/mqtt-over-quic "30ms 延遲")

### 0 RTT 重連時延

測試斷開連線後，重新發起連線並恢復重連所需的時延。

由於 QUIC 在 0 RTT 場景下可以在第一個包上帶上應用層的資料包， 應用層相較於 TCP 一個來回握手響應更快。

QUIC 協議支援 0 RTT 握手，當客戶端和服務端完成**初次**握手後，服務端可向客戶端傳送 NST 包。 客戶端在連線斷開後可用 NST 跳過 1 RTT 中的很多步驟快速重建連線。

0 RTT 的好處是可有效降低客戶端和服務端握手開銷和提高效能（握手延遲），EMQX 預設給客戶端傳送 NST 包， 有效時性為 2 小時。

0 RTT 也支援 early data，相比於 1 RTT 需要握手完成後才可進行應用層傳輸，0 RTT 的 early data 可以在第一個包上帶上應用層資料，用於快速恢復或重啟應用層業務。但由於 0 RTT 的 early data 不能防範重放攻擊， 因此 QUIC 建議不要在 0 RTT 上攜帶會改變應用狀態的資料。

> EMQX 預設不支援 early data，此測試只用於對比驗證。

測試結果表明如果 MQTT 層協議設計得當，在完成首次握手後，QUIC 表現優於純 TCP。

[![MQTT over QUIC](http://img.blog.itpub.net/blog/2022/07/29/982af9e994994700.png?x-oss-process=style/bb "MQTT over QUIC")](https://www.emqx.com/zh/blog/mqtt-over-quic "MQTT over QUIC")

[![MQTT over QUIC](http://img.blog.itpub.net/blog/2022/07/29/b6d5d1992f8f9dc0.png?x-oss-process=style/bb "MQTT over QUIC")](https://www.emqx.com/zh/blog/mqtt-over-quic "MQTT over QUIC")

### 連線/重連時伺服器資源使用

測試新連線與斷線重新連線不同過程中伺服器 CPU 和記憶體的佔用情況，以對比 TLS，QUIC 1 RTT 和 0 RTT 握手時資源開銷。測試結果表明 QUIC 的 CPU 和記憶體使用均優於 TLS，但是重建連線耗費頻寬比 TLS 多。

[![](http://img.blog.itpub.net/blog/2022/07/29/a85b6f54fbfcc294.jpeg?x-oss-process=style/bb)](https://www.emqx.com/zh/blog/mqtt-over-quic)

> 注 1：主要為 MQTT 清除會話，踢開舊連線的額外開銷
>
> 注 2:：主要為傳輸路徑 MTU 驗證導致的大量 QUIC 初始化握手資料包

[![MQTT over QUIC 測試](http://img.blog.itpub.net/blog/2022/07/29/d1d260d9491e0fe0.png?x-oss-process=style/bb "MQTT over QUIC 測試")](https://www.emqx.com/zh/blog/mqtt-over-quic "MQTT over QUIC 測試")

### 客戶端地址遷移

此測試模擬大規模客戶端地址遷移時業務層訊息傳輸的變化。

傳統 TCP/TLS 客戶端必須在應用層感知到斷線才進行重連，此過程響應非常慢並伴有許多不必要的重傳。 QUIC 的處理更加平順，在傳輸層做到了保持連線不要求重連且讓應用層無感（如果有需要應用層也可以訂閱地址的變化）。

QUIC 在客戶端源 IP 地址/埠變化情況下，訊息傳送無任何影響。而 TLS 連線在變化後出現訊息傳送中斷現象，即使客戶端可以透過重連機制重新連線到 EMQX 上，但中間時間視窗將無法進行任何操作。

這一結果表明 QUIC 非常適合用在網路經常需要切換的環境。

[![MQTT over QUIC 測試 ](http://img.blog.itpub.net/blog/2022/07/29/cc0b71e6ea2d86bb.png?x-oss-process=style/bb "MQTT over QUIC 測試 ")](https://www.emqx.com/zh/blog/mqtt-over-quic "MQTT over QUIC 測試 ")

### 網路丟包測試

測試在弱網條件下資料傳輸情況。我們分別做了 3 次測試：EMQX terminated TCP/TLS，QUIC 以及 nginx terminated TCP/TLS。

測試場景：EMQX 以 20K/s 的速率釋出 QoS 1 訊息，在此過程中注入網路錯誤：20% 亂序（傳送端與接受端包的順序不一致），10% 丟包，QUIC 測試中還額外增加每 30 秒一次的網路切換干擾。

在此情況下 QUIC 服務端接收的資料稍微有所抖動，但不丟失訊息；而 TLS 出現因網路環境差而導致的擁塞、丟包。此項結果表明 QUIC 在弱網環境下可以提供可靠的傳輸。

[![MQTT over QUIC 測試](http://img.blog.itpub.net/blog/2022/07/29/4ba61712b5bf8c38.png?x-oss-process=style/bb "MQTT over QUIC 測試")](https://www.emqx.com/zh/blog/mqtt-over-quic "MQTT over QUIC 測試")

[![MQTT over QUIC 測試](http://img.blog.itpub.net/blog/2022/07/29/be8b101debf4c579.png?x-oss-process=style/bb "MQTT over QUIC 測試")](https://www.emqx.com/zh/blog/mqtt-over-quic "MQTT over QUIC 測試")

> 黃圈標記中我們去除了網路錯誤，可以看到 TLS 的收發恢復正常收發，包數量一致沒有堆積，而 QUIC 只是從輕微抖動變得更平滑。

## 更便捷的使用：MQTT over QUIC SDK

[NanoSDK](https://github.com/nanomq/NanoSDK/) 0.6.0 基於 MsQuic 專案率先實現了第一個 C 語言的 MQTT over QUIC SDK。

NanoSDK 透過為 NNG 的傳輸層增加 QUIC 支援，使 MQTT、nanomsg 等協議能夠從 TCP 轉為 UDP，從而提供更好的物聯網連線體驗。其內部將 QUIC Stream 和 MQTT 連線對映繫結，並內建實現了 0 RTT 快速握手重連功能。

> 訊息示例程式碼請參考 [NanoSDK QUIC Demo](https://github.com/nanomq/NanoSDK/blob/main/demo/quic/client.c)。

我們近期也將基於 NanoSDK 進行封裝並陸續推出 Python、Go 等語言的 SDK，方便更多使用者儘快體驗到 MQTT over QUIC 的優勢能力。

同時，相關的 SDK 將支援 QUIC fallback，當 QUIC 不可用時，連線層將自動切換為 TCP/TLS 1.2，確保各類網路環境下業務都能正常執行。

[![NanoSDK 與 EMQX 之間透過 QUIC 進行訊息收發](http://img.blog.itpub.net/blog/2022/07/29/493bdbb59ebc8348.png?x-oss-process=style/bb "NanoSDK 與 EMQX 之間透過 QUIC 進行訊息收發")](https://www.emqx.com/zh/blog/mqtt-over-quic "NanoSDK 與 EMQX 之間透過 QUIC 進行訊息收發")

## 未來的 EMQX QUIC

[![未來的 EMQX QUIC](http://img.blog.itpub.net/blog/2022/07/29/655f88eec2ebb4a6.png?x-oss-process=style/bb "未來的 EMQX QUIC")](https://www.emqx.com/zh/blog/mqtt-over-quic "未來的 EMQX QUIC")

結合 QUIC 特性和物聯網場景，我們為 MQTT over QUIC 規劃了諸多特性，如透過區分控制通道實現主題優先順序設定，實現非可靠實時流傳輸以應對高頻資料傳輸場景，以及靈活的主題和資料通道（Stream）對映以降低主題之間的干擾。未來的版本中將陸續呈現。

EMQ 也正在積極推進 MQTT over QUIC 的標準化落地。繼 2018 年成為 OASIS MQTT 技術委員會中目前為止唯一擁有投票權的中國公司並參與 5.0 協議標準制定後，EMQ 目前也已提交了 MQTT over QUIC 的相關草案。相信在不久的將來，MQTT 的底層協議將同時支援 TCP 與 QUIC，使整個物聯網行業從中獲益。

## 結語

可以看到，QUIC 非常適用於傳統 TCP/IP 網路 UDP MTU 大小能夠保證的弱網環境或者網路經常切換的環境。對於裝置時刻處在移動中的物聯網場景（如車聯網、移動採集等），或是需要頻繁斷連不適合做長連線的場景（如裝置需要定期休眠）來說，QUIC 都擁有巨大的潛力，是更為適合的底層協議選擇，這也是 EMQX 5.0 引入 QUIC 支援的原因。

MQTT over QUIC 在 EMQX 5.0 中的率先實現，讓 EMQ 再次走在全球物聯網訊息伺服器領域的前沿。EMQ 將始終堅持以不斷的技術革新驅動產品持續的迭代升級，期待透過領先的產品為物聯網領域帶來基礎設施保障和業務創新動力。

## 本系列中的其它文章

- [EMQX 5.0 產品解讀 01 | Mria + RLOG 新架構下的 EMQX 5.0 如何實現 1 億 MQTT 連線](https://www.emqx.com/zh/blog/how-emqx-5-0-achieves-100-million-mqtt-connections)

>版權宣告： 本文為 EMQ 原創，轉載請註明出處。
>
>原文連結：[https://www.emqx.com/zh/blog/mqtt-over-quic](https://www.emqx.com/zh/blog/mqtt-over-quic)

MQTT over QUIC：下一代物聯網標準協議為訊息傳輸場景注入新動力

相關文章