# MQTT over QUIC

MQTT 协议广泛用于物联网和车联网的消息服务应用开发。MQTT 基于传输协议工作，传输协议提供可靠、有序和无丢失字节流的双向通信。这种可靠的传输协议可以确保消息的准确传递和按发送顺序接收。在传统物联网场景中，MQTT 协议主要基于 TCP 的协议进行消息的传输，如原始 TCP、TCP/TLS（用于安全性）和 WebSocket（用于 Web 浏览器适配）。然而，在某些场景下，复杂的网络条件可能会限制 MQTT 在这些场景下的应用，例如高延迟、高丢包率和信号弱或不稳定的网络。

为了克服 MQTT 基于 TCP 传输的局限性，EMQX 5.0 开创性地引入了一种新协议 MQTT over QUIC，使 MQTT 客户端和 EMQX 可以通过 Quick UDP Internet Connections (QUIC) 进行通信。该协议提供了与现有 MQTT 协议相同的功能，但具有 QUIC 的额外优势。

本章介绍了采用 MQTT over QUIC 协议的原因以及如何在 EMQX 中实现 MQTT over QUIC。在MQTT over QUIC 的特性和优势中，介绍了客户端与 EMQX 在 QUIC 流上的两种交互模式以及每种模式的特性和优势。在快速开始中，演示了如何使用客户端 SDK 和工具在 EMQX 中启用 MQTT over QUIC。

提示

目前 MQTT over QUIC 仍然是实验性功能，EMQX 正在以 OASIS 成员身份推动其标准化落地。

# 了解 QUIC

QUIC 最初由 Google 开发，后来被互联网工程任务组（IETF）采纳为全球标准。它是一种新的传输协议，提供更快的连接建立速度。通过使用更高效的算法，可以更快地将数据传输速率提高到稳定状态，从而改善了拥塞控制。此外，QUIC 使用基于流的多路复用架构，可以独立传输数据流，有助于避免队首阻塞，并可以提高在高丢包或延迟情况下的性能。

QUIC 也是 HTTP/3 的唯一传输协议，HTTP/3 是最新版本的 HTTP 协议。相比 TCP，QUIC 作为下一代互联网协议 HTTP/3 的底层传输协议，能在减少连接开销与消息延迟的同时，显著提升整体吞吐量和移动连接的稳定性，因此，比 TCP 协议更适合解决复杂网络环境下的通信问题。

# MQTT over QUIC 的应用场景

MQTT over QUIC 特别适用于对实时性和稳定性要求较高的业务。例如，在山区、矿场和隧道中行驶的网联车辆，当进入信号死角或被动切换基站时，连接会中断。MQTT over QUIC 借助 QUIC 的优势，能够克服传统 MQTT over TCP 在以下场景中的缺点：

TCP/TLS 的连接建立缓慢。客户端和服务器之间的初始握手需要多次往返以建立连接。往返时间（RTT）对于连接建立速度至关重要。较长的 RTT 可导致延迟增加和连接建立缓慢。
由于拥塞窗口使用慢启动，导致流量缓慢增加。
队头阻塞。当一个数据包丢失时，整个传输会被阻塞，直到它被恢复，这会显著增加延迟。
无法感知上层协议。TCP 对所有数据传输都做同样的处理，无法区分使用同一网络连接的不同类型数据或业务。

# QUIC vs TCP/TLS 测试对比

在与 TCP/TLS 测试的对比中，MQTT over QUIC 的表现如下：

网络时延较高时，QUIC 能够更快的建立连接、完成订阅。
断开连接后，重新发起连接并恢复重连 QUIC 所需的时延更低。
大规模连接/重连时，对于服务器 CPU 和内存使用 QUIC 均优于 TLS。
网络切换时（客户端源 IP 地址/端口变化），TCP/TLS 下客户端重连响应非常慢并出现消息传输中断现象，而 QUIC 的处理则更加平顺，消息发送无任何影响。
在弱网丢包、包传输乱序环境下，TLS 出现因网络环境差而导致的消息拥塞与丢失，而 QUIC 服务端接收的数据稍微有所抖动，但不丢失消息。

# 应用限制

目前 MQTT over QUIC 在 EMQX 的应用还有以下局限：

目前不支持保留会话状态。这意味着如果客户端需要重新连接，则必须通过数据流重新订阅先前订阅的主题。
如果数据流被任一方意外关闭，则不会保留 QoS 1 和 QoS 2 消息状态。

# 未来规划

目前 MQTT over QUIC 已经具备投入生产能力，已有用户开始进行深度测试集成并获得了良好反馈，如需体验，请参考快速开始。

然而，EMQX 还没有利用 QUIC 提供的所有功能，如多流复用、流优先级、流量控制和不可靠的数据报文，这些功能将在以后的版本中得到解决，并希望能成为 OASIS 标准。

此外，需要进一步解决如何保留消息状态和在不重新连接的情况下恢复订阅这两种在应用限制中提到的局限。