Résumé

  • Les trailers déplaçaient les en-têtes variables après les données dans un même paquet de liaison, afin de faciliter leur alignement sur les pages mémoire du destinataire.
  • L’économie de copies dépendait de l’architecture et du chemin de réception. Attendre les en-têtes pouvait aussi supprimer une possibilité de filtrage ou de décision précoce.
  • L’usage exigeait une connaissance positive de la capacité du voisin. En 1989, sans négociation dynamique par destination, la configuration devait désactiver cette forme par défaut.

Une faveur dont l’autre devait fixer le prix

Il est possible de rendre un paquet plus commode pour une machine sans changer les données qu’il transporte. Mais la commodité n’est pas une propriété universelle du paquet. Elle dépend du matériel qui le reçoit, de la gestion de sa mémoire et du moment où son logiciel examine les informations de contrôle.

C’est le point de départ du RFC 893, publié en avril 1984. Ce texte informatif, qui précise ne pas être un protocole officiel de l’ARPA Internet, décrit une encapsulation employée alors par 4.2BSD UNIX et d’autres systèmes. L’objectif est de réduire le nombre et le volume des copies de mémoire à mémoire du côté récepteur.

L’émetteur participe à cette économie en envoyant les parties du paquet dans un autre ordre. Ce geste ne lui donne cependant aucune autorité sur le chemin de réception de son voisin. Si celui-ci ne reconnaît pas la forme particulière, l’offre de performance devient simplement un paquet incompréhensible.

Ce que la page mémoire change au calcul

Entre l’arrivée sur une interface et l’accès par une application, les données peuvent être copiées plusieurs fois. Le transfert entre matériel et mémoire n’est pas le seul enjeu : il peut aussi falloir passer de l’espace du système d’exploitation à celui d’un programme utilisateur.

Sur une architecture appropriée, modifier la correspondance des pages peut éviter de recopier les octets. Encore faut-il que le bloc se prête à cette opération. Le RFC 893 envisage notamment un début de données aligné sur une frontière de page et une longueur multiple de la page, ou complétée jusqu’à cette frontière, dans un contexte de protection à cette granularité.

Les conditions varient selon l’architecture. Il ne suffit donc pas d’apposer l’étiquette « sans copie » à une encapsulation pour obtenir le résultat. La disposition des données offre une possibilité ; le matériel et le logiciel doivent encore pouvoir l’exploiter.

Or les en-têtes qui précèdent les données n’ont pas tous une longueur constante. La partie de liaison peut fournir un préfixe stable, mais les en-têtes IP, TCP ou d’autres protocoles déplacent le début du contenu lorsqu’ils changent de taille. Une copie pour rétablir l’alignement peut précisément détruire le bénéfice recherché.

Le trailer contourne cet obstacle en repoussant ces en-têtes variables derrière le bloc de données. Le gros bloc devient plus facile à placer convenablement ; les petites informations de contrôle pourront être réorganisées séparément. L’exemple VAX de 512 octets de données dans le document appartient à ce raisonnement historique, pas à une prescription sur la taille des pages des ordinateurs actuels.

Réordonner sur la liaison, reconstruire avant IP

Le mot trailer peut induire une fausse image : il ne s’agit ni d’une annexe de fichier ni d’un second paquet qui apporterait plus tard les instructions manquantes. Le déplacement se fait à l’intérieur du même paquet de liaison.

Le type indiqué par la liaison permet de reconnaître la forme particulière et de déterminer où se trouve la partie terminale. Celle-ci contient des informations sur le protocole d’origine et la longueur des en-têtes, suivies des en-têtes déplacés. Le récepteur enlève les éléments propres à l’encapsulation et reconstitue l’ordre attendu par les couches supérieures.

Les données peuvent ainsi arriver avant leur en-tête sur le câble sans être livrées à l’application en dehors de la signification de TCP. Le flux applicatif n’est pas inversé. La manipulation reste locale au mécanisme de liaison, à condition que la reconstruction soit correctement exécutée.

Le RFC 894, également d’avril 1984, décrit la base ordinaire d’IP sur Ethernet : l’en-tête IP est immédiatement suivi de ses données. Le remplissage nécessaire à la longueur minimale Ethernet ne fait pas partie de la longueur totale IP. Une autre disposition, même destinée à transporter le même IP, nécessite un lecteur qui la comprenne.

La taille du lien n’est pas augmentée pour autant. L’erratum technique 570, vérifié, corrige justement le RFC 894 lorsqu’il qualifie 1500 octets de minimum au lieu de maximum. Une capacité de représentation, une frontière mémoire et la longueur admise sur le réseau ne sont pas des grandeurs interchangeables.

L’en-tête tardif retire aussi une option

Le RFC 893 pose plusieurs conditions de rentabilité : un destinataire capable et volontaire, un coût d’alignement inférieur au gain, un trailer relativement petit et une économie de copies suffisante pour justifier la complexité ajoutée.

