Windowsize, Latenz und Durchsatz

Manchmal neigt man dazu, physikalische Gegebenheiten zu ignorieren und getreu dem Motto "Viel hilft viel" schon davon auszugehen, dass es "passen" wird. Es gibt aber Grenzen, die im normalen Tagesbetrieb gar nicht wirklich auffallen, es sei denn es kommt zu Problemen. Ein oft vernachlässigtes Problem ist die Super-schnelle WAN-Leitung, deren Latenz und die damit erzielbare Übertragungsrate.

Diese Seite soll Sie auf die Thematik aufmerksam machen und weiterführende Links liefern. Sie bleibt aber etwas "einfacher" und geht nicht im Details auf die verschiedenen "Windows" ein wie "Recieve Window" und "Congestion Window". Beachten Sie daher die weiteren Links.

Beispiel: Nur 5 MBit über 100 MBit Link ?

Die Zeiten von 64kbit oder selbst wenigen Megabit an Übertragungsrate sind schon vorbei. Heute wird selbst im WAN mit Gigabit und Terabit gearbeitet und selbst Firmenstandorte lassen sich mit sehr schnellen breitbandigen Verbindungen koppeln. Das ist auch wichtig um z.B. Datensicherungen auszulagern, Exchange Datenbanken in eine Recovery-Site zu replizieren oder auch um Office 365 zu nutzen. Stellen Sie sich daher mal folgendes vor:

  • Zwei Standorte
  • 100 MBit WAN Link
  • Latenzzeit zwischen Endpunkten von 10ms
    Ich teile das mal auf 2x 2,5ms für das Routing an den jeweiligen Standort und 5ms als Laufzeit auf den WAN auf. Bedenken Sie, dass z.B. ein Paket über den Atlantik 70-90ms unterwegs ist.
  • XCOPY-Performance (SMB, aber auch HTTP-Download etc.)

Um zu verstehen, warum das so ist, müssen wir uns die Technik der WAN-Übertragung vor Augen führen:

Paketwege

Ein TCP-Paket wird von einem Endpunkt zum anderen Endpunkt über mehrere Stationen und Wege übertragen. Vernachlässigen wir mal den Computer und IP-Stack, PCI-Bus etc., dann gibt es zwei wichtige Stationen in dem Bild:

  • Switches/Router
    Diese Systeme müssen zumindest einen Teil des Pakets empfangen haben, damit sie den "Next Hop" ermitteln und das Packet weiter senden können. Ein Switch braucht dazu also zumindest die ersten 12 Bytes der "Ziel-MAC-Adresse". Ein IP-Router muss noch etwas länger warten, bis er die Ziel-IP-Adresse erhalten hat. Dann hängt es noch davon ab, ob der Vermittlungsknoten auf dem Ziel gerade "Platz" hat und ob die Weiterleitung nicht doch erst wartet, bis das komplette Paket oder die ersten 64bytes empfangen wurden, ehe er vielleicht auf dem nächsten Teilstück ein Paket mit defekter Prüfsumme Platz belegt. Diese Komponenten haben also einen "Buffer" und speichern das Paket zum teil oder gesamt zwischen. Damit erhöht sich die Latenzzeit. Jede Umschlagstation addiert etwas Zeit.
  • WAN-Link
    Wer bei einer elektrischen Leitung nun an einen Schaltkreis in der Wohnung mit einer Leuchte und dem Lichtschalter denkt, bei dem überall auf der Leitung der gleiche Spannungspegel anliegt, muss sich erst einmal davon lösen. Auch Strom ist nicht "unendlich" schnell. Wie sprechen von ca. 1/3 Lichtgeschwindigkeit. Wenn ich nun aber eine Leitung mit 5ms "Laufzeit" habe und mit 100MBit/s sende, dann ist ein einzelnes Bit gerade mal 1/100M = 0,01µs (=10 ns) lang. Auf eine Leitung, die aufgrund der Länge vielleicht 5ms Latenz aufweist, passen bis zu 500.000 "Bit" hintereinander auf die Leitung. Selbst mit 1.5Kbyte großen Paketen und unter Vernachlässigung von Codierverfahren und Pausen sind das 33 Pakete. Das ist Signaltechnik und nicht mehr Elektrotechnik.

Und das beschreibt nur den Hinweg und nicht den "Roundtrip". Nu ist es aber so, dass ein TCP-Client seine Pakete nicht einfach nur "los sendet", sondern natürlich ein Handshake auch die Zustellung absichert.

TCP Windows Size (64k) und Latenz

