Compression 冗长而昂贵的数据（xml是垃圾）

我在一个有jabber和通信平台的项目中工作

问题是，我需要客户机（很多客户机）在彼此之间进行通信，不仅是为了发出信号，而且是为了在它们之间更改数据

假设客户机A有3个可用的服务。客户端B可以请求A开始从每个服务（如流服务）向他发送信息，直到客户端B要求A停止服务为止

这些服务只能发送一个100毫秒间隔的字符或1000个100毫秒间隔的字符，甚至在需要时发送一些数据

当发送给B的信息到达时，它必须知道什么服务对应，什么动作和值（示例），所以我在jabber上使用json

我的问题是，我在jabber xmpp协议中浪费了很多带宽，只是为了发送一条带有如下主体的消息：

{“s”：“x”，“x”：5}//每100ms（5代表任意数字）

我真的不想使用并行通信（比如直接套接字），因为jabber已经实现了所有这些功能，并且容易扩展，防火墙问题，有时我使用http通信（在本例中，我使用BOSH）

我知道我可以做一些压缩，但是我想知道您是否推荐一些其他的东西，这些东西不能在我的消息后面包含如此多的xml，而且仍然使用jabber

非常感谢你的帮助

致以最良好的祝愿

---

爱德华多：不，Xml不是垃圾。其可读性强，可扩展性强，可压缩性极强

---

XMPP支持流压缩，根据我的所有测试，这种流压缩（主要是zlib）工作得非常好。因此，如果优化通过线路发送的字节数或在低带宽上发送的字节数对您很重要，那么在套接字上使用流压缩。当您使用Bosh时，您必须使用支持HTTP压缩的服务器，或者在两者之间使用代理来启用压缩。但是请记住，BOSH在所有HTTP头上也有很多开销。

听起来，除了重要的数据传输之外，XMPP非常适合您的应用程序

您可能知道，XMPP从未被设计或打算用作数据传输的大管道。大多数涉及重要数据传输的应用程序，如文件传输和语音/视频，都使用XMPP来协商单独的“带外”流。您说这可能会因为防火墙和web客户端而给您带来问题

如果你的应用程序主要是传输文本，那么你真的应该尝试压缩。。。如果带宽是您最受限制的资源，它可以显著节省带宽。缺点是它将占用更多的客户端和服务器内存（默认情况下约为300KB，但这可以通过边际压缩损失来减少）

或者，您也可以查看使用编码的base64数据隧道。我没有你的样本数据，也不知道你是如何包装它们以便运输的，这可能会变得更糟或更好。我想说，如果您去掉JSON并将其转换为更高效的二进制格式，效果会更好。Base64数据压缩得不太好，大约比原始数据大33%。节省的成本是能够去掉JSON和任何其他无关的包装，同时将数据保留在XMPP流中

---

最终，无论使用哪种技术，扩展大多数应用程序都很困难。它主要需要洞察——在没有先测试的情况下，你不应该改变任何东西，你应该事先测试，找出你应该改变什么。您应该分析系统的主要瓶颈（它真的是客户端的带宽吗？？）。根据我的经验，XML本身很少成为直接的瓶颈。然而，所有这些最终都是您的应用程序所独有的，要给出大规模的通用建议并不容易。

谢谢您的回答。我是说xml不是xml本身，而是xmpp消息背后的xml数量。确保测试以确保压缩的CPU开销不会使问题变得更糟。顺便说一句，在谈到二进制协议时，我应该补充一点，Google的协议缓冲区比从头开始设计自己的格式要好得多。当您有固定的数据模式时，它们可以比JSON和XML更紧凑：