二进制协议v。文本协议

94

有谁对二进制协议有一个很好的定义？文本协议实际上是什么？这些在导线上发送的比特之间如何比较？

维基百科对二进制协议的评论如下：

二进制协议是一种旨在或有望由机器而非人类读取的协议（http://en.wikipedia.org/wiki/Binary_protocol）

哦，加油！

更清楚地说，如果我有jpg文件，该文件将如何通过二进制协议发送，如何通过文本协议发送？当然是通过电线发送的比特/字节数。

归根结底，如果您查看一个字符串，它本身就是一个字节数组，因此这两种协议之间的区别应该取决于网上实际发送的数据。换句话说，关于原始数据（jpg文件）在发送之前如何编码。

text  binary  protocols 
— der_grosse
source
— dkinzer 2013年

Answers:

169

二进制协议与文本协议实际上并不是关于二进制Blob的编码方式。真正的区别在于协议是围绕数据结构还是围绕文本字符串。让我举一个例子：HTTP。HTTP是一种文本协议，即使当它发送jpeg图像时，它只是发送原始字节，而不是它们的文本编码。

但是使HTTP成为文本协议的原因是，获取jpg的交换如下所示：

请求：

GET /files/image.jpg HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.01 [en] (Win95; I)
Host: hal.etc.com.au
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8

响应：

HTTP/1.1 200 OK
Date: Mon, 19 Jan 1998 03:52:51 GMT
Server: Apache/1.2.4
Last-Modified: Wed, 08 Oct 1997 04:15:24 GMT
ETag: "61a85-17c3-343b08dc"
Content-Length: 60830
Accept-Ranges: bytes
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: image/jpeg

<binary data goes here>

请注意，可以很容易地将其更紧密地打包到一个看起来像C的结构中

请求：

struct request {
  int requestType;
  int protocolVersion;
  char path[1024];
  char user_agent[1024];
  char host[1024];
  long int accept_bitmask;
  long int language_bitmask;
  long int charset_bitmask;
};

响应：

struct response {
  int responseType;
  int protocolVersion;
  time_t date;
  char host[1024];
  time_t modification_date;
  char etag[1024];
  size_t content_length;
  int keepalive_timeout;
  int keepalive_max;
  int connection_type;
  char content_type[1024];
  char data[];
};

其中，根本不需要传输字段名称，例如，responseType响应结构中的int是一个值为200的int而不是三个字符“ 2”，“ 0”，“ 0”。这就是基于文本的协议：被设计为以一排（通常是人类可读的）文本行而不是许多不同类型的结构化数据进行通信的协议。

— 泰勒·麦克亨利
source
19
1线定义为+1“不同之处在于协议实际上是围绕数据结构还是围绕文本字符串。”
— Frank Shearar
2
泰勒（Tyler），感谢您的回答，我应该说的很深。怪胎场景取决于我们所有人的共识，在电线上只能通过0和1。请告诉我这是否能记录您的想法。说我想通过网络发送数字15（十月）（您在网络上有两台相同的计算机，没有大/小印度混乱等）。如果我要使用二进制协议（例如，我通过TCP套接字发送它）将以00001111的形式发送，但是如果我要使用文本协议，它将以00110001（字符1的ASCII）发送00110101（字符5的ASCII）是真的还是废话？:)
— der_grosse
1
没错 以文本方式执行此操作的优点不仅在于可读性强，而且如果您的数字长于一个字节，则不必担心字节序。
— Tyler McHenry'4
1
我不同意1-line的定义，也不同意发送char 15的示例，要查看差异，正如我在回答中所说的那样，您必须了解整个字符集和定界符/协议，您不能说如果协议是基于文本或基于二进制的，则基于单个数据示例。您可能正在“看”电缆，看到一个65（字符“ A”），但仍然不能说它是基于文本或二进制协议的。两者对于单个字符可能具有相同的表示形式，但这不是基础。
— 埃尔南·埃切（HernánEche）
25

这是一种解决方案定义：

