TCP/IP-Tuning für Linux

TCP-Empfangs- und Sendepuffer

Das Transmission Control Protocol (TCP) stellt sicher, dass Informationen korrekt über das Netz transportiert werden. Kommt es zu Fehlern im Netzwerk, sendet ein Rechner seine Daten nach einer bestimmten Zeit noch einmal. Dies wird so lange wiederholt, bis der Sender von der Gegenstelle die Bestätigung erhält, dass die Informationen einwandfrei empfangen wurden.

Würde der Sender vor dem Verschicken des nächsten Pakets immer auf die Eingangsbestätigung des vorherigen warten, würde das die Übertragung stark verlangsamen. Daher teilt der Empfänger dem Sender beim Verbindungsaufbau die Größe seines Empfangspuffers mit, des so genannten TCP Receive Window (RWIN). Der Sender schickt dann immer so viele Pakete, wie in diesen Zwischenspeicher passen, bevor er auf die erste Eingangsbestätigung wartet. Im Idealfall geht das ganz ohne Verzögerung, weil die Quittung für das erste Paket schon eintrifft, während der Puffer noch gefüllt wird. Analog existiert beim Sender ein Sendepuffer.

Ein zu kleines Fenster wirkt sich ebenso ungünstig aus wie ein zu groß gewähltes. Im ersten Fall stockt der Datenfluss. Im zweiten können mehr Informationen verloren gehen, wenn ein Paket gar nicht oder unvollständig ankommt. Der ideale Wert hängt also besonders von der Leitungsqualität ab.

Eine ungefähre Annäherung an die optimale Puffergröße können Sie mit dem so genannten Bandwidth Delay Product (BDP) ermitteln. Das BDP errechnet sich nach folgender Formel:

Leitungs-Geschwindigkeit * Round Trip Delay

In einem LAN ist die Leitungsgeschwindigkeit die Übertragungsrate der Netzwerkkarte. Uns interessiert aber das BDP für die DSL-Verbindung. Das Round Trip Delay (RTT) ermitteln wir per Ping zu einem nicht allzu nahen Host. Im Fall von DSL mit 1024 Kbit/s und einem ermittelten RTT von 200 ms beträgt das BDP also

1024 Kbit/s * 0,2 s = 204,8 Kbit = 25,6 KByte.