2.3.4 Maximale Segmentgröße und andere Optionen

Die Original-Spezifikation von TCP (RFC 793) kennt nur die folgenden drei Optionen:

In anderen RFCs werden verschiedene Ergänzungen vorgeschlagen. Wir wollen uns hier auf die im RFC 1323 (TCP Extensions for High Performance) beschriebenen Optionen Window Scale und Timestamps sowie die im RFC 2018 (TCP Selective Acknowledgment Options) definierten Optionen SACK-permitted und SACK beschränken, die nur in einigen neueren Implementierungen zu finden sind und auf die wir später noch etwas genauer eingehen werden. Die folgende Abbildung zeigt das Format der in drei genannten RFCs spezifizierten Optionen, diesmal gleich mit ihrer englischen Bezeichnung:

Das erste Byte (Kind) gibt den Typ der Option an. Außer bei Typ 0 und 1, die immer ein Byte umfassen, folgt danach die Angabe der Gesamtlänge (Len) in Bytes, also einschließlich Typ- und Längenfeld. Die Option No-Operation dient als Füllbyte und gestattet es dem Sender, andere Optionen jeweils an einer Wortgrenze (32 Bit) auszurichten.

MSS (Maximum Segment Size) ist eine der am häufigsten verwendeten Optionen, die allerdings lediglich im SYN-Segment beim Verbindungsaufbau angegeben werden darf. So hat jede Seite die Möglichkeit, dem Partner mitzuteilen, bis zu welcher Maximallänge sie TCP-Segmente empfangen kann. Die MSS bezieht sich nur auf das Datenfeld, nicht aber auf den TCP-Kopf.

Sowohl der TCP- als auch der IP-Kopf haben wegen evtl. vorhandener Optionen prinzipiell eine variable Länge. Bei der Berechnung der MSS geht man in der Praxis aber meist vom Standard-Kopf mit je 20 Bytes aus. Das zeigt sich deutlich, wenn die Angabe der MSS fehlt. Dann wird ein Vorzugswert von 536 Bytes angenommen. Diese Zahl ergibt sich als Differenz der Vorzugsgröße eines IP-Datagramms (576 Bytes) und den Längen der beiden Standard-Köpfe von TCP und IP (zusammen 40 Bytes).

Sofern beide Partner über dasselbe physische Netz verbunden sind, sollten sie die MSS so wählen, daß die resultierenden IP-Datagramme gerade der MTU entsprechen, um den Overhead auf ein Minimum zu reduzieren. Im detaillierten Mitschnitt [tcpopen.txt] des Verbindungsaufbaus erkennen wir, daß unsere beiden Rechner, die an dasselbe Ethernet angeschlossen sind, sich genauso verhalten. Sie spezifizieren jeweils 1460 Bytes als MSS. Zuzüglich der 40 Bytes von TCP- und IP-Kopf ergibt sich eine Paketlänge von 1500 Bytes. Das ist exakt die MTU im Ethernet.

Allgemein ist die Wahl der MSS nicht ganz trivial. Einerseits sollten die Segmente eine gewisse Mindestgröße haben, um nicht hauptsächlich Köpfe, sondern auch soviel wie möglich Nutzdaten zu transportieren. Andererseits bewirken zu große Segmente eine Fragmentierung auf IP-Ebene, die man in der Regel immer vermeiden will, da sie den Durchsatz drastisch reduzieren kann. Wie wir bereits früher festgestellt hatten, muß bereits beim Verlust eines einzigen Fragments das gesamte IP-Datagramm und somit das komplette TCP-Segment erneut gesendet werden, da das selektive Wiederholen einzelner Fragmente nicht möglich ist.

Eine Hilfestellung bei der Wahl einer möglichst optimalen MSS kann die Path MTU Discovery (RFC 1191) geben. Da IP die Pakete allerdings dynamisch routet, läßt sich deren exakter Weg nicht mit Sicherheit vorab bestimmen, so daß Fragmentierungen dennoch nicht auszuschließen sind.


© Holger Trapp, 2.6.1998