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

47

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 .

IQAndreas
la source
3
Parmi les 5 protocoles mentionnés, HTTP, SMTP, WHOIS et IRC ont été principalement conçus pour échanger des données textuelles.
el.pescado
4
Notez que HTTP / 2 est un protocole binaire.
Isanae
4
Vous faites principalement référence aux protocoles de couche application et présentation . Les protocoles de niveau inférieur (TCP, IP, Ethernet) sont presque toujours binaires.
Nick T
2
FTP dispose d’un mode binaire qu’il est très important d’utiliser lors du transfert de fichiers binaires, car le mode de transfert normal de nombreux clients réécrivait les fins de ligne pour correspondre à la convention de l’hôte qui corromprait les fichiers binaires lors du transfert entre hôtes ayant des fins de ligne différentes. Ce mode binaire était uniquement destiné au transfert de fichiers et n'affectait pas les commandes.
casey
2
FTP utilise en réalité deux connexions réseau, une en mode texte (le canal de commande) et un en binaire (le canal de données).
Pseudonyme le

Réponses:

40

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 ...

vonbrand
la source
10
La facilité de dépannage est également grandement améliorée. La lecture d'une capture de paquet est assez difficile, elle est encore pire lorsque les applications n'envoient pas de messages dans un format lisible par l'homme.
Nanban Jim
5
"Et personne de sensé ne suggérera d'extraire tous les protocoles existants pour les remplacer par des protocoles binaires". La compression d'en-tête de demande SPDY fait maintenant partie de HTTP / 2. Ou, d'ailleurs, du HTTP aux types de contenu binaire ou aux encodages de transfert.
Steve Jessop
4
Les protocoles en texte brut vous permettent également d'examiner en toute sécurité des données potentiellement dangereuses ou non fiables. Par exemple, j'utilise telnet lorsque je reçois une tentative de spam / hameçonnage qui, je le garantis pratiquement, ne nuira pas à mon système. Il est essentiel d'avoir un accès texte à un système. Même aujourd'hui, vous remarquerez que HTTP / 1.1 est rarement du "texte brut", car l'en-tête Accept-Encoding permet la compression, prise en charge par la plupart des navigateurs et des serveurs, afin de charger les pages plus rapidement.
phyrfox
Au Vintage Computer Fair du Midwest, j’ai trouvé intéressant que des machines comme l’Altair 680 aient besoin de recevoir du code au format Motorola S-record, qui utilise 76 caractères pour 32 octets de données (44 caractères de surcharge). Même si l’on se limitait à utiliser un ensemble de 41 caractères comme 0-9 AZ + - * / =, il devrait toujours être possible de le réduire à quelque chose de plus proche de 57 caractères (25 caractères de surcharge), ce qui réduirait le temps nécessaire à la sauvegarde. ASR-33 pour alimenter 1K de code de 4 minutes à environ trois. Compte tenu de la lenteur des vitesses d'E / S, je me demande pourquoi cela ne semble pas avoir été fait couramment?
Supercat
24

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.

Naftuli Kay
la source
Si les protocoles avaient d'abord été conçus comme binaires, et non comme un raccourci binaire pour un protocole texte, il pourrait ne pas y avoir de terme communément accepté EHLO. Chaque interface utilisateur utilisable pour le protocole binaire pourrait avoir son propre nom, si la norme binaire ne 0x18nommait pas -in-this-position.
Peter Cordes
10

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) .

bûcheron
la source
3

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.

Tim Pozar
la source
Leçon apprise: Placez une balise de version dans des données binaires.
Peter - Réintégrer Monica le
3

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.

Peter - Réintégrer Monica
la source