Es ist zwar nicht so, aber nehmen wir einmal an, dass ein Client auf jedes gesendete Paket erst die Quittung abwartet und die Verarbeitung der Pakete auf dem PC keine Zeit benötigt, dann rechnen wir mit den Zahlen aus dem Beispiel (10ms je Richtung) und kommen auf 20ms "Zeitbedarf" pro Paket. Wenn wir dann noch ein Paket von 1,5kBytes annehmen und die längere Übertragung aufgrund der Länge ignorieren, dann kann der Client maximal 1s/20ms = 50 Pakete senden oder 75kByte.

Aus dem Grund gibt es ein "Windows Verfahren", d.h. der Sender wartet nicht die Bestätigung des Empfangs ab, sondern sendet mehrere Pakete auf die Leitung und sammelt die Quittungen später ein. Das macht er natürlich nicht grenzenlos, sondern es gibt eine "Windows Size". Der Sender muss nämlich die Pakete noch in seinem Speicher halten bis die Quittung eingetroffen ist. Ansonsten könnte er das Paket ja nicht erneut senden, wenn es verloren gegangen ist. Die Standardgröße bei Windows für diesen Buffer ist 64kbyte. Damit ergibt sich eine einfache Rechnung für die maximale Übertragungsrate für eine TCP-Connection

Die TCP WindowSize ergibt sich aus den 64KB = 65536 Bytes = 524288 bits und mit verschiedenen Werte für die Latenzzeit kann der maximal mögliche Durchsatz als Diagramm dargestellt werden.

 

In einem LAN mit 0,5ms Latenzzeit kann eine einzelne TCP-Connection tatsächlich noch 1 GBit übertragen. Aber schon mit einer Verzögerung von 1ms halbiert sich der Durchsatz. Und mit 10ms bleiben gerade noch 51 Megabit technisch übrig. Erst die Veränderung der WindowsSize z.B. auf 128kByte oder sogar 256 kByte hebt bei 10ms die maximal mögliche Übertragungsrate auf 102 bzw. 205 Megabit an.

Luxusproblem ?

Wenn sie sich nun fragen, warum das nicht breiter bekannt ist, dann würde ich schon sagen, dass es sich bei den meisten Firmen eher um ein "Luxus-Problem" handelt. In einem LAN ist die Latenzzeit in der Regel so kurz, dass diese Obergrenze der Geschwindigkeit eher nicht erreicht wird. Zudem arbeiten viele Firmen in der Breite noch mit "Gigabit" oder weniger, so dass ein Client eher nicht an die Grenze stößt. Auf der Server-Seite ist das Problem weniger sichtbar, da dieses Limit "pro TCP-Connection" gilt. Wenn ein Prozess also mehrere TCP-Connections benutzt, dann multipliziert sich die maximal mögliche Datenrate. Ein Server mit 10 GBit Karte kann also immer noch viele hundert Client "voll" bedienen, ohne an Grenzen stoßen zu sollen.

Das Problem kann aber einen individuellen Client oder Server erwischen, wenn er eine Datenmenge über eine "langsame Leitung" zu genau einem anderen System übertragen will und dazu genau eine TCP-Verbindung genutzt wird. Denken Sie man an zwei Exchange Server in einer DAG, die ihre Datenbank "seeden" oder die Replikation zwischen zwei DAG-Mitgliedern.

Auch Richtung Office 365 könnte es zukünftig immer mehr Probleme geben wenn die Bandbreiten immer höher werden. Die Latenzzeit wird damit zwar für das "Stück Kabel" auch kürzer aber bleibt doch noch höher. Eine Migration von Exchange Postfächern in die Cloud wird heute zwar noch nicht maßgeblich durch diese Grenzen beschränkt, aber wie lange gilt dies noch ?

Real wird das Problem immer dann, wenn die WAN-Leitungen immer schneller werden und wir als Anwender und Administratoren uns daraus auch eine schnellere Datenübertragung erwarten. Die , aber die Latenzzeit einfach anhand er Physik (1/3 Lichtgeschwindigkeit) trotzdem nicht geringer wird.

Lösung

