该消息来源指出：
但是，XMPP存在许多问题，使其对于嵌入式IOT协议有些不受欢迎。作为基于XML的协议，XMPP非常冗长，甚至比HTTP还要冗长，并且具有大量数据开销。从IOT CONNECTED DEVICE向服务器发送一个字节数据的单个请求/响应交换超过0.5 kB。交换（EXI）。但是，即使使用EXI，仅XMPP就能获得相同的一个字节数据数百个协议开销。与现在可用的其他选项相比，处理EXI的格式也困难得多。由于这些固有的问题，通常建议避免在嵌入式IoT应用程序中使用XMPP。这是低开销的），因此对于物联网设备推荐/推广这么大，看似冗长的协议似乎很奇怪。
XMPP的开销真的和来源建议的一样大吗？数据的？例如，发送8字节消息时会有多少开销？
另外，如果使用EXI压缩，开销会很大吗？这还会带来一些陷阱吗？
#1 楼
可以说XML是冗长的，但应该意识到这种冗长并不是相对于内容而言的全部“开销”，因为它封装了语义，因此应该对此加以调整。开销是任何强调动态而不是静态结构的协议的症状。例如，HTML实际上是XML的一种宽松形式，它以动态结构传达内容，该结构可以被视为内容的一个方面。您可以将表的内容与表本身区分开来，但是内容是具有特定关系的表格数据这一事实对于内容是必不可少的。如果我只是将每个单元格都当作一个长字符串传输，那么该结构和那些关系就消失了，那么我就丢失了信息，不是那样的内容吗？可能构成一些表格数据。如果我使用一个非常静态的协议，则只需定义如下协议，就可以最少地传输该协议，而不会增加额外开销：不需要指出长度或包括任何终止序列。总是将8个字节用于表示2 x 2网格，其中每个单元格包含16位值。
我的消息完全是这样，使用XML，HTML或XMPP可能被认为很愚蠢–我在浪费总是相同且预先确定的结构组件上的带宽，并浪费了创建和解析它的两端的相应计算时间。一个最小的适当的HTML页面，其中仅包含一个2 x 2表，每个单元格中都有几个字符，可能会至少有100个字节，以容纳格式设置和协议开销。但是，如果不是我所有的消息都完全一样，那么指定消息的类型可能不是“有效负载”的字面意思，而是从内容角度而言是必要的组成部分。我可以只增加两个字节就可以做到这一点，并引入更多的动态性：
消息现在是可变长度的，0-255字节，第一个字节表示长度。
最多有256个用于不同预定义消息类型的代码，其中一个是“ 2 x 2 table”，这是第二个字节。
现在我的8个字节的表内容需要2个字节的开销，但就使用此自定义协议可以发送哪种消息而言，存在更多的可能性。
它仍然远远没有HTML页面或XML名称空间规范（
因此，基于此，如果您所做的主要是发送简单的8字节消息，则XMPP可能会过大。但是，不一定那么多。在我看来，瞥了一眼相关的RFC，“从IOT连接的设备向服务器发送一个字节的数据到服务器的单个请求/响应交换超过0.5 kB”的说法似乎是一种潜在的夸张（但是nb，所有我只是看了一眼，我从未实现或使用XMPP）。我毫不怀疑您可以构造一个这样的例子，但这可能不是一个最小的例子。
由于该协议是面向TCP的，因此仅在我们做完一件事时才需要将建立“由'jabber：client'名称空间限定的XML流”视为消息的一部分-设备与服务器联系以向其发送8个字节，然后发送数据，断开连接。如果这种关系在IoT上下文中通常更持久，那么我们可以假定设备已经与目标建立了连接。在这种情况下，如果消息的最终目标是服务器（相对于服务器要将消息传递到的另一个客户端），则协议开销可能最小。
br />
仅有33个字节的“开销”。这里值得指出的是XML是文本，因此，如果您的消息通常是二进制的，那么它将变得不那么合适，因为需要对数据进行编码（例如，将其编码为base64），这会进一步增加开销和计算量要求。
因此，最终：
XMPP是否会对发送短而频繁的消息的IoT设备产生大量开销？ br />如果存在持久的连接并且消息在很大程度上是非结构化的，那么我认为不是。但是，如果您不需要它提供的功能（关于结构的动态性），那么可能会有更合适的方法。
为此，如果我们有一个上下文，其中单个中央服务器正在处理和/或依赖各种设备之间的消息，即使这些设备中的任何一个正在执行的操作总是很简单明了，那么可以封装一个各种消息仍然有用。如果客户端设备的资源有限，我们可以对大部分协议进行硬编码，然后包装来自该端的每条消息就变得非常简单；我相信许多部署HTTP服务器的IoT设备都可以做到这一点（这与“简单客户端，复杂服务器”相反）。这些服务器无法处理任何类型的HTTP请求（通过预先格式化的拒绝除外），并具有定义明确，重点突出的事情集以及它们将发送的响应，但是由于它们仍然像HTTP服务器一样正常运行，因此各种普通设备（包括智能手机和PC）上的客户都很简单。
#2 楼
首先，我应该说XML已被成功地用于大规模封装实时消息，特别是用于XMPP中的IM和状态通信。似乎也有一些公司打算利用他们的XML知识来尝试为该数据表示系统找到另一个应用程序领域。在消息传递系统中。例如，近年来，使用JSON作为序列化数据而不是XML的一种在线系统发生了显着变化，如果我花了一下开发人员的时间，我会说从本地编码/解码的工具表示形式（例如Python，PHP，Javascript）似乎比JSON更容易使用，而不是XML等效形式，即使XML有更多时间来正确地获得这些答案。XML是计算机难以处理的表示形式，因为它需要相对复杂的文本解析器，然后需要某种分层表示形式才能将其数据提取到程序中。由于涉及的文本太多，因此您需要大量内存来进行编码/解码。
通常，似乎不清楚XML是否在数据表示中增加了很多价值：如果核心消息不是很深层次的，则似乎没有必要添加大量文本字段，但是自相矛盾的是，如果存在很多层次，则对消息进行解码它的文字表示将是艰苦的工作，需要大量资源。同样，以文本表示的好处对我也不是很清楚：当我们第一次编写和调试通信系统时，通常使用监视/解码工具（例如Wireshark）来帮助我们找出问题所在。从长远来看，一切都很好，并且没有人需要详细查看来回的消息（仅计算机）。计算机更喜欢二进制表示。文本表示法在部署的任何阶段都不会给任何人带来任何好处。因此，它既不适合计算机，也不适合人类。
重要的是，物联网有一些特殊的限制，使其变得高效。物联网设备通常将具有有限的处理能力和存储（通常没有大规模的二级存储，只有一些RAM和EEPROM）。物联网设备可能具有最简单的通信链接，甚至可能没有TCP / IP堆栈。将会有各种各样的微控制器设计，甚至在使用标准操作系统（例如Linux，Android）的复杂程度上也是如此。这限制了将提供易于使用的XML接口的现成工具的数量。
总而言之，我怀疑使用IoT时，最好将数据表示留给个案情况的基础上，取决于硬件限制，通信方式（例如广播，数据报，可靠性等），通信频率等。 XML当然不应被视为IoT的必要条件。
#3 楼
很多年前，我确实分析了在支付网络中使用
XML进行支付交易表示的区别
（卡号，日期，时间，终端ID和其他清单）元素）与传统的
位图ISO8583比较XML的开销很大。如果您考虑对具有10000多个节点的网络的影响，每个节点每小时/每天向中央主机发送10多个消息，那么XML就会失效，您确实需要更高效的解决方案。
评论
有趣的问题。虽然我不熟悉XMPP，但需要注意的是，EXI要求两个端点都具有必须同步的架构。物联网设备还必须对该xml进行编码/解码，这对于发送8字节消息而言似乎非常复杂。确实，@ Helmar使用XMPP看起来就像您在数据包大小上所获得的，却在计算复杂度上有所损失。
我认为这个问题通常很好，但是：“例如，每2分钟发送8字节消息会有多少开销？” ->“两分钟”是切线的，容易导致误入歧途。您真正要问的是8字节消息有多少开销（我想，如果只是一条数据，则与1字节消息相同）。关于时间部分，这仅取决于带宽，对于任何想使用必须死掉的网络协议的人来说，这很简单。
@delicateLatticeworkFever如果您认为不相关，我将对其进行编辑（我并不完全相信，但我认为更多细节总比少要好）
这是一个建议，是的。刚读完我写的内容，“这不取决于完全不确定的设备发送确定数量的字节需要多长时间？”例如，如果答案是消息约为〜0.5 kB，则单位中没有时间元素；）这是未指定设备的带宽。