Résumé

  • L’option MSS, de type 2 et longue de quatre octets, est envoyée dans un SYN et indique la quantité maximale de données TCP que son émetteur peut recevoir dans un segment.
  • Les deux sens sont indépendants. La valeur exclut les en-têtes IP et TCP ; l’émetteur tient ensuite compte des en-têtes réellement présents et des contraintes du chemin.

Deux SYN, deux limites de réception

Le mot « négociation » est trompeur. A annonce la capacité de réception de A, tandis que B annonce celle de B. Les valeurs peuvent donc être différentes sans qu’il y ait désaccord : elles concernent des flux opposés.

Le format est précis : type 2, longueur 4, puis une valeur MSS sur 16 bits. Selon le RFC 9293, cette option décrit la taille maximale de segment que l’émetteur est prêt à recevoir. Elle peut figurer dans une demande initiale portant le drapeau SYN et ne doit pas apparaître dans les segments ultérieurs. Elle établit donc une contrainte lors de l’ouverture, et non une série de mises à jour.

Le MSS mesure les octets de données TCP, à l’exclusion des en-têtes IP et TCP. Ce n’est ni la taille du datagramme IP, ni la MTU d’une interface, ni la taille d’écriture d’une application. L’émetteur utilise la valeur de son pair comme une limite parmi d’autres, tout en tenant compte du chemin et des en-têtes qu’il ajoute effectivement.

Le RFC 879, dès 1983, insistait déjà sur ce point : le MSS était « souvent appelé à tort une négociation ». Le récepteur indique ce qu’il peut accepter ; l’émetteur forme ses paquets à partir de cette indication et de ses propres informations.

Pourquoi 536 était une valeur par défaut

Dans le cas IPv4 décrit par le RFC 879, un hôte devait pouvoir réassembler un datagramme de 576 octets. En retirant les en-têtes minimaux de 20 octets pour IPv4 et de 20 octets pour TCP, il restait 536 octets de données TCP.

Cette arithmétique de compatibilité ne prouvait pas que tous les chemins avaient une MTU de 576 octets. Elle ne mesurait pas le trajet entre les hôtes. Elle fournissait une valeur par défaut fondée sur des minima spécifiés, tandis que l’émetteur devait toujours appliquer ses propres contraintes de transmission.

Le MSS reste distinct de la découverte de la MTU du chemin. La PMTUD cherche une propriété de la route, susceptible de changer. Le MSS est échangé à l’ouverture et décrit la capacité de réception d’un endpoint.

La correction concernant les options

Une erreur d’implémentation consistait à soustraire à l’avance l’espace supposé nécessaire aux options IP ou TCP. Le RFC 6691 clarifie que le récepteur doit annoncer la plus grande charge utile TCP qu’il peut réassembler, sans réserver artificiellement cet espace.

Lors de chaque émission, c’est l’émetteur qui réduit au besoin les données afin d’intégrer les options réellement présentes et de respecter la contrainte IP applicable. La décision durable du récepteur et la construction de chaque paquet sont donc de nature différente.

Une grande valeur MSS n’autorise pas l’envoi de paquets trop grands pour le chemin. Une petite valeur ne certifie pas non plus la MTU de chaque saut.

Ce qu’un intermédiaire peut réécrire

Un équipement intermédiaire peut modifier le MSS dans un SYN, notamment pour tenir compte d’un tunnel. Cette modification change la contrainte présentée au pair ; elle ne constitue pas une mesure authentifiée de la capacité du chemin.

Une capture indique la valeur observée à un point donné, éventuellement après réécriture. Elle ne révèle pas nécessairement l’annonce originale, la MTU de tous les sauts ni la raison d’une charge utile plus petite.

La leçon historique est une répartition disciplinée des responsabilités : le récepteur annonce sa limite, l’émetteur construit le paquet et le chemin reste une contrainte extérieure.

Sources