zurück zum Artikel

Viele PCs nutzen die Kapazität ihrer DSL-Verbindung nicht aus. Mit Traffic Shapern oder den richtigen Änderungen in der Windows-Registry lassen sich Downloads beschleunigen, ohne dass die Qualität von VoIP- oder Streaming-Verbindungen leidet.

Aussetzer bei der VoIP [1]-Telefonie oder stockende Übertragung und zu niedriger Durchsatz trotz sehr schnellem DSL [2]-Anschluss sind Probleme, deren Ursachen Windows mit Bordmitteln nicht offenbart. Grundsätzlich kann man drei Fehlerquellen unterscheiden: Die Einstellungen für das TCP/IP [3]-Protokoll des Rechners sind ungünstig, eines oder mehrere Elemente der Internet-Verbindung sind überlastet oder die Daten von mehreren gleichzeitig genutzten Internet-Anwendungen behindern sich mangels einer übergeordneten Verkehrsleitung gegenseitig.

Die TCP-Einstellungen, die die Geschwindigkeit beeinflussen, sind aber nicht über die Windows-Oberfläche zugänglich, sondern in der Registry verborgen. Deshalb läuft der PC bei den weitaus meisten Nutzern im Autopilot-Modus und Fehleinstellungen fallen nur dem Fachmann bei einer detaillierten Untersuchung auf. Die wichtigsten TCP/IP-Variablen, die man in der Registrierung verwaltet, sowie die empfehlenswerten Einstellungen haben wir unter Stellschrauben [4] aufgeführt.

Download anschieben

Ein Grund für zu langsame Downloads bei schnell angebundenen PCs liegt darin, dass die Internet-Endstellen zu kleine Datenmengen senden (Window Size, bei Unix-Systemen RWIN genannt). Das führt dazu, dass zum Beispiel ein Server bei einem Download häufiger auf Quittungen des Empfängers warten muss als technisch nötig, ein Teil der Leitungskapazität also ungenutzt bleibt.

Auf die Server-Einstellung hat man als Surfer keinen Einfluss. Aber der Administrator kann die niedrige Einstellung durchaus gewollt haben – um möglichst viele Teilnehmer gleichzeitig bedienen zu können oder um eine Server-Überlastung zu verhindern.

Der Server muss nämlich für jede einzelne TCP-Verbindung die festgelegte Window Size als Pufferspeicher bereitstellen. Bei stark frequentierten, aber mit Speicher mager ausgestatteten Servern limitiert man also die Window Size, damit der Server mit dem RAM [5] auskommt. Der Internet-Service cdrom.com war eine Zeit lang auf 30 KByte pro TCP-Verbindung eingeschränkt und manche Betreiber von Spiele-Servern limitieren ihre Demo-Zugänge weiterhin auf diese Art.

