关于使用 XML 作为应用程序级协议的问题
我想知道是否可以使用 XML 作为应用程序级协议。 XML 将位于 TCP 协议之上，两个应用程序只需要知道如何解析 XML。
但问题是，XML 不够紧凑。在通过 TCP 发送 XML 有效负载之前，我是否应该使用某种算法来压缩 XML 有效负载？如果我压缩它，那么两端都会涉及压缩/解压缩成本。真是两难啊。有什么好的建议吗？或者我采取了错误的方法？
非常感谢。
I am wondering if I could use XML as the application-level protocol. The XML will just sit on-top of the TCP protocol and the 2 applications will just need to know how to parse XML.
But the problem is, XML is not compact enough. Should I use some algorithm to compact the XML payload before send it with TCP? If I do compact it, then the compressing/decompressing cost will be involved on both ends. What a dilemma. Any good suggestions? Or I take the wrong approach?
Many thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
定义“足够紧凑”，您是否测量过它对于您的应用程序来说太慢了？避免过早优化。
与任何协议一样，在各个方向上都存在权衡。 XML 为您提供了一种众所周知的跨平台格式，其中包含几乎任何语言的库，能够表示各种结构化数据。 XMPP 选择了这一点，并对带宽受限的设置使用可选的压缩。在 XMPP 世界中使用替代表示进行的实验很少被证明值得付出努力。
JSON 比 XML 低了一个档次，但仍然提供许多优点。虽然它缺乏命名空间，但它相当简单，并且库几乎与 XML 库一样常见。不过，JSON 是基于文本的，在某些情况下可能仍然很冗长。
最后一个明智的选择是二进制协议。这样做的优点是您可以根据您的应用程序专门定制和优化它。缺点是您必须自己编写解析和序列化，尽管有一些工具可以自动执行此操作，例如 Google 的 Protocol Buffers 项目。
最终，所有这些都适用于不同的地方，并且选择取决于应用程序开发人员应该在给定项目中使用哪一种。
Define "compact enough", have you measured it to be too slow for your application? Avoid premature optimisation.
As with any protocol, there are trade-offs in various directions. XML buys you a well-known cross-platform format with libraries for just about any language, that's capable of representing all kinds of structured data. XMPP opts for this, and uses optional compression for bandwidth-constrained setups. Experiments in the XMPP world with alternate representations have rarely proven worth the effort.
A notch down from XML, but still providing many of the advantages is JSON. While it lacks namespacing it's fairly simple, and libraries are near as common as XML ones. Still, JSON is text-based and may still be verbose for some situations.
The last sensible choice would be a binary protocol. This has advantages in that you can tailor and optimise it specifically to your application. The disadvantages are that you have to write the parsing and serialization yourself, although there are tools to automate this such as Google's Protocol Buffers project.
Ultimately all of these are suitable in different places, and the choice is up to the application developer for which one they should use for a given project.
我想说，如果您需要一种简单的方法来指定消息的外观，那么您可以直接使用 XML 来存储消息，而不必费心压缩或任何其他操作（XML 并不是非常快）。如果您需要更快、更紧凑的功能，请查看 Google Protocol Buffers 或 Thrift （我个人更喜欢 Protocol buffers，但每个人都不像我..）。
例如，如果您需要使您的界面易于与许多不同的客户端（例如 Web 服务）进行互操作，那么使用 XML 可能是一个好方法。另一方面，如果您始终负责通信的两端，那么您总是可以快速开始一些事情，然后再进行优化。
I'd say that you can use straight XML for your messages and don't bother with compression or anything (XML isn't exactly blazingly fast) if you need a simple way of specifying how your messages look. If you need something faster and more compact, take a look at Google Protocol Buffers or Thrift (I personally prefer Protocol buffers, but everyone is not like me..).
Using XML can for instance be a good way if you need to make your interface be easy to interoperate with lots of different clients for instance (such as Web Services). If on the other hand you are always in charge of both ends of the communication, you can always do something quick to get going and then optimize later.