Résumé

  • Dans la RFC 914, un caractère Telnet voyage dans 41 octets de TCP/IP. Sur une ligne à 1 200 bauds, les auteurs évaluent sa transmission à environ 0,3 seconde, soit un débit utile proche de 30 bauds pour ces caractères isolés.
  • Thinwire I et II ramènent l'exemple à 17 puis 13 octets. Thinwire III transfère les tâches réseau à une passerelle et promet, dans le calcul de la RFC, un débit utile moyen de l'ordre de 900 bauds. Le gain change la place de l'ordinateur dans le réseau.

Une machine assez bon marché pour quitter la salle informatique, une ligne trop étroite pour ses habitudes : voilà la rencontre peu romantique que décrit la RFC 914. David Farber, Gary Delp et Thomas Conte voient arriver des ordinateurs personnels de 3 000 à 10 000 dollars. Les lignes dédiées à 56k coûtent cher et demandent du temps. Les modems téléphoniques à 1 200 ou 2 400 bauds, eux, sont à portée de main. La tentation d'ouvrir Internet à ces machines est évidente. Le paquet qui suit chaque frappe l'est moins : un octet utile, quarante octets de protocole.

On croirait envoyer une carte postale avec tout le bureau de poste accroché derrière.

Les auteurs chiffrent ce poids. À 1 200 bauds, leur paquet Telnet minimal de 41 octets occupe environ 0,3 seconde de ligne. Rapporté au caractère transmis, le résultat ressemble à une liaison de 30 bauds. Leur calcul suppose que la ligne seule limite la vitesse et se comporte comme une liaison synchrone. Les interruptions, le traitement et le cadrage peuvent allonger le temps de 10 à 50 %. L'écho local et l'édition de ligne soulagent certains usages, mais une application qui exige une transmission caractère par caractère présente de nouveau l'addition.

Le modem ne ralentit pas l'alphabet; il transporte toute une procédure autour de chaque lettre.

Premier remède : Thinwire I garde en mémoire le paquet précédent aux deux bouts. Au lieu de renvoyer un paquet entier, l'émetteur indique les positions et les quantités d'octets à remplacer. Dans l'exemple, la mise à jour typique ne prend plus que 17 octets, pour environ 70 bauds utiles selon la RFC. C'est une économie élégante tant que les paquets se ressemblent. Si plusieurs classes de trafic se succèdent, le modèle unique perd son air de famille et la compression se dégrade. Le truc marche; le trafic, lui, ne signe aucune promesse de rester uniforme.

Thinwire II prend cette objection au sérieux. Il classe les paquets par connexion TCP et conserve un modèle pour chacune. Un champ de bits annonce les champs d'en-tête modifiés; de petites différences remplacent de longues valeurs répétées. L'exemple tombe à 13 octets, soit environ 95 bauds utiles pour les caractères isolés. Ce gain exige de la mémoire sur le PC et des tables de connexions sur la passerelle. Si les deux représentations divergent, le flux s'arrête. Il faut détecter l'erreur, fiabiliser la liaison série et renvoyer périodiquement un paquet complet pour se resynchroniser.

Les protocoles inconnus du compresseur passent sans réduction. Les octets économisés sur le fil réapparaissent en état partagé et en discipline de récupération.

Thinwire III change de métier. Le PC cesse de gérer directement toutes les tâches de transport et de réseau pour ses conversations distantes. Une passerelle centrale ouvre les connexions TCP ou UDP à sa demande; sur le fil série, une seule liaison fiable transporte données et commandes multiplexées. Les auteurs estiment un débit utile moyen proche de 900 bauds. Mais cette passerelle devient l'agent Internet du PC. Elle ouvre les connexions vers l'extérieur. Le PC peut demander une ouverture passive sur la passerelle pour offrir un service; une arrivée spontanée ne peut pas simplement atteindre le PC comme un hôte Internet ordinaire.

La ligne maigrit, tandis que le point d'intermédiation grossit.

Le choix se lit désormais autrement qu'en nombres. Thinwire I économise un peu de trafic avec peu de mémoire. Thinwire II économise davantage en faisant tenir deux mémoires d'accord. Thinwire III promet un saut de vitesse en installant la passerelle au cœur de la conversation. Si cette dernière manque de capacité ou ne prend pas en charge un service, le PC en ressent immédiatement la limite. La notice du RFC Editor classe aujourd'hui le texte comme historique. En septembre 1984, ses auteurs proposaient une discussion, pas une norme. Ils avaient néanmoins posé une question durable : à qui remet-on le travail que la ligne refuse de porter ?