车联网移动场景 MQTT 通信优化实践

清楚了问题的根源，接下来我们将借助 MQTT 协议的特性来解决上述问题，构建更稳定的车联网通信架构，避免因为连接重连和中断造成的数据丢失。

虽然 TCP/IP 部分无法改变，但 MQTT 协议提供了许多供配置的参数和消息 QoS 等级供我们配置。针对一些关键数据，比如车机端重要的状态变化和用户发出的请求，我们需要保证消息到达，这就需要我们使用 QoS 1/2。

首先，我们要解决 IP 更新导致 TCP 重连后客户端无法识别的问题。我们可以通过 MQTT 会话保持特性来解决。

*关于 MQTT 会话状态可参考文章：

https://www.emqx.com/zh/blog/mqtt-session

MQTT 要求客户端与服务端在会话有效期内存储一系列与客户端标识（ClientID）相关联的状态，即会话状态。我们将从客户端向服务端发起 MQTT 连接请求开始，到连接中断直到会话过期为止的消息收发序列称为会话。

会话可能仅持续一个网络连接，也可能跨越多个网络连接存在。所以在这种网络切换的过程中，车机端每次连接使用相同的客户端标识，就可以让 MQTT Broker 在TCP连接重建的情况下，仍然可以识别到新连接是之前的客户端，从而将缓存的 QoS 消息重发，并应用之前的连接状态。

客户端使用会话保持的方式以 Java 为例：

public MQTTPublisher(String address, String clientId, boolean cleanSession, int qos) throws MqttException {  this.clientId = clientId;  this.qos = qos;  this.client = new MqttClient(address, clientId, persistence);  MqttConnectOptions connOpts = new MqttConnectOptions();  connOpts.setCleanSession(cleanSession);  //置为fasle即为保留会话  this.client.connect();}

设置完会话保留状态，我们就可以使用 QoS 消息来保证消息的到达。

*关于 QoS 的详解可参考文章：

https://www.emqx.com/zh/blog/introduction-to-mqtt-qos

我们建议对于重要数据在车机端使用 QoS 1 进行发送，并且使用带有 QoS 重传功能和内置 QoS 消息窗口（队列）的 MQTT SDK。例如 NanoSDK（https://www.emqx.com/zh/mqtt-client-sdk），其具有异步确认、内置 QoS 消息队列、自动重发、高吞吐高消费能力等特点。

Broker QoS MsgQueue

QoS 消息在 Broker 端有内存持久化功能，除了客户端有内置的消息队列，Broker 也有一个 QoS 消息队列。

如上文所述，车联网场景经常发生的基站切换导致连接重置，反映到 MQTT 连接就体现为 QoS 消息积压现象。客户端和服务端都会有未确认的消息积压在队列里。所以我们要根据实际情况设置消息队列的长度。

以 EMQX 为例，消息队列设置：

打开 emqx.conf

mqtt {  ## @doc Maximum QoS 2 packets (Client -> Broker) awaiting PUBREL.  max_awaiting_rel  =  100
  ## @doc The QoS 2 messages (Client -> Broker) will be dropped if awaiting PUBREL timeout.  await_rel_timeout  =  300s
  ## @doc Maximum queue length. Enqueued messages when persistent client disconnected, or inflight window is full.  max_mqueue_len  =  1000}

max_awaiting_rel 为接受 QoS 2 的消息队列长度。QoS 1 此项无限制。

await_rel_timeout 为 QoS 2 消息超时时间。

max_mqueue_len 为下发 QoS 1/2 的队列缓存长度

默认的 QoS 2 消息队列长度仅为 100，此处建议根据给客户端发布消息的频率和消费能力适当增加，一般考虑为 publisher 平均每秒产生消息的数量 *2 。此队列提供消费端一定的缓冲时间来完成重连后积压消息的消费。

由于 TCP 采用四元组来判断识别连接的独特性，而 UDP 并没有同样的要求。2022 年 6 月 11 日，IETF 正式颁布了 HTTP/3 RFC 技术标准文档后，基于 UDP 的 QUIC 正式成为了传输层标准之一。而基于 QUIC 的 MQTT 方案也有望成为下一个行业标准。

借助 QUIC 协议的地址迁移、流式多路复用、分路流控、更低的连接建立延迟，我们有望彻底解决车联网移动场景下的连接问题。

0-RTT 示意图

QUIC 能够侦测到地址改变，自动采用 0-RTT 的方式重建连接，从而使得客户端和服务端对于 IP 地址的变动无感知，这样就彻底避免了上文所说的一系列问题。