MQTT 数据使用

本节介绍使用 MQTT 接口与物联网设备管理门户通信时使用的数据量的详细信息。  通常有一些考虑因素，首先是传送的实际有效负载。  

有效负载取决于：

• 使用 TR50 接口还是服务器主题接口。  
• 第二个因素是 MQTT 协议开销，这是包装有效负载的实际 MQTT 协议框架。 
• 最后一个因素是用于与托管系统进行通信的 TCP 开销。

TCP 协议开销

• 有关 TCP 协议的详细信息：见此处
• TCP 连接使用大约 96 个字节（SYN、SYN-ACK、ACK）
• 在发送和接收数据时，每个传输使用大约 64 字节的开销（PSH、ACK）。
• 在 send and reply（发送和回复）场景中（即从设备到物联网设备管理门户）：
  • 如果回复“快” (<1 ms)，则事务可能会使用 96 字节的开销（PSH、PSH-ACK、ACK）
  • 如果回复“慢”，则事务将使用 128 字节的开销（PSH、ACK、PSH、ACK）

MQTT 协议开销

• 协议规范由 IBM 提供：见此处
• MQTT 连接使用大约 86 字节的数据（CONN 和 CONNACK）
• 在 send and reply（发送和回复）场景中（即从设备到云的 API 调用）：
  • 将有一个从设备到云的 PUBLISH，其使用 15 字节的开销 (PUBLISH)。
  • 还有一个从云到设备的 PUBLISH，其包含使用另外 15 字节开销的回复 (PUBLISH)。
• 在推送数据的 server topic（服务器主题）场景中：
  • 将有一个从设备到云的 PUBLISH，其使用 15 字节的开销 (PUBLISH)。
  • 如果 QOS 设置为 1，则会有一个从云到设备的 PUBACK，其开销为 2 字节 (PUBACK)。
• MQTT 定义了心跳间隔，并且在该间隔内，客户端将向服务器发送 PINGREQ 数据包，继而服务器将发送 PINGRSP，每个数据包都使用 2 字节的开销。  心跳间隔可以配置，并且在发生网络故障（客户端和服务器检测到存在通信错误）时会影响延迟。
  • 如果将心跳间隔设置为 24 小时，则每天只发送 1 次心跳；但如果发生网络故障，则在发送心跳消息之前，客户端和服务器将无法识别该故障。  这种情形是否能够接受，取决于应用的设计。

TR50 协议开销

• TR50 使用 JSON 编码消息（ASCII 协议）。
• 可选择使用 zlib 压缩 TR50 消息以减少使用。
• 有关调整大小时使用的示例 API 消息，请参见 API 指南：见此处
• 使用管理门户 API 在线测试查看原始和压缩的不同请求的大小
•  使用 deviceWISE 资产网关时，可以使用两种功能进一步减少数据使用：
  • 命令聚合器
    命令聚合器将一个时间窗口内发出的许多 API 调用组合在一起，构建一个更大的数据包（高效率压缩）。  您可以指定组合的时间窗口以调整流量。  为找到用例的最佳设置，需要进行反复试验。  在某些测试场景中，聚合可以将数据压缩率从未经聚合时的 25% 提高至使用聚合后的 90%。
  • 批处理
    使用命令聚合器时，一些命令会自动进行“批处理”以提高性能。  例如，当传送属性时，它们将使用 property.batch API 进行组合以降低传送时的开销。  如果使用命令聚合器，此组合行为自动进行。