TCP/IP-Tuning für Linux

31.03.2005 von Mike Hartmann
Eine wachsende Zahl von Anwendern surft über einen schnellen DSL-Zugang. Wir zeigen, wie Sie noch mehr aus dem Breitbandanschluss herausholen - durch etwas Tuning und mit kostenlosen Zusatzdiensten.

Die Datenraten, mit denen Provider für ihren DSL-Zugang werben, verheißen Geschwindigkeit satt: Aktuelle DSL-Angebote erreichen zurzeit bis zu fünf Mbit/s Downstream und 512 Kbit/s Upstream.

Was davon effektiv übrig bleibt, hängt von verschiedenen Faktoren ab, etwa der Anbindung des eigenen ISPs, des angesprochenen Servers oder schlicht der Entfernung von der Vermittlungsstelle. Hinzu kommt der Protokoll-Overhead, der mit übertragen werden muss. Als Faustregel rechnet man bei einer guten Anbindung mit höchstens 87 Prozent der theoretisch erzielbaren Bandbreite.

Um möglichst nah an den Maximalwert heranzukommen, lohnt ein Blick auf verschiedene TCP/IP-Einstellungen. Die notwendigen Angaben müssen die User selbst eintragen, was entsprechendes Wissen voraussetzt. Wir verraten, welche Parameter sich für Tuning-Maßnahmen eignen, was sie bewirken und wie sie zusammenhängen.

Maximum Transfer Unit (MTU)

Im Internet kommunizieren die Rechner über TCP/IP. Dieses Protokoll unterteilt die zu transportierenden Daten in Pakete, bevor sie auf die Reise gehen. Der MTU-Wert legt die maximale Größe einer solchen Einheit fest.

Eine Obergrenze ist deshalb notwendig, weil Router zu große Pakete auf ihrem Weg durchs Netz fragmentieren müssen. Erst der Zielrechner setzt dann die einzelnen Fragmente wieder zusammen. Das kostet unnötig Zeit, genauso wie das automatische Aushandeln der MTU über ICMP-Nachrichten. Besser ist es, von vornherein einen optimalen MTU-Wert zu wählen. Dieser lässt sich recht einfach über Bordmittel des Betriebssystems bestimmen. Mit dem Befehl

ping -s 1500 -c 10 -M do <Hostname>

verschicken Sie ein Datenpaket mit einer Länge von 1500 Bytes an den unter "Hostname" angegebenen Rechner. Der Parameter "-M do" legt fest, dass das Paket "in einem Stück" ankommen muss und dass der TCP/IP-Stack gleich eine automatische Erkennung der optimalen MTU vornehmen soll. Das Resultat der Prüfung erhalten Sie in der Ausgabe des Befehls mitgeteilt - inklusive der Angabe, welcher Rechner unterwegs mit der Paketgröße nicht klarkommt.

Die MTU der jeweiligen Netzwerkkarte konfigurieren Sie bei SuSE über YaST. Wählen Sie dort Netzwerkgeräte/Netzwerkkarte aus und danach die zu konfigurierende Karte. Klicken Sie auf Erweitert und dann auf Besondere Einstellungen. Dort finden Sie das Eingabefeld für den MTU-Wert.

Maximum Segment Size (MSS)

Während die MTU die Größe des kompletten Datenpakets angibt, bestimmt die "Maximum Segment Size" (MSS) den Platz, der für die Nutzdaten zur Verfügung steht. Diese teilen sich den Platz mit den Verwaltungsangaben, die im Header stehen und Auskunft über Absender und Empfänger geben.

Standardmäßig besteht ein TCP/IP-Paket aus zwei Headern: IP und TCP, jeweils 20 Bytes groß. Weitere acht Bytes fallen für den PPPoE-Overhead an. Da die maximale Länge für ein gültiges Ethernet-Paket 1500 Bytes beträgt, ergibt sich daraus eine Obergrenze für MSS von 1452 Bytes. Welcher Wert im konkreten Einzelfall passt, lässt sich anhand der Formel "MTU minus Header" berechnen.

In der nachfolgenden Tabelle finden Sie einige Werte, die den Zusammenhang zwischen verschiedenen Headern, MTU und MSS verdeutlichen:

Typische Größen für Header, MTU und MSS

Größe (in Bytes)

Beschreibung

Angaben für TCP/IP ohne Nutzung des Feldes "Options"

1500

Maximale Paketgröße, die im Internet ohne Fragmentierung verschickt werden kann

1492

Maximale Paketgröße bei Einsatz von PPPoE

1460

MSS bei einem MTU-Wert von 1500

1464

Bei PPPoE-Implementierung: Maximale Ping-Größe ohne Fragmentierung

