Résumé

  • RFC 817 refusait de confondre l’empilement qui spécifie les échanges avec le découpage qui exécute le travail. Une interface publique devait rester stable ; le chemin interne pouvait traverser IP et TCP selon la fonction de démultiplexage.
  • Chaque placement — processus, noyau ou processeur frontal — déplaçait latence, copies, temporisateurs, espace mémoire et modes de panne. Aucun ne supprimait magiquement le coût de la frontière.
  • L’information ne devait franchir une couche que pour une optimisation nommée et mesurée. Le regroupement d’un ACK, d’une mise à jour de fenêtre et d’un écho Telnet illustrait le gain, tandis que le transfert de fichier montrait la limite.

La machine extérieure avait encore besoin d’une porte

Dans l’organisation la plus séduisante, un processeur de communication prenait en charge les protocoles. Son système pouvait être conçu pour les paquets, ses programmes réutilisés avec plusieurs hôtes, et ses ingénieurs concentrés sur une seule tâche. Le coût du matériel pouvait même être inférieur à celui d’une réécriture propre dans chaque grand système.

Mais l’hôte devait parler à ce processeur. Il fallait cadrer des données, gérer le flux, signaler les événements et réagir aux pannes de la liaison. Le petit programme d’interface restait un protocole par nature. En éloignant la pile, on ajoutait donc une frontière physique sans supprimer la discipline logicielle que l’on voulait éviter.

RFC 817 donnait un exemple presque comique de dernier recours : faire passer les connexions distantes pour des terminaux locaux au moyen de fils et de ports de télétype. La « machine à traire » permettait la connexion distante, mais enfermait chaque canal dans un seul usage. Le fichier et le courrier restaient hors de portée. Une intégration qui satisfaisait l’urgence pouvait figer l’avenir.

Cette scène concentrait la question du document. La modularité n’était pas un bien abstrait. Elle devait être évaluée par ce qu’elle isolait, ce qu’elle rendait réutilisable et ce qu’elle interdisait ensuite.

Processus et noyau échangeaient des défauts

Mettre tout un protocole dans un processus épargnait certaines modifications du noyau et permettait à une équipe moins familière du système de travailler. Pourtant chaque arrivée pouvait attendre l’ordonnanceur. Les services ressemblant à des périphériques locaux devaient parfois redescendre dans le noyau pour imiter l’interface attendue, ce qui annulait une partie de la simplicité organisationnelle.

Le noyau supprimait un changement de contexte et rapprochait réseau et périphériques. Il offrait cependant un environnement médiocre pour les actions complexes déclenchées par un temporisateur. Exécuter ces actions au niveau d’une interruption empêchait souvent l’attente, risquait de masquer les interruptions trop longtemps et laissait l’ordonnanceur sans moyen de limiter le temps absorbé par une rafale de paquets.

L’espace du noyau pouvait aussi être si restreint que chaque nouvelle fonction obligeait à en retirer une ancienne. Une pile profondément mêlée au système devait être reprise à chaque évolution de celui-ci. La vitesse immédiate pouvait devenir une dette de portage permanente.

RFC 817 n’attribuait donc pas une victoire générale à un emplacement. Il demandait d’identifier les actions : proximité du périphérique, démultiplexage, temporisateurs, attente, état par connexion, copie et réveil. La bonne frontière suivait ces fonctions et les capacités réelles du système.

Le démultiplexage coupait IP et TCP en travers

Une séparation propre entre IP dans le noyau et TCP dans un processus avait un coût précis. Avant de connaître le processus utilisateur destinataire, il fallait lire l’en-tête TCP. Un processus TCP central devait donc être réveillé, choisir la connexion, puis réveiller l’application. Le dessin des couches avait créé deux ordonnancements là où une décision fonctionnelle suffisait.

RFC 817 proposait une coupe orthogonale. Une partie d’IP et de TCP restait dans le noyau, juste assez pour reconnaître le destinataire final. Le datagramme lui était remis directement ; les autres traitements, notamment ceux exigeant des temporisateurs, pouvaient se poursuivre dans son environnement.

Le contrat de réseau ne changeait pas. Le pair recevait le même TCP. Seule la carte locale du travail changeait. Une couche spécifiée disait ce qui devait rester interopérable ; un module exécuté disait où l’état était possédé, où l’on pouvait attendre et combien coûtait le passage.

