为什么我们不在http上发送二进制而不是文本？

Question

看起来二进制文件会更紧凑并且可以以标准方式反序列化,为什么要使用文本呢？这看起来效率低下,而且Web框架只能用字符串来解决问题.为什么没有二进制标准？Web会更快,浏览器可以非常快速地加载二进制页面.

如果我要启动二进制协议(HBP超级二进制协议),我将定义哪种标准？

Answer 1

HTTP协议本身可以作为文本读取.这很有用,因为您可以远程登录到任何服务器并与之通信.

作为文本还允许您轻松地使用wireshark等程序观看HTTP通信.然后,您可以轻松诊断问题的根源.

HTTP定义了一种使用方式resources.这些资源不需要是文本,也可以是图像或其他任何内容.可以通过指定Content-Encoding标头将文本资源作为二进制文件发送.您的资源类型是通过Content-Type标头指定的.

所以你的问题实际上只适用于HTTP协议本身,而不适用于作为资源的有效负载.

Web会更快,浏览器可以非常快速地加载二进制页面.

我不认为这是真的.最慢的部分可能是连接建立和慢速TCP启动.

以下是HTTP响应如何使用二进制表示形式发送文本资源的示例:

HTTP/1.1 200 OK
服务器:Apache/2.0
内容编码:gzip
内容长度:1533内容类型:text/html; 字符集= ISO-8859-1

Answer 2

基于文本的协议有许多重要的优点:

• 假设您使用的是UTF-8或其他面向八位字节的编码,则无法解决字节顺序问题.
• 让每个人都同意基于文本的模式(例如用XML完成的模式)是很困难的.想象一下,试图让每个人都同意二进制协议中的数字应该是多少位.
  • 相关地,想象试图让他们就浮点表示达成一致.这不是一个假设 - IBM威胁要破坏ECMAScript 5标准化工作而不是浮点表示问题.
• 网络是基于文本的,我不只是指协议级别.大部分内容都是文本(同时,几乎所有内容都是文本).因此,现代编程语言已经围绕着他们使用文本的想法而成长,并且解析二进制格式并不那么重要.
  • 不久前,我不得不在Python中生成一个模糊的二进制格式,以便与遗留系统进行交互.事实证明这比我想象的要痛苦得多.解析它会远远更糟.
• 开发人员无法查看字节流并说出"哦,我的字符串长度丢失",他可以查看例如XML文档并说"哦,该元素没有被关闭".这使开发和故障排除变得更加容易.
• 性能被高估了,而XML解析器现在"足够快".如果你正在做的事情真的必须从硬件中挤出最后一点性能,你几乎肯定不会做任何基于Web的事情,并且可能会构建你自己的二进制协议来在你已经在两个应用程序之间进行通信控制.

Answer 3

这里是二进制通信标准,其中许多日期早于HTTP的.我构建/工作了一个二进制的客户端/服务器数据库协议,它确实工作并且在字节方面是有效的.所以问题是,为什么市场上的文本格式获胜？

我认为可能有很多因素,但我相信这些是最重要的因素:

• 您可能不记得从XML之前的日子开始,但是在尝试交换数据时,字节排序曾经是一个令人头痛的问题.每一点都很珍贵,所以文件格式尽可能紧密地打包.但是,只要您尝试在Mac和PC与大型机之间交换文件,就会意识到整数的二进制版本远非标准.程序员花了无数个小时来纠正这个问题.
• 使用文本流可以更轻松地进行调试和开发.正如有人指出的那样,您可以使用telnet终端会话来进行一些开发.很多时候你可以忽略字符编码问题.Unix管道和流的简单比喻可能是它成功的主要原因.这更容易.

Answer 4

嗯,它看起来像死记,但......似乎,你在预测未来.HTTP 2.0将是二进制的.