XMPP是否会对发送短而频繁的消息的IoT设备产生大量开销？

我一直在阅读XMPP作为物联网设备的潜在通信协议，但是在阅读了一个来源之后，如果您担心每条消息的开销，我不确定它是否真的合适。

但是，XMPP存在许多问题，使其对于嵌入式IOT协议有些不受欢迎。作为基于XML的协议，XMPP非常冗长，甚至比HTTP还要冗长，并且具有大量数据开销。从物联网设备向服务器发送一个字节数据的单个请求/响应交换大于0.5 kB。

有一个规范草案可以使用称为有效XML交换（EXI）的XML编码来压缩XMPP。但是即使使用EXI，仅XMPP就能获得相同的一个字节数据数百个协议开销。与现在可用的其他选项相比，处理EXI的格式也困难得多。由于这些固有的问题，通常建议避免在嵌入式IoT应用程序中使用XMPP。

但是，XMPP 声称自己适合物联网应用程序（尽管它没有专门说明它的开销很低），因此为物联网设备推荐/推广这么大，看似冗长的协议似乎很奇怪。

XMPP的开销真的和数据源建议的那样大吗？例如，发送8字节消息时会有多少开销？

另外，如果使用EXI压缩，那么开销会这么大吗（如源中所述）？这还会带来一些陷阱吗？

communication networking xmpp

— 极光0001
source

有趣的问题。虽然我不熟悉XMPP，但需要注意的是EXI要求两个端点都具有必须同步的架构。物联网设备还必须对该xml进行编码/解码，这对于发送8字节消息而言似乎非常复杂。

— Helmar

@Helmar的确，使用XMPP看起来就像您在数据包大小上获得了什么一样，却在计算复杂性上失去了。

— Aurora0001

我认为这个问题通常很好，但是：“例如，每2分钟发送8字节消息会产生多少开销？” ->“两分钟”是切线的，容易导致误入歧途。您真正要问的是8字节消息有多少开销（我想，如果只是一个数据，则与1字节消息相同）。关于时间部分，这仅取决于带宽，对于任何打算使用必须死掉的网络协议的人来说，这都是简单的数学运算。

— goldilocks

@delicateLatticeworkFever如果您认为不相关，我将对其进行编辑（我不完全相信，但我认为更多细节总比少要好）

— Aurora0001

这是一个建议，是的。刚读完我写的内容，“这不取决于完全未指定的设备发送确定数量的字节需要多长时间吗？” 例如，如果答案是消息约为〜0.5 kB，则单位中没有时间；）这是未指定设备的带宽。

— goldilocks

Answers:

可以说XML是冗长的，但应该意识到这种冗长并不是相对于内容而言的所有“开销”，因为它封装了语义，因此应该对此加以调整。开销是任何强调动态而不是静态结构的协议的症状。例如，HTML实际上是XML的一种宽松形式，它以动态结构传达内容，该结构可以被视为内容的一个方面。您可以将表的内容与表本身区分开来，但是内容是具有特定关系的表格数据这一事实是该内容不可或缺的一部分。如果我只是把每个单元格都当作一个长字符串传输，那么那个结构和那些关系就消失了，那么我就丢失了信息，那不是内容吗？

让我们考虑一个8字节的消息，它可能构成一些表格数据。如果我使用一个非常静态的协议，那么只需定义以下协议，就可以最少地传输该协议而没有额外的开销：

每个消息正好是8个字节，因此我们无需指出长度或包含任何终止序列。
始终将八个字节用于引用2 x 2网格，其中每个单元格包含一个16位值。

如果我所有的消息都一样，那么使用XML，HTML或XMPP可能被认为是愚蠢的-我在浪费总是相同且预定的结构组件上的带宽，并浪费了创建和解析它的两端的相应计算时间。一个最小的正确的HTML页面，其中仅包含一个2 x 2表，每个单元格中都有几个字符，可能至少要有100个字节才能容纳格式和协议开销。

但是，如果不是我所有的消息都完全一样，那么指定消息的类型可能不是“有效载荷”的字面意思，而是从内容角度而言是必要的组成部分。我可以再加上两个字节就可以做到这一点，并引入更多的动态性：

现在，消息的长度是可变的，为0-255字节，第一个字节表示长度。
对于不同的预定义消息类型，有（最多）256个代码，其中之一是“ 2 x 2表”，即第二个字节。

现在，我的8个字节的表内容需要2个字节的开销，但是就可以使用此自定义协议发送的消息种类而言，存在更多的可能性。

它仍然远远没有HTML页面或XML名称空间规范（或XMPP本质上是它的集合）的可能性。

