Azure IoT Hub MQTT小消息传输过慢及限流问题咨询

一、小消息被严重限流的可能原因 #

• 单设备速率限制：IoT Hub的免费层/基础层对单个设备的发送速率有默认限制（比如免费层单设备每秒最多发送1条消息，基础层S1单设备默认速率也远低于每秒100条），你可能误把IoT Hub的总吞吐量配额当成了单设备的配额。
• 未利用批量发送：每条84字节的消息单独发送，即使按4KB计数，频繁的MQTT publish交互（尤其是QoS 1需要ACK）会累积网络延迟和服务端处理开销，导致单条耗时被拉长。
• 过长的Device ID：68字节的Device ID会增加身份验证、路由处理的开销，IoT Hub对过长的设备ID可能有额外的处理延迟，同时也会增加MQTT报文的头部大小。
• 连接方式问题：如果每次发送消息都重新建立MQTT连接，TLS握手的耗时（通常几百毫秒）会直接导致单条消息发送耗时飙升到0.6秒。
• 区域网络延迟：设备与IoT Hub所在区域的网络RTT过高，QoS 1的ACK往返会放大延迟，导致发送速率上不去。

二、改用TLS/SSL+专用MQTT broker的效果 #

首先，Azure IoT Hub的MQTT连接默认就是基于TLS/SSL的，所以换TLS/SSL本身不会带来提速。但改用专用MQTT broker（如EMQX、Mosquitto）确实能提升传输速度，原因如下：

• 专用broker的单设备吞吐量限制更宽松，能支持更高的并发发送速率。
• 可以在broker侧将多条小消息打包成一个4KB的消息，再批量转发到IoT Hub，既节省IoT Hub的消息配额，又减少与IoT Hub的交互次数，降低延迟。
• 如果将专用broker部署在靠近设备的区域，能大幅降低网络延迟，提升整体传输效率。

但要注意，专用broker需要自行维护，且最终同步到IoT Hub时仍需遵守IoT Hub的配额限制，只是通过批量转发能更高效地利用配额。

三、低成本实现数据存储与对比的方案 #

• 批量打包小消息：将多条84字节的传感器数据打包成一个4KB的消息发送，这样每条MQTT消息对应约47条原始数据，既充分利用IoT Hub的4KB计数规则，又能将发送速率提升数倍。
• 选择合适的IoT Hub层级：无需直接购买最高级的套餐，基础层S1每月费用仅几十美元，单单位（1个S1单位）就能支持每秒1111条4KB消息的吞吐量，完全满足你的需求。免费层仅适合测试，不适合长期使用。
• 保持MQTT持久连接：不要每次发送都断开连接，长连接能避免重复的TLS握手开销，这是降低单条消息耗时的关键。
• 优化Device ID：尽量缩短Device ID（比如用短ID映射长标识），减少服务端处理和报文传输的开销。
• 调整QoS级别：如果数据允许少量丢失，改用QoS 0可以省去ACK的往返延迟；如果需要可靠性，QoS 1配合批量发送也能大幅提升速率。
• 直接路由到存储服务：通过IoT Hub的消息路由功能，将数据直接转发到Blob Storage或Azure Data Explorer（ADX），无需额外的中间服务，同时存储费用远低于IoT Hub的高配额套餐，方便后续的真实数据与模拟数据对比分析。

内容的提问来源于stack exchange，提问作者Parko