二进制协议死了吗？ [关闭]答案

【问题标题】：Are binary protocols dead? [closed]二进制协议死了吗？ [关闭]
【发布时间】：2011-02-01 06:47:47
【问题描述】：

由于当时的互联网速度非常慢（拨号），似乎曾经有更多的二进制协议。我一直看到一切都被 HTTP 和 SOAP/REST/XML 所取代。

这是为什么？

二进制协议真的死了还是只是不那么流行了？为什么他们会死掉或不那么受欢迎？

【问题讨论】：

ZIP 文件是不是二进制协议？
我说的是网络
根据您的问题，定义“一切”和“死”。还要定义“二进制协议”。
只要一切都不是免费的，在纯文本（成本带宽）或压缩文本（成本处理器周期）和二进制之间的经济性非常重要的情况下，总会有二进制协议，使用文本协议在经济上是不可行的。
SSL/TLS、NFS/Sun RPC、X11、SMB/CIFS、VNC、SSH 和 rsync 都是立即想到的常用二进制协议。 ASCII 协议变得更加流行的原因似乎主要是由于使用 HTTP 作为传输层而不是裸 TCP，以及（通常）在另一端使用 JavaScript。对于这两种情况，与使用 XML 或 JSON 等文本协议相比，使用二进制协议会令人讨厌。

标签： tcp binary client protocols

【解决方案1】：

你只是无法击败二进制文件

二进制协议总是比文本协议更节省空间。即使互联网速度急剧增加，我们希望传达的信息的数量和复杂性也在增加。

您引用的文本协议在标准化、灵活性和易用性方面非常出色。但是，总会有一些应用程序的二进制传输效率会超过这些因素。

大量信息本质上是二进制的，可能永远不会被文本协议取代。视频流是一个明显的例子。

即使您压缩基于文本的协议（例如使用 GZip），通用压缩算法也永远不会像围绕特定数据流设计的二进制协议那样高效。

但有时您不必这样做

您看到更多基于文本的协议的原因是，与各种应用程序的数据大小相比，传输速度和数据存储容量确实增长得很快。我们人类发现使用文本协议要容易得多，因此我们围绕文本表示设计了我们无处不在的 XML 协议。当然，如果我们真的必须保存每个字节，并构建通用工具来可视化和处理数据，我们可以将 XML 创建为二进制协议。

再说一次，有时你真的会这样做

许多开发人员习惯于从多 GB、多核计算机的角度进行思考。即使是现在你的典型手机也让我的第一台 IBM PC-XT 感到羞耻。尽管如此，有些平台（例如嵌入式设备）对处理能力和内存有相当严格的限制。在处理此类设备时，可能需要二进制文件。

【讨论】：

不知道，我能看到...
@Jeffrey：至少你可以用记事本或 vi 调试问题；-)
@Martin：通用压缩总是比自定义二进制协议效率低。通用算法必须对数据的多样性和频率做出假设。极端示例：假设您要传输完全随机的 1 和 0 系列。二进制协议将 100% 有效（除了任何标头和路由信息）。例如，如果您在 XML 中表示这一点，那么您最希望的就是 10... 您不仅有围绕数据的额外字符，而且还有一个通用的压缩算法不能假设你不会输入其他字母或数字。
@Eric，但足以胜过缺点吗？对于 jpeg 或电影，您总是需要二进制文件 - 看到数字是没有用的。但是对于大多数协议，尤其是像 XML 这样的大量冗余文本，gzip 做得很好。如果你正在做一个协议，考虑一个简单的文本流，然后 gzip 看看在二进制之前是否足够好。
在嵌入式世界中，通常没有足够的内存来处理 XML。

【解决方案2】：

与编程语言并行可能非常相关。

虽然高级语言是大多数编程工作的首选工具，并且（部分）由于 CPU 速度和存储容量的提高而成为可能，但它们并没有消除对汇编语言的需求。

以类似的方式，非二进制协议引入了更多的抽象性、更多的可扩展性，因此特别适用于应用程序级通信。他们也受益于带宽和存储容量的增加。然而在较低的层次上，如此浪费仍然是不切实际的。

此外，与编程语言不同的是，编程语言有强烈的动机去“承受性能损失”以换取增加的简单性、开发速度等，分层结构通信的能力使得复杂性和“二进制性” "的较低层对应用程序级别相当透明。例如，只要接收到的 SOAP 消息是正常的，应用程序就不需要知道这些消息是否被有效地压缩以通过网络传输。

【讨论】：

【解决方案3】：