Cette structure rendait imaginable un TCP par connexion, adapté au débit d’un transfert ou à la faible latence d’un terminal. Elle créait aussi plusieurs variantes à corriger. RFC 817 présentait ce choix comme expérimental, non comme une règle acquise. La spécialisation n’était recevable qu’avec une stratégie de maintenance.

Une touche Telnet révélait le loyer de l’isolement

À la réception d’un caractère, TCP préparait un ACK. La fenêtre pouvait être mise à jour. Telnet ou l’application préparait l’écho ; une commande Telnet ajoutait ses propres actions. Des composants séparés et justes pouvaient envoyer plusieurs paquets en réponse à un seul.

Les réunir économisait la ressource de communication et les passages dans l’ordonnanceur des deux hôtes. Il fallait pour cela qu’une quantité limitée d’intention traverse la frontière. TCP pouvait attendre quelques millisecondes pour savoir si la couche supérieure allait répondre.

La validité dépendait du trafic. Pour Telnet, l’attente rassemblait ACK, fenêtre et écho. Pour un transfert de fichier sans données en sens inverse, elle retardait probablement le paquet suivant. Une information de contexte améliorait donc le choix ; une règle universelle l’aurait dégradé.

RFC 1122 fixa plus tard une politique de delayed ACK : retard inférieur à une demi-seconde et au moins un ACK pour deux segments complets. Il reprit le cas du terminal, où ACK, fenêtre et écho pouvaient passer de trois segments à un, puis avertit qu’un retard excessif perturbait la mesure du RTT et l’horloge des paquets. Le franchissement avait un délai, un but et une limite.

Une interface protégeait et aveuglait

Une interface de couche visible permettait à plusieurs clients d’utiliser le même service. Elle isolait les changements et réduisait la quantité de connaissance exigée de chacun. C’est ce qui rendait possible la coexistence de machines et d’équipes différentes.

Sa rigidité cachait en même temps l’intention. Un service réduit à un flux d’octets pouvait obliger un transfert massif à adopter des opérations conçues pour d’autres usages. Deux processus privés de mémoire partagée copiaient les mêmes données via le noyau. Des couches indépendantes choisissaient chacune leur instant d’émission.

RFC 817 parlait d’un bénéfice et d’une pénalité. Le propos n’autorisait pas à supprimer les interfaces. Il obligeait à rendre visible leur loyer : paquets, copies, réveils, recherches de table, délai, variantes et coût de réparation.

RFC 1958 dira ensuite à la fois que la modularité est bonne et que la performance et le coût comptent, tout en plaçant le retour des implémentations réelles au-dessus des maximes. RFC 3439 reliera la complexité aux dépenses et à la difficulté de changer d’échelle. La pureté et le couplage devaient donc tous deux fournir des preuves.

Multics ne justifiait pas la saleté partout

Le calcul du checksum TCP sur Multics matérialisait un goulot. Les octets de huit bits s’alignaient mal dans des mots de 36 bits. Une première version mettait environ six millisecondes pour 576 octets ; un recodage attentif descendit sous la milliseconde.

La méthode était volontairement spécifique et, selon le texte, sale. Elle devenait acceptable parce que le goulot avait été mesuré, que la fonction était localisée et que le résultat attendu restait vérifiable. Répandre ce style dans tout le système aurait détruit la maintenance au nom d’un gain non démontré ailleurs.

Le reste de l’amélioration venait de décisions moins spectaculaires. Tester d’abord le segment suivant attendu. Organiser la file de retransmission pour son opération la plus courante, la suppression après ACK, plutôt que pour la retransmission rare. Éviter les copies imposées seulement par la frontière d’un module.

La performance se dispersait dans tout le programme. Il n’existait généralement pas un monstre unique à vaincre. Elle se construisait par la mesure du chemin entier avant que les frontières ne deviennent impossibles à déplacer.

Le contrat commun n’était pas la carte privée

RFC 817 séparait deux autorités. La spécification publique décidait ce que les pairs pouvaient attendre sur le réseau. L’implémentation locale décidait comment un hôte distribuait travail, mémoire et temps, à condition de conserver ce résultat externe.

Confondre les deux transformait un plan pédagogique en ordonnanceur obligatoire. Les distinguer permettait à plusieurs systèmes de conserver le même Internet tout en faisant des choix internes différents.

La couche restait nécessaire. Le module restait révisable. Et chaque passage entre eux devait montrer la dépense qu’il supprimait sans cacher la dépendance qu’il créait.

Sources