首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >为什么我们不在http上发送二进制而不是文本呢?

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

Stack Overflow用户
提问于 2009-12-12 10:06:00
回答 8查看 12.7K关注 0票数 31

二进制似乎会更紧凑,可以用标准的方式进行反序列化,为什么要使用文本呢?这似乎效率很低,web框架只能在字符串上胡乱摆弄。为什么没有二进制标准?web将变得更快,浏览器将能够非常快速地加载二进制页面。

如果我要启动一个二进制协议(HBP超二进制协议),我将定义什么类型的标准?

EN

回答 8

Stack Overflow用户

回答已采纳

发布于 2009-12-12 10:24:38

HTTP协议本身是文本可读的。这很有用,因为您完全可以telnet到任何服务器并与其通信。

文本形式还允许您轻松查看与wireshark等程序的HTTP通信。然后,您可以轻松地诊断问题的根源。

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

因此,您的问题实际上只适用于HTTP协议本身,而不适用于资源的有效负载。

网页的速度会更快,浏览器加载二进制页面的速度也会非常快。

我不认为这是真的。最慢的部分可能是连接建立和slow TCP start

以下是HTTP响应如何发送具有二进制表示的文本资源的示例:

超文本传输协议/1.1 200 OK

服务器: Apache/2.0

Content-Encoding: gzip

内容长度: 1533内容类型:文本/html;字符集=ISO-8859-1

票数 35
EN

Stack Overflow用户

发布于 2009-12-12 10:36:32

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

  • 假设您使用的是UTF-8或其他面向八位字节的编码,那么就没有字节顺序的问题了。
  • 让所有人都同意基于文本的模式(比如那些用XML完成的模式)已经够难的了。想象一下,试图让每个人都同意一个数字在二进制协议中应该是多少位。
    • 与此相关,想象一下试图让他们在浮点表示上达成一致。这不是一个假设-- IBM威胁要破坏浮点表示issues.

上的ECMAScript 5标准化工作。

  • web是基于文本的,我指的不仅仅是协议层。大部分内容都是文本(一度,几乎所有内容都是文本)。因此,现代编程语言已经成长起来,它们使用的是文本,而解析二进制格式并不那么重要。
    • 不久前,我不得不用Python语言生成一个晦涩难懂的二进制格式,以便与遗留系统交互。结果比我想象的要痛苦得多。解析它将会是很远很远的worse.

  • 开发人员不能在查看字节流时说“哦,我的字符串长度丢失了”,就像他看一个XML文档时说“哦,那个元素没有关闭”一样。这使得easier.
  • Performance的开发和故障排除被高估了,现在的解析器已经“足够快”了。如果你正在做的事情真的必须从硬件中挤出最后一点的性能,那么你几乎肯定不是在做任何基于web的事情,而是可能会构建自己的二进制协议来在你已经控制的两个应用程序之间进行通信。
票数 16
EN

Stack Overflow用户

发布于 2009-12-12 11:04:23

存在二进制通信标准,其中许多标准早于http。我构建/使用的客户机/服务器数据库协议是二进制的,它确实可以工作,而且是按字节高效的。所以问题是,为什么文本格式会在市场上取胜?

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

  • 您可能不记得在XML出现之前的日子了,但是在尝试交换数据时,字节排序曾经是一个令人头疼的问题。每一点都是宝贵的,所以文件格式被尽可能地压缩。但是,当你试图在Mac、PC和大型机之间交换文件时,你就会意识到整数的二进制版本远远不是标准的。程序员花费了无数的时间来纠正这个问题。使用文本流可以更轻松地调试和开发
  • 。正如有人指出的那样,您可以使用telnet终端会话来进行一些开发。很多时候,你可以忽略字符编码问题。Unix对管道和流的简单比喻可能是它成功的主要原因。这更简单。
票数 12
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/1891993

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档