Zusammenfassung

  • Die MSS-Option im SYN meldet die größte TCP-Datenmenge, die ihr Absender empfangen kann. Hin- und Rückrichtung besitzen unabhängige Obergrenzen, kein gemeinsames Verhandlungsergebnis.
  • Der Sender bildet daraus erst mit der IP-Sendegrenze und den tatsächlich vorhandenen Optionen seine effektive Send-MSS.
  • MSS ist weder Path MTU noch Empfangsfenster, Anwendungsrahmen oder Zusage, dass jedes Segment diese Größe erreicht.

Der Wert wirkte rückwärts

RFC 793 definierte Maximum Segment Size als TCP-Option Kind 2 mit Länge 4. Die 16-Bit-Angabe bezeichnete die maximale Empfangssegmentgröße des TCP, das den SYN sendete. Die Option gehörte nur in Segmente mit gesetztem SYN.

Damit begrenzt die 1460 im Client-SYN den Verkehr Server→Client. Die 1200 im SYN-ACK begrenzt Client→Server. Unterschiedliche Puffer, Schnittstellen oder Richtlinien dürfen unterschiedliche Werte erzeugen. Es gibt keinen Schritt, der beide Zahlen vergleicht und eine davon auswählt.

RFC 879 nannte MSS 1983 ausdrücklich eine Ankündigung, die oft fälschlich als Verhandlung bezeichnet werde. Eine gemeinsame Vereinbarung würde eine symmetrische Verbindungseigenschaft schaffen. MSS verteilt stattdessen zwei einseitige Empfangsaussagen.

Ein einzelnes Betriebsfeld „negotiated MSS“ löscht Urheber und Richtung. Genau diese Kompression macht legitime Asymmetrie verdächtig und kann eine Grenze später auf den falschen Datenstrom anwenden.

576 minus vierzig

Der historische IPv4-Ausgangspunkt war ein Datagramm von 576 Oktetten, das Hosts empfangen und wieder zusammensetzen können mussten. Nach je 20 Oktetten für feste IPv4- und TCP-Header blieben 536 Datenoktette. RFC 879 stellte klar, dass MSS nur TCP-Daten zählt.

SYN und FIN verbrauchen Sequenznummernpositionen, zählen aber nicht als MSS-Daten. Sequenzraum, vollständige Segmentlänge und Nutzdaten dürfen deshalb nicht gleichgesetzt werden.

RFC 1122 verlangte Senden und Empfangen der Option. Fehlt sie beim Verbindungsaufbau, gilt 536 als Send-MSS. RFC 9293 bewahrt 536 für IPv4 und setzt 1220 für IPv6 an: 1280 minus 40 Oktette IPv6 und 20 Oktette TCP.

Eine fehlende Option erlaubt nicht beliebige Größen. Sie aktiviert einen konservativen Standard. Dieser Standard misst weder den heutigen Pfad noch ein typisches Betriebssystem.

Die Gegenstelle kannte den Pfad nicht

RFC 1122 und RFC 9293 unterscheiden die empfangene SendMSS von der effektiven Send-MSS. Der Sender muss die kleinere Grenze aus entfernter Empfangsfähigkeit und der von IP erlaubten Übertragungsgröße verwenden und den aktuellen Header berücksichtigen.

Eine Gegenstelle kann große Segmente annehmen, obwohl ein Tunnel dazwischen sie nicht trägt. Ein breiter Pfad gibt umgekehrt keine Erlaubnis, die kleinere Empfangsangabe zu überschreiten. Endpunkt und Pfad liefern getrennte Belege.

Path MTU Discovery untersucht, wie ein Sender seine Pfadschätzung mit Fehlermeldungen und Zustellproben ändert. MSS ist die andere Eingabe: eine gerichtete Aussage des Empfängers. Die vorhandene PMTUD-Arbeit grenzt einen MSS-Lehrgang ausdrücklich aus.

