为什么有这么多基于文本的互联网协议？

从我发现，一个非常大的量的协议的旅行在互联网上是“基于文本的”，而不是二进制。有问题的协议包括但不限于HTTP，SMTP，FTP（我认为这是全部基于文本的协议），WHOIS，IRC。

实际上，这些协议中的某些协议每当要传输二进制数据时都会跳入某些循环。

这背后有原因吗？基于文本的协议显然会带来一些开销，因为它们需要发送更多的数据来传输相同数量的信息（请参见下面的示例）。有什么好处胜过这个？

通过基于文本的，我的意思是大多数协议中使用的字符是之间0x20（空间）和0x7E（~），与用于偶尔“字调校妥当，” 非常特殊的用途，如换行，空，ETX和EOT。这与通过连接传输原始二进制数据相反。

例如，将整数123456作为文本传输将涉及发送字符串123456（以十六进制表示为31 32 33 34 35 36），而将32位二进制值发送为（以十六进制表示）0x0001E240（如您所见，“包含”特殊的空字符） 。

当世界更年轻，并且计算机并非全都是光荣的PC时，字长各不相同（我们在这里遇到的2020年DEC包含36位字），二进制数据格式是一个有争议的问题（大尾数与小尾数，甚至更奇怪）位的顺序是相当普遍的）。字符大小/编码方面几乎没有共识（ASCII，EBCDIC是主要竞争者，我们的DEC具有5/6/7/8位/字符编码）。ARPAnet（Internet的前身）旨在连接任何类型的计算机。共同点是（现在仍然是）文本。您可以合理地确定7位编码的文本不会被用于传输数据的底层方法所破坏（直到最近，以某种8位编码发送电子邮件才保证了收件人将收到残缺不全的邮件，

如果您在telnet或FTP协议说明（第一个Internet协议，然后是将网络远程连接到“超级计算机”，然后将文件往复移动）中翻阅，您会发现该连接包含很多细节的协商。我们采取统一

是的，二进制将（稍微）更有效率。但是机器和内存（以及网络）已经得到了巨大的发展，所以过去的一点点过去已经成为过去（大部分）。而且没有人会建议删除所有现有协议以将其替换为二进制协议。此外，文本协议提供了一种非常有用的调试技术。今天，我从未安装过telnet服务器（最好使用加密的SSH协议进行远程连接），但是必须方便地telnet客户端才能与一些错误的服务器“对话”以找出故障。今天，您可能会使用netcat或ncat进行搜索...

可以忽略的一项优势是实验能力。如果您将管子往下塞，您将需要编写一些可转换EHLO为0x18或类似内容的实用程序。无需执行此操作，您只需将telnet连接到邮件服务器，然后发送即可EHLO。

在当今时代，没有什么可以阻止您使用Assembly或Brainf * ck编写代码，这样做可能会节省一些时间。但是，如果您对其他人确切说明自己做了什么，以使他们能够理解您的代码并与您的代码进行交互，这并非易事。

使用协议，使用户能够容易地学习如何使用它们非常重要，因为在今天，大多数使用ARPAnet或Internet 起源的人都是在终端后面感到自在的人。

顺便说一下，今天的公司也有类似的争论。我们应该序列化为JSON还是BSON（JSON的二进制表示）？如果您序列化为BSON，则会节省一些开销，但是现在您需要一个转换器将BSON转换为JSON，反之亦然，因为当不可避免地出问题时，人们将不得不在某个时候读取该数据。

并不是很多互联网协议都是基于文本的。实际上，如果我猜到了，我会说基于文本的协议是少数。对于在互联网上看到的几乎所有基于文本的协议，人们至少发明了两种二进制协议来发送相同或相似的数据。

但是，确实，大多数互联网流量使用基于文本的协议。如果您假设二进制协议比文本多得多，但文本流量比二进制多得多，那么这个事实就很有趣。这意味着互联网上大多数成功的协议都是基于文本的。除了少数应用程序（bittorrent是一个例子）之外，二进制协议趋向于消失。

