ngpaas.eu

Edge oder Cloud? Latenz verständlich erklärt

Latenz bei Edge und Cloud: wie Entfernung, Netzknoten, Funkzugang, Handshakes und Verarbeitung sich summieren und wann Rechenleistung vor Ort wirklich hilft.

EdgeVeröffentlicht

Edge Computing verringert die Latenz, weil der Weg zwischen Nutzer oder Gerät und dem verarbeitenden Server kürzer wird. Am meisten bringt das, wenn die Alternative eine weit entfernte Cloud-Region ist oder die Anwendung Antworten innerhalb weniger Millisekunden braucht. Für viele Webanwendungen gilt dagegen: Schon eine Cloud-Region im eigenen Land beseitigt den Großteil der Entfernung. Was dann noch an Verzögerung bleibt, entsteht durch Handshakes, das Zugangsnetz und die Anwendung selbst.

Woraus sich Latenz zusammensetzt

Gemessen wird meist die Umlaufzeit (Round-Trip Time, RTT), also die Zeit von der Anfrage bis zur Antwort. Sie setzt sich aus mehreren Teilen zusammen:

  1. Ausbreitungsverzögerung: die Zeit, die das Signal für die physische Strecke braucht. Sie hängt nur von Entfernung und Medium ab.
  2. Übertragung: das Aufbringen der Bits eines Pakets auf die Leitung. Bei heutigen Bandbreiten klein, bei großen Datenmengen relevant.
  3. Warteschlangen und Routing: Jeder Router auf dem Weg fügt etwas Verzögerung hinzu, unter Last mehr.
  4. Zugangsnetz: die letzte Meile. DSL, Kabel, Glasfaser, WLAN oder Mobilfunk bringen jeweils eigene, teils stark schwankende Verzögerungen mit.
  5. Protokoll-Handshakes: Aufbau der TCP-Verbindung und Aushandeln der TLS-Verschlüsselung kosten Umläufe, bevor die eigentliche Anfrage startet.
  6. Verarbeitung: die Anwendung, Datenbankabfragen und Aufrufe anderer Dienste.

Edge Computing verkürzt vor allem Punkt 1 und 3, bei netzintegrierter Edge auch einen Teil von Punkt 4. Gegen langsame Datenbankabfragen hilft es nicht.

Eine physikalische Abschätzung

Dieser Abschnitt ist eine physikalische Näherung, keine Messung. Licht bewegt sich im Vakuum mit rund 300.000 km pro Sekunde, in Glasfaser langsamer, mit etwa zwei Dritteln davon, also rund 200.000 km pro Sekunde. Das ergibt etwa 5 Mikrosekunden je Kilometer und Richtung oder rund 1 ms Umlaufzeit je 100 km Glasfaser.

Faserstrecke (einfach) Mindest-Umlaufzeit allein durch Ausbreitung
10 km (innerhalb einer Stadt) etwa 0,1 ms
100 km etwa 1 ms
500 km (innerhalb eines großen Landes) etwa 5 ms
1.000 km (quer durch Mitteleuropa) etwa 10 ms
6.500 km (grob Frankfurt–US-Ostküste Luftlinie) etwa 65 ms

Echte Glasfaserwege sind länger als die Luftlinie, und jeder Router kostet Zeit, gemessene Werte liegen also höher. Die Größenordnung zeigt die Tabelle trotzdem: Innerhalb Deutschlands, Österreichs oder der Schweiz macht die Entfernung nur wenige Millisekunden aus, über den Atlantik dominiert sie.

Handshakes vervielfachen die Strecke

Eine verschlüsselte Webanfrage über TCP mit TLS 1.3 braucht einen Umlauf für den TCP-Handshake und einen für den TLS-Handshake, bevor die HTTP-Anfrage selbst einen weiteren Umlauf kostet. Die erste Antwort braucht also mindestens drei Umläufe. TLS 1.3 und QUIC, das Transportprotokoll unter HTTP/3, sparen Handshake-Umläufe ein, und wiederverwendete Verbindungen vermeiden sie bei Folgeanfragen ganz.

