似乎早期由于网络速度慢（拨号上网），存在更多二进制协议，现在我看到所有东西都被HTTP和SOAP/REST/XML替代了。
为什么会这样呢？
二进制协议是否真的已经消失了，还是只是不那么流行了？它们为什么会消失或变得不那么流行？
二进制协议已经过时了吗？
40
- Earlz
8
5ZIP文件是二进制协议吗？ - S.Lott
2我更多地谈论网络相关的内容。 - Earlz
1从你的问题中，定义“everything”和“dead”。还要定义“binary protocol”。 - MattH
“我更多地谈论网络” - 你指的是哪个网络层？ - MattH
1SSL/TLS、NFS/Sun RPC、X11、SMB/CIFS、VNC、SSH和rsync都是常用的二进制协议，立即浮现在脑海中。ASCII协议变得更加普遍的原因似乎主要是由于使用HTTP作为传输层，而不是裸TCP，并且（通常）在另一侧使用JavaScript。对于这两种情况，与使用XML或JSON等文本协议相比，使用二进制协议将会很麻烦。 - Jack Lloyd
显示剩余3条评论
15个回答
44
二进制无可替代
与文本协议相比，二进制协议始终更具空间效率。 即使互联网速度大幅提高，我们希望传达的信息的数量和复杂性也随之增加。
您提到的文本协议在标准化、灵活性和易用性方面都非常出色。 但是，在某些情况下，二进制传输的效率将超过这些因素。
许多信息是二进制的，可能永远不会被文本协议取代。 视频流媒体就是一个明显的例子。
即使您使用GZip压缩文本协议，通用的压缩算法也永远无法像针对特定数据流设计的二进制协议那样有效。
但有时您并不需要
之所以看到更多基于文本的协议，是因为与广泛应用的应用程序数据大小相比，传输速度和数据存储容量确实快速增长。 我们人类发现使用文本协议更容易，因此我们使用文本表示形式构建了 ubiquitous XML协议。 当然，如果我们确实必须节省每个字节，我们可以将XML创建为二进制协议，并构建通用工具来可视化和处理数据。
然而，有时确实需要二进制
许多开发人员习惯于使用多个GB、多个核心的计算机进行思考。 即使是现今普通的手机也比我的第一台IBM PC-XT更强大。 但是，在嵌入式设备等平台上，对处理能力和内存有相当严格的限制。 在处理此类设备时，二进制可能是必需的。
- Eric J.
8
58我可以看到，但我不知道这是什么...<video><image timecode="0"><row rowIndex="0"><pixel colIndex="0"><red>5</red><green>100</green><blue>25</blue></pixel><pixel colIndex="1"><red>7</red><green>95</green><blue>25</blue></pixel>... - Jeffrey L Whitledge
4@Jeffrey：至少你可以使用记事本或vi来调试问题；-) - Eric J.
3@Martin：通用压缩永远比自定义二进制协议效率低。通用算法必须对数据的多样性和频率进行假设。极端例子：假设你想传输一系列完全随机的1和0。二进制协议将会是100%有效（除了任何标题和路由信息）。如果你用XML来表示这个序列，最好也只能像<b>1</b><b>0</b>这样。不仅要添加额外字符来围绕数据，而且通用的压缩算法无法假设你不会添加其他字母或数字。 - Eric J.
1@Eric，但是足够好以抵消缺点了吗？对于JPEG或电影，您始终需要二进制-看到数字是无用的。但对于大多数协议，特别是像XML这样具有大量冗余文本的协议，gzip表现得非常出色。如果您正在执行协议，请考虑使用简单的文本流，然后使用gzip，看看是否足够好，然后再转为二进制。 - Martin Beckett
2在嵌入式世界中，通常没有足够的内存来处理XML。 - Tobias Langner
显示剩余3条评论
7
与编程语言的并行可能是非常相关的。
虽然高级语言是大多数编程工作的首选工具，并且在一定程度上由于CPU速度和存储容量的增加而变得成为可能，但它们并没有消除对汇编语言的需要。
类似地，非二进制协议引入了更多的抽象性和扩展性，因此特别适用于应用层通信。它们也受益于带宽和存储容量的增加。然而，在更低的层次上，浪费这样的资源仍然是不切实际的。
此外，与编程语言不同，其中有强烈的激励“承担性能损失”，以换取增加的简单性、开发速度等，在通信结构化为分层的情况下，较低层次的复杂性和“二元性”就相当透明，不会对应用层产生影响。例如，只要收到的SOAP消息没有问题，应用程序就不需要知道这些消息实际上已被压缩以便在传输过程中使用。
- mjv
5
我很少看到有人谈论二进制协议，尤其是块协议，可以极大地简化服务器架构的复杂性。
许多文本协议是以这样一种方式实现的：解析器没有基础来推断在接收到逻辑单元之前需要多少更多的数据（XML和JSON都可以提供完成所需的最小字节数，但不能提供有意义的估计）。这意味着解析器可能不得不定期让出套接字接收代码以检索更多数据。如果您的套接字处于阻塞模式下，则这是可以接受的，如果不是，则不那么容易。通常意味着所有解析器状态必须保留在堆上，而不是栈上。
如果您有一个二进制协议，在接收过程的非常早期，您就知道需要多少个字节才能完成数据包，那么您的接收操作就不需要与解析操作交错进行。因此，解析器状态可以保存在堆栈上，并且解析器可以每条消息执行一次并直接运行而无需暂停以接收更多字节。
许多文本协议是以这样一种方式实现的：解析器没有基础来推断在接收到逻辑单元之前需要多少更多的数据（XML和JSON都可以提供完成所需的最小字节数，但不能提供有意义的估计）。这意味着解析器可能不得不定期让出套接字接收代码以检索更多数据。如果您的套接字处于阻塞模式下，则这是可以接受的，如果不是，则不那么容易。通常意味着所有解析器状态必须保留在堆上，而不是栈上。
如果您有一个二进制协议，在接收过程的非常早期，您就知道需要多少个字节才能完成数据包，那么您的接收操作就不需要与解析操作交错进行。因此，解析器状态可以保存在堆栈上，并且解析器可以每条消息执行一次并直接运行而无需暂停以接收更多字节。
- Kennet Belenky
3
在一些应用程序中，如非常低带宽通信，始终需要使用二进制协议。但是文本协议具有巨大的优势。例如，我可以使用Firebug轻松查看我的应用程序发出的每个HTTP调用发送和接收的内容。试试用二进制协议做到这一点吧 :)
文本协议的另一个优点是，尽管它们比二进制协议不那么空间有效，但文本数据压缩得非常好，因此数据可能会自动压缩以获得最佳效果。例如，请参见HTTP压缩。
- Justin Ethier
4
2如果协议有文档记录，那么相当于Firebug的工具是可行的，只是比较复杂。 - Adriano Varoli Piazza
1用netcat连接十六进制编辑器有什么问题吗？ :) - Earlz
+1 是将可读的 ASCII 协议与压缩相结合。 - Norman Ramsey
2
我看到一些用于互联网应用的二进制协议
- Google Protocol Buffers 用于内部通信，例如Google Chrome书签同步
- Flash AMF 用于与Flash和Flex应用程序进行通信。Flash和Flex都可以通过REST或SOAP进行通信，但AMF格式对于Flex来说更有效率，一些基准测试证明了这一点
- Jeduan Cornejo
1
protoBuf 应该像 XML 一样作为一种交换格式，而不应该成为一种协议。 - ZhaoGang
2
我很高兴你提出这个问题，因为自XML推出以来，非二进制协议的使用量已经成倍增长。十年前，几乎每个人都在吹嘘他们与基于XML的通讯的“兼容性”。然而，这种方法是二进制协议的几种方法之一，有许多缺陷。
例如，其中一个价值就是可读性。但是，在调试时，人类应该阅读事务时，它们与二进制传输相比非常低效。这是因为XML本身是一个二进制流，必须使用另一层将其转换为文本片段（“标记”），然后再将其包含的数据转换回二进制形式。
人们发现的另一个价值是可扩展性。但是，如果在事务开始时使用二进制流的协议版本号，则可以轻松地维护可扩展性。不需要发送XML标记，可以发送二进制指示符。如果版本号是未知的，则接收端可以下载此未知版本的“字典”。例如，这个字典可以是XML文件。但是，下载字典只需要进行一次操作，而不是每个单独的事务！
因此，效率和可扩展性可以很容易地保持在一起！有很多“编译XML”协议可以做到这一点。
最后，但并非最不重要的，我甚至听到有人说XML是克服小端和大端类型二进制系统的好方法。例如，Sun计算机与Intel计算机。但是这是不正确的：如果双方都能以正确的方式接受XML（ASCII），那么双方肯定也能以正确的方式接受二进制，因为XML和ASCII也以二进制方式传输.......
希望你会觉得这是有趣的阅读！
例如，其中一个价值就是可读性。但是，在调试时，人类应该阅读事务时，它们与二进制传输相比非常低效。这是因为XML本身是一个二进制流，必须使用另一层将其转换为文本片段（“标记”），然后再将其包含的数据转换回二进制形式。
人们发现的另一个价值是可扩展性。但是，如果在事务开始时使用二进制流的协议版本号，则可以轻松地维护可扩展性。不需要发送XML标记，可以发送二进制指示符。如果版本号是未知的，则接收端可以下载此未知版本的“字典”。例如，这个字典可以是XML文件。但是，下载字典只需要进行一次操作，而不是每个单独的事务！
因此，效率和可扩展性可以很容易地保持在一起！有很多“编译XML”协议可以做到这一点。
最后，但并非最不重要的，我甚至听到有人说XML是克服小端和大端类型二进制系统的好方法。例如，Sun计算机与Intel计算机。但是这是不正确的：如果双方都能以正确的方式接受XML（ASCII），那么双方肯定也能以正确的方式接受二进制，因为XML和ASCII也以二进制方式传输.......
希望你会觉得这是有趣的阅读！
- Etamar Laron
2
二进制协议并没有死亡。在许多情况下，发送二进制数据更加高效。
WCF支持使用TCP进行二进制编码。 http://msdn.microsoft.com/en-us/library/ms730879.aspx
- Raj Kaimal
2
到目前为止，所有答案都集中在空间和时间效率上。 没有人提到我认为是众多基于文本的协议的头号原因：信息共享。 这是互联网的全部意义，并且使用基于文本的易于处理的协议更容易实现 也易于机器处理。 使用文本数据交换可以摆脱语言依赖性、应用程序特定性和平台偏见的编程。
链接任何您想要使用的XML / JSON / *解析库，找出信息的结构，并剪切出您感兴趣的数据部分。
链接任何您想要使用的XML / JSON / *解析库，找出信息的结构，并剪切出您感兴趣的数据部分。
- Jonathon Faust
1
这当然完全取决于应用程序是什么。到目前为止，已经有两种一般类型的例子，一个是与xml/html相关的答案，另一个是与视频/音频相关的。前者被设计为“共享”，正如乔纳森所指出的，而后者在数据传输方面更高效（没有Matrix视觉，“读”电影就永远不会像读HTML文档那样有用）。
调试的便利性并不是选择文本协议而不是“二进制”协议的理由 - 数据传输的要求应该决定这一点。我在航空航天业工作，其中大部分通信都是高速、可预测的数据流，比如高度和无线电频率，因此它们被分配到数据流中的位上，无需人类可读的包装。它的传输效率也非常高，并且除了干扰检测之外，不需要任何元数据或协议处理。
所以我可以肯定地说它们还没有消亡。
我同意人们的选择可能受到他们需要调试它们的事实的影响，但这还将严重依赖于可靠性、带宽、数据类型和所需的处理时间（以及可用的功率！）。
- Elliot
1
当然，也请看一下我的评论。许多人喜欢在“解密”模式下调试事物的事实，今天被转化为让计算机从二进制到文本再到二进制重新解密和加密，这是一个冗余的任务，一旦人不在循环中！ - Etamar Laron
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接