Geschwindigkeit zu EU-Servern niedriger als bei Speedtest

Speedtest meldet 290 Mbit/s. Die reale Geschwindigkeit zu Servern in der EU liegt eher bei 38 Mbit/s. Ein Abstand von rund dem Achtfachen fällt auf. Fast immer geht er auf die lange internationale Strecke zurück und nicht auf Ihre Technik oder auf unseren Dienst.

Kurz gefasst

Speedtest und eine echte Verbindung zu einem fernen Server messen verschiedene Dinge. Speedtest prüft die nackte Kapazität Ihrer Leitung auf einer sehr kurzen Strecke. Die Arbeit mit Servern in der EU hängt an der Verzögerung und am Zustand der internationalen Kanäle, über die Ihr Verkehr läuft. Ein hohes Ergebnis bei Speedtest sagt deshalb nur, dass Ihre Leitung gesund ist. Die niedrige Geschwindigkeit in die EU stößt dagegen an die Physik weiter Strecken und an die Last in den Transitnetzen.

Wie der Abstand aussieht

Hier ist dieselbe Leitung, zweimal gemessen und nur Minuten auseinander. Zuerst Speedtest gegen einen Server, den er selbst gewählt hat.

Zwei Details auf dieser Anzeige erklären fast die ganze Zahl. In der Zeile "Connections" steht "Multi", die Zahl ist also aus mehreren Strömen zusammengezählt. Und der gewählte Server steht im selben Land. Jetzt dieselbe Leitung gegen die Server, die Webinare wirklich tragen, auf dem Schritt "Speed" unseres Verbindungstesters.

Der Empfang bricht um rund das Achtfache ein. Der Versand rutscht nur von 26 auf 16, ein weit sanfteres Gefälle. Keine der beiden Zahlen spricht für eine kaputte Leitung, und wohin jede von ihnen geht, erklärt der Rest dieses Artikels.

Die zweite Anzeige lesen Sie besser genau. "TO YOU" ist der Empfang, "FROM YOU" der Versand. Führen Sie das Webinar selbst? Dann zählt genau die Zahl "FROM YOU", denn Kamera, Mikrofon und Bildschirm gehen nach oben weg. Ein Teilnehmer, der nur zuschaut, hängt dagegen an "TO YOU". Im Messwert oben sind 15,98 Mbit/s im Versand etwa das Zehnfache dessen, was ein Referent braucht.

Die Beschriftungen auf den Bildern sind englisch, denn die Oberflächen sind in der englischen Fassung aufgenommen. In einer deutschen Oberfläche tragen dieselben Punkte deutsche Namen und stehen an denselben Stellen.

Was Speedtest wirklich misst

Speedtest ist darauf gebaut, die höchste Zahl zu zeigen, die er bekommen kann. Sein Ergebnis bildet die Arbeit mit fernen Servern deshalb nur zum Teil ab.

• Er nimmt den nächsten Server. Speedtest wählt den Knoten mit der geringsten Verzögerung, meist im Netz Ihres Anbieters oder in derselben Stadt. Der Verkehr dorthin läuft kurz und berührt internationale Kanäle gar nicht.
• Er öffnet viele Verbindungen auf einmal. Speedtest fährt mehrere TCP-Ströme gleichzeitig, meist 4 bis 16, und addiert deren Geschwindigkeit. So umgeht er das Limit einer einzelnen Verbindung auf langer Strecke, dazu mehr im nächsten Abschnitt. Echte Programme arbeiten oft mit einem Strom oder zweien und bekommen diesen Zuschlag nie.
• Die Verzögerung ist minimal. Auf kurzer Strecke beträgt die Umlaufzeit, auch RTT genannt, nur wenige Millisekunden, und TCP kommt auf die volle Geschwindigkeit der Leitung.

Speedtest zeigt also den Laborwert Ihrer Leitung. Was Sie im Austausch mit einem Server in einem anderen Land bekommen, zeigt er nicht.

Bandbreitenverzögerungsprodukt und das TCP-Fenster

Der größte Teil des Abstands hängt an diesem einen Mechanismus.

TCP schickt Daten in Fenstern. Der Sender schiebt eine Portion hinaus und wartet auf die Bestätigung, bevor er weitermacht. Die höchste Geschwindigkeit einer einzelnen TCP-Verbindung folgt einer einfachen Formel.

Geschwindigkeit = Fenstergröße / Verzögerung (RTT)

Damit die Leitung ganz ausgelastet ist, muss das Fenster mindestens so groß sein wie das Bandbreitenverzögerungsprodukt, kurz BDP.

BDP = Bandbreite × RTT

Setzen wir die Zahlen jener Leitung mit 290 Mbit/s ein, bei einer Verzögerung zu einem Server in der EU von rund 50 ms.

