简要回答

此计算器将设备规模、上报频率、载荷大小、QoS、下行比例和显式开销余量转换为每秒消息数、方向吞吐量和 30 天传输量的规划估算。它适用于在抓包或压力测试之前进行方案比较。

输出结果并非线路精确值。MQTT 包长度随主题长度、属性、包标识符和剩余长度编码而变化。TLS、TCP、IP 和无线帧还会增加更多字节，而重传和会话恢复会改变流量形态。保持假设可见，并在设计成熟后用实际测量值替换它们。

参数说明

  • 设备数量是该场景所代表的活跃设备总数。
  • 每设备每分钟消息数是平均上行频率。将事件驱动的突发流量转换为独立的峰值场景，而不是将其隐藏在日均值中。
  • 载荷字节数是开销余量之前的应用载荷。
  • QoS 选择透明的规划系数：QoS 0 为 1.00，QoS 1 为 1.12，QoS 2 为 1.28。
  • 下行占上行百分比代表命令、确认、期望状态、配置和其他代理到客户端的流量。
  • TLS 与帧开销是用户提供的百分比，在 QoS 系数之前加到载荷字节数上。

QoS 系数不是协议常量。它们是可通过代码编辑的启发式值，用于避免此轻量工具将包交换成本视为等同。在采购或容量决策中，应使用来自你的客户端、代理、主题结构和网络的实际抓包数据替换它们。

方法与公式

上行消息速率为：

设备数量 × 每设备每分钟消息数 ÷ 60

每条上行消息的估算字节数为：

载荷字节数 × (1 + 开销百分比 ÷ 100) × QoS 系数

上行吞吐量将该速率转换为兆比特每秒。下行吞吐量是上行吞吐量的指定百分比。月传输量假设合并速率持续运行 30 天，并使用十进制吉字节。

示例分析

假设 10,000 台设备每分钟发送一条 256 字节载荷，上行速率约为每秒 166.7 条消息。选择 QoS 1、18% 帧和 TLS 开销、下行等于上行的 5%。

规划字节数为 256 × 1.18 × 1.12，即每条上行消息约 338.3 字节。由此得出约 0.451 Mbit/s 上行和 0.023 Mbit/s 下行。如果这些平均速率不间断持续 30 天，显示的传输量约为 153.5 GB。

现在为真实峰值创建第二个场景。如果设备在整分钟时同时上报或在重连后批量发送缓存消息，月均传输量可能保持相似，但瞬时吞吐量和代理负载会急剧上升。两个数字都很重要，但回答的是不同的问题。

局限性与测量边界

估算不包括实际主题名、MQTT 固定头和可变头、MQTT 5 属性、CONNECT 和心跳流量、DNS、TCP 建立、TLS 握手、证书大小、IP 和链路层头、重传概率、留存投递、离线队列和压缩。它假设恒定速率，不建模 p95 载荷大小或区域网络质量。

蜂窝和卫星计费可能对会话或数据包取整、适用最低增量，或对上行和下行分别定价。因此字节估算不是计费预测。它也不是代理容量结论：路由扇出、持久化、认证和连接数可能在网络吞吐量之前就制约代理。

隐私与可分享场景

所有计算在本页面完成。六个数值或选择参数在计算后写入当前 URL，使场景可以重新打开和比较。如果设备规模或流量假设属于机密，分享链接前请替换为代表性数值。不上传任何数据。

复制生成 Markdown 摘要，而 JSON、CSV 和 Markdown 下载由浏览器本地生成。

常见问题

载荷大小应包含主题吗？

不。只输入应用载荷，然后用开销百分比代表其余部分，直到抓包提供更好的依据。

为什么 QoS 1 的系数只有 12%？

这是规划启发式值，不是对 MQTT 的断言。实际成本取决于包大小、确认、重传、批处理和连接行为。

应该使用平均频率还是峰值频率？

两者都运行。平均流量帮助估算传输量；同步峰值和恢复突发决定网络和代理余量。

相关指南

在分配 QoS 系数之前，阅读选择 MQTT QoS，尤其是在已有丢包处理和应用确认机制的情况下。