Il reconnaît également un inconvénient direct. Lorsque les en-têtes sont à la fin, le destinataire doit recevoir et conserver l’ensemble avant de pouvoir traiter ces informations. Un système habitué à examiner tôt un en-tête peut perdre la possibilité de rejeter rapidement le paquet ou de choisir ses ressources avant l’arrivée complète.

Le document considère le retard de reconnaissance du type comme une objection valable. Il répond que, dans le cas de DMA qu’il discute, le paquet entier était déjà reçu avant le traitement. Cette réponse vaut pour ce chemin de réception. Elle ne démontre pas que tous les matériels DMA, aujourd’hui comme hier, auraient les mêmes contraintes.

Le bilan oppose donc des coûts situés, non une bonne et une mauvaise forme absolues. Un destinataire peut gagner sur les copies ; un autre ne gagner que du travail supplémentaire. Les auteurs rapportent des avantages de leur implémentation, mais ces observations historiques ne constituent pas ici un nouveau banc d’essai.

L’option n’était pas une obligation collective

Le RFC 894 autorisait des systèmes consentants sur le même Ethernet à utiliser des trailers. Il n’obligeait aucun hôte à les implémenter. Avant d’envoyer cette forme, un système devait savoir positivement que son destinataire pourrait l’interpréter.

La difficulté opérationnelle apparaît dans les descriptions de 1984. La 4.2BSD alors évoquée décidait au démarrage, interface par interface, d’envoyer des trailers ou de ne jamais en envoyer sur cette interface. Cette granularité supposait une coopération uniforme sur le média partagé. Une négociation par hôte au moyen d’ARP était envisagée comme évolution.

En octobre 1989, le RFC 1122, section 2.3.1, donne une limite plus précise. Les deux participants de liaison, hôte ou passerelle, doivent être reconnus capables. En l’absence d’une négociation dynamique par destination, la configuration par défaut doit désactiver les trailers.

Ce contraste documente une évolution des règles et du mécanisme décrit. Il ne fixe pas la première date de livraison pour tous les systèmes, et ne signifie pas que toutes les versions de BSD aient conservé la même option globale jusqu’en 1989.

Une adresse résolue, une capacité encore à annoncer

L’ARP ordinaire ne répond pas à la nouvelle question. Le RFC 826 relie une adresse de protocole à une adresse matérielle sur la liaison choisie pour le prochain saut. Il distingue le type Ethernet qui transporte ARP, l’espace de protocole indiqué dans le contenu ARP et le code d’opération de demande ou de réponse.

La négociation décrite par RFC 1122 préserve l’échange IP ARP normal. Un système disposé à recevoir des trailers ajoute une réponse Trailer ARP, de structure ordinaire mais portant le type de protocole trailer dans ARP. Elle ne remplace pas la réponse IP de base et ne suppose pas l’émission préalable d’une demande Trailer ARP.

Le destinataire d’une demande ordinaire peut joindre cette annonce à sa réponse IP. L’auteur de la demande peut aussi annoncer sa propre capacité de réception lorsqu’il reçoit la réponse IP correspondante. Chacune des annonces parle de celui qui l’émet : elle dit ce qu’il accepte de recevoir.

Un hôte configuré pour utiliser la forme peut conserver cette information pour son voisin, par exemple dans une entrée ARP. Ce n’est ni une preuve de vitesse, ni une authentification cryptographique, ni un accusé de réception des données d’une application.

La portée reste locale. Le RFC 1009, de juin 1987, explique notamment qu’une passerelle peut répondre par proxy ARP avec l’adresse de sa propre interface pour une destination extérieure qu’elle sait atteindre. La capacité du partenaire ainsi identifié ne prouve donc pas celle du destinataire final ou de toute la route.

Ne pas répondre indéfiniment à une réponse

L’ajout d’une annonce introduit un risque de conversation autoentretenue. Un hôte au comportement incorrect peut répondre à une annonce Trailer ARP par une réponse IP ARP. Si l’autre côté répond à chaque réponse IP par une nouvelle annonce, la suite peut se prolonger sans demande nouvelle.

RFC 1122 borne ce cas : l’annonce envoyée à la réception d’une réponse IP doit correspondre à une demande encore en attente. L’adresse matérielle était donc encore inconnue avant le traitement de cette réponse. L’annonce accompagnant une réponse normale à une demande reçue relève d’un autre cas et reste permise.

La distinction ne repose pas sur un délai imaginaire ou un nombre de répétitions ajouté après coup. Elle repose sur l’état local : y avait-il encore une question à résoudre ? Un événement ne devient pas une raison de recommencer simplement parce qu’il ressemble à un événement déjà vu.

Le même texte souligne une autre difficulté de diagnostic. Les trailers ne sont sélectionnés que pour certains attributs de taille. Des paquets peuvent donc arriver normalement tandis que d’autres disparaissent à cause d’un désaccord de format. Ce n’est pas une affirmation selon laquelle tous les gros paquets échouent, ni une preuve automatique de problème de MTU.

Une communication partiellement réussie peut seulement avoir évité les paquets concernés. Pour savoir ce qui a été testé, il faut regarder la forme choisie et l’état du destinataire, pas uniquement constater qu’une adresse répond.