BDP = 290 000 000 Bit/s × 0,05 s = 14 500 000 Bit = 1,81 MB

Rund 1,8 MB müssen also in jedem Moment unterwegs sein, sonst wird die Leitung nicht satt. Hängt eine Seite an einer begrenzten Fenstergröße fest, also an den klassischen 64 KB ohne Fensterskalierung? Dann ergibt sich für eine einzelne Verbindung diese Obergrenze.

Geschwindigkeit = 65 536 Byte × 8 Bit / 0,05 s ≈ 10,5 Mbit/s

Deshalb bleibt eine einzelne Verbindung zu einem fernen Server bei 10 bis 20 Mbit/s stehen, obwohl die Leitung selbst für Hunderte Megabit ausgelegt ist. Auf kurzer Strecke mit einem RTT von 2 ms lieferte dasselbe Fenster über 260 Mbit/s. Darum taucht die Sache bei Speedtest nie auf. Je höher die Verzögerung, desto stärker der Effekt. Kaputt ist hier nichts, so arbeitet das Protokoll einfach.

Verzögerung und die Physik langer Strecken

Die Verzögerung auf einer langen Strecke besteht aus mehreren Teilen, und manche davon lassen sich gar nicht wegnehmen.

Licht läuft durch Glasfaser mit rund 200 000 km/s, deutlich langsamer als im Vakuum, weil das Glas das Licht bricht. Jede tausend Kilometer Strecke bringen etwa 5 ms in eine Richtung, also etwa 10 ms für den Umlauf. Gerade Strecken gibt es zudem kaum, der reale Weg ist meist länger als die geografische Entfernung.

Dazu kommt die Verzögerung an jedem Zwischenknoten. Ein Router verarbeitet das Paket, stellt es in eine Warteschlange und schickt es weiter. Auf dem Weg zu einem Server in der EU liegen davon meist 10 bis 20, auch Hops genannt. Jeder legt seinen Anteil drauf. Je höher der RTT am Ende ausfällt, desto niedriger die Obergrenze einer einzelnen Verbindung nach der Formel oben.

Paketverluste und ihre Wirkung auf TCP

Schon kleine Paketverluste auf einem internationalen Kanal schneiden die Geschwindigkeit stark zusammen. TCP liest ein verlorenes Paket als Zeichen von Überlast, drosselt deshalb und baut das Tempo danach wieder auf. Den Zusammenhang beschreibt die Formel von Mathis.

Geschwindigkeit ≈ MSS / (RTT × √p)

MSS ist die maximale Segmentgröße, meist rund 1460 Byte, RTT ist die Verzögerung, und p ist der Anteil verlorener Pakete. Die Geschwindigkeit fällt umgekehrt zur Wurzel aus der Verlustrate und hängt direkt an der Verzögerung.

In der Praxis sehen die Zahlen dramatisch aus. Bei einem RTT von 50 ms und üblichem MSS halten schon 0,1 Prozent Verlust eine einzelne Verbindung bei etwa 7 Mbit/s. Ein Prozent Verlust drückt sie auf rund 2,3 Mbit/s, zwei Prozent unter 1,7 Mbit/s. Auf langen Transitstrecken sind 1 bis 2 Prozent Verlust zur Spitzenzeit völlig normal. Wo sie diese Werte erreichen, beißen sie härter als das Fensterlimit oben. Daher wird aus einer Strecke, die morgens nur langsam wirkt, am Abend eine unbrauchbare.

Routing und Peering

Der Weg Ihres Verkehrs zu einem Server in der EU ist nicht gerade. Er läuft über eine Kette von Betreibern und über das Routing-Protokoll BGP. Und das wählt seinen Weg nach kaufmännischen und technischen Gründen, nicht nach der kürzesten Entfernung.

Daraus folgen mehrere typische Probleme. Eine Strecke kann über ein drittes Land laufen, obwohl es kürzer ginge, und dann steigen Verzögerung und Verlustrisiko zugleich. Der Verkehr quert außerdem die Nahtstellen zwischen den Netzen, also Peering-Punkte und Transitkanäle. Eine verstopfte Nahtstelle ist genau der Ort, an dem die Geschwindigkeit fällt. Häufig ist auch asymmetrisches Routing, bei dem Pakete auf einem Weg hinaus und auf einem anderen zurück gehen. Die Diagnose wird davon trüb. Internationale Kapazität muss ein Anbieter zudem einkaufen, und wer sparsam eingekauft hat, dem geht sie zur Spitzenzeit aus.

Überlastete internationale Kanäle Ihres Anbieters