Die physikalischen Eigenschaften lassen sich nicht ändern aber die Nutzung der Bandbreite durch Applikationen kann über verschiedene Wege "optimiert" werden

  • Mehrere TCP-Streams
    Der einfachste Weg den Datendurchsatz zu erhöhen ist die Aufteilung der Arbeit auf mehrere Streams. Für viele Anwendungen ist dies sehr einfach möglich, z.B. das Kopieren von Dateien muss ja nicht sequentiell erfolgen, sondern über Threads können mehrere Dateien nebeneinander übertragen werden. Auch eine Backup/Restore-Funktion kann mehrere Streams aufsetzen, um die Performance zu steigern. Allerdings muss der Client und der Server da natürlich mitspielen.
  • kürzere Latenz
    Sie können auch im Bereich des Netzwerks versuchen, einfach "schneller" zu werden. Jeder Hop auf einer Verbindung kostet Zeit und je mehr Stationen involviert sind und diese vielleicht noch intensive Checks durchführen, desto langsamer wird der der Durchsatz. Allerdings ist das Potential hier eher darauf beschränkt, Engpässe zu ermitteln und zu beseitigen, die zusätzliche Verzögerungen noch draufsetzen.
  • Höhere WindowSize
    Wie Sie oben im Diagramm gesehen haben, können Sie natürlich auch mit einer höheren WindowSize arbeiten. Dann sendet der Client einfach mehr Pakete auf die Reise. Diese Einstellung ist in Windows möglich aber hat auch den Nachteil, dass der TCP-Stack sich mehr Pakete für eine eventuell erforderliche erneute Sendung merken muss. Der RAM-Speicherbedarf des TCP-Stack nimmt entsprechend zu. Das Risiko besteht aber, dass Router und das Zielsystem mit der "Überladung" nicht zurecht kommen. Wenn der Sender also statt 64kByte z.B. 256 KB sendet aber der Empfänger pro Verbindung eben nur 64kByte bereit stellt, führt dies im schlimmsten Fall zu einem Verbindungsabbruch. Denkbar sind aber auch einfach, dass die überzähligen Pakete verworfen werden, wodurch der Client diese selbst neu senden muss.
  • WAN Acceleratoren
    Zuletzt gibt es natürlich noch Geräte von Cisco, RiverBed und anderen Herstellern, die eine "Beschleunigung" des WAN versprechen. Sie tun dies schon viele Jahre durch die "Optimierung" von Paketen durch Kompression und Caching. Aber sie können auch die ACK-Pakete "simulieren" und damit den Sender dazu bringen weiter zu senden. Die "Sicherung" der Übertragung übernehmen dann diese Optimierer. Technisch wirkt es sich aus wie eine größere WindowSize

TCP Windows Scaling und TCP SACK

Am besten ist es natürlich, wenn niemand hier "manuell" Eingreifen muss, sondern die Systeme sich selbst entsprechen der Leitung verhalten und optimieren. Und natürlich haben auch die Entwickler von TCP schon viel früher das "Problem" erkannt und entsprechend nachgerüstet. So gibt es mit der RFC 1323 entsprechende Erweiterungen des TCP-Protokolls, mit dem Sender und Empfänger sich auf angepasste Werte abstimmen können.

Allerdings hängt es vom Betriebssystem ab, ob diese Funktionen unterstützt werden und auch aktiviert sind:

Betriebssystem TCP Window Scaling Bemerkungen und Links

Vor Windows 2000

Nicht implementiert

 

Windows 2000, XP, 2003

Implementiert aber per Default deaktiviert

224829 Description of Windows 2000 and Windows Server 2003 TCP Features

Vista, Server 2008 und neuer

Default aktiv, kann manuell abgeschaltet werden

Default Buffersize 64k. kann bis auf 16MB wachsen.

Linux Kernel < 2.6.8

Nicht aktiv

 

Linux Kernel >= 2.6.8

Per Default aktiv

Seit ca. Aug 2004.
Konfiguration kann in den Pseudo-Dateien "/proc/sys/net/ipv4/tcp_window_scaling", "/proc/sys/net/ipv4/tcp_rmem", "/proc/sys/net/ipv4/tcp_wmem" nachgeschaut werden.

FreeBSD, OpenBSD, NetBSD

Per Default eingeschaltet

 

MacOS

Per Default eingeschaltet

 

Wie sie sehen können, haben die Betriebssysteme schon seit mindestens 10 Jahren die Funktion "TCP Windows Scaling" nach RFC 1323 im Bauch und sogar aktiv. Insofern "sollten" die Endgeräte sich entsprechend der WAN-Leitung auf eine optimierte Bandbreite einstellen können. Allerdings kann es natürlich immer sein, dass in Router oder eine Firewall die RFC1323-Erweiterungen nicht durchlässt. Dann hängen die Clients auf 64kByte Windows fest und der Durchsatz ist gebremst. Die RFC beschreibt dazu:

2.2 Window Scale Option
The three-byte Window Scale option may be sent in a SYN segment by a TCP. It has two purposes: (1) indicate that the TCP is prepared to do both send and receive window scaling, and (2) communicate a scale factor to be applied to its receive window. Thus, a TCP that is prepared to scale windows should send the option, even if its own scale factor is 1. The scale factor is limited to a power of two and encoded logarithmically, so it may be implemented by binary shift operations.

Sonderfall SMB

