虽然可以公平地说 XML 是冗长的，但应该认识到这种冗长并不完全是与内容相关的“开销”，因为它封装了语义；任何强调动态而不是静态结构的协议的症状都是开销。例如，HTML 实际上是一种轻松的 XML 形式，它以动态结构传达内容，该结构可以被视为内容的一个方面。您可以将表格的内容与表格本身区分开来，但内容是具有特定关系的表格数据这一事实是内容不可或缺的；如果我只是把每个单元格作为一个长字符串传输，那么结构和那些关系就消失了，所以我丢失了信息，这不是内容吗？
让我们考虑可能构成一些表格数据的 8 字节消息。如果我使用一个非常静态的协议，我可以在没有额外开销的情况下至少通过定义这样的协议来传输它：
- 每条消息正好是 8 个字节，因此我们不需要指明长度或包含任何终止序列。
- 8 个字节始终用于引用 2 x 2 网格，其中每个单元格包含一个 16 位值。
如果我所有的消息都完全如此，那么使用 XML、HTML 或 XMPP 可能会被认为是愚蠢的——我在总是相同和预先确定的结构组件上浪费带宽，并且在创建和解析它的两端浪费相应的计算时间。一个仅包含一个 2 x 2 表格且每个单元格中有几个字符的最小的、合适的 HTML 页面可能至少有 100 个字节，以适应格式和协议开销。
但是，如果不是我的所有消息都完全如此，那么指定它是哪种消息可能不是“有效负载”的文字部分，但它是内容方面的必要组成部分。我只需要额外的两个字节就可以做到这一点，并引入更多的活力：
- 消息现在是可变长度的，0-255 个字节，第一个字节表示长度。
- 对于不同的预定义消息类型，有（最多）256 个代码，其中之一是“2 x 2 表”，即第二个字节。
现在，我的 8 个字节的表内容需要 2 个字节的开销，但是在使用此自定义协议可以发送哪些类型的消息方面存在更广泛的可能性。
它仍然远不及 HTML 页面或XML 命名空间规范（或其集合，这就是XMPP 本质上是什么）的可能性。
因此，基于此，如果您所做的主要是发送简单的 8 字节消息，那么 XMPP 可能有点矫枉过正。然而，不一定那么多。声称“从 IoT CONNECTED DEVICE 向服务器发送一个字节的数据的单个请求/响应交换超过 0.5 kB”在我看来，瞥一眼相关的 RFC，是潜在的夸大其词（但请注意，所有我只是瞥了一眼，我从未实现或使用过 XMPP）。我不怀疑你可以构建一个这样的例子，但这可能不是一个最小的例子。
由于该协议是面向 TCP 的，如果我们正在做一次性的事情，建立“一个由 'jabber:client' 命名空间限定的 XML 流”只需要被视为消息的一部分——设备联系服务器发送 8 个字节，发送数据，断开连接。如果这种关系更加持久（通常在 IoT 环境中），那么我们可以假设设备已经与目的地建立了连接。在这种情况下，如果消息的最终目的地是服务器（而不是服务器要将消息传递到的另一个客户端），那么协议开销可能是最小的。
<message><body>8 bytes.</body></message>
微不足道的 33 个字节的“开销”。值得指出的是，XML 是文本，因此如果您的消息通常是二进制的，那么它就会变得不太合适，因为需要对数据进行编码（例如，到base64），这会增加额外的开销和计算要求。
所以，最终：
XMPP 对于 IoT 设备发送短而频繁的消息是否有很大的开销？
如果存在持久连接并且消息在很大程度上是非结构化的，我不这么认为。但是，如果您不需要它提供的东西（结构方面的活力），那么可能有更合适的方法。
追求这一点，如果我们有一个上下文，其中单个中央服务器正在处理和/或依赖各种设备之间的消息，即使这些设备中的任何一个可能总是简单明了，一个协议可以封装各种消息仍然有用。如果客户端设备的资源有限，我们可以对大部分协议进行硬编码，并且包装来自该端的每条消息成为一项非常简单的任务；我相信许多部署 HTTP 服务器的物联网设备都会这样做（这与“简单客户端，复杂服务器”相反）。这些服务器不能处理任何类型的 HTTP 请求（除非通过预先格式化的拒绝），并且有一个非常明确的、集中的事情将要做的事情和他们将发送的响应，但由于它们仍然作为 HTTP 服务器正常运行，