面临的问题

本地IoT物联网设备产品都偏向于低成本，低计算力，如果指望像Yolo，PyTorch这种依赖于本地硬件算力的视觉人工智能框架应用生产环境是不太现实的。在4G时代由于移动通信带宽仍低于云端要求，将计算全部放在云端并向IoT设备传回数据仍不现实，虽然5G时代改变了这种局面，但仍需要在云端与IoT通信方式与算法上加以改进来适应大量音视频数据传输与传回识别数据。

EMQ5.0与次世代物联网标准协议

2022年底EMQ实现了通过 QUIC 协议中继 MQTT 消息的突破，并将研究结果以开源的形式公布。这个结果在目前来看的确是次世代（官方文章叫 Next-Generation）MQTT Over QUIC（以下简称MOQ）让两者的缺点互相填补，QUIC填补了MQTT断线重连难，断线后操作系统释放资源慢，应用层无法及时感知断线状态，重连时Server/Client开销大，弱点网络环境下，数据传输受阻拥塞、丢包、重传等缺点。

例如，车联网用户通常会面临类似的问题：车辆可能在山区、矿山、隧道等地行驶，进入信号盲区或被动切换基站（也称为参波网络）时会导致连接中断。频繁的连接中断和缓慢的连接建立会导致糟糕的数据延迟。在一些对实时数据传输和稳定性要求较高的业务中，比如L4无人驾驶汽车，客户需要付出很大的代价来缓解这个问题。

在这些场景中，QUIC 的低连接开销和多路径支持显示了它的优势。 MQTT over QUIC 是解决这一困境的一个很好的解决方案——基于 QUIC 的 0 RTT/1 RTT 重连/新能力和迁移支持，可以有效改善弱网络和不规则网络路径下的用户体验。

MOQ的特性天生适合应用在汽车，飞机等非固定网络环境的场景中，并可以弥补传统TCP/TLS造成的高延迟与丢包等缺陷。尤其是高数据量传输场景（音视频，数据集大文件与快速响应分析结果）

配合MQTT-SN协议

如果只介绍MOQ我就不必要来写文章参赛了（笑）虽然MOQ有以上这些缺点，但很可惜MOQ“本身”并不适合传输视频数据，MQTT和QUIC协议设计之初都没有考虑过音视频数据包。但它的概念优于现有的视频流协议（比如RTSP，WebRTC等）且MQTT for Sensor Networks（MQTT-SN）一种针对传感器网络优化的MOQ协议变体日渐成熟且最近添加了对二进制数据传输的支持。

那我们就可以利用MQTT-SN来传输视频数据，由于MQTT-SN是一种轻量级协议，虽然不适合来传输超高清高分辨率的流视频数据，所以系统还是用在中近距离的作业场景中效果更佳。

所以我们创造了一种新的通信模式

理论性能测试

我没有车，不可能开着去偏远地区或山区跑一圈（我还没有驾照，而且我也不会开手动挡）实测MOQ+SN 和传统TCP/TLS他们两个哪个更棒。但我做了一些简单的理论测试来验证我的猜想可行。

先引用官方的一些数据（来自EMQ）

其实10ms测试对视频流数据来说是一个很关键的指标，如果大量丢失关键帧会严重影响YOLO的判断能力。

接下来是我的一些理论测试

本次测试主要测试使用MOQ传输视频流，二进制流延迟性，而非极端网络状态下的通信稳定情况。极端状态下的通信情况EMQ官方已给出结果而本人也没有能力去测试。

MOQ客户端/服务器二进制数据流延迟测试

游戏《反恐精英：起源》通过简单的修改游戏代码后可以支持MOQ协议进行游戏数据传输。游戏基于C/S架构，对网络延迟有极高的要求。

云端：阿里云 北京主机 39.106.57.89 CentOS 8 服务器系统

本地：中国移动 黑龙江哈尔滨 223.104.102.206

裸ping：

游戏中使用普通传输：

使用MOQ传输游戏数据：

很明显，在传输二进制数据流时，游戏数据包延迟更低，MOQ比传统TCP/TLS有更大的优势。

MOQ客户端/服务器视频流延迟测试

云端：阿里云 北京主机 39.106.57.89 CentOS 8 服务器系统

本地：中国移动 黑龙江哈尔滨 223.104.102.206

推流环境：RSR+webRTC（FLV）推流延迟设置为”尽可能小“

裸ping：

使用RTSP视频流传输延迟：

使用MOQ（MQTT-SN）传输视频流数据延迟：

作为YOLO监测已到达一个可接受的延迟值范围内。

MQTT-SN在IOT设备上的可行性

由于MOQ协议还没有大火，所以在MicroPython上还没有官方支持的MQTT-SN库。不够我已经成功移植了一部分SN功能到ESP32CAM板上，并实现了与本机电脑配合YOLO进行人脸识别的功能。