End2End Performance und Bandbreite

Wie schnell eine Internet-Leitung ist, wird meist immer an der Bandbreite fest gemacht. Sei es nun DSL16000, DSL100000 oder 200Mbit Kabel oder noch schnellere Glasfaser. Auf dieser Seite möchte ich diese Aussage relativieren und anderen Faktoren mit in den Fokus bringen, die mindestens genauso wichtig sind. Die Bandbreite ist ein Begriff für die "Geschwindigkeit" einer Leitung aber nicht für deren Durchsatz.

Ich vertrete den Standpunkt, dass eine "Bandbreitenmessung" nicht seriös möglich ist und auch keinen Sinn macht, wenn mehrere Teilstrecken dabei involviert sind. Eine reine  Bestimmung der Bandbreite macht vielleicht Sinn auf einer Teilstrecke zwischen zwei Stationen, z.B.: ein WAN-Link oder ein komplette verwaltetes Netzwerk. Über das Internet sind solche Messungen maximal eine Momentaufnahme und helfen für den Regelbetrieb nicht weiter.

Das Netzwerk ist die Straße

Ehe ich in die Technik einsteige, möchte ich erst einmal einen Vergleich bemühen, um sie abzuholen. Denn was die Mehrheit der Leser als Bandbreite bezeichnet ist am ehesten mit der Höchstgeschwindigkeit auf der Teilstrecker zu vergleichen. Wir wissen aber alle, dass der Weg von A nach B sich nicht an der theoretischen Höchstgeschwindigkeit einer Teilstrecker ermitteln lässt, sondern durch eine Summe von weiteren Faktoren beeinflusst wird. Wer für die Zustellung von Paketen, sei es nun eine Warensendung mit einem LKW oder Daten als IP-Paket, zuständig ist, muss die Performance realitätsnah messen.

  • Es ist nicht wichtig, wie schnell sie maximal fahren könnten, sondern wie zügig sie am Ziel und wieder zurück unterwegs sind.
    Für die Messung der maximalen Bandbreite gibt es Werkzeuge wie Tools: NETIO, IPERF und TTCP und andere "Hochlasttools". Für Stresstest auf Festplatten gibt es Jetstress und IOMeter und selbst für CPUs und GPUs gibt es Tests. Letztlich messen Sie damit aber am Anfang einmalig die Höchstgeschwindigkeit, wie schnell das gekaufte System im isolierten Fall sein könnte. Nicht mehr und nicht weniger.
  • Es ist nicht wichtig, wie viele vor und hinter ihnen fahren
    Eine Straße ist eine sequentielle Strecke, auf der hintereinander die Fahrzeuge fahren. Für das einzelne Paket ist es aber nicht wichtig, wer vorher oder danach die Straße nutzt. Es ist nicht einmal besonders aussagekräftig, wenn jemand auf der Zufahrt oder Abfahrt steht und die Autos und deren Größe misst. Solche Messungen sind zwar Standard mit MRTG, Nagios und anderen SNMP-basierten Tools, aber sie lassen nur sehr ungenau einen Rückschluss auf die Transportleistung der Strecke zu. Allerdings ist so eine Messung günstig und einfach und sollte als ergänzende Maßnahme gesehen werden.
  • Wichtig ist, dass sie ausreichend schnell ihr Ziel erreichen
    Da fängt schon mal das Problem an sich auf eine Qualität festlegen zu müssen. Sprüche wie "so schnell wie möglich" helfen nicht bei der Bewertung einer Verbindungsstrecke. Aber die Festlegung gibt auch vor, wie die Verbindung zu letztlich zu messen ist.

Eine vernünftige "Messung" einer Straßenverbindung erfolgt also nicht anhand der Staumeldungen im Radio oder Verkehrszählungen auf den Zufahrten sondern indem die real fahrenden Fahrzeuge ihre Daten liefern. Auf dem Straßenverkehr gibt es schon massenhaft "Messobjekte" in Form von Maut-Meldern, die nicht nur die Anzahl erfassen sondern auch die Fahrzeit ermitteln könnten. Ich weiß nicht, ob sie das tun oder dürfen. Aber die meisten Menschen sind durch ihre Smartphones auch lebende und sich bewegende Sensoren. Google und Co erfassen sehr wohl die Bewegungsdaten durch das Straßennetz und errechnen daraus Vorhersagen zur Fahrzeit.