Facebook、Last.fm 和 Evernote 使用 Thrift binary protocol。

【讨论】：

【解决方案4】：

我很少看到有人谈论这个，但二进制协议，尤其是块协议可以大大简化服务器架构的复杂性。

许多文本协议的实现方式使得解析器无法推断在接收到逻辑单元之前还需要多少数据（XML 和 JSON 都可以提供完成所需的最少字节数，但是无法提供有意义的估计）。这意味着解析器可能必须定期让与套接字接收代码以检索更多数据。如果您的套接字处于阻塞模式，这很好，如果不是，则不是那么容易。这通常意味着所有解析器状态都必须保存在堆上，而不是堆栈上。

如果您有一个二进制协议，在接收过程的早期您就知道完成数据包需要多少字节，那么您的接收操作不需要与解析操作交错。因此，解析器状态可以保存在堆栈中，并且解析器可以在每条消息中执行一次并直接运行而无需暂停以接收更多字节。

【讨论】：

【解决方案5】：

在某些应用程序中总是需要二进制协议，例如非常低带宽的通信。但是基于文本的协议有巨大的优势。例如，我可以使用 Firebug 轻松准确地查看应用程序发出的每个 HTTP 调用发送和接收的内容。祝你好运，使用二进制协议:)

文本协议的另一个优点是，尽管它们的空间效率低于二进制，但文本数据的压缩效果非常好，因此可以自动压缩数据以获得两全其美的效果。例如，请参阅HTTP Compression。

【讨论】：

如果协议有文档，相当于Firebug是可行的，只是复杂而已。
netcat 连接到十六进制编辑器有什么问题？ :)
可以使用诸如Wireshark（以前的Ethereal）之类的协议分析器来理解二进制协议。如果您正在为二进制协议编写代码，那么制作分析器也是有意义的。
+1 用于将可读的 ASCII 协议与压缩相结合

【解决方案6】：

二进制协议并没有死。在许多情况下，发送二进制数据效率更高。

WCF 支持使用 TCP 的二进制编码。 http://msdn.microsoft.com/en-us/library/ms730879.aspx

【讨论】：

【解决方案7】：

到目前为止，答案都集中在空间和时间效率上。没有人提到我认为有这么多基于文本的协议的第一大原因：信息共享。这就是互联网的全部意义所在，而且使用基于文本的、人类可读的协议更容易被机器处理。您可以通过文本数据交换摆脱依赖于语言、特定于应用程序、偏向平台的编程。