Lokalen Verkehr, in der Stadt und im Land, haben die meisten Anbieter reichlich. Darum zeigt Speedtest zu einem nahen Server auch immer eine hohe Zahl. Internationale Kanäle sind teurer, und die Anbieter kaufen davon nur begrenzt ein. Am Abend in der Spitze werden genau sie zum Nadelöhr. Das erklärt die spürbaren Sprünge der Geschwindigkeit in die EU über den Tag, während der lokale Speedtest gleichbleibend hoch steht.

Weitere technische Faktoren

Neben den Hauptursachen wirken noch ein paar Dinge auf die Geschwindigkeit zu einem fernen Server.

MTU und Fragmentierung. Ist die MTU auf der Strecke kleiner als erwartet, zerfallen die Pakete, und die Effizienz sinkt. Ein schief eingestelltes PMTUD, also die Bestimmung der MTU auf dem Pfad, führt zu schwarzen Löchern und hängenden Übertragungen.

Bufferbloat. Aufgeblähte Puffer auf Zwischenknoten heben die Verzögerung unter Last und bringen die Flusskontrolle von TCP durcheinander, und die reale Geschwindigkeit fällt weiter.

Shaping und Priorisierung, auch QoS genannt. Manche Anbieter drosseln internationalen Verkehr absichtlich oder schieben ihn nach hinten, manchmal auch nur eine bestimmte Art davon. Man sieht es sofort an der Geschwindigkeit.

Protokoll-Overhead. Die Kopfdaten von TCP, IP und Verschlüsselung fressen einen Teil der Bandbreite. Auf kurzer Strecke sieht man davon nichts. Zusammen mit Verlust und Verzögerung auf langer Strecke kommt einiges zusammen.

Ihre eigene Umgebung. WLAN statt Kabel, ein überlasteter Heimrouter, ein Virenscanner oder ein VPN auf dem Gerät drücken die reale Geschwindigkeit ebenfalls. Schließen Sie das zuerst aus, bevor Sie in der Ferne suchen.

Warum es weder an der Technik noch am Dienst liegt

Ein hohes Ergebnis bei Speedtest beweist, dass Ihre Technik und Ihre lokale Leitung gesund sind und die vorgesehene Geschwindigkeit liefern. Der Einbruch bei Servern in der EU kommt von woanders. Schuld sind die Verzögerung auf langer Strecke, das Fensterlimit einer einzelnen TCP-Verbindung, Paketverluste und der Zustand der internationalen Kanäle Ihres Anbieters. Das alles liegt außerhalb unseres Dienstes und außerhalb Ihrer Technik, nämlich auf dem Netzabschnitt zwischen Ihrem Anbieter und den Backbone-Betreibern.

Und noch etwas, bevor Sie den Zahlen hinterherlaufen. Ein Webinar braucht weit weniger als eine Dateiübertragung, deshalb reichen uns 20 Mbit/s in die EU völlig. Ein Referent braucht rund 1,6 Mbit/s im Versand, mit Bildschirmfreigabe rund 3,2. Ein Teilnehmer braucht genug für jeden Sprecher auf Sendung, und alle Zahlen nennt Technische Voraussetzungen. Stabilität zählt hier mehr als nackte Geschwindigkeit. Laufen Ihre Veranstaltungen glatt, ist der Abstand zu Speedtest eine Kuriosität und kein Defekt.

Wie Sie das selbst nachmessen

Ein paar Prüfungen zeigen die Ursache.

• Starten Sie Speedtest von Hand und wählen Sie einen Server in Deutschland oder in Finnland. Alle unsere Server stehen in der EU, in Deutschland, Frankreich, den Niederlanden und Finnland, doch die Sendung tragen die deutschen und die finnischen Maschinen. Die niederländischen und die französischen verschicken die Einladungen zu bevorstehenden Veranstaltungen. Eine Messung gegen diese beiden erzählt Ihnen also von einer Strecke, die Ihre Webinare nie nehmen. Deutschland und Finnland zeigen die echte Geschwindigkeit auf der Strecke, die wirklich benutzt wird, und nicht die zum nächsten lokalen Server.
• Verfolgen Sie die Strecke. Der Befehl tracert unter Windows oder traceroute unter macOS und Linux zu unserem Server liefert die Kette der Knoten mit der Verzögerung an jedem. Verlust und Verzögerung zeigt das Werkzeug mtr anschaulicher, unter Windows heißt es WinMTR, und Sie lassen es zur Spitzenzeit ein paar Minuten laufen.
• Vergleichen Sie eine Verbindung mit mehreren. Ist der Download über mehrere Ströme schnell und über einen einzigen langsam? Genau das bestätigt das Fensterlimit von TCP auf langer Strecke.
• Haben Sie die technische Möglichkeit? Messen Sie den Durchsatz zum fernen Knoten direkt mit iperf3, erst mit einem Strom, dann mit mehreren.

