Résumé

  • RFC 872 contestait l'idée qu'un lien local, rapide et peu sujet aux erreurs rendait TCP trop lourd par nature. Les besoins de l'application décidaient des services à fournir entre les machines.
  • Padlipsky admettait l'intérêt d'UDP ou d'un accès direct aux ressources locales selon l'usage ; entretenir une seconde pile de protocoles réservée au réseau local avait aussi un prix.

Un câble court peut faire croire qu'un protocole fiable arrive avec trop de bagages. Dans la RFC 872, publiée en septembre 1982, Michael A. Padlipsky regardait ce qu'il y avait dans la valise. La méfiance envers « TCP sur un réseau local » se répétait de conversation en conversation. Il l'a comparée au Woozle, une créature qu'on croit découvrir en suivant des traces qu'on a laissées soi-même. Son texte avait de l'humour ; il visait surtout une erreur de raisonnement très concrète.

Il fallait d'abord définir le réseau local en cause. Pour Padlipsky, c'était un sous-réseau de communication à courte portée, à débit élevé et à faible taux d'erreur, qui reliait des ordinateurs éventuellement différents afin qu'ils partagent des ressources. Le câble pouvait être de plusieurs sortes ; la topologie aussi. Ce qui comptait était la conversation entre machines. Un ensemble de terminaux accédant chacun à un hôte, sans véritable protocole entre ces hôtes, relevait chez lui d'une autre catégorie. La vitesse des bits sur le lien disait peu de choses sur le dialogue qu'une application attendait de son voisin.

TCP apportait à ce dialogue une connexion logique fiable, avec contrôle de flux et livraison ordonnée. Un transfert de fichier gardait ses besoins même si son destinataire se trouvait dans le bâtiment d'à côté. Le voisinage pouvait rendre le lien plus propre et plus rapide. Il ne décidait pas, à la place du programme, si un octet manquant ou une arrivée dans le désordre était acceptable. La fonction demandée par l'application restait le point de départ.

L'autre pièce de la démonstration était IP. Padlipsky séparait ce protocole de TCP au lieu de traiter les deux comme un bloc indivisible. IP déterminait si la destination se trouvait sur le réseau proche ou exigeait le passage par une passerelle ; il composait avec des tailles de paquets différentes et remettait les données au protocole supérieur concerné. Cette fonction pouvait servir à d'autres protocoles entre hôtes. Quand la même machine devait communiquer au-delà de son réseau local, le premier tronçon rapide faisait partie d'un trajet bien plus vaste.

La petite distance jusqu'au câble n'effaçait pas la suite du voyage.

Il y avait des choix. Une application de parole découpée en paquets pouvait préférer une voie rapide à la fiabilité de TCP ; la RFC citait UDP dans ce rôle. Une application conçue pour une seule installation pouvait exploiter directement certaines facilités locales. Padlipsky comptait néanmoins le coût d'une suite supplémentaire : il fallait l'écrire, la vérifier, puis la maintenir à côté de TCP/IP si les machines devaient également joindre le réseau étendu. Un gain imaginé sur le fil pouvait devenir une charge réelle dans l'atelier logiciel. On pouvait sortir le monstre du dessin sans construire deux maisons pour l'éviter.

La question des performances méritait un examen sérieux. Sur un lien où les erreurs étaient rares, la somme de contrôle TCP semblait à certains superflue. Padlipsky rapportait des mesures faites sur plusieurs types d'hôtes de la communauté de recherche : cette opération ne représentait qu'une part du traitement par transmission dans ces systèmes. Ce chiffre appartenait à des implémentations et à une époque précises. Pour décider, il fallait mesurer le système entier. Le disque devait fournir les données, le système d'exploitation les préparer et l'application les recevoir.

Un lien annoncé très rapide pouvait attendre tranquillement qu'un hôte termine son travail.

L'auteur citait aussi des implémentations de TCP/IP déjà utilisées et des protocoles applicatifs en service. Il demandait malgré tout des mesures soigneuses sur les réseaux locaux. Une solution locale plus légère pouvait se justifier lorsque les contraintes et les résultats la favorisaient. Il fallait comparer des services équivalents et chiffrer aussi la maintenance des deux chemins. La vitesse imprimée sur une fiche réseau avait moins de valeur que l'observation d'un transfert complet.

La RFC 872 conserve un débat de 1982 et une manière de le résoudre. Quel service l'application demande-t-elle ? La machine doit-elle parler au reste de l'internet ? Où se trouve le goulet mesuré, sur le lien, dans le protocole ou dans l'hôte ? Le monstre se révèle de taille raisonnable dès qu'on allume la lumière au bon endroit.