链接到您想要使用的任何 XML/JSON/* 解析库，找出信息的结构，并截取您感兴趣的数据片段。

【讨论】：

【解决方案8】：

我在互联网应用程序中看到的一些二进制协议

Google Protocol Buffers 用于内部通信，但也用于，例如 Google Chrome 书签同步
Flash AMF 用于与 Flash 和 Flex 应用程序通信。 Flash 和 Flex 都可以通过 REST 或 SOAP 进行通信，但是 AMF 格式对 Flex 来说效率更高，正如一些 benchmarks 所证明的那样

【讨论】：

protoBuf 应该是像 XML 这样的交换格式，而不应该是协议。

【解决方案9】：

我真的很高兴您提出了这个问题，因为自从引入 XML 以来，非二进制协议的使用已经成倍增加。十年前，您会看到几乎每个人都在吹捧他们“遵守”基于 XML 的通信。但是，这种方法是二进制协议的几种方法之一，它有许多不足之处。

例如，其中一个价值是可读性。但是可读性对于调试很重要，当人类应该阅读事务时。与二进制传输相比，它们的效率非常低。这是因为 XML 本身是一个二进制流，必须使用另一层将其转换为文本片段（“令牌”），然后再转换为包含数据的二进制。

人们发现的另一个价值是可扩展性。但是，如果在事务开始时使用二进制流的协议版本号，则可以轻松维护可扩展性。可以发送二进制指示符，而不是发送 XML 标记。如果版本号是未知的，那么接收端可以下载这个未知版本的“字典”。例如，这个字典可以是一个 XML 文件。但是下载字典是一次性操作，而不是每次交易！

因此效率可以与可扩展性保持在一起，而且非常容易！有很多“已编译的 XML”协议可以做到这一点。

最后但并非最不重要的一点是，我什至听到有人说 XML 是克服小端和大端类型二进制系统的好方法。例如，Sun 计算机与 Intel 计算机。但这是不正确的：如果双方都能以正确的方式接受 XML（ASCII），那么双方肯定都能以正确的方式接受二进制，因为 XML 和 ASCII 也是二进制传输的......

希望你能找到这个有趣的阅读材料！

【讨论】：

【解决方案10】：

二进制协议将继续存在于需要效率的地方。大多数情况下，他们将生活在较低级别，硬件实现比软件实现更常见。速度不是唯一的因素——实现的简单性也很重要。使芯片处理二进制数据消息比解析文本消息要容易得多。

【讨论】：

【解决方案11】：

当然这完全取决于应用程序？到目前为止，已经有两种通用类型的示例，xml/html 相关的答案和视频/音频。正如 Jonathon 所说，一个被设计为“共享”，另一个在数据传输方面效率很高（如果没有 Matrix 的愿景，“阅读”电影永远不会像阅读 HTML 文档那样有用）。

易于调试并不是选择文本协议而不是“二进制”协议的理由 - 数据传输的要求应该规定这一点。我在航空航天行业工作，该行业的大多数通信都是高速、可预测的数据流，例如高度和无线电频率，因此它们在流中被分配位，不需要人类可读的包装器。它的传输效率也很高，并且除了干扰检测之外，不需要元数据或协议处理。

所以我当然会说他们没有死。

我同意人们的选择可能会受到他们必须对其进行调试这一事实的影响，但也很大程度上取决于所需的可靠性、带宽、数据类型和处理时间（以及可用的电源！）。

【讨论】：

绝对如此，请同时查看我的评论。许多人喜欢在“解密”模式下调试事物的事实，如今已转化为让计算机解密并将其从二进制重新加密为文本再重新加密为二进制的坏习惯，一旦人类不在循环中，这是一项多余的任务!

【解决方案12】：

它们没有死，因为它们是每个通信系统的底层。每个主要通信系统的data link 和network 层都基于某种“二进制协议”。

以互联网为例，您现在可能在局域网中使用Ethernet，PPPoE 与您的ISP 通信，IP 上网冲浪，也许FTP 下载文件。所有这些都是“二进制协议”。

我们看到上层向基于文本的协议转变，因为与“二进制协议”相比，它们更容易开发和理解，而且大多数应用程序没有严格的带宽要求。

【讨论】：

【解决方案13】：

取决于应用程序... 我认为在实时环境中（火线、USB、现场总线......）总是需要二进制协议

【讨论】：

【解决方案14】：

二进制协议死了吗？

两个答案：

希望如此。
没有。

至少二进制协议比 XML 更好，它提供了二进制协议的所有可读性以及 ~~所有效率~~的效率低于精心设计的 ASCII 协议。

【讨论】：

【解决方案15】：

Eric J 的回答几乎可以说明这一点，但这里还有一些值得深思的事实。请注意，以下内容与媒体协议（视频、图像）无关。有些事情你可能很清楚，但我每天都在听到神话，所以你去吧......

二进制协议和文本协议的表达能力没有区别。您可以以相同的可靠性传输相同的信息。
对于每个最佳二进制协议，您都可以设计一个最佳文本协议，该协议只占用大约 15% 的空间，并且您可以在键盘上键入该协议。
在实践中（每天都会看到实用的协议），由于许多二进制协议的静态特性，差异通常更小。

例如，取一个可以变得非常大（例如，在 32 位范围内）但通常非常小的数字。在二进制中，人们通常将其建模为四个字节。在文本中，它通常以打印数字后跟冒号的形式完成。在这种情况下，10 以下的数字变为两个字节，100 以下的数字变为三个字节。（您当然可以声称二进制编码不好，并且可以使用一些大小位来提高空间效率，但这是您必须记录的另一件事，在双方都实施，并且能够在出现故障时进行故障排除通过你的电线。）

例如，二进制协议中的消息通常由长度字段和/或终止符构成，而在文本协议中，您只需使用 CRC。

在实践中，由于需要冗余，差异通常不太显着。

您需要某种程度的冗余，无论是二进制还是文本。二进制协议通常不会出错。您必须 100% 正确记录您发送的每一位数据，而且由于我们大多数人都是人类，这种情况很少发生，而且您无法很好地阅读它以得出安全的结论，什么是正确的。

总结：理论上，二进制协议空间更大，计算效率更高，但在实践中的差异通常比您想象的要小，而且交易通常不值得。我在物联网领域工作，几乎每天都必须处理定制的、设计糟糕的二进制协议，这些协议真的很难排除故障，实施起来很烦人，而且空间效率也不高。如果您不需要绝对调整电池的最后毫安电流并使用微控制器周期（或传输媒体）进行计算，请三思而后行。

【讨论】：

您有物联网领域中基于文本的协议的示例吗？