¿Por qué hay tantos protocolos de Internet basados ​​en texto?

Por lo que he encontrado, una muy gran cantidad de protocolos que los viajes en internet son "basado en texto," en lugar de binario. Los protocolos en cuestión incluyen, entre otros, HTTP, SMTP, FTP (¿creo que este está basado en texto?), WHOIS, IRC.

De hecho, algunos de estos protocolos saltan algunos aros cuando quieren transmitir datos binarios .

¿Hay alguna razón detrás de esto? Los protocolos basados ​​en texto obviamente tienen un poco de sobrecarga, ya que requieren enviar más datos para transmitir la misma cantidad de información (ver el ejemplo a continuación). ¿Qué beneficios superan esto?

Por texto , me refiero a que la mayoría de los caracteres utilizados en el protocolo están entre 0x20(espacio) y 0x7E( ~), con el ocasional "carácter especial" utilizado para fines muy especiales , como las líneas nuevas, nulo, ETX y EOT. Esto se opone a transmitir datos binarios sin procesar a través de la conexión.

Por ejemplo, transmitir el entero 123456como texto implicaría enviar la cadena 123456(representada en hexadecimal como 31 32 33 34 35 36), mientras que el valor binario de 32 bits se enviaría como (representado en hexadecimal) 0x0001E240(y como puede ver, "contiene" el carácter nulo especial .

Cuando el mundo era más joven, y las computadoras no eran todas PC glorificadas, el tamaño de las palabras variaba (un DEC 2020 que teníamos aquí tenía palabras de 36 bits), el formato de datos binarios era un tema polémico (big endian vs little endian, e incluso más extraño) las órdenes de bits eran razonablemente comunes). Hubo poco consenso sobre el tamaño / codificación de caracteres (ASCII, EBCDIC fueron los principales contendientes, nuestro DEC tenía codificaciones de 5/6/7/8 bits / carácter). ARPAnet (el predecesor de Internet) fue diseñado para conectar máquinas de cualquier descripción. El denominador común era (y sigue siendo) texto. Puede estar razonablemente seguro de que el texto codificado de 7 bits no se alterará por los medios subyacentes para enviar datos (hasta hace muy poco, el envío de correo electrónico en una codificación de 8 bits tenía la garantía de que el destinatario recibiría mensajes mutilados,

Si revisa, por ejemplo, las descripciones de los protocolos telnet o FTP (los primeros protocolos de Internet, la idea de la red era conectarse de forma remota a una "supercomputadora" y mezclar archivos de aquí para allá), verá que la conexión incluye la negociación de muchos detalles tomamos como uniforme

Sí, el binario sería (un poco) más eficiente. Pero las máquinas y los recuerdos (y también las redes) han crecido enormemente, por lo que el poco trabajo de antaño es cosa del pasado (principalmente). Y nadie en su sano juicio sugerirá eliminar todos los protocolos existentes para reemplazarlos con los binarios. Además, los protocolos de texto ofrecen una técnica de depuración muy útil. Hoy nunca instalo el servidor Telnet (mejor uso el protocolo SSH encriptado para conexiones remotas), pero tengo que tener a mano al cliente Telnet para "hablar" con algún servidor errante para resolver problemas. Hoy probablemente usarías netcat o ncat para holgazanear ...

Una ventaja que podría pasarse por alto es la capacidad de experimentar . Si está empujando pedazos por el tubo, necesitará escribir alguna utilidad que se traduzca EHLOen algo 0x18similar. En lugar de hacerlo, puede simplemente hacer telnet en un servidor de correo, enviar EHLOy estar en camino.

Nada le impide hoy en día escribir código en Assembly o Brainf * ck , y podría ahorrar algunos bits al hacerlo. Sin embargo, explicarle exactamente lo que le ha hecho a otra persona para que pueda entender e interactuar con su código no será fácil si lo hace.

Con los protocolos, es importante que los usuarios puedan aprender fácilmente cómo usarlos, ya que la mayoría de las personas que usaban ARPAnet o el comienzo de Internet eran personas que se sentían cómodas detrás de un terminal.

Argumentos similares, por cierto, se mantienen hoy en las empresas. ¿Deberíamos serializar a JSON o BSON (representación binaria de JSON)? Si serializa a BSON, arroja algo de sobrecarga, pero ahora necesita un traductor para convertir su BSON en JSON y viceversa, ya que un humano tendrá que leer esos datos en algún momento cuando algo inevitablemente salga mal.

No es que muchos protocolos de Internet estén basados ​​en texto. De hecho, si tuviera que adivinar, diría que los protocolos basados ​​en texto son minoritarios. Para casi todos los protocolos basados ​​en texto que ve en Internet, existen al menos dos protocolos binarios que la gente ha inventado para enviar los mismos datos o datos similares.

Pero es cierto que la mayoría del tráfico de Internet utiliza protocolos basados ​​en texto. Este hecho es interesante si supone que hay muchos más protocolos binarios que el texto pero mucho más tráfico de texto que el binario. Significa que la mayoría de los protocolos exitosos en Internet están basados ​​en texto. Excepto por un pequeño número de aplicaciones (bittorrent es un ejemplo), los protocolos binarios tienden a morir.

En los primeros días de Internet, las corporaciones tendían a diseñar y usar protocolos binarios (MSN, por ejemplo, no el sitio web de MSN de hoy, la red propietaria original de MicroSoft que se suponía que reemplazaría a HTTP), mientras que los militares, los institutos de investigación y los académicos tendían a diseñar y usar un protocolo basado en texto. Parte de la razón fue que construir y depurar protocolos binarios era difícil y las corporaciones pueden permitirse el lujo de pagarle a la gente para que lo haga mientras que los militares, investigadores y académicos lo hacían en su tiempo libre sin pagar (la mayoría de las personas que desarrollaron Internet tenían trabajos no relacionados con el desarrollo de internet).

Cuando escribe código los fines de semana como un pasatiempo y no se le paga por hacer lo que hace, tiende a elegir la solución más simple: el texto. Entonces, los protocolos basados ​​en texto fueron utilizados por más personas que los protocolos binarios.

Pero esa no es la historia completa. Construir una red es difícil. Realmente difícil. Hoy estamos tan acostumbrados a Internet que no nos damos cuenta del milagro de la ingeniería. Casi todos los aspectos de Internet evolucionaron a partir de una corrección de errores. Por ejemplo, usamos la dirección IP en lugar de la dirección MAC porque nos permite construir enrutadores con solo kilobytes (o estos megabytes) en lugar de terabytes de RAM para la tabla de enrutamiento. Mientras más y más problemas intentamos resolver, más preferimos los protocolos basados ​​en texto para depurarlos. Una vez que tuvimos suficiente experiencia en el desarrollo de protocolos de red de bajo nivel, cuando llegó el momento de desarrollar protocolos de aplicación, la mayoría de los programadores e ingenieros experimentados solían preferir los protocolos de texto.

Por experiencia personal, trabajé para una empresa que construye enrutadores y también para una empresa que construye equipos de telemetría, por lo que tengo mucha experiencia trabajando con protocolos binarios como TCP / IP, ARP, IEC60870-5- 101 y DNP3. También he trabajado con protocolos de texto como HTTP, POP3 y NMEA. También he trabajado con formatos de datos binarios como ASN.1 y formatos de datos de texto como JSON y XML. Si tuviera que elegir, elegiría texto casi siempre. La única vez que elegiría el binario es si el protocolo es realmente de bajo nivel (entonces implementaría lo suficiente para poder colocar un protocolo basado en texto en la parte superior) o si los datos son naturalmente binarios (como archivos de audio) .

El binario estructurado también tiene limitaciones para expandirlo. En mis días de trabajar con FidoNet y construir una puerta de enlace entre UUCP / USNET, los encabezados de mensajes de Fidonet eran un binario estructurado. Expandirlo incluso tratando de agregar un byte en algún lugar significa romper todo lo que está tratando de funcionar con él. Tener un encabezado de texto o protocolo significa que puede expandir algo sin romper cosas.

Su pregunta se puede interpretar de tres maneras:

1. ¿Por qué los datos numéricos se transmiten en representación textual, como si se hubieran impreso con, por ejemplo printf()?
2. ¿Por qué los protocolos de capa de aplicación clásicos, por ejemplo, el canal de control ftp, smtp, http, tradicionalmente usan un conjunto de caracteres ASCII de 7 bits? (El ASCII de 7 bits se puede considerar "texto" porque la mayoría de los bytes corresponden a glifos imprimibles o códigos de control de texto como la nueva línea y el feed).
3. ¿Por qué los blobs de datos binarios a menudo se convierten en ascii de 7 bits cuando se envían a través de Internet, por ejemplo, como un archivo adjunto de correo?

La respuesta a la primera es la interoperabilidad. Los enteros y los valores de coma flotante tienen diferentes representaciones binarias en diferentes máquinas, o incluso compiladores, o incluso con diferentes opciones de compilación. Transmitirlos de manera efectiva printf/scanffacilita la interoperabilidad. Tenga en cuenta que esta elección solo se hizo para los protocolos de nivel superior de los cuales se mencionan algunos anteriormente; en la capa de red, los datos se transmiten binariamente. Para esto, TCP / IP define una representación entera binaria, y las bibliotecas que implementan TCP / IP proporcionan medios para convertir entre representaciones de host y red con htonly amigos.

La respuesta a la segunda pregunta es probablemente que RFC 206 (¡tenga en cuenta el número bajo - 1971!) Describe el protocolo telnet, en el que se basan muchos protocolos de capa de aplicación, como un reemplazo directo de teletipo

cuya función es hacer que un terminal del sistema en línea aparezca en cualquier sistema de tiempo compartido compatible con el teletipo en la red como si estuviera conectado directamente a ese sistema .

(Énfasis en el texto original.) Al menos algunos teletipos y en particular redes de teletipos utilizaron ASCII de 7 bits como el conjunto de caracteres que debe haberlo hecho una elección natural.

La respuesta a la tercera es simplemente que debido a que los protocolos de la capa de aplicación están basados ​​en telnet y telnet es de 7 bits ascii, mucho software y hardware no estaba preparado para manejar datos de 8 bits . Enviar archivos adjuntos binarios podría considerarse un mal uso del correo electrónico; De ahí los aros. Hoy en día eso ya no es cierto y los protocolos se extienden continuamente (o simplemente se usan) para manejar directamente los datos binarios.