Ein IP-Paket kann diese Daten so natürlich nicht liefern. Hier sind erst einmal nur die beiden Endpunkte in der Lage, direkt die Laufzeit zu messen. Das stimmt so aber nicht ganz, da die meisten Firewalls heute aber schon "Stateful Inspection" machen und daher genau sehen, welche Pakete zusammengehören. Sie können als auch allein durch die "Betrachtung" ermitteln, wie lange TCP-Pakete unterwegs sind.

Es ist also ein Unterschied, ob sie die Performance eines Abschnitts der Verbindung messen wollen oder die komplette Verbindung. Oder wieder mit dem Straßenverkehr. Wie viel Einfluss hat wohl die kurze aber voll ausgebaute und ohne Tempolimit versehene Teilstrecke auf der Autobahn, wenn diese nur einen geringen Teil meine Reise ausmacht? Wichtiger sind also Performance Messungen, die auch eine Aussagekraft haben. Daher habe ich mal ein paar technische Aspekte bei der Übertragung von Paketen beschrieben.

Latenz durch Routing und Hops

Router brauchen etwas zeit um selbst bei freien Verbindungen die Pakete zu routen. Sie müssten zumindest den Anfang des Pakets mit der IP-Zieladresse empfangen haben, um den "Next Hop" bestimmen zu können. Natürlich geht das mit Gigabit schneller als mit 2 Megabit-Links. Sie können ein beliebiges IP-Paket nehmen. Der Anfang ist immer gleich aufgebaut:

Bei diesem Ethernet-Paket ist die Destination-IP-Adresse ab der Position 30-33 (Bytes). Der Router muss also mindestens 34 Bytes empfangen haben, um das Paket auf der anderen Seite weiter zu leiten. Allerdings warten die Router meist das komplette Paket ab. Nur so können Sie die anhand der Prüfsumme am Ende den defekten Paket erkennen und sich die Weiterleitung sparen. Wenn die nächste Leitung schneller ist, als die Empfangsleitung, dann macht es auch keinen Sinn schon vorschnell loszusenden. Bei Switches ist es hingegen einfacher möglich, ein Paket schon nach dem Empfang der Ziel-MAC-Adresse weiter zu leiten, wenn alle Ports gleich schnell sind.

Bei Routern sehen Sie aber, dass jeder Hop mehr schon aufgrund des grundlegenden Routing-Prozesses für etwas Verzug sorgt. Addieren müssen Sie auch noch Verzögerungen aufgrund der eigentlichen Routing-Entscheidung und Warteschlangen auf der Ausgangsseiten und QoS-Überholern mit einplanen.

Entfernung kostet Zeit

Seit der Ermittlung der "Lichtgeschwindigkeit" und der Annahme, dass nichts schneller sein kann, können auch Elektronen nicht schneller als Licht sein. Unsere Erde ist schon 40.000km im Umfang und wenn Licht mit 300.000km/Sek unterwegs ist, dann braucht ein Lichtstrahl messbare 0,13 Sekunden oder 130ms für eine Runde um die Erde. Niemand wird ein Paket um die Erde senden, wenn es zum Nachbarn soll. Sie könnten also annehmen, das es maximal die Hälfte der Zeit braucht, d.h. 65ms. Aber da Leitungen nicht genau den kürzesten Weg nehmen, wird es etwas länger. Elektronen sind aber nun nicht mit Lichtgeschwindigkeit unterwegs sondern je nach Kabel entsprechend langsamer und selbst Licht in einer Glasfaser ist nicht so schnell wie Licht im Vakuum. Es ist sogar langsamer als Elektronen auf Kupfermedien, die aber aufgrund der Widerstände in WAN-Verbindungen schlechter sind.

  • 300.000km/s Licht im Vakuum
  • 200.000km/s Licht in Glasfaser
  • 225.000km/s Elektronen auf Kupfer

Und selbst auf Kupfer gibt es noch unterschiede je nach Kabeltyp. Die Chip-Designer müssen sich mit solchen Geschwindigkeiten herum schlagen, damit z.B. bei parallelen Bussen alle Signale auf allen Leitungen auch zeitgleich beim Ziel ankommen. Daher sind heutige Bus-Systeme fast durchweg seriell. Aber die Entfernung ist natürlich ein Maß für die Latenzzeit. Auf der Seite Latenz im Netzwerk habe ich dazu weitere Details beschrieben.

Im Jahr 2022 hat Microsoft die Firma Lumenisity gekauft, welche Glasfaser mit "Luft" entwickeln. Das Licht wird dabei nicht mehr durch Glas geleitet und an der Kante gebrochen, sondern durch Luft mit Spiegelungen, was wohl eine ca. 30%tige Reduzierung der Latenzzeit bringen kann.

