TCP/IP-Tuning für Linux

Mögliche Probleme bei MTU/MSS

Beim Verbindungsaufbau mittels Drei-Wege-Handshake teilen sich die beiden Stationen über das optionale Feld TCP-Options die jeweils unterstützte Maximum Segment Size mit. Hängt beispielsweise ein Rechner hinter einem DSL-Router, wäre die MSS für diesen Rechner 1460, da Standardpakete im lokalen LAN verschickt werden. Für die Kommunikation mit dem Internet gilt jedoch eine andere MSS von 1452 - immerhin ist der PPPoE-Header zu berücksichtigen.

Der Rechner im LAN sagt dem Internet-Server nun, dass er Pakete mit 1460 Bytes Nutzlast annehmen kann. Dieser schickt natürlich entsprechend große Pakete. Spätestens der Router des ISP kann diese Pakete nicht mehr zum Router des Benutzers schicken, denn durch diese Leitung passt nur eine Nutzlast von 1452 Bytes. Wenn das "Don't fragment"-Bit nicht gesetzt ist, teilt der Router das Paket in zwei Pakete auf: eines mit 1452 Bytes und eines mit acht Bytes. Das zweite Paket verbraucht also für 8 Bytes Nutzlast 48 Bytes an Header-Informationen.

Das DF-Bit ist allerdings beispielsweise gesetzt, wenn der Server Path MTU Discovery verwendet. Dann verwirft der Router des ISP das Paket und schickt eine ICMP-Kontrollmeldung, die die richtige MSS mitteilt, an den Absender. Dieser schickt ein kleineres Paket und merkt sich für den Rest der Verbindung den MSS-Wert.

Kommt das ICMP-Paket allerdings nicht beim Absender an, etwa weil die ICMP-Meldung unterwegs gefiltert wird, verschickt er auch kein kleineres Paket. Stattdessen wartet er eine Weile auf die Bestätigung des Empfängers, und da diese nicht kommt, verschickt er das Paket erneut - wieder mit der falschen Größe. Das Spiel geht so lange weiter, bis Server oder Client aufgeben.