二进制协议死了吗？
似乎以前有更多的二进制协议，因为互联网速度非常慢（拨号）。 我已经看到一切被HTTP和SOAP / REST / XML取代。
为什么是这样？
二进制协议真的死了，还是不太受欢迎？ 他们为什么会死亡或不那么受欢迎？
你只是不能打败二进制
二进制协议总是比文本协议更节省空间。 即使互联网速度急剧增加，我们希望传达的信息的数量和复杂性也是如此。
您参考的文本协议在标准化，灵活性和易用性方面都非常出色。 但是，二元运输的效率总是会超过这些因素。
大量的信息本质上是二进制的，可能永远不会被文本协议取代。 videostream就是一个明显的例子。
即使您压缩基于文本的协议（例如使用GZip），通用压缩algorithm也不会像在特定数据stream周围devise的二进制协议那样高效。
但有时你不必去
您看到更多基于文本的协议的原因是因为与广泛应用的数据大小相比，传输速度和数据存储容量的确增长迅速。 我们人类发现使用文本协议更容易，因此我们围绕文本表示devise了无处不在的XML协议。 当然，我们可以将XML创build为二进制协议，如果我们真的必须保存每个字节，并且构build了通用工具来可视化和处理数据。
再次，有时你真的这样做
很多开发人员习惯于用多GB，多核心的计算机来思考。 即使你现在的典型的手机，我的第一个IBM PC – XT的耻辱。 不过，还有像embedded式设备这样的平台，对处理能力和内存有相当严格的限制。 在处理这种设备时，二进制可能是必需的。
与编程语言并行可能非常相关。
虽然高级语言是大多数编程工作的首选工具，并且由于CPU速度和存储容量的增加而成为可能（部分），但他们并没有消除对汇编语言的需求。
以类似的方式，非二进制协议引入了更多的抽象，更多的可扩展性，因此是应用级通信的select。 他们也从增加带宽和存储容量中受益。 然而，在较低的层次上，如此浪费仍然是不切实际的。
而且与编程语言不同，在编程语言中，为了增加简单性，开发速度等，交换结构的通信能力使得“低性能”的复杂性和“二元性”相当透明到应用程序级别 。 例如，只要收到的SOAP消息都可以，应用程序就不需要知道这些消息是否被有效压缩以通过networking传输。
Facebook，Last.fm和Evernote使用Thrift二进制协议 。
我很less看到这个话题，但二进制协议，块协议特别是可以大大简化服务器体系结构的复杂性。
许多文本协议的实现方式使得parsing器在接收逻辑单元之前无法推断出需要多less数据（XML和JSON都可以提供最小必需的字节来完成，但不能提供有意义的估计）。 这意味着parsing器可能必须定期切换到套接字接收代码来检索更多的数据。 如果你的套接字处于阻塞模式，这没问题，如果不是那么简单。 它通常意味着所有的parsing器状态必须保留在堆上，而不是堆栈上。
如果你在接收过程的早期有一个二进制协议，你就知道你需要完成多less个字节的数据包，那么你的接收操作就不需要和parsing操作交错了。 因此，parsing器状态可以保存在堆栈上，并且parsing器可以对每个消息执行一次并直接运行，而不会暂停接收更多字节。
在一些应用中总会需要二进制协议，例如非常低带宽的通信。 但是基于文本的协议有很大的优势。 例如，我可以使用Firebug轻松查看每个由我的应用程序进行的HTTP调用发送和接收的内容。 祝你好运与二进制协议:)
文本协议的另一个优点是，即使它们比二进制文件的空间效率更低，文本数据压缩得也很好，因此可以自动压缩数据以获得两全其美的效果。 例如，请参阅HTTP压缩 。
二进制协议没有死。 在很多情况下发送二进制数据要高效得多。
WCF支持使用TCP的二进制编码。 http://msdn.microsoft.com/en-us/library/ms730879.aspx
一些二进制协议，我在互联网应用程序野外看到
- Google协议缓冲区 ，用于内部通信，但也适用于Google Chrome书签同步
- Flash AMF ，用于与Flash和Flex应用程序进行通信。 Flash和Flex都具有通过REST或SOAP进行通信的能力，但是对于Flex，AMF格式的效率要高一些
我真的很高兴你提出这个问题，因为自引入XML以来，非二进制协议的使用倍增。 十年前，你几乎可以看到每个人都在鼓吹他们与基于XML的通信的“合规性”。 然而，这种方法是二进制协议的几种方法之一，有许多缺陷。
其中一个价值就是可读性。 但是当人类阅读交易时，可读性对于debugging是非常重要的。 与二元转移相比，它们效率非常低。 这是由于XML本身是一个二进制stream，必须使用另一个层转换为文本片段（“令牌”），然后再转换为包含数据的二进制文件。
人们发现的另一个价值是可扩展性。 但是如果在事务开始时使用二进制stream的协议版本号，则可以容易地保持可扩展性。 可以发送二进制指标，而不是发送XML标签。 如果版本号是未知版本，则接收端可以下载该未知版本的“字典”。 这个字典可以，例如，是一个XML文件。 但下载字典是一次性操作，而不是每一笔交易！
所以效率可以与可扩展性一起保存，非常容易！ 在那里有很多“ 编译的XML ”协议就是这样做的。
最后但并非最不重要的一点，我甚至听到有人说XML是克服小端和大端types的二进制系统的好方法。 例如，Sun电脑vs Intel电脑。 但是这是不正确的：如果双方都能正确接受XML（ASCII），当然双方都可以正确接受二进制，因为XML和ASCII也是二进制传输的。
希望你find这个有趣的阅读！
二元协议将继续生活在需要效率的地方。 大多数情况下，他们将生活在较低层次，硬件实现比软件实现更普遍。 速度不是唯一的因素 – 执行的简单性也很重要。 制作一个芯片进程二进制数据消息比parsing文本消息要容易得多。
到目前为止，答案都集中在空间和时间效率上。 没有人提到我觉得这是许多基于文本的协议的第一个原因：共享信息。 这是整个互联网的一个重要组成部分，使用基于文本的人类可读的协议也容易处理，这些协议也很容易被机器处理 。 您可以使用文本数据交换来消除语言依赖性，特定于应用程序，平台偏差的编程。
以任何XML / JSON / *链接 – 您要使用的parsing库，找出信息的结构，并剪切出您感兴趣的数据。
这当然完全取决于应用程序？ 到目前为止，已经有两种常见的types，xml / html相关答案和video/audio。 一个被devise成像Jonathon所指出的那样被“共享”，而另一个被有效地用于数据的传输（并且没有Matrix的愿景，“阅读”电影将永远不会像读取HTML文档那样有用）。
简单的debugging不是select一个“二进制”的文本协议的理由 – 数据传输的要求应该规定。 我在航空航天工业工作，大多数通信是高速，可预测的数据stream，如高度和射频，因此它们被分配到一个stream上的位，并且不需要可读的包装器。 除了干扰检测之外，传输也是高效的，不需要元数据或协议处理。
所以当然我会说他们没死。
我同意人们的select很可能受到它们必须debugging的影响，但是也将很大程度上取决于所需的可靠性，带宽，数据types和处理时间（以及可用的功率！）。
它们并没有死，因为它们是每个通信系统的底层。 各大通信系统的数据链路和networking层都是基于某种“二进制协议”的。
以互联网为例，您现在可能在您的局域网中使用以太网 ，使用PPPoE与您的ISP进行通信，使用IP来浏览网页，也可能使用FTP来下载文件。 所有这些都是“二进制协议”。
我们看到在上层基于文本协议的转变，因为与“二进制协议”相比，它们更容易开发和理解，并且因为大多数应用程序没有严格的带宽要求。
取决于应用程序…我认为在实时环境（火线，USB，现场总线…）将永远是一个需要二进制协议
二进制协议死了吗？
两个答案：
- 希望如此。
- 没有。
至less一个二进制协议比XML更好，它比一个精心devise的ASCII协议提供了一个二进制协议的所有可读性，以及所有低效率的效率。
Eric J的回答几乎是这样说的，但是这里有更多的想法和事实。 请注意，下面的东西不是关于媒体协议（video，图像）。 有些东西可能对你来说很清楚，但是我每天都会听到神话，所以在这里你去…
-
二进制协议和文本协议之间的performance力没有区别。 您可以以相同的可靠性传输相同的信息。
-
对于每一个最佳的二进制协议，你可以devise一个最佳的文本协议，只需要大约15％的空间，你可以在键盘上input该协议。
-
在实践中（实际的协议是每天都可以看到的），由于许多二进制协议的静态性质，差别往往不那么显着。
例如，取一个可能变得非常大的数字（例如，在32位范围内），但通常非常小。 在二进制中，人们通常以四个字节为模型。 在文本中，通常以打印的数字和冒号来完成。 在这种情况下，低于10的数字变成两个字节，低于100三个字节的数字。 （当然，你可以声称二进制编码是坏的，你可以使用一些大小的位来提高空间利用率，但这是另一件事，你必须logging，实施双方，并能够排除故障在你的电线上。）
例如，二进制协议中的消息通常由长度字段和/或终止符构成，而在文本协议中，您只需使用CRC。
- 在实践中，由于需要冗余，差异往往不太重要。
你想要一定程度的冗余，不pipe是二进制还是文本。 二进制协议通常不会出现任何错误。 你必须100％正确地logging你发送的每一个字节，而且由于我们大多数人是人类，所以很less发生这种情况，你不能很好地阅读，以便得出一个安全的结论。
总而言之 ：二进制协议在理论上是更多的空间和更高的计算效率，但实际上这种差异往往小于你的想象，交易往往是不值得的。 我在物联网领域工作，不得不在日常的基础上处理定制的，devise糟糕的二进制协议，这些协议真的很难排除故障，烦人实施，而且没有更多的空间效率。 如果您不需要绝对地调整电池的最后一个毫安，然后用微控制器周期（或传输媒体）进行计算，那就考虑一下。