Datenmenge ist relevant

Auch die Größe eines Pakets ist für die Messung relevant. Die meisten Tools messen die Latenzzeit einer Verbindung durch einen einfachen PING. Ein PING ist klassischerweise ein ICMP-Paket mit 64 Bytes. Das ist natürlich ein anderes Protokoll als TCP oder UDP und kann schon daher von Firewalls, Routern etc. ganz anders behandelt werden. Angefangen von "wirf weg, wenn kein Platz" bis "Priorisiere, damit der Anwender zufrieden ist" gehen. Für eine Performancemessing ist ICMP aber nur bedingt geeignet.

Viel wichtiger ist aber die Paketlänge. Selbst bei VoIP besteht ein Sprachpaket aus ca. 160 Byte Audio (64kbit mit 20ms Frame), welche je nach Codec noch komprimiert wird. Aber es ist auf jeden Fall mehr als 64kByte. Schauen Sie sich dann aber mal ein TCP-Nutzpaket an, dann sind viele Pakete über 1500 Bytes groß und noch mehr wieder viel kleiner. Mit Wireshark können Sie recht einfach die Verteilung der Paketgrößen auf einem Server ermitteln.

Es sind schon deutlich mehr kleine Pakete. Das sind dann meist Quittungen. In Bytes gesamt ergeben aber die 3869-1757 = 5626 Pakete gerade mal 414 kByte, während die 1532 große Pakete hier 2,3 MByte übertragen haben. Ein richtiger Request setzt sich natürlich aus mehreren Paketen zusammen. Wenn ich eine kleine Mail mit vielleicht 15 kByte sende, dann sind das mindestens 10 Pakete a 1500 Bytes, die nacheinander über die Leitung gehen und entsprechend quittiert werden. Den Overhead für das Protokoll (z.B. MAPI/HTTP) unterschlage ich nun einfach mal.

Ein einfacher ICMP-Test mit 64bit hin und zurück ist natürlich viel schneller abgeschlossen als ein HTTP-Request auf eine Seite. Wenn jemand eine 100ms Latenzzeit fordert, dann müsste er auch dazu sagen, für welchen Test dies gilt. Wenn die Aussagen dazu fehlen, dann dürfte es sich um einen einfachen PING handelt.

Window Scaling, Windows-Size, Sack und Latenz

Neben der Länge des individuellen Pakets kommt noch die Größe der Übertragung ins Spiel. Wenn ich eine Mail mit vielleicht 1,5 Megabyte sende, dann sind das nicht nur 1000 Pakete a 1500Bytes. Die 1000 Pakete gehen ja nicht nonstop über die Leitung sondern ein TCP-Stack sendet einen gewisse Menge und wartet dann auf die Quittung. Dieses "Sende-Fenster" wird von den beiden Partnern dynamisch ausgehandelt. Die TCP-Stack nutzen dabei die Geschwindigkeit (Latenzzeit) als Maß für die Entfernung und messen auch den den Durchsatz um dynamisch die Windows-Size entsprechend zu erhöhen oder zu reduzieren. Ist die Windows-Size zu hoch, dann könnten vermehrt Pakete durch Router gedroppt werden, da sie nicht mehr in die Warteschlange zum Versand passen. Mit Wireshark können Sie für eine TCP-Verbindung schön ermitteln, wie sich die Windowsize verändert hat:

Bei einer zu kleinen Windowsize wird aber Bandbreite verschenkt, da der Sender pausiert, bis der Empfänger die Pakete quittiert hat. Diese Drosselung passiert pro TCP-Connection. Daher nutzen fast alle Programme auch mehrere TCP-Sessions parallel, damit es weniger "Blocking Connections" gibt.

Diese Problematik ist bei falsch arbeitenden TCP-Stack durchaus ärgerlich. Stellen Sie sich mal folgendes vor:

  • Zwei Server sind über eine WAN-Verbindung und Routing verbunden
  • Das WAN ist ein 1 GBit "Dark Fiber" des Kunden von Hamburg nach München.
  • Die "Roundtrip-Zeit" beträgt 10ms
    Da hat die Entfernung sicher was damit zu tun und natürlich auch die Router
  • Server 1 sendet Daten per FTP zu Server 2
  • Übertragen werden aber "nur" 6400kbyte, also 6,4 Megabyte/Sek oder 64MBit

Die Gigabit-Leitung wird also gerade mal zu 6,4% ausgelastet. Was läuft hier falsch ?.

