Résumé

  • L’option MSS d’un SYN exprime la plus grande charge TCP que son émetteur accepte de recevoir. Les deux sens ont donc des plafonds indépendants, et non une valeur commune négociée.
  • L’émetteur calcule encore sa MSS effective en prenant la contrainte la plus basse entre le pair et IP, puis en retirant les options réellement présentes dans chaque paquet.
  • Une MSS ne certifie ni le MTU du chemin, ni la fenêtre de réception, ni une frontière applicative, ni la taille que prendront tous les segments.

Le nombre repart dans l’autre sens

RFC 793 attribuait à Maximum Segment Size le type 2, une longueur de quatre octets et une valeur de seize bits. Celle-ci communiquait « la taille maximale de segment reçue » par le TCP qui envoyait le segment. L’option ne devait apparaître que sur un paquet portant SYN.

Cette dernière précision place le nombre au début d’une connexion, mais ne le transforme pas en résultat commun. Le 1460 du client gouverne les données que le serveur lui enverra. Le 1200 du serveur gouverne les données allant vers le serveur. Deux capacités de réception, deux directions, deux responsabilités.

RFC 879 corrigea expressément le vocabulaire en 1983 : il parla d’annonce, « souvent appelée à tort négociation ». Une négociation choisit normalement un paramètre partagé. Ici, aucun mécanisme ne compare les offres pour désigner un gagnant. Chaque extrémité borne seulement ce qu’elle saura recevoir.

La distinction devient opérationnelle dès que les chemins, les interfaces ou les mémoires sont asymétriques. Deux valeurs différentes ne prouvent ni une anomalie ni une mauvaise entente. Les réduire à une ligne « MSS négociée » supprime l’auteur et le sens de l’observation.

D’où venait 536

Le socle historique d’IPv4 était un datagramme de 576 octets que tout hôte devait pouvoir recevoir et réassembler. Avec vingt octets d’en-tête IPv4 fixe et vingt d’en-tête TCP fixe, il restait 536 octets de données TCP. RFC 879 clarifia que MSS compte les octets de données, pas les en-têtes.

SYN et FIN consomment bien une position dans l’espace de séquence, mais ne deviennent pas pour autant des octets de données MSS. La taille d’un segment de données et l’occupation de l’espace de séquence sont deux comptabilités liées, non identiques.

RFC 1122 imposa la prise en charge de l’émission et de la réception de l’option. Sans valeur reçue à l’établissement, l’émetteur devait supposer 536. La spécification actuelle, RFC 9293, conserve ce défaut pour IPv4 et fixe 1220 pour IPv6, soit 1280 moins quarante octets IPv6 et vingt octets TCP.

L’absence d’option ne signifie donc pas que tout segment est permis. Elle déclenche un défaut conservateur. Ces nombres ne mesurent pas une route contemporaine et ne promettent pas que l’application remplira chaque segment ; ils empêchent seulement une lacune d’information de devenir une autorisation illimitée.

Le pair fournit une borne, pas le paquet final

RFC 1122 puis RFC 9293 distinguent la SendMSS reçue de la « MSS d’envoi effective ». Cette dernière doit être la plus petite des contraintes : la capacité distante, qui reflète la réception et le réassemblage du pair, et la taille maximale que la couche IP permet actuellement d’émettre. Les longueurs d’en-tête pertinentes sont ensuite comptées.

Un pair peut accepter 9000 octets de données TCP sans que le chemin sache transporter le datagramme correspondant. À l’inverse, un chemin large ne donne pas le droit de dépasser les 1200 annoncés par le destinataire. La réception et le transit produisent des preuves différentes.

C’est la frontière avec Path MTU Discovery. L’article existant sur PMTUD suit les messages de routeur, les caches de chemin et les sondes de livraison par lesquels un émetteur apprend une capacité de chemin révisable. MSS apporte autre chose à ce calcul : la limite directionnelle du terminal distant.

La charge réellement observée peut rester bien au-dessous des deux plafonds. Il peut manquer des données applicatives ; les fenêtres de congestion ou de réception peuvent être étroites ; une retransmission peut couper ailleurs ; des options peuvent consommer de la place. Un petit segment n’est pas, à lui seul, la preuve d’un clamp intermédiaire.