1452

MSS bei einem MTU-Wert von 1492 (typisch bei PPPoE)

576

Typische MTU bei analogen Modem-Wählverbindungen

536

MSS bei einem MTU-Wert von 576

48

Summe der Header von TCP, IP und PPPoE

28

Summe der Header von IP und ICMP

20

IP-Header

20

TCP-Header

8

PPPoE-Header

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.

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.

Einstellen der Fenstergrößen

Unter Linux sind die folgenden sysctl-Variablen für die TCP-Puffer zuständig:

net.core.rmem_max und net.core.wmem_max geben die maximale Größe für Empfangs- und Sendepuffer von Netzwerkpaketen an.

Die beiden Variablen net.ipv4.tcp_rmem und net.ipv4.tcp_wmem enthalten jeweils drei Werte. Minimum, Default und Maximum. Der erste gibt den Mindestspeicher an, den ein TCP-Socket bekommt, auch wenn das System nur wenig Speicher hat. Ist ausreichend Speicher vorhanden, weist der Kernel einem TCP-Socket den über Default spezifizierten Wert zu. Bei Bedarf kann der Puffer bis hin zum Maximum erhöht werden. Dies erfolgt dynamisch durch den Kernel. Das hier angegebene Maximum darf allerdings nicht höher sein als das unter net.core.rmem_max beziehungsweise unter net.core.wmem_max eingestellte.

Tragen Sie die Variablen und ihre Werte in die Datei /etc/sysctl.conf ein und laden die neuen Parameter durch Eingabe von

sysctl -p

Je nach verfügbarem Hauptspeicher und Anbindung des Rechners im LAN oder ans Internet bieten sich andere Werte an. Riesige Puffer sind nur für Gigabit-Netzwerke notwendig. Ein Drehen an dem Default-Wert kann sich allerdings schon positiv auswirken. Beim Minimum sollten Sie keine Experimente machen und den Standardwert von 4096 beibehalten.

# increase Linux TCP buffer limits
net.core.rmem_max = 2097152
net.core.wmem_max = 2097152

# increase Linux autotuning TCP buffer limits
# min, default, and max number of bytes to use
net.ipv4.tcp_rmem = 4096 87380 2097152
net.ipv4.tcp_wmem = 4096 65536 2097152

Weitere Parameter

In der Diskussion um TCP/IP-Parameter, über die man den Breitbandzugang beschleunigen kann, tauchen neben MTU, MSS und RWIN meist noch andere Parameter auf. Dass sie eine Leistungssteigerung bringen, hat sich bei unseren Versuchen allerdings nicht bestätigt. Wir stellen sie deshalb an dieser Stelle nur kurz in der Übersicht vor. Wer übrigens auf bessere Ping-Zeiten spekuliert und dazu die MTU senkt, tut dies auf Kosten der Download-Geschwindigkeit. Dieser Kniff dürfte also in erster Linie Spiele-Freaks interessieren.

PMTU Discovery

Die Path MTU Discovery regelt, ob die TCP-Verbindung einen festen Maximalwert für MTU verwendet oder den geeigneten Wert selber herauszufinden versucht. Dazu setzt der IP-Stack bei jedem ausgehenden Paket das "Don't Fragment"-Bit. Kommt eine entsprechende ICMP-Statusmeldung zurück, setzt der Stack für diese Verbindung die MTU auf den gemeldeten Wert. Standardmäßig ist Path MTU Discovery aktiv. Ein Abschalten erfolgt über die sysctl-Variable net.ipv4.ip_no_pmtu_disc.

Erweiterungen aus RFC 1323

Zwei Schalter sorgen dafür, dass die Erweiterungen aus der RFC 1323 aktiviert werden. Mit net.ipv4.tcp_window_scaling kann der TCP-Stack größere Puffer als 64 KByte für Sende- und Empfangspuffer verwenden. Wird der Parameter auf 0 gesetzt, verwendet Linux maximal 64 KByte, unabhängig davon, wie Sie tcp_rmem und tcp_wmem konfiguriert haben. Via net.ipv4.tcp_timestamps werden Zeitstempel aktiviert, über die sich das RTT-Delay besser kalkulieren lässt, anhand dessen der Stack die Puffergröße dynamisch anpasst.

TTL

Die "Time to live" bestimmt, nach wie vielen Routern ein IP-Paket als unzustellbar verworfen wird. Die Variable net.ipv4. ip_default_ttl enthält diesen Wert und steht per Default auf 64. Hierüber lässt sich allerdings keinesfalls die Geschwindigkeit einer Verbindung beeinflussen. Bei kürzerer TTL erhält man lediglich die Fehlermeldung, dass keine Daten fließen, etwas früher.