Der Absender startet mit einer TCP-Windowsize von 64Kbyte aber die Aushandlung einer anderen Windowsize schlägt fehl, weil "etwas" dies unterbunden habt. Das kann eine Konfiguration des TCP-Stack sein, eine Firewall, die größere Windowsize-Buffer nicht bereitstellen will, WAN-Optimierer, die in den TCP-Handshake eingreifen. Egal was es ist würde ich dies als "Fehler" bezeichnen, der sich wie folgt auswirkt.

  • Der Sender übermittelt die ersten 64Kbyte in mehreren Paketen a 1514 Bytes
  • Der Sender muss dann "warten" bis wenigstens ein Paket quittiert wurde, ehe er ein weiteres Pakete senden kann
    Der Einfachheit halber nehmen wir an, dass die Gegenseite alle Pakete auf einmal Quittiert.
  • Diese Pakete sind idealisiert 10ms unterwegs (Roundtip)
  • Nach 10 ms gehen die nächsten 64kByte auf den Weg

Sie können selbst rechnen, dass 64kByte in 10ms übertragen werden und man so auf 6400kByte/Sek kommt. Das Problem wird um so größer, je länger die Latenzzeit ist. Das Problem reduziert sich aber, wenn die Partner eine größere Windowsize vereinbaren können. Natürlich hilft es auch mehrere parallele Sessions zu starten, wenn dies sinnvoll ist. Outlook startet z.B. getrennte Sessions für OAB-Download und je Postfach.

Eine zweite Optimierung ist SACK. (Selective Acknowledgment). Mit dieser Option kann der Empfänger selektiv Pakete quittieren. Wenn also von 100 Paketen nur 98 ankommen, dann kann der Empfänger dies dem Sender sagen, so dass dieser nur die beiden fehlenden Pakete noch mal senden und nicht die komplette Gruppe.

Mit Excel können Sie selbst schnell den Durchsatz abhängig von der Latenz und der Windowsize ermitteln.

Nun können Sie auch gut ermessen, warum selbst im LAN die Latenzzeit z.B. bei Backups oder der Replikation von Exchange Datenbanken einen Einfluss auf den Durchsatz haben kann. Es macht durchaus Sinn mit Wireshark oder Netmon den TCP-Handshake zu untersuchen, ob wirklich Windows Scaling und SACK von beiden Partnern aktiv genutzt werden. Das gilt natürlich erst recht für Verbindungen zu Office 365 über HTTP-Proxy Server hinweg. Hier müssen Sie genau genommen sogar beide Seiten, d.h. Client zu Proxy und Proxy zu Cloud-Service kontrollieren.

ICMP, TCP, TLS oder HTTPS?

Sie haben sicher schon gemerkt, dass ich kein Freund von ICMP zur Messung von Laufzeiten und Durchsatz bin. Ich habe daher mit der Exchange Online Gegenstelle "outlook.office36.com" verschiedene Tests gemacht, die sehr gut die Unterschiede zwischen den verschiedenen Protokollen aufzeigen:

Alle Tests wurden mehrfach ausgeführt so das die DNS-Auflösung schon erfolgt ist und die Adresse im Cache vorliegt. Die Zeiten, Paketanzahl und Bytes sind die reine Nutzdatenmenge..

Protokoll Test Datenmenge Latenz

ICMP Ping

 

ping outlook.office365.com -n 1

Ping wird ausgeführt für outlook.ms-acdc.office.com [40.101.90.178] mit 32 Bytes Daten:
Antwort von 40.101.90.178: Bytes=32 Zeit=19ms TTL=243

Ping-Statistik für 40.101.90.178:
    Pakete: Gesendet = 1, Empfangen = 1, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 19ms, Maximum = 19ms, Mittelwert = 19ms

2 Pakete
371 Bytes

19ms

TCP-Connect

 

Test-NetConnection -Port 443 -ComputerName outlook.office365.com

ComputerName     : outlook.office365.com
RemoteAddress    : 52.97.139.2
RemotePort       : 443
InterfaceAlias   : DisplayLinkLAN
SourceAddress    : 192.168.178.36
TcpTestSucceeded : True