看到它便会知道。

这是很难找到涵盖所有极端情况的简洁定义的情况之一。但这也是那些极端情况完全不相关的情况之一，因为它们根本不会在现实生活中发生。

您在现实生活中会遇到的几乎所有协议都看起来像这样：

> fg,m4wr76389b zhjsfg gsidf7t5e89wriuotu nbsdfgizs89567sfghlkf
>  b9er t8ß03q+459tw4t3490ß´5´3w459t srt üßodfasdfäasefsadfaüdfzjhzuk78987342
< mvclkdsfu93q45324äö53q4lötüpq34tasä#etr0 awe+s byf eart

[想像那里还有很多其他不可打印的废话。传达文本和二进制之间的差异的挑战之一是您必须以文本形式进行传达:-)]

或像这样：

< HELLO server.example.com
> HELLO client.example.com
< GO
> GETFILE /foo.jpg
< Length: 3726
< Type: image/jpeg
< READY?
> GO
< ... server sends 3726 bytes of binary data ...
> ACK
> BYE

[我是当场弥补的。]

那里没有太多的歧义。

我有时听到的另一个定义是

文本协议是您可以使用调试的协议 telnet

也许我在这里表现出我的书呆子，但是我有实际上通过SMTP和POP3编写和阅读了电子邮件，通过NNTP读取了usenet文章，并使用HTTP通过了HTTP来查看网页telnet，除了其他目的，除了看它是否真正有用。

实际上，在撰写本文时，我有点发烧了：

bash-4.0$ telnet smtp.googlemail.com 25
Trying 74.125.77.16...
Connected to googlemail-smtp.l.google.com.
Escape character is '^]'.
< 220 googlemail-smtp.l.google.com ESMTP Thu, 15 Apr 2010 19:19:39 +0200
> HELO
< 501 Syntactically invalid HELO argument(s)
> HELO client.example.com
< 250 googlemail-smtp.l.google.com Hello client.example.com [666.666.666.666]
> RCPT TO:Me <Me@Example.Com>
< 503 sender not yet given
> SENDER:Me <Me@Example.Com>
< 500 unrecognized command
> RCPT FROM:Me <Me@Example.Com>
< 500 unrecognized command
> FROM:Me <Me@Example.Com>
< 500-unrecognized command
> HELP
< 214-Commands supported:
< 214 AUTH HELO EHLO MAIL RCPT DATA NOOP QUIT RSET HELP ETRN
> MAIL FROM:Me <Me@Example.Com>
< 250 OK
> RCPT TO:You <You@SomewhereElse.Example.Com>
< 250 Accepted
> DATA
< 354 Enter message, ending with "." on a line by itself
> From: Me <Me@Example.Com>
> To: You <You@SomewhereElse.Example.Com>
> Subject: Testmail
>
> This is a test.
> .
< 250 OK id=1O2Sjq-0000c4-Qv
> QUIT
< 221 googlemail-smtp.l.google.com closing connection
Connection closed by foreign host.

该死，距离我这样做已经有一段时间了。那里有很多错误:-)

— 约格·米塔格
source
7

二进制协议的示例：RTP，TCP，IP。

文本协议示例：SMTP，HTTP，SIP。

这应该使您可以概括为二进制协议和文本协议的合理定义。

提示：只需跳至示例部分或图表。它们可以说明泰勒的摇摆不定。

— 弗兰克·希勒（Frank Shearar）
source
1
弗兰克（Frank），感谢您的链接，但是当我完成RFC的时候，它将是2099年：)我想从已经读过这些书的人们那里得到一些答案。我仍然在思考泰勒·麦克亨利的答案……
— der_grosse 2010年
必须说，很棒的分享。
— 伊克拉。
5

正如你们大多数人所建议的，我们仅通过查看网络上的内容就无法区分协议是二进制还是文本

AFIK

二进制协议-位是边界顺序非常关键

例如，RTP

前两位是版本，下一位是标记位

文本协议-特定于协议的分隔符字段顺序并不重要

