Pourquoi autant de protocoles Internet sont-ils basés sur du texte?

D'après ce que j'ai trouvé, une très grande quantité de protocoles qui voyagent sur Internet sont "basés sur du texte" plutôt que binaires. Les protocoles en question incluent, mais ne sont pas limités à HTTP, SMTP, FTP (je pense que celui-ci est entièrement basé sur du texte?), WHOIS, IRC.

En fait, certains de ces protocoles sautent à travers des cercles quand ils veulent transmettre des données binaires .

Y a-t-il une raison derrière cela? Les protocoles à base de texte ont évidemment une charge supplémentaire, car ils nécessitent l'envoi de plus de données pour transmettre la même quantité d'informations (voir l'exemple ci-dessous). Quels avantages l'emportent sur cela?

Par texte , j'entends par là que la plupart des caractères utilisés dans le protocole se situent entre 0x20(espace) et 0x7E( ~), avec parfois des "caractères spéciaux" utilisés à des fins très spéciales , telles que les nouvelles lignes, null, ETX et EOT. Ceci est opposé à la transmission de données binaires brutes via la connexion.

Par exemple, transmettre l'entier 123456sous forme de texte impliquerait l'envoi de la chaîne 123456(représentée en hexadécimal par 31 32 33 34 35 36), alors que la valeur binaire sur 32 bits serait envoyée en tant que (représenté en hexadécimal) 0x0001E240(et comme vous pouvez le voir, "contient" le caractère nul spécial .

Lorsque le monde était plus jeune et que les ordinateurs n'étaient pas tous des ordinateurs glorifiés, la taille des mots variait (un DEC 2020 avait ici des mots de 36 bits), le format des données binaires était une question litigieuse (big endian vs little endian, et même plus étrange les ordres de bits étaient raisonnablement communs). Il y avait peu de consensus sur la taille / l’encodage des caractères (ASCII, EBCDIC étaient les principaux candidats, notre DEC avait des encodages 5/6/7/8 bits / caractères). ARPAnet (le prédécesseur Internet) a été conçu pour connecter des machines de toutes sortes. Le dénominateur commun était (et est toujours) le texte. Vous pouvez être raisonnablement certains que le texte codé sur 7 bits ne serait pas compromis par le moyen sous-jacent de transmettre les données (jusqu'à tout récemment, l'envoi d'e-mails avec un codage à 8 bits garantissait que le destinataire recevrait des messages mutilés,

Si vous fouillez dans les descriptions de protocoles telnet ou FTP (par exemple, les premiers protocoles Internet, l'idée du réseau était alors de se connecter à distance à un "superordinateur" et de mélanger les fichiers), vous constaterez que la connexion inclut la négociation de nombreux détails. nous prenons comme uniforme,

Oui, le binaire serait (un peu) plus efficace. Mais les machines et les mémoires (ainsi que les réseaux) ont énormément grandi, de sorte que le resserrement du passé appartient désormais au passé. Et personne sensé ne suggérera d’extraire tous les protocoles existants pour les remplacer par des protocoles binaires. En outre, les protocoles de texte offrent une technique de débogage très utile. Aujourd’hui, je n’installe jamais le serveur telnet (il est préférable d’utiliser le protocole SSH chiffré pour les connexions distantes), mais j’ai besoin d’un client telnet pratique pour "parler" à un serveur errant afin de détecter les problèmes. Aujourd'hui, vous utiliseriez probablement netcat ou ncat pour vos déplacements ...

Un avantage qui peut être négligé est la capacité d' expérimenter . Si vous mettez des morceaux dans le tube, vous devrez écrire un utilitaire qui se traduira EHLOen 0x18ou similaire. Au lieu de faire cela, vous pouvez simplement telnet sur un serveur de messagerie, envoyer EHLOet être sur votre chemin.

De nos jours, rien ne vous empêche d'écrire du code dans Assembly ou Brainf * ck , et vous pourriez très bien économiser quelques bits en le faisant. Cependant, expliquer ce que vous avez fait exactement à quelqu'un d'autre pour lui permettre de comprendre et d'interagir avec votre code ne sera pas chose facile.

Avec les protocoles, il est important que les utilisateurs puissent facilement apprendre à les utiliser, car à l’époque, la plupart des gens qui utilisaient ARPAnet ou les débuts d’Internet étaient des personnes qui se sentaient à l’aise derrière un terminal.

Des arguments similaires, d'ailleurs, se retrouvent dans les entreprises. Devrions-nous sérialiser en JSON ou BSON (représentation binaire de JSON)? Si vous sérialisez en BSON, vous perdez un peu de temps, mais vous avez maintenant besoin d'un traducteur pour convertir votre BSON en JSON et vice-versa, car un humain va devoir lire ces données à un moment donné, lorsque quelque chose se passe inévitablement.

Ce n'est pas que beaucoup de protocoles Internet sont basés sur du texte. En fait, si je devais deviner, je dirais que les protocoles basés sur du texte sont minoritaires. Pour presque tous les protocoles textuels que vous voyez sur Internet, il existe au moins deux protocoles binaires que les gens ont inventés pour envoyer des données identiques ou similaires.

Mais il est vrai que la majorité du trafic Internet utilise des protocoles à base de texte. Ce fait est intéressant si vous supposez qu'il existe beaucoup plus de protocoles binaires que de texte mais beaucoup plus de trafic de texte que de binaire. Cela signifie que la plupart des protocoles réussis sur Internet sont basés sur du texte. À l'exception d'un petit nombre d'applications (bittorrent en est un exemple), les protocoles binaires ont tendance à mourir.

Dans les premiers temps d'Internet, les entreprises avaient tendance à concevoir et à utiliser un protocole binaire (MSN par exemple, et non le site Web de MSN d'aujourd'hui, le réseau propriétaire exclusif MicroSoft, censé remplacer HTTP), tandis que l'armée, les instituts de recherche et les universitaires avaient tendance à: concevoir et utiliser un protocole textuel. Une partie de la raison était qu’il était difficile de créer et de déboguer des protocoles binaires et que les entreprises pouvaient se permettre de payer les gens pour le faire, tandis que l’armée, les chercheurs et les universitaires le faisaient pendant leurs temps libres et sans salaire (la plupart des développeurs d’Internet avaient emplois non liés au développement d’Internet).

Quand vous écrivez du code la fin de semaine comme passe-temps et que vous n'êtes pas payé pour faire ce que vous faites, vous avez tendance à choisir la solution la plus simple: le texte. Les protocoles basés sur du texte ont donc été utilisés par plus de personnes que les protocoles binaires.

Mais ce n'est pas l'histoire complète. Construire un réseau est difficile. Vraiment dur. Nous sommes tellement habitués à Internet aujourd'hui que nous ne réalisons pas à quel point c'est un miracle de l'ingénierie. Presque tous les aspects d'Internet ont évolué à partir d'un correctif. Par exemple, nous utilisons l'adresse IP au lieu de l'adresse MAC, car elle nous permet de créer des routeurs avec seulement des kilo-octets (ou des mégaoctets de nos jours) au lieu de téraoctets de RAM pour la table de routage. Plus nous essayons de résoudre les problèmes, plus nous avons tendance à préférer les protocoles texte pour les déboguer. Une fois que nous avions suffisamment d'expérience dans le développement de protocoles réseau de bas niveau, lorsque le moment est venu de développer des protocoles d'application, la plupart des programmeurs et ingénieurs expérimentés ont eu tendance à préférer les protocoles de texte.

De par mon expérience personnelle, j'ai travaillé pour une entreprise de construction de routeurs et pour une entreprise de construction d'équipements de télémétrie. J'ai donc beaucoup d'expérience dans l'utilisation de protocoles binaires tels que TCP / IP, ARP, IEC60870-5- 101 et DNP3. J'ai également travaillé avec des protocoles de texte tels que HTTP, POP3 et NMEA. J'ai également travaillé avec des formats de données binaires tels que ASN.1 et des formats de données texte tels que JSON et XML. Si je devais choisir, je choisirais le texte presque à chaque fois. La seule fois où je choisirais le binaire, c’est si le protocole est vraiment de bas niveau (alors j’en implémente juste assez pour pouvoir utiliser un protocole basé sur du texte par dessus) ou si les données sont naturellement binaires (comme des fichiers audio) .

Le binaire structuré a aussi des limites pour l'élargir. Au cours de mes journées avec FidoNet et la construction d’une passerelle entre lui et UUCP / USNET, les en-têtes de messages de Fidonet étaient un binaire structuré. Le développer en essayant simplement d'ajouter un octet quelque part signifie casser tout ce qui est en train d'essayer de fonctionner avec. Avoir un en-tête de texte ou un protocole signifie que vous pouvez développer quelque chose sans casser des choses.

Votre question peut être interprétée de trois manières:

1. Pourquoi les données numériques sont-elles transmises sous forme de représentation textuelle, comme si elles avaient été imprimées avec, par exemple printf()?
2. Pourquoi les protocoles de couche d'application classiques - par exemple, le canal de contrôle ftp, smtp, http - utilisent-ils tous traditionnellement un jeu de caractères ASCII 7 bits? (L'ASCII 7 bits peut être considéré comme du "texte" car la plupart des octets correspondent à des glyphes imprimables ou à des codes de contrôle de texte tels que newline et from feed.)
3. Pourquoi les blobs de données binaires sont-ils souvent convertis en ascii 7 bits lorsqu'ils sont envoyés sur Internet, par exemple sous forme de pièce jointe à un courrier?

La réponse à la première est l'interopérabilité. Les entiers et les valeurs à virgule flottante ont différentes représentations binaires sur différentes machines, voire même des compilateurs, ou même avec des options de compilateur différentes. Leur transmission efficace via printf/scanffacilite l’interopérabilité. Notez que ce choix n’a été fait que pour les protocoles de niveau supérieur dont quelques-uns sont mentionnés ci-dessus; sur la couche réseau, les données sont transmises de manière binaire. Pour cela, TCP / IP définit une représentation sous forme d’entier binaire et les bibliothèques implémentées sous TCP / IP offrent un moyen de convertir les représentations d’hôte et de réseau avec les htonlamis.

La réponse à la deuxième question est probablement que la RFC 206 (notez le numéro bas - 1971!) Décrit le protocole telnet, sur lequel de nombreux protocoles de couche d’application sont basés, comme remplacement direct par télétype.

dont la fonction est de faire en sorte qu'un terminal du système en ligne apparaisse sur tout système à partage de temps compatible avec un télétype sur le réseau, comme s'il était directement connecté à ce système .

(Souligné dans le texte d'origine.) Au moins certains télétypes, et en particulier les réseaux de télétypes, utilisaient un jeu de caractères ASCII 7 bits, qui devait en faire un choix naturel.

La réponse à la troisième est simplement que, comme les protocoles de couche d’application sont basés sur telnet et que telnet est en ascii 7 bits, la plupart des logiciels et du matériel n’étaient pas prêts à traiter des données 8 bits . L'envoi de pièces jointes binaires peut être considéré comme une mauvaise utilisation du courrier électronique. d'où les cerceaux. Aujourd'hui, ce n'est généralement plus le cas et les protocoles sont continuellement étendus (ou simplement utilisés) pour traiter directement des données binaires.