(measure-command {`
   Test-NetConnection `
       -Port 443 `
       -ComputerName outlook.office365.com`
   }`
).TotalMilliseconds

147,5493

5 Pakete
300 Bytes

120-150ms

TLS-Handshake

Das folgende Skript verbindet sich mit einem Port und zeigt nach Empfang des "Server Hello" das Zertifikate der Gegenseite an:

(measure-command {`
   .\Get-TCPCert.1.1.ps1 `
      -remotehost outlook.office365.com `
      -portrange 443 `
}).TotalMilliseconds 

Get-LANCert: Start
------------- Get-LANCert:Processing outlook.office365.com
 Using PortRange
 Iteration PortRange 443
 Init Result
 Connect to outlook.office365.com:443 Connected
 Get TCP-Stream
 Get SSL-Stream
 AuthenticateAsClient HandshakeOK
 Read the certificatedone
  Parsing Certificate Data
    CN= CN=outlook.com
  Closing Connection
  Sending Result to Pipeline
  Done
Get-LANCert:End

107,6897

14 Pakete
4554 Bytes

110-130ms

HTTP-Request

Eine einfache Abfrage der OWA-Seite. Der Parameter -UseBasicParsing" verhindert den Redirect auf die Anmeldeseite.

(measure-command `
   {Invoke-WebRequest `
      -uri "http://outlook.office365.com" `
       -UseBasicParsing}).totalmilliseconds

17 Pakete
5472 Bytes

250-300ms

HTTP-Request

Eine einfache Abfrage per HTTPS der OWA-Seite. Der Parameter -UseBasicParsing" verhindert den Redirect auf die Anmeldeseite. Aber der TLS-Handshake kommt noch oben drauf.

(measure-command `
   {Invoke-WebRequest `
      -uri "https://outlook.office365.com" `
       -UseBasicParsing}).totalmilliseconds

18 Pakete
8848 Bytes

300-400ms

Sie sehen also schön, wie aus der 19ms Verbindung per ICMP für die HTTP-Requests schon deutlich mehr Zeit erforderlich wird. Das ist auch ein Grund, warum es für Audio/Video immer am besten ist, UDP für die Anwender zu erlauben.

Interessant wäre hier natürlich noch die Messung von HTTPS-Requests durch den Proxy Server und am Proxy Server vorbei und den Einfluss auf die Latenz zu bewerten. Das gilt insbesondere auch, wenn der Proxy-Server z.B. einen Bypass für Office 365 vornehmen kann oder Sie einen "Cloud-Proxy" wie z.B. ZScaler u.a. einsetzen. Wobei hier auch schon der einfache HTTP-Request auf die PAC-Datei des Proxy-Servers die Zeit der ersten Teilstrecke ermittelt.

Zwischenstand

Wenn in Produkten und Internetforen über Latenzzeit gesprochen wird und sich die Teilnehmer gegenseitig unterbieten, dann sind diese Zahlen dennoch immer zu relativieren. Wenn es um die kleinsten Werte geht, dann kommt fast immer ein ICMP-Ping mit minimaler Paketgröße zum Einsatz. Aus meiner Sicht haben diese Messwerte aber nur einen sehr eingeschränkten Nutzen, denn über ICMP werden keine Nutzdaten übertragen.

Dennoch scheint auch Microsoft mit diesen Zahlen zu arbeiten. Ein "Ping" kann ja auch jeder einfach mal ausführen und wenn Sie einen Ping auf outlook.office 365.com machen, dann sehen Sie in der Diagnose auch gleich den Namen des Office 365 Zugangspunkt und eine vereinfachte Laufzeitmessung. Das gilt natürlich nur, wenn ICMP auch erlaubt ist. Wenn die Company-Firewall ICMP nicht mag und eine direkte Verbindung per TCP unterbindet, dann wird man wohl oder übel einen HTTP-Request absetzen müssen.

Die Handwerker kennen alle den Spruch "Wer misst miss meistens Mist" in dieser oder abgewandelter Form. Es liegt aber viel Wahrheit darin, denn bei einer Messung können viele Randbedingungen das Ergebnis verfälsche. In der Elektrotechnik führt schon der Wechsel des Messbereich am Multimeter zu einer Veränderung des Innenwiederstands, der natürlich auch Einfluss auf die Messgröße hat. Selbst mir ist es schon passiert, dass ein nicht korrekt funktionierendes Gerät allein durch das Anlegen einer Prüfspitze funktioniert hat. Selbst in für Exchange kann ich davon berichten, dass ein End2End-Test auf ein Postfach allein durch das Messen die Daten im Cache des Exchange Server gehalten haben und damit die Anwendung, die bislang über Performanceprobleme geklagt hat, auf einmal problemlos und schnell gelaufen ist.

Achten Sie bei ihren Messungen daher immer auf die das korrekte Messinstrument, den ordnungsgemäßen Testaufbau und hinterfragen Sie ihre Ergebnisse immer wieder aufs neue

Weitere Links