Les options variables appartiennent à celui qui fabrique le paquet

Les en-têtes IP et TCP peuvent changer de longueur d’un paquet à l’autre. Fallait-il alors retirer de l’annonce MSS l’espace de toutes les options qui pourraient apparaître plus tard ? Cette question entretint une confusion que RFC 6691 trancha.

Pour calculer la valeur annoncée, on soustrait seulement les en-têtes IP et TCP fixes du MTU effectif. On ne pré-réserve pas les options possibles. Lorsqu’il construit un paquet concret, l’émetteur réduit sa charge de la longueur exacte des options IP et TCP présentes dans ce paquet.

L’attribution suit la connaissance. Le récepteur ne sait pas, au moment du SYN, quelle combinaison d’options l’autre côté utilisera pour chacun de ses futurs segments. Une valeur fixe ne peut pas décrire toutes les combinaisons. L’émetteur, lui, connaît l’en-tête qu’il assemble.

Si le récepteur retranche une réserve et que l’émetteur la retranche de nouveau, les segments deviennent inutilement courts. Si personne ne retranche les options, le datagramme devient trop long et risque fragmentation ou abandon. Le bon résultat dépend moins d’une marge universelle que d’une seule comptabilité, au bon moment.

RFC 6691 invalida aussi l’ancien exemple de RFC 879 qui retirait directement une option de sécurité IP de la MSS annoncée. Une errata vérifiée corrigeait l’alignement arithmétique de cet exemple, mais la règle ultérieure montra que l’emplacement même de la soustraction était erroné. RFC 9293 consolide désormais la doctrine : en-têtes fixes dans l’annonce, coûts variables chez l’émetteur.

Une errata proposée pour RFC 1122 prétendait que sa formule retranchait deux fois les options IP. Elle fut rejetée ; les notes de vérification distinguent les options réservées par IP de celles que TCP remet à IP. Une proposition d’errata n’est pas une modification normative tant que son statut ne l’établit pas.

Un plafond trop bas peut masquer le chemin

Une annonce prudente a un coût. RFC 6691 avertit qu’une MSS trop petite peut empêcher PMTUD d’exploiter un chemin plus large. La connexion fonctionne, mais davantage de paquets transportent davantage d’en-têtes et l’opérateur peut ne plus voir que le chemin avait une marge inutilisée.

Cela ne justifie pas une annonce optimiste sur une interface à MTU variable. Avec certaines compressions, l’en-tête réduit doit parfois redevenir complet pour resynchroniser l’état. Une retransmission peut alors être plus grande que le paquet original. RFC 6691 recommande d’utiliser le plus petit MTU effectif pour construire une promesse répétable.

Les jumbogrammes IPv6 montrent la limite du champ de seize bits. La valeur 65535 y est traitée comme l’infini et PMTUD détermine la taille réelle. « Infini » est un code de délégation, pas une propriété physique du chemin.

Le registre conserve la grammaire

Le registre IANA des paramètres TCP conserve le type 2, longueur 4, Maximum Segment Size et renvoie à RFC 9293. Il prouve qu’une syntaxe commune reste attribuée. Il ne mesure ni les valeurs émises par les systèmes, ni les réécritures, ni la capacité d’un chemin.

RFC 9293 a remplacé RFC 793, RFC 879 et RFC 6691, ainsi que les exigences TCP de RFC 1122. Cette consolidation n’a pas transformé MSS en accord symétrique. Elle a conservé une séparation plus précieuse : le récepteur annonce ce qu’il sait de lui-même ; l’émetteur joint cette borne à ce qu’IP sait du départ ; le coût variable est retiré par celui qui connaît le paquet présent.

Le nombre n’est donc utile qu’avec sa provenance. Deux annonces, deux directions, deux calculs effectifs et une série de paquets observés valent mieux qu’une case unique « MSS négociée ».

Sources et limites

Ces sources établissent la spécification, ses corrections et le registre. Elles ne donnent ni part de déploiement actuelle, ni valeur par défaut d’un produit, ni fréquence de clamp, ni mesure d’un chemin réel.