在Internet的早期，公司倾向于设计和使用二进制协议（例如，MSN，而不是今天的MSN网站，最初的专有MicroSoft Network应该替代HTTP），而军事，研究机构和学者则倾向于设计和使用基于文本的协议。部分原因是建立和调试二进制协议很困难，并且公司可以负担得起人们付钱去做，而军人，研究人员和学者却在闲暇时无偿付钱（大多数开发互联网的人都有与发展互联网无关的工作）。

当您在业余时间以业余爱好编写代码并且不因做自己的事情而获得报酬时，您倾向于选择较简单的解决方案-文本。因此，基于文本的协议比二进制协议被更多的人使用。

但这还不是全部。建立网络非常困难。真的很难。今天，我们已经习惯了互联网，因此还没有完全意识到这是工程学的奇迹。互联网的几乎每个方面都是从错误修复演变而来的。例如，我们使用IP地址而不是MAC地址，因为它允许我们构建只有几千字节（或这些天的兆字节）的路由器，而不是用于路由表的TB的RAM。我们尝试解决的问题越来越多，我们越倾向于使用基于文本的协议来调试它们。一旦我们有足够的开发低级网络协议的经验，当开发应用程序协议时，大多数有经验的程序员和工程师就会倾向于使用文本协议。

从个人经验来看，我曾在一家制造路由器的公司工作过，也曾在一家建筑遥测设备的公司工作过，所以我在使用二进制协议（例如TCP / IP，ARP，IEC60870-5-）方面有很多经验。 101和DNP3。我还使用过HTTP，POP3和NMEA等文本协议。我还使用了二进制数据格式（例如ASN.1）和文本数据格式（例如JSON和XML）。如果要选择，我几乎每次都会选择文本。我唯一选择二进制的是协议是否真的是低级的（那么我将实现足够的水平，以便可以在顶部或顶部对基于文本的协议进行定位），或者数据自然是二进制的（例如音频文件） 。

结构化二进制文件在扩展它方面也有局限性。在使用FidoNet并在其与UUCP / USNET之间建立网关的那一天，Fidonet的消息头是结构化的二进制文件。即使只是尝试在某个地方添加一个字节来扩展它，也意味着要破坏尝试使用它的所有内容。具有文本标题或协议意味着您可以扩展某些内容而不会破坏某些内容。

您的问题可以通过三种方式解释：

1. 为什么数字数据以文本形式传输，就像用例如eg打印printf()？
2. 为什么传统的应用程序层协议（例如ftp控制通道，smtp，http）传统上都使用7位ASCII字符集？（7位ASCII可被视为“文本”，因为大多数字节对应于可打印的字形或文本控制代码，例如换行符和feed中的字符。）
3. 为什么二进制数据块通过互联网（例如，作为邮件附件）发送时经常转换为7位ascii？

第一个答案是互操作性。整数和浮点值在不同的机器甚至编译器上，甚至在不同的编译器选项上都具有不同的二进制表示形式。通过有效地传输它们printf/scanf可以简化互操作性。请注意，此选择仅针对上面提到的一些高级协议。在网络层上，数据是二进制传输的。为此，TCP / IP定义了一个二进制整数表示形式，而实现TCP / IP的库提供了使用htonl和朋友在主机表示形式和网络表示形式之间进行转换的方法。

第二个问题的答案可能是RFC 206（请注意，数字很低-1971！）将telnet协议描述为直接电传打字机，它是许多应用层协议所基于的telnet协议

其功能是使在线系统终端出现任何电传兼容，分时系统中的网络就好像它是直接连接到该系统。

（强调原文。）至少某些电传打字机，尤其是电传打字机网络使用7位ASCII作为字符集，这一定使它成为自然选择。

对第三个问题的答案很简单，因为应用层协议是基于telnet的，并且telnet是7位的ascii，所以许多软硬件都不准备处理8位的数据。发送二进制附件可能被视为滥用电子邮件；因此，箍。如今，通常情况已不再如此，协议不断扩展（或简单使用）以直接处理二进制数据。