In unserem Geräte-Test liegt außerdem ein Link auf eine eigene Prüfung der Internetqualität mit Geschwindigkeit, Ping und Jitter. Ein schneller Weg, den Zustand der Leitung in einem bestimmten Moment festzuhalten.

Was zu tun ist

Zeigen Ihre Prüfungen hohe Verzögerung oder Paketverluste auf der internationalen Teilstrecke? Gehen Sie mit konkreten Daten zu Ihrem Anbieter, also mit der Streckenverfolgung und einer Messung von mtr samt Uhrzeit. Die Strecke zu ändern oder die internationale Anbindung auszubauen, ist Sache des Anbieters. Von unserer Seite geben wir die Adressen unserer Server für die gezielte Diagnose und helfen beim Lesen der Ergebnisse. Schreiben Sie uns im Online-Chat, und wir schicken sie Ihnen.

Unter dem Strich

Ein Ergebnis um 290 Mbit/s bei Speedtest bestätigt, dass Ihre Leitung gesund ist. Der Einbruch unter 40 Mbit/s bei Servern in der EU ist zu erwarten. Er kommt von der Verzögerung auf langer Strecke, vom Fensterlimit einer einzelnen TCP-Verbindung, von Paketverlusten und von der Last auf den internationalen Kanälen Ihres Anbieters. Diese Ursachen sitzen im Netz zwischen Ihnen und uns, nicht in Ihrer Technik und nicht in unserem Dienst. Eine einfache Diagnose der Strecke zeigt, welche der vier gerade schadet.

Häufig gestellte Fragen

Soll ich eine schnellere Leitung kaufen, um das zu beheben?

Nein. Ein Webinar braucht weit weniger als eine Dateiübertragung, und 20 Mbit/s in die EU reichen uns völlig. Ein Referent braucht rund 1,6 Mbit/s im Versand, mit Bildschirmfreigabe rund 3,2, und alle Zahlen nennt Technische Voraussetzungen. Stabilität zählt hier mehr als nackte Geschwindigkeit. Laufen Ihre Veranstaltungen glatt, ist der Abstand zu Speedtest eine Kuriosität und kein Defekt.

Mein Empfang ist um das Achtfache gefallen, mein Versand kaum. Was davon zählt?

Der Versand, wenn Sie selbst das Webinar führen. Kamera, Mikrofon und Bildschirm gehen nach oben weg, und das ist die Zahl "FROM YOU". Ein Teilnehmer, der nur zuschaut, hängt an "TO YOU", dieselbe Messung liest sich also je nach Rolle bei der Veranstaltung anders. In der Messung oben rutschte der Versand nur von 26 auf 16 Mbit/s. Das ist etwa das Zehnfache dessen, was ein Referent braucht.

Gegen welchen Speedtest-Server messe ich für einen fairen Vergleich?

Gegen einen in Deutschland oder in Finnland. Alle unsere Server stehen in der EU, in Deutschland, Frankreich, den Niederlanden und Finnland, doch die Sendung tragen die deutschen und die finnischen Maschinen. Die niederländischen und die französischen verschicken die Einladungen zu bevorstehenden Veranstaltungen. Eine Messung gegen diese beiden erzählt Ihnen also von einer Strecke, die Ihre Webinare nie nehmen.

Was davon kann ich selbst beheben?

Fangen Sie bei sich an. WLAN statt Kabel, ein überlasteter Heimrouter, ein Virenscanner oder ein VPN auf dem Gerät drücken die reale Geschwindigkeit. Ist hier alles sauber und zeigen die Prüfungen trotzdem hohe Verzögerung oder Verluste auf der internationalen Teilstrecke? Dann liegt es beim Anbieter. Gehen Sie dorthin mit konkreten Daten, also mit der Streckenverfolgung und einer Messung von mtr samt Uhrzeit. Die Adressen unserer Server für die gezielte Diagnose geben wir Ihnen, schreiben Sie uns dazu im Online-Chat.

Warum ist die Strecke morgens in Ordnung und abends unbrauchbar?

Internationale Kanäle kaufen die Anbieter nur in begrenztem Umfang ein, und am Abend in der Spitze werden sie zum Nadelöhr. Lokaler Verkehr hat reichlich Reserve, darum hält sich Speedtest zu einem nahen Server den ganzen Tag hoch. Paketverluste folgen derselben Kurve, und 1 bis 2 Prozent auf langen Transitstrecken sind zur Spitzenzeit völlig normal. Bei einem RTT von 50 ms hält ein Prozent Verlust eine einzelne Verbindung bei rund 2,3 Mbit/s. Genau das macht aus einer nur langsamen Strecke eine unbrauchbare.