Tatsächliche Segmente können wegen wenig Anwendungsdaten, Fenstern, Staukontrolle, Wiederholungsgrenzen, Optionen oder Scheduling kleiner bleiben. Kleine Pakete beweisen allein weder Clamping noch Pfadkapazität.

Variable Optionen mussten beim Sender bleiben

IP- und TCP-Header ändern ihre Länge. Sollte der Empfänger schon im SYN Platz für alle denkbaren späteren Optionen abziehen? RFC 6691 beantwortete die Frage nach dem Wissensträger.

Für die angebotene MSS werden nur feste IP- und TCP-Header vom effektiven MTU abgezogen. Der Sender reduziert bei jedem konkreten Paket die Daten um die tatsächlich enthaltenen Optionen. Nur er kennt diese Kombination.

Zieht der Empfänger vorsorglich ab und der Sender erneut, werden Segmente unnötig klein. Zieht niemand ab, werden Pakete zu groß und können fragmentieren oder verworfen werden. Eine feste MSS kann variable Kombinationen nicht korrekt vorwegnehmen.

RFC 6691 verwarf auch die Prämisse eines alten RFC-879-Beispiels, das eine IP-Security-Option direkt vom Angebot abzog. Ein verifiziertes Erratum korrigierte dessen Padding-Arithmetik; die spätere Regel zeigte jedoch, dass die Subtraktion grundsätzlich in die Paketbildung gehörte. RFC 9293 konsolidiert diese Regel.

Erratum 6381 zu RFC 1122 behauptete eine doppelte Subtraktion von IP-Optionen. Es wurde abgelehnt; die Prüfer trennten von IP reservierten Raum von durch TCP übergebenen Optionen. Der Status einer Korrektur ist selbst Evidenz.

Zu klein ist ebenfalls eine Entscheidung

RFC 6691 warnt, dass eine kleine MSS Path MTU Discovery daran hindern kann, einen größeren Pfad auszunutzen. Erreichbarkeit bleibt bestehen, während Paketanzahl und Overhead steigen und die Ursache unsichtbar wird.

Bei Schnittstellen mit wechselndem effektivem MTU darf aber auch nicht nur der Bestfall gelten. Headerkompression kann zur Resynchronisation vollständige Header brauchen; eine Wiederholung könnte dann den Umschlag sprengen. Empfohlen wird die kleinste effektive MTU.

Für IPv6-Jumbogramme gilt 65535 als unendlich, während PMTUD die reale Größe bestimmt. Das ist ein Escape aus dem 16-Bit-Feld, kein unendlicher Pfad.

Das Register misst keine Verbindung

Das IANA-TCP-Register führt Kind 2, Länge 4 als Maximum Segment Size mit RFC 9293. Es bewahrt gemeinsame Syntax, aber keine aktuellen Werte, Umschreibungen oder Pfadbeweise.

RFC 9293 ersetzte RFC 793, 879 und 6691 sowie die TCP-Anforderungen aus RFC 1122. Er bewahrte die Aufgabenteilung: Empfänger kündigen eigene Fähigkeit an; Sender verbinden sie mit IP; variable Kosten trägt derjenige ein, der das Paket baut.

Eine MSS ist eine gerichtete Obergrenze mit Herkunft. Zwei Anzeigen und zwei effektive Rechnungen sind die belastbare Akte, nicht eine erfundene gemeinsame Zahl.

Auch gleiche Werte beweisen keine symmetrische Route, identische Puffer oder erfolgreiche Aushandlung. Zwei Systeme können lediglich dieselbe lokale Konvention verwenden, während ihre tatsächlichen Sendepfade verschieden bleiben.

Quellen und Grenzen

Diese Quellen belegen Spezifikation, Revision und Registrierung, nicht heutige Implementierungsanteile, Defaults, Clamping-Häufigkeit, reale Pfadgröße oder einen Störungsgrund.