例如，SIP

还有一个是，在二进制协议中，我们可以分割一个字节，即，单个位可能具有特定的个别含义；在文本协议中，最小有效单位是BYTE。您不能分割一个字节。

— Toyvenu
source
2

两者都使用不同的字符集，即文本，使用简化的字符集，二进制文件不仅包含“字母”和“数字”，还包括所有可能的字符（这就是为什么维基百科说“人类”）

o更清楚一点，如果我有jpg文件，该文件将如何通过二进制协议发送，如何通过文本协议发送？当然是通过电线发送的比特/字节数。

你应该读这个Base64

赞赏任何评论，我正在尝试着这里的本质。

我认为缩小字符集的本质是缩小复杂性，并达到可移植性，兼容性。安排并同意许多人来尊重宽字符集（或任何宽泛的字符集）比较困难。拉丁/罗马字母和阿拉伯数字是世界闻名的。（当然，还有其他减少代码的考虑因素，但这是主要的考虑因素）

假设在二进制协议中，部分之间的“契约”是关于位的，第一位表示此位，第二位表示此位，等等，甚至是字节（但可以自由使用字符集而无需考虑可移植性），例如在私有封闭系统中或（靠近硬件标准），但是，如果您设计一个开放系统，则必须考虑如何在广泛的情况下表示代码，例如在世界另一端的机器中如何表示代码？这里是文本协议，合同将尽可能地符合标准。我设计了这两者，这就是原因，非常定制的解决方案是二进制文件，开放式或便携式系统的文本。

— 埃尔南·埃切
source
我了解base64及其功能，而这正是我发布问题时所想到的。当我想以ASCII表示形式发送任何东西（编码）时，base64很好，因此它将是文本协议。从技术上讲，它将位输入分成6对，使用查找表等。谁能提供关于二进制协议的工作原理的类似解释？补充问题：我们可以在哪个OSI级别上讨论二进制和文本协议，这些世界在这些级别上的确切含义是什么？
— der_grosse
1
二进制示例包括低级协议，例如简单的串行通信（en.wikipedia.org/wiki/Asynchronous_serial_communication）或数据如何存储在内存中（en.wikipedia.org/wiki/Data_structure_alignment）。关于OSI..well，因为文本和二进制协议用于表示数据（不仅用于通信），所以它们不必处于任何OSI级别，我可以说1,2,3,4层具有“二进制”协议”和“文本协议”可以位于5,6,7。
— 埃尔南Eche
0

我想你错了。并不是由协议决定数据在“线路”上的外观，而是由数据类型决定使用哪种协议进行传输。以tcp套接字为例，将使用二进制协议发送和接收jpeg文件，因为它是二进制数据（人类不可读，字节在32-126 ascii范围内），但是您可以使用以下方式发送/接收文本文件：两种协议，您都不会注意到它们之间的区别。

— 西蒙妮·玛格丽特丽
source
不，我不认为我做错了。我仍在寻找二进制协议是什么的（好的）定义。jpeg的示例是为了阐明我的问题，别无其他，不要将其作为问题的中心。我应该说协议决定了在线传输数据时的外观，为什么协议呢？
— der_grosse
我给您提供了一个精确的定义，您只需要仔细阅读即可。“二进制协议管理32-126 ascii范围内的字节，也称为不可打印字符”
— Simone Margaritelli 2010年
文本协议还可以通过将它们拆分为更小的ASCII表格来处理它们。等等。所以最好的情况是您的定义含糊不清。但感谢您的贡献。
— der_grosse
0

文本协议可以是不言自明和广泛的。这是不言自明的，因为消息仅在消息本身中包含字段名称。如果不参考协议规范，则无法理解二进制协议消息中的哪个值。

它的广泛性意味着HTTP作为文本协议只是制定了简单的规则，但您可以通过自由添加新的标头或更改内容类型以传输不同的有效负载来扩展数据结构。标头是元数据，具有协商和自动适应的能力。

— 超
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.