DynDNS.org

Ein DSL-Zugang bietet mehr Möglichkeiten als nur schnelles Surfen. So lässt sich beispielsweise der heimische Rechner mit einfachen Mitteln als Internet-Server betreiben - etwa, um auch unterwegs auf dringend benötigte Daten zuzugreifen oder um per Remote Control seinen Rechner fernzusteuern.

Das große Problem bei diesem Ansinnen besteht jedoch in der dynamischen IP-Adresse, die bei jedem Einwahlvorgang neu zugewiesen wird. Damit ist der Rechner nicht immer unter derselben IP zu erreichen. Praktischer wäre ein Host-Name wie wunschname.xyz.de.

Die Website DynDNS.org bietet kostenlos dynamische DNS-Dienste und sorgt also dafür, dass der Rechner des Anwenders unter einem bestimmten Host-Namen erreichbar ist - trotz wechselnder IP-Adresse. Um das Angebot nutzen zu können, muss man sich zunächst mit gewünschtem User-Namen, Passwort und gültiger E-Mail-Adresse registrieren. An diese Adresse sendet DynDNS.org eine Nachricht, die das weitere Vorgehen zur Account-Aktivierung beschreibt.

Hat alles geklappt, kann man sich anschließend mit seiner Kennung einloggen und einen Host-Namen aussuchen, unter dem man erreichbar sein möchte. Pro Account erlaubt der Anbieter fünf dynamische und fünf statische Host-Einträge. Die dynamischen Einträge werden nach 35 Tagen ohne Update der IP-Adresse gelöscht. Dafür bleiben sie nur 60 Sekunden im Cache der Name-Server - ideal, falls sich die IP rasch hintereinander ändert. Die statischen Einträge behalten auch nach Ablauf von 35 Tagen ihre Gültigkeit, bleiben allerdings vier Stunden im Cache.

Nach der Registrierung ist der Rechner unter dem angegebenen Namen erreichbar - sofern er online ist. Eine Abwesenheitsmeldung für den umgekehrten Fall gewährt DynDNS.org nur denjenigen, die das Unternehmen mit einer Spende unterstützen. Allerdings wird keine Mindestsumme genannt.

Um die Zuordnung von Host-Namen und IP-Adresse stets auf dem aktuellen Stand zu halten, benötigt man außerdem einen DDNS-Client. Eine reiche Auswahl für verschiedene Plattformen finden Sie auf der Site von dyndns.org. Die Client-Anwendung läuft im Hintergrund und synchronisiert in einstellbaren Intervallen die in der Datenbank von DynDNS.org (oder anderen Anbietern) eingetragene IP mit der gerade aktuellen.

Nach diesen Schritten hat man die Basisfunktionalität hergestellt. Echten Mehrwert erhält man durch das Einspielen zusätzlicher Applikationen, etwa eines Webservers wie Apache oder einer Remote-Control-Software wie VNC.

Fazit

Wer vorhat, seinen DSL-Zugang zu optimieren, sollte vorab bedenken, dass zahlreiche externe Faktoren die Performance negativ beeinflussen können. Das betrifft beispielsweise die Entfernung des eigenen Standorts von der Ortsvermittlungsstelle oder die Anbindung des ISPs und der angesprochenen Server. Selbst im Idealfall erreicht der Datendurchsatz maximal 87 Prozent des Nennwerts. Ein Download mit durchschnittlich 890 Kbit/s von theoretisch möglichen 1024 Kbit/s liegt also bereits am oberen Rand des Leistungsspektrums.

Vermuten Sie dennoch die Geschwindigkeitsbremsen im Betriebssystem, empfiehlt es sich, einige TCP/IP-Parameter zu überprüfen. Nach unseren Erfahrungen sollte sich das Tuning auf die Einstellungen von MTU, MSS und RWIN konzentrieren. Ist man etwa vom Analog-Modem auf Breitband umgestiegen, reicht die von MTU festgelegte Paketgröße nicht mehr aus. Die spürbarste Steigerung der Transferrate brachte bei unseren Tuning-Versuchen allerdings ein höherer Wert für RWIN, der die Größe des Empfangspuffers bestimmt.

Soll der frisch getunte Rechner auch als Server im Web verfügbar sein, bieten sich Dienste wie DynDNS.org an. Sie sorgen dafür, dass man auch mit einer dynamischen IP-Adresse unter einem festen Host-Namen erreichbar bleibt. Für einen solchen Computer zählt neben einem Virenscanner unbedingt auch eine Firewall zur Grundausstattung. Schließlich will man seine Daten nicht mit jedem teilen. (mha)