你问的是协议还是消息格式？当我们指的是数据格式时，我们经常错误地使用术语协议。我自己这样做，通常是因为每个人都不清楚这种区别。

IoT 中使用的消息传递协议往往相当紧凑，至少比 http 更紧凑，并提供在消息传递中很重要的重要功能（会话、流量控制、可靠性等）。消息格式是发送的消息中的数据。我假设这就是你要问的。

最紧凑的消息格式是经过仔细考虑的手动二进制格式。在低带宽场景中，当您想要发送几个字节并确切知道这些字节是什么样子时，经常使用它。对于较大的消息，缺点很明显，通常应该不惜一切代价避免。

我对许多不同的数据序列化选项进行了详细评估。我希望 protobuf 和 messagepack 相当紧凑，它们确实如此。然而，我的第二个问题是找到在许多不同平台上维护和可用的库，包括设备上的 C。

令人惊讶的是，我选择的格式是 gzip 压缩的 JSON。它很容易实现和理解，到处运行，而且，与我使用的数据相比，与其他方法大致相同或更小。

还要注意，如果你有一个安全通道，比如 TLS，无论如何你都会在 TLS 握手中消耗一大块数据 (>6KB)。

几年前，我预计像协议缓冲区这样的格式会占主导地位，但实际上并没有发生太多。可能是因为可以轻松地写出和解析（和压缩）json。我喜欢Flatbuffers的外观，但优势在于解析速度而不是紧凑。

由于您处于调查阶段，我建议您在每个方面编写一些代码，使用您的情况典型的数据，并进行一些比较。开始时拥有硬数据有助于确认您的选择。

基于标记的格式的一大优势是您在选择传输的数据方面保持灵活性。这在不断发展的生态系统中非常重要，您预计服务会在几年的发展中不断发展。

尽管紧密编码的二进制数据结构可以有效地传输，但您至少需要预先决定结构的外观。后来，当您意识到即使是一个领域也需要扩展时，您就会陷入困境。即使对协议进行更新也很困难，因为在每个端点都更新之前，您不能废弃旧的编码。

这表明最佳方法是混合极简数据包和基于标记的编码（使用后者作为后备）。此值取决于最高带宽有效负载。如果您已经在传输频繁的视频大小的块，那么优化不频繁的控制数据就不那么值得了。如果您有频繁的小传输（可能是温度），那么将传输的开销最小化是有意义的 - 但也许只是批量传输也一样好。