因此，基于此，如果您主要是在发送简单的8字节消息，则XMPP可能会过大。但是，不一定那么多。在我看来，乍看一下相关的RFC，“从IOT连接的设备向服务器发送一个字节的数据的单个请求/响应交换大于0.5 kB”的说法似乎是一种夸张的说法（但是nb，所有我所做的只是一眼，我从未实现或使用XMPP）。我毫不怀疑您可以构造一个这样的例子，但这可能不是一个最小的例子。

由于该协议是面向TCP的，因此仅在我们做完一件事情时，才需要将建立“由'jabber：client'名称空间限定的XML流”视为消息的一部分-设备与服务器联系以向其发送8个字节，然后发送数据，断开连接。如果这种关系是更持久的（通常在IoT环境中），那么我们可以假设设备已经与目标建立了连接。在这种情况下，如果消息的最终目标是服务器（与服务器要将消息传递到的另一个客户端相反），则协议开销可能最小。

<message><body>8 bytes.</body></message>

33个字节的“开销”。这里值得指出的是XML是文本，因此，如果您的消息通常是二进制的，那么它将变得不那么合适，因为该数据需要进行编码（例如，编码为base64），这会进一步增加开销和计算量要求。

因此，最终：

XMPP是否会对发送短而频繁的消息的IoT设备产生大量开销？

如果存在持久连接，并且消息在很大程度上是非结构化的，那么我不这么认为。但是，如果您不需要它提供的功能（关于结构的动态性），那么可能会有更合适的方法。

为此，如果我们有一个上下文，其中单个中央服务器正在处理和/或依赖各种设备之间的消息，即使这些设备中的任何一个正在执行的操作总是很简单明了的，那么可以封装一个协议的协议各种消息仍然有用。如果客户端设备的资源有限，我们可以对大部分协议进行硬编码，然后包装来自该端的每条消息就变得非常简单；我相信许多部署HTTP服务器的IoT设备都可以做到这一点（这与“简单客户端，复杂服务器”相反）。这些服务器无法处理任何类型的HTTP请求（通过预先格式化的拒绝除外），并且具有一组定义明确，重点突出的功能，这些功能可以执行操作以及它们将发送的响应，但是由于它们仍然可以像HTTP服务器那样正常运行，

— 金发姑娘
source

首先，我应该说XML已被成功地用于大规模封装实时消息，特别是用于XMPP中的IM和状态通信。似乎也有一些公司打算利用其XML知识来尝试为该数据表示系统找到另一个应用程序领域。

但是，并非所有人都相信XML是消息传递系统中所有问题的答案。例如，近年来，使用JSON作为序列化数据而不是XML的一种在线系统发生了显着变化，如果我暂时挂上我的开发人员帽子，我会说从本地编码/解码的工具表示形式（例如，在Python，PHP，Javascript中）似乎比JSON更容易使用，而不是XML等效形式，即使XML有更多时间来正确地获得这些答案。

XML是计算机难以处理的表示形式，因为它需要相对复杂的文本解析器，然后需要某种层次结构表示形式才能允许其数据在程序中提取。由于涉及的文本太多，因此您需要大量内存来进行编码/解码。

XML似乎常常为数据表示增加更多的价值：如果核心消息不是很深层次的，那么似乎就没有必要添加大量文本谷壳了，但是反之，如果存在很多层次，那么就可以对消息进行解码它的文字表示将是艰苦的工作，需要大量资源。另外，用文本表示的好处对我来说还不清楚：当我们第一次编写和调试通信系统时，通常使用监视/解码工具（例如Wireshark）来帮助我们找出问题所在。从长远来看，一切都很好，并且没有人需要详细查看来回的消息（仅计算机）。计算机更喜欢二进制表示。在部署的任何阶段，文本表示都不会给任何人带来好处。

XML很难使人阅读（和手动构造），同时又很难使计算机工作。因此，它是既不适用于计算机也不适合人类的系统。

重要的是，物联网有一些特殊的约束，使其变得高效。物联网设备通常将具有有限的处理能力和存储（通常没有大规模的辅助存储，只有一些RAM和EEPROM）。物联网设备可能具有最简单的通信链接，甚至可能没有TCP / IP堆栈。将会有各种各样的微控制器设计，甚至在使用标准操作系统（例如Linux，Android）的复杂程度上也是如此。这限制了提供易于使用的XML接口的现成工具的数量。

总而言之，我怀疑在物联网中，取决于硬件限制，通信方式（例如广播，数据报，可靠性等），通信频率等情况，最好根据具体情况保留数据表示。XML当然不应被视为IoT的必要条件。

— 魔术牛
source

很多年前，我确实分析了使用差异

与传统的比较方式相比，支付网络中的XML用于支付交易表示（card_number，日期，时间，terminal_id和其他元素列表）

位图ISO8583
XML具有巨大的开销。如果您考虑对具有10000多个节点的网络的影响，每个节点每小时/每天向中央主机发送10多个消息，那么XML就会失效，您确实需要更有效的方法。

— 阿米特（Amit Vujic）
source