[ Main | Local ]

Die RFCs zum Thema

Die MTU und TCP

Was ist die MTU (Maximum Transmission Unit)?
Die MTU wird von der Netzwerk-Hardware bzw. vom Netzwerk-Protokoll vorgegeben. Es ist die mögliche Anzahl an Daten in Bytes, die in einer Übertragung gesendet werden können. Je nach Terminologie sind das dann Frames, Cells, Pakets, Datagramms ... Hier eine Tabelle gängiger Werte:

 
------------------------------------------------
Protokoll   Default  Possible   Recommended
Name          MTU      MTU          MTU
------------------------------------------------
X.25          576    60-2058        576
SLIP          1006   60-4096        1006
Ethernet      1500   60-1500        1500
IEEE 802.3    1492   60-1492        1492
Token Ring    1492   60-4096        3900
(4Mbps)
Token Ring    1492   60-17800       8500
(16 Mbps)
FDDI          4352    1-4352        4352
ATM           9180    1-60416       60416
 

Die MSS und TCP

Was ist die MSS (Maximum Segment Size)?
Das TCP ist ein Protokoll, das mit kontinuierlichen Datenströmen umgeht. Der Datenstrom wird von TCP in Teile zerlegt, sogenannte Segmente. Diese werden mit einem Header zur Flußkontrolle versehen und dann an die IP-Ebene weitergegeben. IP seinerseits gibt das Paket weiter an das Netzwerkinterface. Auf dem Kabel gibt es nun eine maximal zulässige Größe für eine Dateneinheit, die MTU. Da es sinnlos wäre, größere Einheiten zu senden, beziehen sich die oberen Schichten auf diese MTU und ermitteln die reine Nutzlast, also die MTU minus aller Header, die noch dazu kommen. Das ist die Maximum Segment Size.

TCP ist in der Lage, die MSS, die auf dieser Verbindung benutzt werden soll, bekannt zu geben. Das heißt, daß das lokale TCP mitteilt: "Ich kann Segmente bis zur Größe xxx empfangen." Dazu wird die vom lokalen System unterstützte MSS als Option im TCP-Header mitgegeben. Das findet beim Aufbau der Verbindung statt, also während des TCP Handshakes - beide Seiten wählen dann den kleineren Wert. Dadurch benutzt die Verbindung die optimale Größe, es werden also Verzögerungen und unnötige Last durch die Fragmentierung (und das Zusammensetzen) von Paketen vermieden. Das entlastet besonders Router und Gateways.

Im RFC ist die Definition folgende: Die größte Anzahl von Daten-Bytes, die der Sender dieser TCP Option in einem TCP Segment ohne TCP Header Erweiterungen, das in einem IP Datagramm ohne IP Header Erweiterungen kommt, verarbeiten kann.
Das bedeutet, das man nicht Blind Segmente derselben Größe wie die MSS schicken darf, sondern darauf achten muß, welche Header man mitschickt.

Im einfachsten Fall, also ohne Path MTU Discovery, hängt die mitgeteilte MSS davon ab, ob die Gegenstelle auf dem lokalen Netz ist, oder auf einem fernen Netzwerk. Lokales Netzwerk bezieht sich dabei nicht nur auf dasselbe physikalische Netz, sondern auch auf Subnetze, die man als lokal deklariert hat (unter AIX mit dem no-Parameter subnetsarelocal). Ferne Netze werden dann weiterhin mit der Standard-MTU bedient.

Die MSS auf dem lokalen Netz

Wenn das System anhand der IP-Adresse und eventuell eingestellter Parameter festgestellt hat, das die Gegenstelle als lokal gilt, dann wird TCP die anzusagende MSS aus der MTU (Maximum Transmission Unit) ermitteln:
TCP MSS = MTU - (TCP-Header Länge + IP-Header Länge)
Jetzt sind beide Header leider Variabel (bis zu 60 Byte) - und ein wegen irgendwelcher Optionen längerer Header verkleinert die Nutzlast, also das TCP-Segment. Man hat festgelegt, das mit 40 Byte für den TCP-Header und IP-Header zusammen (je 20 Byte für die Standard-Header der beiden Protokolle) gerechnet wird. Dabei geht man davon aus, das längere Header aufgrund von mitgegebenen Optionen meist nur in der Startphase der Verbindung auftreten - später, wenn wirklich Daten fließen, finden sich meist nur Standard-Header. Das ist dann die optimale Segment Größe für dieses Netzwerk - TCP wird seinen Datenstrom entsprechend in Pakete schneiden, und IP braucht diese nur noch mit dem IP-Header verlängern und weitergeben.

Die MSS einer Verbindung zu einem fernen Netz

Verbindungen zu fernen Netzen sind eine dynamische Angelegenheit. Es können Teile des Netzes wegbrechen, Router können in die Knie gehen etc. Das bedeutet, das man über die MTUs der Netze, die man passieren muß, keinesfalls informiert sein kann.

Auch stellt TCP keinen Mechanismus zum Finden und Prüfen der MTU auf dem Weg zu einer fernen Maschine zur Verfügung. Um trotzdem einen sicheren Verkehr ohne Fragmentierung zu bekommen, stellt man die MSS auf einen Wert ein, den laut weltweiten Standards alle am World Wide Web hängenden Maschinen beherrschen müssen. Vorgegeben ist eine MTU von 576 Byte, was auf eine MSS von 512 Byte herauskommt.

Das ist eine sehr konservative Annahme - und für viele Pfade zu fernen Netzen viel zu schlecht. Sind alle Wege bekannt, z.B. in einem Firmennetz, dann kann man systemweit eine höhere Standard-MSS einstellen (unter AIX mit dem no-Parameter tcp_mssdflt). Das gilt dann allerdings für alle Verbindungen. Und es muß auf beiden Seiten so gesetzt sein, denn das normale Aushandeln macht TCP immer noch. Ist eine Maschine oder ein Netz "richtig" fern, dann wird unterwegs Fragmentierung nötig sein - Man kann in den seltensten Fällen vorhersagen, wohin sich die User zu verbinden wünschen...

Wenn sich Aussagen bezüglich der kleinsten MTU entlang eines bestimmten Weges (Pfades) machen kann, dann spricht nichts dagegen, diese pro Route einzustellen. Es muß dazu auf beiden Endstellen eine statische Route zur jeweils anderen Maschine/Netz angelegt werden - unter Benutzung der -mtu Option des route-Kommandos. Dabei wird die MTU angeben, nicht die MSS wie bei den vorherigen Möglichkeiten. Das geht nur bei kleinen Netzen gut - und es verträgt sich nicht mit dynamischem Routing.

Unter aktuellen Gegebenheiten, Netzen mit unterschiedlichen MTUs, dynamischen Routen usw. ist es nicht mehr vernünftig, die MSS/MTU Größe nicht automatisch und dynamisch zu ermitteln. Deshalb ist das Verfahren der Wahl Path MTU Discovery.

[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]