Wenn der Durchsatz pro TCP-Verbindung mittels kleiner Window Size eingeschränkt ist, können Download-Manager helfen, indem sie mehrere Verbindungen gleichzeitig öffnen und eine Datei in mehreren Segmenten laden (Siehe dazu: Parallel-Turbo, Schnelles Laden von Dateien mit Download-Managern für Windows, c't 11/06, S. 106 [6].)

Ist hingegen die Window Size des lokalen Rechners zu niedrig, kann man sie in der Registrierung höher stellen. Tuning-Utilities, von denen es zahlreiche gibt, erledigen solche Einstellungen automatisch, zum Beispiel der T-Online Speedmanager. Ein größeres Window kann jedoch die Latenz erhöhen, sodass mit dieser Einstellung überlegter Umgang angebracht ist. Eine Faustformel für optimale Download-Einstellungen finden Sie im unter Stellschrauben [7].

Weitaus häufiger kommt es vor, dass man als Surfer einen schnellen Server selbst ausbremst, und zwar, indem man parallel zum Download eine oder mehrere Internet-Anwendungen nutzt, die die Sendekapazität des DSL-Anschlusses beanspruchen – Sendedaten lokaler Anwendungen behindern nämlich den Versand von Quittungspaketen (ACK-Pakete, Acknowledge), und ohne fortschreitende Quittungen stockt der Download.

In der Tabelle Durchsatzbremsen [8] lassen sich die dabei auftretenden Symptome beobachten: Ping-Zeiten variieren je nach Situation stark, und Uploads bremsen gleichzeitige Downloads aus.

Der Grund liegt darin, dass im Internet alle Pakete um die verfügbare Bandbreite unkoordiniert konkurrieren – wer zuerst kommt, mahlt zuerst. Auch gibt es anders als im Telefonnetz keine geschaltete Ende-zu-Ende-Verbindung, sondern die Pakete werden einfach von Hop zu Hop bis zum Ziel weitergereicht.

Wenn sie unterschiedliche Wege zum Ziel nehmen, reisen sie unterschiedlich schnell, und wenn zwischengeschaltete Router [9] überlastet sind, können Pakete verloren gehen. Mit beiden Situation wird das TCP-Protokoll dank einer ausgeklügelten Flusskontrolle in der Regel fertig. Als Surfer bemerkt man von der teils komplexen Signalisierung, den Paketverlusten, Haltezeiten und Sendewiederholungen nichts, nur unterm Strich registriert man einen enttäuschenden Durchsatz.

Mischbetrieb

Mischbetrieb

Solche Reibungsverluste dürften noch zunehmen, weil Netzbetreiber ihre schnellen Anschlüsse für Triple-Play [10]-Kombinationen anbieten – Internet, IPTV und VoIP-Telefonie nutzen dann zum Beispiel WG- oder Familienmitglieder parallel zum Mail-Versand und Online-Spielen. Dabei konkurrieren alle Anwendungen unkoordiniert um die Bandbreite eines Anschlusses und dann treten bei der VoIP-Telefonie zu hohe Verzögerungen und Aussetzer auf, Downloads laufen zäh und die Reaktionszeit bei Spielen nimmt überproportional zu.

An der Bandbreite der Internet-Backbones liegen solche Probleme nicht; die haben ausreichend Reserven. Ein Flaschenhals liegt zwischen dem Endkunden und dem Internet-Service-Provider, die "letzte Meile". Diese Teilnehmeranschlussleitung (TAL) zum Provider hat am wenigsten Bandbreite und deshalb stauen sich die Daten davor und dahinter.

Besonders deutlich fällt dieser Effekt bei extrem asymmetrischen Anschlüssen auf, zum Beispiel bei ADSL2+. Dabei liefert der Empfangskanal bis zu 16 MBit/s, während der Sendekanal maximal 1 MBit/s befördert. Geht auf so einem Anschluss ein Download mit maximaler Geschwindigkeit ein, ist der Senderkanal schon zu 50 Prozent allein mit ACK-Paketen gefüllt und sobald eine weitere Anwendung sendet, treten die üblichen Symptome auf.

Es kann daher von Vorteil sein, die Upload-Geschwindigkeit für bestimmte Anwendungen zu begrenzen. Zum Beispiel bringen viele Tauschbörsen-Programme Funktionen für die Bandbreitenbegrenzung mit und wenn man mehrere solcher Programme gleichzeitig nutzt, etwa eMule [11] und BitTorrent [12], muss man sogar jedem Programm einen festen Teil der Gesamtbandbreite zuordnen. Leider bieten viele andere Anwendungen, etwa FTP [13]-Clients oder Mail-Programme, keine solche Option.

VoIP-Bedürfnisse

Beim Internet-Radio oder auch IPTV müssen die Daten mit einer konstanten Rate abgespielt werden. Die Pakete kommen jedoch nicht mit einer konstanten Datenrate beim Empfänger an, weil sie unterschiedliche Wege nehmen oder zwischengeschaltete Router vorübergehend ausgelastet sind.

Daher puffern die Player die eingehenden Pakete und lesen sie mit einer konstanten Datenrate aus. Die Puffergröße wählt der Player so, dass er Übertragungsaussetzer von einigen Sekunden ausgleichen kann. Wird die Verzögerung zu lang, läuft der Puffer leer und die Musikwiedergabe setzt kurz aus beziehungsweise das Video ruckelt. Um solche Situationen zu vermeiden, würde man den Puffer instinktiv großzügig dimensionieren.

Streaming- oder auch VoIP-Daten kommen nicht mit einer konstanten Geschwindigkeit an. Daher werden sie nach dem Empfang gepuffert und dann mit einer konstanten Rate abgespielt. Das hat bei Streaming-Anwendungen lediglich einen kleinen Nachteil zur Folge: Die Latenz nimmt zu und die Wiedergabe eines Video-Clips setzt später ein als bei kleinem Puffer.

Bei Voice over IP toleriert man aber nur geringe Latenzen. Steigen sie über 200 ms, empfindet man sie als störend, weil unklar ist, wann der Gesprächspartner schweigt, sodass man ihm ungewollt ins Wort fällt.

Einerseits will man also möglichst große Puffer, um Aussetzer zu vermeiden, andererseits will man möglichst kleine Puffer, um kurze Antwortzeiten zu erreichen. Verschiedene Verfahren bieten einen Ausweg aus dieser Zwickmühle. Der eleganteste Ansatz besteht darin, die VoIP-Pakete höher zu priorisieren, damit sie andere Pakete möglichst wenig aufhalten.

Dafür müsste jedoch eine Verbindung Ende-zu-Ende mit definierter Bandbreite und Latenz ausgehandelt werden und alle Router einer Strecke müssten sich daran beteiligen (Quality of Service – QoS [14]). Doch dafür ist nicht nur ein globales Prioritätsschema erforderlich, sondern die Router der Backbones müssten ziemlich viele Daten puffern und priorisieren – also deutlich mehr Speicherkapazität und Rechenleistung haben als heutige. Immerhin wendet aber der eine oder andere Carrier intern schon ein wenig QoS an und befördert etwa VoIP-Pakete bei hohem Andrang bevorzugt.

[15]

Intelligente Ampelsteuerung

Intelligente Ampelsteuerung

Die Lösung auf Anwenderseite heißt Traffic Shaping. Traffic Shaper steuern den Netzwerkverkehr, um die Latenz zu kontrollieren. Dabei werden die Internet-Päckchen klassifiziert und je nach Priorität unterschiedlich schnell auf den Weg gegeben.

Der einfachste Mechanismus ist die Priorisierung von ACK-Paketen. Damit lässt sich schon mal die Download-Geschwindigkeit erhöhen, weil die Quittungen ohne Verzug abgeschickt werden. Genau besehen ist das aber nur der Anfang – im Grunde sollten sämtliche von einem PC ausgehende Datenströme nach Wichtigkeit für den Anwender priorisiert werden.

Für diverse Betriebssysteme gibt es Traffic-Shaper-Programme, darunter FreeBSD, Mac OS X, Linux und Windows (cFos und cFosSpeed [16], NetLimiter [17]). Bei FreeBSD und Mac OS X kann man das Freeware-Tool Throttled [18] einsetzen, das die ohnehin schon in der Firewall vorhandenen Funktionen mit einem Frontend versieht. Linux hat einen Packet-Scheduler im Kernel, der mit dem Layer-7-Packet-Classifier zusammenarbeitet. Letzterer erkennt Pakete bestimmter Anwendungen am Inhalt und kann sie so priorisieren. Auch können viele Router zumindest ACK-Pakete beschleunigt weiterleiten. Einige, etwa Fritz!Box Fon, bevorzugen auch Voice-over-IP-Pakete beim Versand und High-End-Router priorisieren gar sämtlichen Internet-Verkehr, den sie zuordnen können.

Idealerweise sollte Traffic Shaping zentral, also im Router stattfinden. Der Traffic Shaper kann dann den Verkehr aller LAN [19]-Teilnehmer zum Internet hin priorisieren. Dafür muss er möglichst alle Protokolle kennen – und das geht in der Praxis nicht immer. Zum Beispiel ist die Identifizierung von Paketen des VoIP-Dienstes Skype schwierig oder auch die verschlüsselte Kommunikation von BitTorrent. Sowohl der PC als auch der Router können die Pakete zwar analysieren, aber der PC ist im Vorteil, weil er die Datenströme ihm nicht bekannter Protokolle auch noch anhand der Programmnamen zuordnen kann.

Traffic Shaper haben eine ganze Reihe von Tricks auf Lager, um den Datenverkehr bei völlig unterschiedlichen Kommunikationsszenarien in Fluss zu halten. Einige arbeiten mit einem festen oder automatisch erzeugten Parametersatz, andere erlauben dem Anwender weitreichende Eingriffe. Wer will, kann dann einzelne Verbindungen nach IP-Adresse, Portnummer, Layer-7-Protokoll, Programmname und diversen anderen Kriterien manuell priorisieren.

Standardmäßig stellt zum Beispiel cFos unterschiedliche Prioritätsqueues zur Verfügung. Hochpriorisierte Daten gibt das Programm grundsätzlich bevorzugt auf den Weg. Die Queue-Kapazität ist auf drei Sekunden limitiert – wird sie größer, verwirft der Traffic Shaper Datenpäckchen, die die Queue verlängern würden – sonst zieht sich der Versand zu lange hin. Der TCP-Stack schließt daraus, dass die Strecke zurzeit ausgelastet ist, versucht es später wieder und sendet fortan mit weniger Bandbreite. In der Praxis laufen die hoch priorisierten Queues aber nie über. Niedrig priorisierten Daten gewährt cFos einen Mindestdurchsatz (25 Prozent der Sendekapazität), sodass langsame TCP-Verbindungen nicht verhungern.

Wie ein Traffic Shaper die TCP-Kommunikation optimieren kann, illustrieren Beispiele, bei denen über eine ADSL-Leitung zunächst unterschiedliche Download- und Upload-Szenarien mit und ohne Traffic Shaping laufen. Dabei beobachtet man, dass der Download-Durchsatz ohne Traffic Shaping trotz ausreichender Window Size deutlich unter der physikalischen Download-Rate liegt (2 MBit/s). In der Tabelle Durchsatzbremsen [20] sind die Werte für einen Test-PC aufgeführt, der bei einem ungebremsten Download rund 230 kByte/s befördert, jedoch bei parallelem Upload nur noch rund 130 kByte/s erreicht – die Hälfte der Empfangsbandbreite liegt also brach.

Auf die Finger geschaut

Auf die Finger geschaut

Diese Situation entsteht, wenn zum Beispiel während des Downloads eine größere Mail verschickt wird. Dann wird der Sendepuffer über einen längeren Zeitraum kontinuierlich mit Daten gefüllt. Geht man von einem Anschluss aus, der maximal 128 kBit/s senden kann, dauert es rund zwei Sekunden, bis 32 kByte Daten verschickt sind. Wenn in dieser Situation ein ACK-Paket, das den Fortgang des Downloads aufrecht erhalten soll, ans Ende des Puffers geschrieben wird, dauert es eben zwei Sekunden, bis es überhaupt losgeschickt wird, und noch weitere Millisekunden, bis es angekommen ist.

Ein deutlich besseres Ansprechverhalten erzielt man schon, wenn man den Tauschbörsen-Upload limitiert (etwa auf 75 Prozent der Sendekapazität). Dann ist der Sendepuffer so häufig leer, dass ACK-Pakete von Downloads, VoIP-Päckchen, Online-Spiel-Daten und anderem mehr ohne Verzögerung weitergeleitet werden.

Besser, weil umfassender, macht das ein Traffic Shaper, weil er alle wichtigen Pakete erkennt und sie im einfachsten Fall direkt an den Anfang des Sendepuffers schreibt, sodass sie alle anderen Daten überholen. Am besten sind mehrere Queues, die unterschiedliche Prioritäten haben – sie werden unterschiedlich schnell ausgelesen und die darin zwischengelagerten Daten gelangen je nach Lesepriorität unterschiedlich schnell auf den Weg.

Angewendet auf dem Anschluss einer Familie könnte ein Traffic Shaper also die Voice-over-IP-Daten am höchsten priorisieren, dann die Spiele-Pakete und den IPTV-Datenstrom weitergeben und schließlich Mails auf den Weg bringen. Die dann noch zur Verfügung stehende Bandbreite überlässt er Tauschbörsen-Programmen. Sie können aber vorübergehend sogar weiter gebremst werden, damit etwa Urlaubsfotos mit akzeptabler Geschwindigkeit verschickt werden. Letztlich sind die Priorisierungen aber persönliche Entscheidungen der Anwender. Spielernaturen dürften die Game-Pakete vermutlich höher priorisieren als den VoIP-Verkehr.

Verschränkung lösen

Bei vielen Providern lässt sich die Latenz der DSL-Leitung per FastPath [21]-Option verkürzen. Von Haus aus arbeiten die DSL-Anschlüsse nämlich mit einer robusteren Kodier-Art (höheres Interleaving), die auf Kosten der Durchlaufzeit der Daten geht – und FastPath senkt die Durchlaufzeit. Manche Hardcore Gamer gehen so weit, einen DSL-Anschluss mit FastPath eigens für Spiele anzuschaffen.

Zu beachten ist aber, dass FastPath nur bei Leitungen mit guter Übertragungsqualität empfehlenwert ist. Hat man eine, die vielen Störungen ausgesetzt ist, sinkt zwar die Latenz, aber Paketverluste nehmen zu und das TCP/IP-Protokoll muss sich selbst um die Fehlerkorrektur kümmern. Bei TCP-Verbindungen schlagen dann die Mechanismen zur Sendewiederholung an. Dann sinkt zum Beispiel bei HTTP-Downloads der Durchsatz stark. Bei UDP-Verbindungen gibt es jedoch keine Fehlerkorrektur, sodass sich Paketverluste zum Beispiel bei VoIP-Anwendungen als Aussetzer bemerkbar machen.

Aufgaben abwälzen

Ein wenig bekanntes Feature von Windows XP ist das "Task Offloading", bei dem das Betriebssystem den Prozessor entlastet, indem es bestimmte Aufgaben an speziell dafür entwickelte Netzwerkkarten überträgt. Microsoft hat dafür die Berechnung der IP- beziehungsweise TCP-Checksumme, verschiedene Arbeitsschritte bei der IPSec [22]-Verschlüsselung sowie die TCP-Paket-Segmentierung als "Task Offloading" spezifiziert [23].

Bei der Berechnung der IP- oder TCP-Checksummen muss der Prozessor sämtliche übertragenen Daten einmal "anfassen", was eine gewisse Belastung suggeriert. Bei der IPSec-Verschlüsselung kann die Netzwerkkarte die Berechnung von MD5- beziehungsweise SHA1-Hash-Werten sowie die Verschlüsselung mittels Triple-DES [24] übernehmen. Beispielsweise tun das die 3Com-Karten 10/100 Secure NIC [25] sowie 10/100 Secure Server NIC. Das entlastet den Prozessor spürbar, wenn er IPSec-Daten sehr schnell befördern muss, etwa im GBit-LAN.

Bei der TCP-Paket-Segmentation werden Pakete, die größer sind als die MTU [26], von der Netzwerkkarte selbstständig in kleinere TCP-Segmente unterteilt und einzeln gesendet (zum Beispiel KillerNic von Bigfoot Networks).

Einige Netzwerkkarten unterstützen einen Teil dieser Aufgaben, darunter sogar Onboard-Karten (zum Beispiel nForce4 Ultra). Manche Tuning-Tüftler werden daher wohl eine solche Anschaffung erwägen. Doch Task-Offloading ist nur dann "nice to have", wenn die CPU stark mit Netzwerk-Aktivitäten beschäftigt ist, etwa bei vielgenutzten Servern. Deshalb sind im Server-Bereich bei Sun oder auch IBM solche Karten häufiger vertreten.

Im Privat-Umfeld und in kleineren Büronetzwerken wirkt sich diese Funktion aber nicht auf die Übertragungsgeschwindigkeit aus. In Tests zeigte sich zum Beispiel, dass heutige Prozessoren bei aktuellen Sende-Bandbreiten die Checksummen nebenbei berechnen. Auch sollte man bedenken, dass viele LANs bereits mit Gigabit-Geschwindigkeit arbeiten, also rund 100 MByte/s anliefern, aber aktuelle Festplatten kaum über 70 MByte/s annehmen können. Der Flaschenhals ist bei modernen LANs also nicht die Netzwerkkarte, sondern das Speichermedium.

[27]

Stellschrauben

[28]

Stellschrauben

Es gibt einen ganzen Haufen von Parametern, die das Internet-Verhalten eines Windows-XP-Rechners beeinflussen. Windows bietet dafür jedoch kein grafisches User-Interface, sondern lediglich Einstellungen in der Registry. Eine vollständige Liste dieser Parameter hat Microsoft auf den Support-Seiten veröffentlicht. Die Dokumentation von Microsoft ist in diesem Punkt aber oft dünn, stellenweise auch irreführend, sodass wir die wichtigsten Parameter en détail erklären.

Fast alle sind im Bereich HKLM\­SYSTEM\­CurrentControlSet\­Services\­Tcpip\Parameters einsortiert. Die Parameter sind im DWORD-Format anzugeben und Änderungen werden erst nach einem Neustart aktiv. Wenn die hier genannten Schlüssel nicht existieren, verwendet Windows Standardwerte.

TcpWindowSize, im Unix-Bereich auch RWIN genannt, gibt an, wie viele Byte der Sender ohne Empfangsbestätigung schicken darf. Microsoft schreibt dazu, dass dieser Wert unter Windows XP per Faustformel eingestellt wird:

12 × (MTU des Adapters - 40)

Das genügt für Modem- und ISDN-Verbindungen, aber für DSL-Anschlüsse ist der Wert zu niedrig. In der Praxis scheint sich Microsoft nicht immer an die eigene Dokumentation zu halten. Beispielsweise fanden wir bei Stichproben DSL- und Kabelmodem-Treiber, deren Window-Size auf 65.535 Byte eingestellt war. Das irritiert Anwender, die noch nicht so weit mit der Materie befasst sind. Ob aber der eingestellte Wert für einen bestimmten Anschluss gut genug ist, lässt sich leicht mit dieser Formel prüfen:

Window Size = Downstream-Rate in Byte pro Sekunde/3

So sind schnelle Downloads bei Servern möglich, deren Antworten bis zu 333 ms zum Eintreffen brauchen (Roundtrip Time, lässt sich zum Beispiel mit Ping ermitteln). Sollte der Anschluss häufig durch Uploads ausgelastet sein, muss man noch höhere Werte einstellen, um die Empfangsbandbreite auszuschöpfen.

Für VoIP-Anwendungen sind deutlich geringere Werte sinnvoll:

Window Size = Downstream-Rate in Byte pro Sekunde/10

Das drückt natürlich die Download-Rate, sodass man diesen Wert in der Praxis nur ungern einstellen möchte, zumal für jede Änderung ein Windows-Neustart erforderlich ist. Daher greift man lieber zu einem Traffic Shaper, der die richtige Einstellung während des Betriebs automatisch vornimmt.

EnablePMTUDiscovery aktiviert beziehungsweise deaktiviert die Path MTU Discovery (Wert 1 respektive 0). Diesen Eintrag sollte man nicht ändern, also die Path MTU Discovery aktiviert lassen.

EnablePMTUBHDetect, Black Hole Detection, ist standardmäßig deaktiviert (Wert 0), weil sonst Verzögerungen entstehen können. Diese Funktion ist nur dann nützlich, wenn die Path MTU Discovery wegen eines Black Hole fehlschlägt.

Wenn ein Router bei der MTU-Analyse ein zu großes Paket wegen des Don't-Fragment-Bits nicht zerteilt, sondern verwirft, schickt er dem Sender eine Fehlermeldung, sodass Letzterer die MTU senken kann. Geht die Fehlermeldung verloren, scheitert dieser Mechanismus, und dann spricht man von einem Black Hole. EnablePMTUBHDetect kann mit solchen Situationen umgehen, senkt aber erfahrungsgemäß den Durchsatz.

DefaultTTL: Time To Live, gibt an, wie viele Router im Netz ein Datenpaket maximal bis zum Ziel weiterreichen dürfen (Hops). Wird die maximale Hop-Anzahl überschritten, müssen die Router das Paket verwerfen und den Sender benachrichtigen. Dieser Parameter hat entgegen anderslautender Meinungen keinerlei Einfluss auf die Übertragungsgeschwindigkeit – man bekommt allenfalls früher eine Nachricht, dass der Ziel-Server nicht erreicht wurde, schränkt aber die Wahrscheinlichkeit ein, dass ein entfernter Server erreicht wird, der eben jenseits der TTL liegt. Der Wert sollte nicht kleiner als 64 gesetzt werden, da sonst Gefahr besteht, dass die Pakete ihr Ziel nicht erreichen. Die Standardeinstellung ist 128.

SackOpts schaltet Selective Acknowledgments ein (SACKs). Der Empfänger kann damit einzelne Pakete quittieren, auch wenn er sie nicht in der Reihenfolge empfängt, in der sie der Sender geschickt hat. Diese Option ist standardmäßig aktiviert (1=SACK) und sollte es auch bleiben, da sie die Verzögerungen bei Paketverlust auf ein Minimum senkt, ohne nennenswert Bandbreite zu kosten.

Tcp1323Opts schaltet Window Scaling und Timestamps ein respektive aus. 0 deaktiviert Window Scaling und Timestamps, 1 schaltet nur Window Scaling ein, 2 schaltet nur Timestamps ein, 3 schaltet beides ein (Standard).

Timestamps ermöglichen es, den TCP Retransmission Timeout genauer zu berechnen und anhand dessen entscheidet der Sender, wann er im Fehlerfalle ein Datenpaket neu schickt. Das ist wichtig, wenn man eine sehr große TcpWindowSize benutzt.

MTU, Maximum Transmission Unit, maximale Größe eines IP-Pakets mitsamt IP-Header [29], TCP-Header und Nutzdaten. –1 ist die Voreinstellung und bedeutet, dass der Stack die maximale Paketgröße automatisch mittels Path MTU Discovery ermittelt.

Aus der MTU berechnet man den TCP-Parameter MSS [30] (Maximum Segment Size, die maximale Menge an Nutzdaten pro Paket):

MSS = MTU - 20 Byte TCP-Header - 20 Byte IP-Header

Die MTU findet sich als einziger TCP-Parameter im Subkey Interfaces unter der GUID des Adapters. Ist kein MTU-Wert vorhanden, wird Path MTU Discovery verwendet, um den passenden Wert zu ermitteln. Falls also ein Wert eingetragen ist, empfiehlt es sich in der Regel, ihn zu löschen.

Die GUID des DFÜ-Adapters ist gut versteckt: es ist die letzte Zeile aus dem Eintrag unter HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Adapters \NdisWanIp\IpConfig.

Anders als manche Surfer meinen, muss die Window Size nicht unbedingt ein ganzzahliges Vielfaches der MSS sein – das passt zwar theoretisch prima in das TCP-Schema, aber sobald ein Router auf dem Weg per Path MTU Detection eine kleinere MSS erzwingt, ist die Einstellung ohnehin Makulatur und daher in der Praxis nicht wichtig.

Byte-Knauserei

Byte-Knauserei

Ein TCP-Wert, an dem gerne gedreht wird, ist die MTU, die Maximum Transmission Unit. MTU gibt die maximale Größe eines Pakets an, das ein Netzwerk ohne Fragmentierung befördern kann. Dabei gibt es widerstreitende Interessen bezüglich der optimalen Größe.

Je größer die MTU, desto günstiger das Verhältnis von TCP/IP-Header zu Nutzdaten. Ein TCP/IP-Header besteht aus 40 Byte. Beim Schritt von einer kleinen MTU (zum Beispiel 576 Byte) zu einer großen MTU von 1500 Byte sinkt der Header-Anteil von 6,9 auf 2,7 Prozent.

Es gilt aber auch: Je größer ein Paket, desto länger braucht es für die Übertragung. Wenn nun interaktive Anwendungen parallel mit einem Upload laufen, etwa eine ssh-Sitzung oder ein VoIP-Telefonat, kommt es vor, dass das ssh-Paket, das ein einziges Eingabezeichen befördert, hinter einem 1500 Byte großen Upload-Paket eingereiht wird. Das kleine Paket kann also erst danach verschickt werden. Bei einer Upstream-Geschwindigkeit von 192 kBit/s (24 kByte/s) dauert das immerhin 62 ms. Das kann bei interaktiven Anwendungen wie eben einer ssh-Sitzung oder beim Telefonieren schon störend sein. Ein kleineres Paket von 576 Byte macht den Weg hingegen schon nach 24 ms frei – der gemischte Verkehr läuft also flüssiger ab. Davon profitieren beispielsweise Online-Spiele.

Steigende Upstream-Bandbreiten mildern dieses Problem zunehmend. Schon MTUs über 1500 Byte sind untypisch und werden kaum zu realisieren sein, da die Ethernet [31]-Leitungen, die viele Provider intern für die Weiterleitung einsetzen, maximal 1500 Byte pro Paket transportieren. Zudem dürfen PPPoE [32]-Pakete nur maximal 1492 Byte groß sein, sodass ein DSL-Router 1500 Byte große Ethernet-Pakete seines LAN in zwei PPPoE-Pakete teilen müsste. Das würde den Durchsatz deutlich senken. Eines hätte die maximale Länge von 1492 Byte IP-Daten plus 8 Byte PPPoE-Header, das zweite jedoch nur die restlichen 8 Byte des Ethernet-Frames als Nutzdaten sowie 20 Byte IP-Header und 8 Byte PPPoE-Header.

MTU-Automatik

Glücklicherweise kann der Sender die optimale MTU feststellen, wenn Path MTU Discovery eingeschaltet ist. Dann senkt er den Wert automatisch, denn TCP tut alles, um zu verhindern, dass Pakete fragmentiert werden. Es kostet Zeit und Speicher, fragmentierte Pakete am Ziel zusammenzusetzen. Auch sind größere Pakete bei Paketverlust kostspieliger – es dauert länger, bis der Fehler korrigiert ist und der Durchsatz sinkt stärker als bei kleinerer MTU.

Bei der Path MTU Discovery werden alle Pakete mit dem "Don't-Fragment-Bit" gekennzeichnet und zunächst mit der am gegebenen Adapter maximalen Größe versandt. Falls ein auf der Strecke befindlicher Router das Paket nicht ohne Fragmentierung weitergeben kann (was ihm das Don't-Fragment-Bit verwehrt), verwirft er das Paket und meldet dem Sender einen Fehler mitsamt seiner maximalen Paketgröße.

Der Sender passt dann die Paketgröße an und wiederholt den Versuch, bis er zum Ziel durchkommt. Weil sich die Route zwischen Sender und Empfänger ändern kann, wendet der Sender die Methode gelegentlich wieder an. Bei DSL mit PPPoE beträgt die MTU 1492 Byte, bei ISDN, DSL mit PPPoA oder Kabel in der Regel 1500 Byte.

Beim Aufbau einer TCP-Verbindung sendet jede Seite die von ihr maximal akzeptierte Maximum Segment Size. Dieser Wert ergibt sich aus der MTU – 40 Bytes für den TCP/IP-Header. Wenn eine Endstellen MSS = 1460 meldet, kann sie also Pakete bis zu 1500 Byte Größe nutzen (1460 + 40). Die MSS ist aber nur eine Obergrenze. Sollte Path MTU Discovery einen kleineren Wert ergeben, wird dieser benutzt.

Vista bringt Verbesserungen

Vista bringt Verbesserungen

Viele der hier vorgestellten Techniken sind auf Windows XP bezogen, etliche lassen sich auch unter anderen Betriebssystemen anwenden. Mit Vista, dessen TCP/IP-Stack Microsoft komplett überarbeitet hat, haben die Redmonder einiges verbessert: Für Änderungen bestimmter Parameter ist – anders als bei XP und Vorgängern – kein Neustart erforderlich.

Um etwa VoIP-Aussetzern beizukommen, kann man den RWIN-Wert manuell verkleinern, damit sich Daten möglichst wenig stauen. Dann muss man aber bei Windows XP bis zur nächsten RWIN-Änderung mit anschließendem Reboot in Kauf nehmen, dass der Download von weit entfernten Servern deutlich langsamer geht als möglich. Vista erlaubt es hingegen, den RWIN-Wert beispielsweise vor einem VoIP-Telefonat zu verkleinern und danach ohne Reboot heraufzusetzen. Außerdem bringt Vista eine "Automatic configuration of stack settings" mit, das die Window Size der Bandbreite anpasst. (ssu [33])

URL dieses Artikels:
https://www.heise.de/-221778

Links in diesem Artikel:
[1] http://www.heise.de/glossar/entry/Voice-over-IP-395310.html
[2] http://www.heise.de/glossar/entry/Digital-Subscriber-Line-396855.html
[3] http://www.heise.de/glossar/entry/Transmission-Control-Protocol-Internet-Protocol-398037.html
[4] #Stellschrauben-u4
[5] http://www.heise.de/glossar/entry/Random-Access-Memory-399469.html
[6] http://www.heise.de/kiosk/archiv/ct/06/11/106
[7] #Stellschrauben-u4
[8] #Durchsatzbremsen-u3
[9] http://www.heise.de/glossar/entry/Router-399395.html
[10] http://www.heise.de/glossar/entry/Triple-Play-397613.html
[11] http://www.emule-project.net/
[12] http://www.bittorrent.com/
[13] http://www.heise.de/glossar/entry/File-Transfer-Protocol-398667.html
[14] http://www.heise.de/glossar/entry/Quality-of-Service-398849.html
[15] 
[16] http://www.cfos.de/index2.htm
[17] http://www.heise.de/software/download/netlimiter_lite/17703
[18] http://www.heise.de/software/download/throttled/21887
[19] http://www.heise.de/glossar/entry/Local-Area-Network-399387.html
[20] #Durchsatzbremsen-u3
[21] http://www.heise.de/glossar/entry/Fastpath-397503.html
[22] http://www.heise.de/glossar/entry/IPSec-397475.html
[23] http://msdn2.microsoft.com/en-us/library/ms799293.aspx
[24] http://www.heise.de/glossar/entry/Triple-DES-397499.html
[25] http://www.heise.de/glossar/entry/Network-Interface-Card-399555.html
[26] http://www.heise.de/glossar/entry/Maximum-Transfer-Unit-398361.html
[27] 
[28] 
[29] http://www.heise.de/glossar/entry/Header-396869.html
[30] http://www.heise.de/glossar/entry/Maximum-Segment-Size-396837.html
[31] http://www.heise.de/glossar/entry/Ethernet-399379.html
[32] http://www.heise.de/glossar/entry/Point-to-Point-Protocol-over-Ethernet-396829.html
[33] mailto:ssu@ct.de

Copyright © 2007 Heise Medien