Fischertechnik
AVR
Raspberry Pi
Elektronik
Netzwerk
Sonstiges
Impressum
Wie lang ist eigentlich ein Bit
In Hochgeschwindigkeitsnetzen stellt sich zunehmend die Frage, welchen Einfluss die Leitungslänge und die daraus entstehende Latenz hat. Die Latenz begrenzt in vielen Fällen die erreichbare Datenübertragungsrate, die deutlich kleiner als die verfügbare Bandbreite ist. Konkrete Beispiele und Berechnungen hierzu folgen später. Ein Beispiel aus der Praxis soll hier reichen: sftp über 700km Glasfasernetz erreicht ca. 3 Mbps auf einer 1 Gbps-Verbindung, nutzt die verfügbare Bandbreite also nichteinmal zu einem halben Prozent. Mehr Bandbreite hilft hier nicht, die Übertragung zu beschleunigen.Mit welchen Latenzen ist zu rechnen?
Die Übertragungsgeschwindigkeit in Lichtwellenleitern (und auch Kupferkabeln) kann in guter Näherung mit zwei Dritteln der Lichtgeschwindigkeit, also 200.000.000 Metern pro Sekunde, angenommen werden. Daraus ergibt sich eine Latenz von ca. 1μs pro 200m Faserlänge oder 1 ms pro 200km.Diese Werte gelten nur für die nackte Faser ("dark fiber") und erhöhen sich ggf. dramatisch bei jedem zwischengeschalteten aktiven Element.
Und wie lang ist jetzt ein Bit?
Bei 10 Gbps ergibt sich mit der angenommenen Geschwindigkeit eine Bitlänge von 200.000.000 / 10.000.000.000 m = 0,02 m = 2 cm.Fastethernet nutzt 100.000.000 bps. Somit belegt ein Bit hier 200.000.000 / 100.000.000 m = 2 m.
Ist ein Netzwerkkabel dann ein Speicher?
Ja, die Überlegung ist richtig. Bei 10 Gbps speichert ein Meter LWL ca. 50 Bit oder gut 6 Byte; pro Kilometer sind das ca. 6 kByte, und auf eine Verbindung von Frankfurt nach Hamburg "passen" ca. 3 MByte Daten.Mit dieser Sichtweise ist auch relativ leicht verständlich, warum die Latenz Datenübertragungsanwendungen so ausbremsen kann. Verlangt eine Anwendung zum Beispiel alle 64kByte von der Gegenseite eine Bestätigung, werden von den 3 MByte Speicherplatz nur 64kByte (ca. 2 Prozent) genutzt, dann wird gewartet, bis sie beim Empfänger ankommen, die Bestätigung benötigt wieder die volle Latenzzeit. Während dieser kann noch immer nicht weiter gesendet werden, der gesamte Speicher dieser Datenrichtung läuft leer durch. Dadurch halbiert sich die genutzte Speicherkapazität auf dann ca. 1 Prozent. Von den 10 Gbps verfügbarer Übertragungsrate bleiben somit gerade mal 100 Mbps für eine einzelne Übertragung. Die gute Nachricht ist, dass hier 100 solche Übertragungen gleichzeitig laufen könnten.
Die Realität ist noch schlechter: Die Fasern liegen nicht immer auf dem kürzesten Weg und die Carrier setzen diverse aktive Komponenten ein. Die theoretische Latenzzeit von 2,5μs liegt in der Praxis schnell bei 4-6μs, was die Übertragungsgeschwindigkeit mal soeben halbiert. Die oben angenommene Fenstergröße von 64kB war in den Anfangstagen von TCP/IP die absolute Obergrenze des Protokolls; inzwischen kann durch das window scaling genannte Verfahren mit sehr viel größeren Blöcken gearbeitet werden. Wichtig sind hierbei aber zwei Punkte. Einerseits muss durch die Nutzung der TCP-Option SACK sichergestellt werden, dass bei Störungen nicht der gesamte Block, sondern nur der gestörte Bereich wiederholt wird, und andererseits müssen die Protokolle der darüberliegenden Protokollschichten und Anwendungen auch auf Bestätigungen verzichten können.
Ein typisches Beispiel für Probleme ist der Einsatz von SSL-Verschlüsselung. SSL erlaubt maximal eine Verschlüsselung von 16kByte in einem Block. Dieses wird in sehr vielen Anwendungen auf die Netzwerkebene "durchgereicht" und führt im aktuellen Beispiel nocheinmal zu einer Viertelung der Übertragungsleistung. Von den 100 Mbps sind durch reale Latenzen und schlechte SSL-Implementierung dann nur noch 12 Mbps übrig. Jetzt passen sogar 800-1000 solcher Übertragungen gleichzeitig auf die Anbindung.
Beispielauswertung von Fenstergröße und Latenzzeit aus einem Trace
In einer grafischen Darstellung der Werte SEQUENCE und ACKNOWLEDGE aus dem TCP-Header über die Zeit lassen sich leicht die Latenzzeiten und die TCP-Window-Size ablesen. Im hier eingefügten Beispiel ist das typische Verhalten zehn Mal zu sehen. Erst wird ein Block (in ca. 10 Einzelpaketen) gesendet und dann auf die Bestätigung(en) gewartet. Grafisch entsteht so eine Treppe. Die Höhe jeder Stufe entspricht der Fenster- oder Blockgröße (hier ca. 16 kByte), die Breite der sogenannten Roundtriptime RTT (hier ca. 20 Millisekunden). Wie weiter oben beschrieben, vergeht die doppelte Latenzzeit, bis die Daten beim Empfänger ankommen und die Bestätigung dann auch wieder beim Sender ist und dieser dann erneut sendet.Aus einer solchen Darstellung lässt sich die Datenübertragungsrate der Anwendung mit ca. 160 kByte in 0,25 Sekunden, also ca. 640kBps oder 5 Mbps leicht ermitteln. Die Netzwerkbandbreite kann grob abgeschätzt werden: In den 0,25 Sekunden liegen 10 latenzbedingte Wartezeiten mal jeweils 20 Millisekunden, in Summe 0,2 Sekunden. Die reine Datenübertragung liegt damit bei ca. 160 kByte in 0,05 Sekunden oder 25 Mbps.
Ab einer (tatsächlich genutzten) Fenstergröße von 64kByte lässt sich die Steigung auch grafisch recht genau bestimmen; die Netzübertragungsrate berechnet sich aus der Stufenhöhe geteilt durch die Zeit des jeweiligen Anstiegs.
Lotus Notes über eine 34 Mbps-ADSL-Anbindung
Die Blockgröße wird hier durch die Anwendung bestimmt.
Die TCP-Windows-Size liegt deutlich über den hier sichtbaren 16 kByte.
Die Blockgröße wird hier durch die Anwendung bestimmt.
Die TCP-Windows-Size liegt deutlich über den hier sichtbaren 16 kByte.
Elefant, elephant ['ɛləfənt] und LFN
Bandwidth delay product (BDP)
Die Problematik der hochbandbreitigen Netzwerke mit signifikanter Latenz ist gut untersucht. Als Kenngröße hat sich das Produkt aus Bandbreite (in Bits pro Sekunde) und Latenz im Sinne der Round Trip Time RTT (in Sekunden) entwickelt. Im obigen ADSL-Beispiel mit 34 Mbps und 20 ms RTT ergibt sich ein Wert von 34.000.000 bps * 0,020 s = 680.000 Bit (oder auch 85.000 Byte). Das Produkt wird typischerweise als BDP bezeichnet.Wird TCP eingesetzt, muss die genutzte Windowsize größer als das BDP sein, um die verfügbare Bandbreite auch mit einer einzelnen Verbindung ausnutzen zu können. Im obigen Fall ist dieses nicht der Fall, und somit ergibt sich die unerwartet geringe Anwendungsbandbreite.
Long fat network (LFN)
Solche Performanceprobleme treten ab einem BDP von 100.000 Bit (12.500 Byte) verstärkt auf. Ab diesem Wert wird ein Netz als "long fat network" oder LFN bezeichnet. Ausgesprochen wird das Akronym unter Netzwerkern wie das amerikanische Wort für Elefant also ['ɛləfənt]. Beim obigen ADSL-Beispiel handelt es sich wegen 680.000 > 100.000 also um ein LFN.Ein anderes LFN hatte ich in der 10 Gbps-Anbindung Hamburg↔Frankfurt genannt. RTT ist hier real 12 ms. Das BDP beträgt also 10.000.000.000 bps * 0,012 s = 120.000.000 bit (15.000.000 Byte, 14,3 MByte).
Bei der DatenÜbertragung über Satelliten liegt die RTT minimal bei 4 * 240 ms, realistisch sogar über einer Sekunde. Somit ist schon ab einer Übertragungsrate von 100 kbps von einem LFN auszugehen.
Die folgende Tabelle zeigt exemplarisch für einige Szenarien die Grenze zum LFN auf; unterhalb der angegebenen Übertragungsrate ist davon auszugehen, dass auch einzelne Anwendungen die Bandbreite ausnutzen können.
| Übertragungsrate | max. RTT | max. Entfernung |
|---|---|---|
| 39 kbps | 2,6 s | per Funk zum Mond |
| 64 kbps | 1,5 s | 156.300 km |
| 256 kbps | 400 ms | 39.100 km |
| 2 Mbps | 50 ms | 5.000 km |
| 3,3-5 Mbps | 20-30 ms | DSL/ADSL |
| 34 Mbps | 3 ms | 300 km |
| 100 Mbps | 1 ms | 100 km |
Tuning
Durch geeignete Maßnahmen lassen sich trotz der beschriebenen Beschränkungen hohe Bandbreiten ausnutzen:- Mehrere parallele Sessions nutzen.
Dieses nutzen aus mehreren Gründen die Browser. Ein Effekt ist, dass auch ohne Veränderung des TCP-Verhaltens eine Vervielfachung der nutzbaren Anwendungsbandbreite möglich wird.
Mit zwei parallelen Sessions lassen sich unter DSL-Bedingungen bereits mehr als 6 Mbps ausnutzen.
GridFTP nutzt ebenfalls mehrere parallele Verbindungen zur performanten Übertragung großer Dateien. - TCP Extensions for High Performance nach RFC 1323
Durch die Option Window Scale kann die Window Size auf bis zu 1 GByte vergrößert werden.
Da in realen Netzen immer Paketverluste entstehen, muss die Option durch
TCP Selective Acknowledgment Options nach RFC 2018
ergänzt werden, damit nur fehlerhafte Teilstücke wiederholt werden müssen. - Performance Enhancing Proxies Intended to Mitigate
Link-Related Degradations (RFC 3135)
Einsatz von Proxies zur Optimierung der WAN-Nutzung.
Solche Proxies werden auch als PEP (Performance Enhancement Proxy) bezeichnet und nutzen diverse Tricks wie z.B. Caching bereits übertragener Daten, Komprimierung der Daten vor der Übertragung, Ersatz TCP durch ein Streamingprotokoll und Vieles mehr. Diese PEP müssen an jeweils beiden Enden des Übertragungsweges aufgebaut werden; bei sternförmigen Kommunikationen wie Firmenszentrale zu mehreren Außenstellen, reicht oft ein Proxy pro Lokation.
Die Anwendungen "sehen" diese Proxies nicht; die Proxies werden deshalb auch als transparente Proxies bezeichnet.
Erreichbare Übertragungsraten
|
 |
Berechnung erreichbarer Übertragungsraten
max. Übertragungsrate: