Summary

  • RFC 1692 proposait de réunir plusieurs petits segments Telnet ou Rlogin destinés au même hôte dans un datagramme IP, afin de réduire le travail lié au nombre de paquets.
  • Le regroupement cachait les ports TCP aux routeurs qui filtraient sur ce critère. Le texte leur demandait de bloquer TMux ou d'examiner chaque segment intérieur. RFC 4450 a ensuite classé TMux Historic.

Un caractère tapé, un paquet envoyé. Multipliez le geste par les sessions d'un serveur de terminaux : le compteur de bits reste modeste, celui des interruptions de l'hôte s'emballe. Les auteurs de RFC 1692, publié en août 1994, soulignaient qu'un paquet d'un octet demandait presque autant de traitement à l'hôte qu'un paquet de 1 500 octets. Ils décrivaient une limite mesurée en paquets par seconde, que le débit en bits pouvait dissimuler.

La solution TMux visait les nombreux échanges Telnet et Rlogin allant d'un serveur vers quelques hôtes. Au lieu d'un datagramme IP pour chaque petit segment, l'émetteur en réunissait plusieurs sous un seul en-tête IP. Devant chaque segment, un mini-en-tête de quatre octets indiquait la longueur et le protocole d'origine, avec un contrôle simple de ce mini-en-tête. Le datagramme extérieur portait le numéro de protocole 18. À l'arrivée, le destinataire séparait les segments et les remettait à TCP ou UDP. Les applications continuaient de voir leurs échanges ordinaires.

Le paquet commun n'apparaissait pas immédiatement. Un minuteur démarrait au premier segment ; ceux arrivés avant son expiration partageaient l'envoi. Les auteurs suggéraient 20 à 30 millisecondes, configurables, et plaçaient la limite probable vers un dixième de seconde pour préserver la réactivité du terminal. Un tampon plein partait sans attendre. Les segments plus grands, par exemple au-delà de 700 octets, devaient plutôt voyager seuls. Une faible charge pouvait donc rendre l'emballage absurde : un seul segment y gagnait surtout le temps passé dans le tampon.

Il fallait encore vérifier que l'autre hôte savait ouvrir l'enveloppe. Un paquet TMux valide reçu en retour pouvait faire preuve de capacité. Pour amorcer l'échange, le RFC prévoyait une requête ENQ vide avec le protocole 18 ; sans réponse, les essais s'espaçaient. Les datagrammes ordinaires pouvaient circuler pendant cette attente. Une capacité mémorisée expirait, car un redémarrage pouvait changer le logiciel du destinataire.

Le chapitre consacré à la sécurité retirait au lecteur toute envie de confondre économie et gratuité. Un routeur qui filtre les connexions selon les ports TCP ne voit que le protocole 18 à l'extérieur. Les ports sont dans les segments emballés. Des segments plus volumineux de la même connexion peuvent passer seuls et être jugés selon d'autres informations. RFC 1692 prescrivait donc à un routeur filtrant par port mais incapable de lire TMux de bloquer ces datagrammes dans les deux sens. Un routeur compatible pouvait ouvrir le paquet, vérifier chaque segment et écarter ceux qui échouaient au filtre.

Le projet avait commencé comme Proposed Standard. Lors d'une revue menée en 2004 et 2005, la communauté a examiné si les anciens projets seraient encore implémentés ou maintenus. RFC 4450 a rangé TMux parmi ceux devenus Historic, statut repris par le RFC Editor. L'histoire tient dans cette transaction : moins de paquets à traiter pour l'hôte, moins de détails visibles pour le routeur chargé de décider ce qui passe.

Sources