Bound by the Speed of Light

Die Anzahl der Leute, die Bandbreite weiterhin mit Latenz verwechseln, und die die Grenzen der Lichtgeschwindigkeit nicht verstehen, scheint irgendwie nicht kleiner zu werden.

Immer wieder wird eine Diskussion darüber entfacht, dass man doch schließlich eine Gigabit Strecke habe und es doch kein Problem sei die paar Gigabyte an Daten von Hamburg nach München zu kopieren, bis es dazu kommt, dass über die Gigabit Strecke gerade einmal ein paar Hundert Megabit oder weniger gehen.

Der erste Anlaufpunkt ist dann meist der Leitungsanbieter der seine teure aber langsame Leitung instand setzen soll. Das Ergebnis ist dann meistens, dass der Leitungsanbieter mit dem Ergebnis zurück kommt, dass alles in Ordnung sei und den Leitungsparametern entspreche.
Selbstverständlich sind bis zu diesem Punkt schon diverse Telefonate, E-Mails und Wochen ins land gegangen. Ohne Besserung…

Aber woran liegt es denn dann, wenn die Leitung in Ordnung ist ?

Der nächste Anlauf ist dann oft der eigene ITler oder eben der Softwareanbieter.
Aber am ende können beide nur bedingt das Problem lösen.

Sobald es zu größeren Distanzen kommt, ist Latenz meistens ein größeres Thema als Bandbreite, wobei Bandbreite ja heutzutage in vielen Gegenden Deutschlands im Überschuss verfügbar ist.

Aber was ist mit Latenzen, Ping Zeiten, Paketlaufzeiten oder wie auch immer man das ganze nennen mag ?

Hier kommen dann erst einmal ein paar Naturkonstanten zutragen. Zum einen die Entfernung, welche Fix ist.
Zum anderen die Lichtgeschwindigkeit welche als Naturkonstante recht unumstößlich ist.

Lichtgeschwindigkeit = 299792458 m/s = 299792 km/s = 1079251200 km/h

Entfernung Hamburg <-> München = 750 KM 

Allein aus diesen Konstanten ergibt sich, dass ein Licht welches man in Hamburg einschaltet (oder eben in eine direkt zwischen den beiden Standorten verlegte Glasfaser schickt erst 2,5 Milli Sekunden ! später in München ankommt.

2,5 Milli Sekunden, ergo eine Round Trip Time von 5 Milli Sekunden… sind doch wohl zu vernachlässigen, oder ? Leider nein…

Bleiben wir in diesem Beispiel einmal dabei, das eine Datei von Hamburg nach München kopiert werden soll. Als Protokoll nutzen wir das noch verbreitete SMBv2 Protokoll https://de.wikipedia.org/wiki/Server_Message_Block.
Dieses Protokoll zeichnet sich leider nicht durch seine WAN Optimierungen aus, und verwendet nahezu ausschließlich das Statusorientierte TCP Protokoll…

 

Um zu verstehen, warum die Latenzzeit Ihre Leistung beeinträchtigt, lohnt es sich zu verstehen, wie das SMB-Protokoll funktioniert, zumindest auf einer grundlegenden Ebene. SMB oder CIFS ist ein Client / Server-Protokoll, bei dem der Computer des Benutzers, der Client, versucht, Dateien vom Server abzurufen. Wenn der Benutzer eine Datei wünscht, stellt der Client mehrere Anforderungen an den Server, um die Daten zu erhalten. Einfach ausgedrückt muss der Client die Datei nachschlagen, dh dem Server mitteilen, welche Datei er lesen möchte, und dann nach jedem Block der Datei fragen. Das SMB-Protokoll versucht, Blöcke aus der Datei in 4-KB-Blöcken zu lesen, und es muss nacheinander nach jedem Block gefragt werden.

Was hat das ganze jetzt mit Latenzen zu tun ?

Sehr viele Operationen im SMB Protokoll erfordern eine Fertigstellung der vorhergehenden Operation, so das eine Leseanweisung immer Sequentiell nach der anderen gestellt wird.

Das ganze läuft dann wie folgt ab :

  1. CLIENT : Datei anfragen
    2. SERVER : Datei gefunden
    3. CLIENT : 1. Block lesen
    4. SERVER : 1. Block senden
    5. CLIENT : 2. Block lesen
    6. SERVER : 2. Block senden

Zwischen allen Einzelschritten Muss der Arbeitsplatz also auf eine Antwort des Servers warten, was in  lokalen Netzen meist in deutlich unter 1ms erledigt ist.

Lasst uns für einen Moment so tun, als ob wir ein Ultra-High-Tech-Licht-in-einem-Vakuum-Netzwerk haben und die Latenz (Round Trip Time) immer 10 ms beträgt.
Lassen Sie uns auch so tun, dass die Bandbreite kein Problem ist. Wie lange dauert es, bis eine 1-MB-Datei über den perfekten Verbindung gelesen wurde? Wenn jede Anfrage 4 KB umfasst, werden 256 Anfragen gesendet, was 2560 Millisekunden entspricht.
Nicht so schlimm, denken Sie, aber die Nutzer bemerken Verzögerungen von nur 200 ms.

Immer wenn Ihre Benutzer eine Datei öffnen, wird er diese Verzögerung bemerken und über das langsame Netzwerk schimpfen….

Die beste Antwort hierauf ist dann leider, dass man ein anderes Protokoll als SMB2 verwenden sollte…