Deshalb wirkt Entfernung stärker, als die nackten Zahlen vermuten lassen: Bei 65 ms Umlaufzeit summieren sich drei Umläufe auf rund 200 ms, bevor der Server überhaupt gerechnet hat.

Wann die Cloud nah genug ist

Für eine typische Web- oder Mobilanwendung mit Nutzern in der DACH-Region hält eine Cloud-Region in Frankfurt, Nürnberg oder einer anderen nahen Stadt die Ausbreitungsverzögerung im niedrigen Millisekundenbereich. Verbesserungen kommen dann eher durch:

  • offene Verbindungen und HTTP/2 oder HTTP/3,
  • Caching statischer Inhalte in einem CDN,
  • schnellere Datenbankabfragen und APIs.

Welche Anbieter Rechenzentren nahe Ihren Nutzern betreiben, zeigt der Überblick europäische Cloud-Anbieter. Für kleinere Projekte lohnt auch der Blick auf Hetzner vs. DigitalOcean, beide mit Standorten in Deutschland.

Wann sich die Edge lohnt

Rechenleistung näher heranzurücken zahlt sich aus, wenn:

  • Regelkreise Antworten binnen weniger Millisekunden brauchen, etwa in Robotik, Maschinensteuerung oder Augmented Reality,
  • Nutzer oder Geräte weit von jeder passenden Cloud-Region entfernt sind, etwa an abgelegenen Industriestandorten oder auf Schiffen,
  • große Datenmengen wie Video oder hochfrequente Sensordaten sonst weite Wege gehen müssten,
  • die Verbindung unzuverlässig ist und die Anwendung trotzdem weiterlaufen muss.

In Fabriken bleibt mit einem Edge-Server vor Ort und einem privaten 5G-Campusnetz oder gut geplantem WLAN der gesamte Weg auf dem Gelände. Das Gesamtkonzept erklärt Was ist Edge Computing?.

Messen statt schätzen

Bevor Sie in Edge-Infrastruktur investieren, messen Sie. ping zeigt die Umlaufzeit zu einem Host, traceroute oder mtr zeigen den Weg und wo sich Verzögerung aufbaut, und die Entwicklerwerkzeuge des Browsers zerlegen eine Webanfrage in DNS, Verbindungsaufbau, TLS und Wartezeit auf den Server. Messen Sie von dort, wo Ihre Nutzer tatsächlich sind, und zu den Zeiten, in denen sie die Anwendung nutzen. Diese Zahlen zeigen, ob die Entfernung wirklich das Problem ist.

Häufige Fragen

Was ist Latenz?

Latenz ist die Zeit, die ein Datenpaket vom Sender zum Empfänger braucht. Im Netzwerk wird meist die Umlaufzeit (Round-Trip Time, RTT) angegeben: die Zeit von der Anfrage bis zur Antwort, gemessen in Millisekunden.

Wie viel Latenz spart ein Edge-Server?

Das hängt davon ab, wie weit die alternative Cloud-Region entfernt ist und wie das Netz routet. Als physikalische Faustregel gilt rund 1 ms Umlaufzeit je 100 km Glasfaser. Messen Sie Ihre eigenen Strecken mit ping oder traceroute, statt sich auf allgemeine Werte zu verlassen.

Hat 5G weniger Latenz als WLAN?

Nicht grundsätzlich. Beide erreichen unter guten Bedingungen niedrige Werte. 5G-Campusnetze werden vor allem wegen Abdeckung, Mobilität und planbarer Dienstqualität auf großen Flächen gewählt, nicht weil sie immer schneller wären als ein gut geplantes WLAN.

Senkt ein CDN die Latenz bei dynamischen Inhalten?

Ein CDN beschleunigt vor allem zwischenspeicherbare Inhalte. Bei dynamischen Anfragen kann es helfen, indem es Verbindungen nahe am Nutzer aufbaut, die Anfrage muss aber trotzdem bis zur Anwendung und Datenbank.