Por que tantos protocolos da Internet são baseados em texto?

Pelo que descobri, uma quantidade muito grande de protocolos que viajam pela Internet são "baseados em texto" e não binários. Os protocolos em questão incluem, mas não estão limitados a HTTP, SMTP, FTP (acho que este é todo baseado em texto?), WHOIS, IRC.

De fato, alguns desses protocolos passam por alguns obstáculos sempre que eles desejam transmitir dados binários .

Existe uma razão por trás disso? Os protocolos baseados em texto obviamente têm um pouco de sobrecarga, pois exigem o envio de mais dados para transmitir a mesma quantidade de informações (veja o exemplo abaixo). Quais benefícios superam isso?

Por texto , quero dizer que a maioria dos caracteres usados ​​no protocolo está entre 0x20(espaço) e 0x7E( ~), com o ocasional "caráter especial" usado para fins muito especiais , como as novas linhas, null, ETX e EOT. Isso se opõe à transmissão de dados binários brutos pela conexão.

Por exemplo, transmitir o número inteiro 123456como texto envolveria o envio da string 123456(representada em hexadecimal como 31 32 33 34 35 36), enquanto o valor binário de 32 bits seria enviado como (representado em hexadecimal) 0x0001E240(e como você pode ver, "contém" o caractere nulo especial .

Quando o mundo era jovem, e os computadores não eram todos PCs glorificados, o tamanho das palavras variava (um DEC 2020 que tínhamos por aqui tinha palavras de 36 bits), o formato dos dados binários era um problema controverso (big endian vs little endian e ainda mais estranho ordens de bits eram razoavelmente comuns). Houve pouco consenso sobre o tamanho / codificação de caracteres (ASCII, EBCDIC foram os principais concorrentes, nosso DEC teve 5/6/7/8 bits / codificação de caracteres). O ARPAnet (o antecessor da Internet) foi projetado para conectar máquinas de qualquer descrição. O denominador comum era (e ainda é) texto. Você pode estar razoavelmente certo de que o texto codificado em 7 bits não será confundido pelos meios subjacentes para enviar dados (até muito recentemente, o envio de email em uma codificação em 8 bits garantia que o destinatário receberia mensagens mutiladas,

Se você vasculhar, por exemplo, as descrições dos protocolos telnet ou FTP (os primeiros protocolos da Internet, a idéia da rede era conectar-se remotamente a um "supercomputador" e embaralhar arquivos para lá e para cá), você verá que a conexão inclui muitos detalhes sobre a negociação. tomamos como uniforme,

Sim, o binário seria (um pouco) mais eficiente. Mas as máquinas e as memórias (e também as redes) cresceram enormemente; portanto, o pouco esforço de outrora é coisa do passado (principalmente). E ninguém em sã consciência sugerirá retirar todos os protocolos existentes para substituí-los por binários. Além disso, os protocolos de texto oferecem uma técnica de depuração muito útil. Hoje nunca instalo o servidor de telnet (use melhor o protocolo SSH criptografado para conexões remotas), mas preciso do cliente de telnet à mão para "conversar" com algum servidor errante para descobrir problemas. Hoje você provavelmente usaria netcat ou ncat para futzing por aí ...

Uma vantagem que pode ser esquecida é a capacidade de experimentar . Se você estiver empurrando pedaços no tubo, precisará escrever algum utilitário que se traduza EHLOem algo 0x18parecido. Em vez de fazer isso, você pode simplesmente telnetar em um servidor de email, enviar EHLOe seguir seu caminho.

Atualmente , nada impede você de escrever código em Assembly ou Brainf * ck , e você pode economizar alguns bits ao fazer isso. No entanto, explicar o que exatamente você fez com outra pessoa para que ela possa entender e interagir com seu código não será fácil se você o fizer.

Com os protocolos, é importante que os usuários aprendam prontamente como usá-los, pois a maioria das pessoas que usavam o ARPAnet ou o início da Internet eram pessoas que se sentiam confortáveis ​​atrás de um terminal.

Argumentos semelhantes, a propósito, são mantidos nas empresas hoje. Devemos serializar para JSON ou BSON (representação binária de JSON)? Se você serializa para BSON, perde algumas despesas, mas agora precisa de um tradutor para converter seu BSON em JSON e vice-versa, pois um humano precisará ler esses dados em algum momento quando algo inevitavelmente der errado.

Não é que muitos protocolos da Internet sejam baseados em texto. De fato, se eu adivinhasse, diria que os protocolos baseados em texto são minoria. Para quase todos os protocolos baseados em texto que você vê na Internet, existem pelo menos dois protocolos binários que as pessoas inventaram para enviar dados iguais ou semelhantes.

Mas é verdade que a maioria do tráfego da Internet usa protocolos baseados em texto. Esse fato é interessante se você assumir que há muito mais protocolos binários que texto, mas muito mais tráfego de texto que binário. Isso significa que a maioria dos protocolos de sucesso na Internet são baseados em texto. Exceto por um pequeno número de aplicações (o exemplo bittorrent), os protocolos binários tendem a morrer.

Nos primórdios da Internet, as empresas tendiam a projetar e usar o protocolo binário (MSN, por exemplo, não o site do MSN de hoje, a MicroSoft Network proprietária original que deveria substituir o HTTP) enquanto os militares, institutos de pesquisa e acadêmicos tendiam a projetar e usar protocolo baseado em texto. Parte do motivo foi que a construção e a depuração de protocolos binários eram difíceis e as empresas podem pagar as pessoas para fazê-lo enquanto militares, pesquisadores e acadêmicos o faziam em seu tempo livre sem pagamento (a maioria das pessoas que desenvolveu a Internet tinha empregos não relacionados ao desenvolvimento da internet).

Quando você escreve código nos fins de semana como hobby e não é pago por fazer o que faz, costuma escolher a solução mais simples - texto. Portanto, protocolos baseados em texto foram usados ​​por mais pessoas do que protocolos binários.

Mas essa não é a história completa. Construir uma rede é difícil. Muito difícil. Hoje estamos tão acostumados à internet que não percebemos completamente o milagre da engenharia. Quase todos os aspectos da Internet evoluíram a partir de uma correção de bug. Por exemplo, usamos o endereço IP em vez do endereço MAC, porque nos permite construir roteadores com apenas kilobytes (ou megabytes atuais) em vez de terabytes de RAM para a tabela de roteamento. Quanto mais problemas tentamos resolver, mais tendemos a preferir protocolos baseados em texto para depurá-los. Quando tivemos experiência suficiente no desenvolvimento de protocolos de rede de baixo nível, quando chegou a hora de desenvolver protocolos de aplicativos, a maioria dos programadores e engenheiros experientes tendia a preferir protocolos de texto.

Por experiência pessoal, trabalhei para uma empresa construindo roteadores e também para uma empresa construindo equipamentos de telemetria, por isso tenho muita experiência trabalhando com protocolos binários como TCP / IP, ARP, IEC60870-5- 101 e DNP3. Também trabalhei com protocolos de texto como HTTP, POP3 e NMEA. Também trabalhei com formatos de dados binários, como ASN.1, e formatos de dados de texto, como JSON e XML. Se eu escolhesse, escolheria o texto quase sempre. A única vez em que eu escolheria o binário é se o protocolo é realmente de nível baixo (então eu implementaria apenas o suficiente para que eu possa plonk um protocolo baseado em texto por cima ou por cima) ou se os dados são naturalmente binários (como arquivos de áudio) .

O binário estruturado também tem limitações em expandi-lo. Nos meus dias de trabalho com a FidoNet e a construção de um gateway entre ela e a UUCP / USNET, os cabeçalhos de mensagens da Fidonet eram um binário estruturado. Expandi-lo, apenas tentando adicionar um byte em algum lugar, significa quebrar tudo o que está tentando trabalhar com ele. Ter um cabeçalho ou protocolo de texto significa que você pode expandir algo sem quebrar as coisas.

Sua pergunta pode ser interpretada de três maneiras:

1. Por que os dados numéricos são transmitidos na representação textual, como se tivessem sido impressos com, por exemplo printf()?
2. Por que os protocolos clássicos da camada de aplicação - por exemplo, o canal de controle ftp, smtp, http - tradicionalmente usam um conjunto de caracteres ASCII de 7 bits? (O ASCII de 7 bits pode ser considerado "texto" porque a maioria dos bytes corresponde a glifos imprimíveis ou códigos de controle de texto, como nova linha e feed.)
3. Por que os blobs de dados binários geralmente são convertidos para ascii de 7 bits quando são enviados pela Internet, por exemplo, como um anexo de email?

A resposta para a primeira é a interoperabilidade. Valores inteiros e de ponto flutuante têm representações binárias diferentes em máquinas diferentes, ou mesmo compiladores, ou mesmo com apenas opções diferentes de compilador. Transmiti-los efetivamente via printf/scanffacilita a interoperabilidade. Observe que essa escolha foi feita apenas para os protocolos de nível superior, dos quais alguns são mencionados acima; na camada de rede, os dados são transmitidos binariamente. Para isso, o TCP / IP define uma representação inteira binária e as bibliotecas que implementam o TCP / IP fornecem meios para converter entre representações de host e de rede com htonle amigos.

A resposta para a segunda pergunta é provavelmente que o RFC 206 (observe o número baixo - 1971!) Descreve o protocolo telnet, no qual muitos protocolos da camada de aplicação se baseiam, como uma substituição direta do teletipo

cuja função é fazer com que um terminal do sistema online apareça em qualquer sistema de compartilhamento de tempo compatível com teletipo na rede como se estivesse diretamente conectado a esse sistema .

(Ênfase no texto original.) Pelo menos alguns teletipos e, em particular, redes de teletipo usavam ASCII de 7 bits como o conjunto de caracteres que deve ter feito dele uma escolha natural.

A resposta para a terceira é simplesmente que, como os protocolos da camada de aplicação são baseados em telnet e o telnet é de 7 bits ascii, muito software e hardware não estavam preparados para lidar com dados de 8 bits . O envio de anexos binários pode ser considerado um uso indevido de email; daí os aros. Hoje, isso geralmente não é mais verdade e os protocolos são continuamente estendidos (ou simplesmente usados) para manipular diretamente dados binários.