Alle Protokolle, die auf Basis von TCP arbeiten, können von der dynamischen Window Site profitieren, wenn Sie denn ihre Daten auch "lossenden". Es gibt aber durchaus Protokolle, die ihre Daten nicht einfach "Streamen", sondern noch selbst in Blöcken organisieren oder einen eigenen Handshake mit aufbauen. Bei SMTP sind die ersten Pakete ja auch Befehle wie "Mail From", "RCPT TO"  etc., die von der Gegenseite beantwortet werden müssen. Erst nach dem "DATA" kann der Sender ohne weitete Bestätigung des Empfängers die Daten auf die Reise senden.

Eine Ausnahme ist aber SMB, das Protokoll zum Dateisharing unter Windows. SMB 1.0 hat alle Dateizugriffe in 4k Blöcke aufgeteilt und diese einzeln geschrieben. Der Client hat sich quasi so verhalten, als hätte er einen blockorientierte Festplatte im Zugriff. Nebenbei konnte so der Server mit weniger Aufwand die Blöcke einfach entgegennehmen und abspeichern. Nur "schnell" ist das natürlich nicht, wenn der Client nach dem Senden von 4k erst al auf die Antwort des Servers wartet. Das hat Microsoft angeblich mit SMB 2.0 verbessert. Dennoch kann es sein, dass sie hier noch etwas nachsteuern müssen:

... Microsoft has explained that performance issues come about primarily because SMB 1.0 is a block-level rather than a streaming protocol, that was originally designed for small LANs; it has a block size that is limited to 64K, SMB signing creates an additional overhead and the TCP window size is not optimized for WAN links. Solutions to this problem include the Updated SMB 2.0 protocol, Offline Files, TCP window scaling and WAN acceleration devices from various network vendors that cache and optimize SMB 1.0 and 2.0.
Quelle: Server Message Block (https://en.wikipedia.org/wiki/Server_Message_Block)

Es gibt nun verschiedene Ansätze im Internet, über Werte in der Registrierung auch SMB zu "beschleunigen". Ich bin da allerdings vorsichtig, da SMB nicht mehr nur ein "Windows Only"-Protokoll ist, sondern mittlerweile auch auf Unix (SAMBA) aber auch verschiedenen anderen NAS und Storage Systemen genutzt wird. Selbst meine Fritz!Box kann per USB einen Speicher per SMB bereit stellen und eine Webcam kann per SMB Bilder auf einen Server ablegen. Hier sind also sicher einige Tests mehr erforderlich. Der erste Schritt ist meiner Meinung nach erst einmal die Analyse woran es denn liegt, ehe man an den Einstellungen etwas verstellt. Vielleicht lässt sich der Zugriff schon allein dadurch beschleunigen, dass SMB 1.0  verhindert wird. Gerne genommen werden auch falsche Einstellungen im Bereich "TCPChimney und RSS".

WireShark als Analyse

Also ist ein Blick mit WireShark und Co in den TCP-Handshake interessant. Zuerst interessiert mich, ob der Client beim Verbindungsaufbau die Option mit sendet. Bei meinem Windows 7 Client sieht das so aus:

Als nächstes muss man das SYN-Paket der Gegenseite abwarten und hier kontrollieren. Die Antwort auf dieses Paket enthält auch ein Angebot für "Windows Scale"

Das bedeutet natürlich noch nicht, dass und in welcher Weise die Endpunkte auch davon gebrauch machen. Aber mit jedem weiteren Paket kann dann die aktuelle Window-Size ausgelesen werden. Hier sind wir schon mal bei 132kByte:

Hier scheint also die Anpassung der Fenster zu funktionieren. Dankenswerterweise hat WireShark sogar eine Statistik-Funktion für diese Windows Size:

Leider zeigt die Statistik dann immer nur einen Stream an. Sie können zwar rechts unten dann in den Streams durchlaufen und auch auf die Gegenrichtung umschalten.

Eine Übersicht über alle verwendeten Windows-Größen habe ich aber noch nicht gefunden. Allerdings kann WireShark die errechnete Paketgröße auch als Filter verwenden. Ich habe dann einfach mal einen Filter eingesetzt. um Pakete mit 75k Windowsize zu finden, was auf jeden Fall mehr als 64k sind. Dazu habe den Filter auf " tcp.window_size >75000" gesetzt und mit dann die gefundenen Pakete angeschaut

Eine Analyse der Window_Size für diese Verbindung ergibt dann folgende Bild:

Hier ist gut zu sehen, dass diese Verbindung auch mit einer Window-Size von 132100 Bytes arbeitet. Hier haben sich Sender und Empfänger entsprechend geeinigt, um eine größere Datenmenge zu übertragen. So kann zumindest als Stichprobe geprüft werden, ob abweichende Werte für die Window Size genutzt werden können. Sollten Sie so was gar nicht sehen, dann könnte es daran liegen, dass ein Router oder eine Firewall die Erweiterungen blockiert.

Weitere Links