共计 4986 个字符，预计需要花费 13 分钟才能阅读完成。
随着智能化浪潮席卷寰球，现在的车辆早已不再是单纯的交通工具，而是一个具备自主推理能力、能和云端交互进行车路协同的挪动智能节点。
很多的新型利用场景岂但计算量微小，而且对通信链路有十分强的低时延、低能耗和高牢靠要求。传统的通信协议如 HTTP 等并不能同时满足以上要求。而作为目前物联网畛域事实上的标准协议，MQTT 提供了 Pub/Sub 的音讯模式，具备精简低劣的协定设计，能够满足低延时和低功耗的需要，实用于资源无限的车机系统。但不同于智能家居、机器人这类设施固定且网络环境稳固的场景，车联网中疾速挪动、场景切换快、网络状况复杂多变等个性，对 MQTT 协定在车端和服务端的利用提出了更高的要求。
本文将深入分析车联网挪动场景下 MQTT 音讯传输面临的问题及产生起因，并利用 MQTT 协定个性对其加以解决和优化，帮忙用户构建更稳固的车联网通信架构。
当你高速驾驶时，当你穿梭隧道时，网络理论产生了什么？
置信大家应用 4G 手机时都有过相似体验：进入地下室时信号强度忽然变弱，尽管网络没有显示中断，然而理论应用体验就和断网一样；亦或是在一个很大区域的 WiFi 网络范畴内挪动，在不同的 AP（无线接入点）覆盖范围之间切换时也会有相似状况。这就是一个典型的挪动设施导致的网络迁徙问题。而在车联网中，因为车辆是高速移动，特地是在高速公路基站笼罩稠密或穿过隧道的状况，都会导致这种问题更加频繁地呈现，从而引起车机端 MQTT 连贯中断重连。
首先咱们来看看车联网场景面对的网络现状：依据 2020 年底的数据，我国基站总数为 931 万个，其中 3G/4G 基站总数为 575 万个。但这些基站大多集中在城市区域，而在农村，高速公路甚至是隧道内的信号笼罩就远没有城市那么全面。目前，针对高速公路和国道省道等区域的网络覆盖计划根本分为公网延长笼罩和专网笼罩计划。
- 公网延长笼罩：将路线区域与周边区域统一规划，应用惯例基站蜂窝组网形式进行笼罩。因为往往是间接将大网的网络资源延长到高速公路上，所以也叫大网延长笼罩。
- 专网笼罩：针对非凡的点笼罩和线笼罩场景的特殊要求进行优化，配置非凡的频率、信令和性能进行异频组网。因为建设老本高，往往更多用于高速铁路沿线笼罩。专网与公网之间齐全隔离，只有在特定出入口例如高速公路收费站能力进入或来到专网。
能够发现，咱们应用的网络是依附通信从业者建设的一个个蜂窝基站提供的。而车辆在疾速挪动的过程中，地位更新频繁，常常会在多个基站覆盖范围之间切换。这导致其网络信令负荷大，基站切换频繁，最终将导致车载 4G 模块的网络链路中断。尽管专网笼罩能够通过采纳 BBU+RRU 小区合并的技术来缩小网际切换和同频烦扰，进而解决这一问题，但因为专网计划建设老本昂扬，所以理论场景里，车联网更多面对的还是第一种公网笼罩计划。
于是，咱们就会发现车机端的 4G 连贯呈现如上图所示的一直高低线的状况。
多普勒效应和隧道笼罩
除了基站笼罩带来的网络问题外，当车辆行驶速度很快的时候，也会因为多普勒效应造成提早减少和丢包。车速越大，频偏越大，提早越大，丢包的概率也越大。
MQTT 连贯产生了什么？
咱们晓得了车辆的网络状况，那么这些因素是如何影响车机端 MQTT 连贯的呢？
家喻户晓，MQTT 连贯也是基于 TCP/IP 协定栈。看到这里大家可能会有疑难：TCP/IP 协定栈里有连贯保活机制，MQTT 协定里也有 Keep Alive 参数供连贯重建复原，哪怕基站切换导致了短暂的通信中断，然而等到进入下一个基站的范畴，通信链路也很快就复原了，那么为什么还会导致车辆设施 MQTT 连贯的频繁离线呢？要答复这个疑难，咱们须要联合 TCP/IP 和挪动网络入网过程一起来剖析。
TCP/IP 协定诞生之初，次要针对的是稳固的有线网络，作为一个牢靠传输协定，其外部有数据 ACK，可能进行数据重传和连贯复用。然而，这一切都是基于 IP 地址不变的前提下，而在车联网场景里，基站切换是会导致车机端的 IP 地址变更的。每次车机 4G 模块进入新的基站覆盖范围时都会从新发动一次入网附着申请。
其中的协定细节这里不进行具体解释。因为目前咱们依然在应用 IPV4 规范，所以车机 4G 模块在从新入网过程中会向新搜查到的 eNB 基站发送一个要害的信令 PDN（Packet Domain Network）来申请为本人调配一个新的 IP 地址，而这个地址往往都是 NAT 地址，这也是 4G 终端开机即在线的技术的一环。此时还随同着网络品质检测、APN 匹配等流程来判断终端应用的网络类型和推送网络路由以保障连通性。如果此时的边缘 eNB 基站没有针对车机端的 4G 卡和 PDN 信令进行对应优化，是无奈获知其原先应用的 IP 地址的，那么这时候 IP 地址就产生了扭转，须要进行 NAT 地址重绑定。而对于 MQTT 和 TCP/IP 这一类长链接协定来说，IP 地址变动后，TCP 服务端无奈辨认呈现在的客户端是否还是原先的客户端，所以 TCP 连贯是必须要从新建设的，从而导致 MQTT 连贯也必须重建。
以上是一个失常的疾速挪动的车辆在蜂窝基站间失常切换会产生的过程。而理论状况中网络更加简单，公网笼罩计划因为共享基站和接入网资源，若边缘基站负载过高还会产生 eNB 基站对 PDN 申请不响应等状况。网络侧对承载申请不响应，更不用说伪基站。此外地理环境和多普勒效应引起的多径效应和信号衰减都会导致延时减少和连贯中断。
如何改善挪动网络下 MQTT 连贯稳定性？
分明了问题的本源，接下来咱们将借助 MQTT 协定的个性来解决上述问题，构建更稳固的车联网通信架构，防止因为连贯重连和中断造成的数据失落。
尽管 TCP/IP 局部无奈扭转，但 MQTT 协定提供了许多供配置的参数和音讯 QoS 等级供咱们配置。针对一些要害数据，比方车机端重要的状态变动和用户收回的申请，咱们须要保障音讯达到，这就须要咱们应用 QoS 1/2。
Clean Session
首先，咱们要解决 IP 更新导致 TCP 重连后客户端无奈辨认的问题。咱们能够通过 MQTT 会话放弃个性来解决。
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();}MQTT 5.0
基于这种网络连接频繁断开重连的状况，为了防止应用层频繁收到高低线事件，影响业务进行。MQTT 5.0 也对协定进行了响应的优化：
Will Delay Interval（延时遗愿音讯公布）：咱们常常应用遗愿音讯对客户端的下线进行追踪和告知。在这种状况下会频繁的收到遗愿音讯。所以遗嘱工夫距离的一个重要用处就是防止在频繁的网络连接长期断开时公布遗嘱音讯，因为客户端往往会很快从新连上网络并持续之前的会话。
Session Expiry Interval（会话过期间隔）：MQTT 3.1.1 未对会话放弃工夫做明确规定。如果应用 sesseion 放弃性能的客户端大量频繁高低线会造成 Broker 内存应用减少，最终影响服务高可用。所以 MQTT 5.0 也针对这种状况设计了会话过期工夫。客户端能够在连贯时应用这一个性设置本人的会话放弃工夫。
QoS 1/2
设置完会话保留状态，咱们就能够应用 QoS 音讯来保障音讯的达到。
咱们倡议对于重要数据在车机端应用 QoS 1 进行发送，并且应用带有 QoS 重传性能和内置 QoS 音讯窗口（队列）的 MQTT SDK。例如 NanoSDK，其具备异步确认、内置 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。此队列提供生产端肯定的缓冲工夫来实现重连后积压音讯的生产。
更优的解决方案：MQTT over QUIC
因为 TCP 采纳四元组来判断辨认连贯的独特性，而 UDP 并没有同样的要求。2022 年 6 月 11 日，IETF 正式颁布了 HTTP/3 RFC 技术标准文档后，基于 UDP 的 QUIC 正式成为了传输层规范之一。而基于 QUIC 的 MQTT 计划也无望成为下一个行业标准。
借助 QUIC 协定的地址迁徙、流式多路复用、分路流控、更低的连贯建设提早，咱们无望彻底解决车联网挪动场景下的连贯问题。
QUIC 可能侦测到地址扭转，主动采纳 0-RTT 的形式重建连贯，从而使得客户端和服务端对于 IP 地址的变动无感知，这样就彻底防止了上文所说的一系列问题。
结语
本文剖析了车联网挪动场景中 MQTT 通信不稳固景象的成因，并通过客户端和服务端对会话放弃、QoS、客户端 ID 的配置和内置音讯队列缓存等 MQTT 协定个性，在肯定水平上解决了高速移动带来的连贯不稳固导致的数据失落问题。
此外，如前文提到，相比之下 MQTT over QUIC 可能是一种更优的解决方案。目前最新公布的 EMQX 5.0 已反对 MQTT over QUIC 并设计了独特的音讯传输机制和治理形式，实现了无效升高数据丢包率，缩小握手提早。车联网用户能够应用 EMQX 5.0 取得更加高效、低提早的物联网数据传输体验。随着 EMQ 在 MQTT over QUIC 标准化过程的踊跃推动，置信将来车联网及其他更多物联网行业的弱网与不固定网络通路场景下的音讯传输问题都将失去进一步改善。
EMQ 车联网行业白皮书现已正式上线！
汇聚 EMQ 多年服务车联网畛域客户的实践经验，从协定抉择等理论知识到平台架构设计等实战操作，为车联网从业者搭建牢靠、高效、合乎行业场景需要的车联网平台提供可操作、可落地的参考指南。
版权申明：本文为 EMQ 原创，转载请注明出处。
原文链接：https://www.emqx.com/zh/blog/mqtt-communication-optimization-practices-for-iov
