Telekom Speedtest
Wie schnell ist wohl meine Internet-Verbindung? Diese Frage wird sich jeder Nutzer stellen, wenn ein Download mal wieder zu lange dauert. Telekom-Kunden können einen Service der Telekom unter http://speedtest.t-online.de nutzen, um zumindest die Verbindung innerhalb des Telekom-Netzwerks zu prüfen.
Der Test
Ich war eigentlich auf der Suche nach Tools um die Anbindung von Kunden an Office 365 zu prüfen und viele haben natürlich einen Telekom-Anschluss zuhause. Da hat mich interessiert, wie die Telekom den Speed-Test durchführt. Also habe ich Anfang Sep 2016 mal bei mir den Test gestartet und mit NetMon dahinter zugeschaut, was da passiert. Es genügt ein Browser, um den Test durchzuführen und da die Telekom nichts verschlüsselt, kann man auch gut dabei zuschauen. Hier erst mal das Ergebnis.
So sieht es im September 2016 in Hövelhof in einem Neubaugebiet aus. Allerdings werden aktuell schon Kabel verbuddelt und es besteht Hoffnung, dass sich hier noch etwas bessert. Aber es ist ja nicht nur die Geschwindigkeit der "letzten Meile". Die Gesamtperformance zu unterschiedlichen Zielen ist ja wichtiger. Nicht desto trotz ist der Test zumindest eine Prüfung der Leistung des Zugangsproviders. Das habe ich zumindest erwartet. Sie können auch gut sehen, dass die Telekom-Testroutine hier den Download, Upload und Pings misst.
Wer misst...
Entsprechend habe ich im NetMon 3 natürlich Pakete erwartet und gefunden.
- Download
Sehr einfach sind am Anfang noch die Pakete zu finden, mit denen der Browser wohl einen Download anfordert und dann auch ausführt. Es sieht so aus, als ob hier vier parallele Downloads gestartet werden.
Der Payload sind dann aber einfach "leere"CR/LR-Zeichen mit 1452 Bytes/Paket. nicht weiter spektakulär - Upload
Auch der Upload ist relativ schnell ausfindig gemacht
Hier scheint das Tool dann vier HTTP-Post-Requests zu einem Server zu senden, um die Performance zu messen. Allerdings wird hier wohl ein "Dummy-Text" gesendet und die Gegenseite ist ein IIS 8.5 - Ping
Ich war schon neugierig, wie die Telekom wohl ein "PING" umsetzt. Allerdings war es gar kein ICMP-Ping, sondern ein HTTP-Ping.
Darf sie ohne Fragen einen Report senden ?
Was die Telekom aber beim Test nicht verrät ist die Tatsache, dass die Ergebnisse nicht nur ihnen im Browser angezeigt werden, sondern anscheinend auch zur Telekom gemeldet werden:
Im Payload findet sich folgender JSON-Datensatz
{
"speedTestRun":"2016-09-04T23:04:04.121Z",
"planId":"Ax4001",
"connectionInfo":{
"city":"Paderborn",
"providerName":"Telekom",
"originalProviderName":"Telekom",
"originalPlanId":"Ax4001",
"countryCode":"DE",
"countryName":"Germany",
"accessRegion":"5251",
"mobileApp":false,
"downloadSpeedResult":8.18463169463871,
"uploadSpeedResult":1.2292695318218078,
"pingResult":21.25,
"actualDownloadSpeed":8.09,
"actualUploadSpeed":0.81,
"accessDownloadSpeed":8.09,
"accessUploadSpeed":0.81,
"productDownloadSpeed":16,
"productUploadSpeed":1.02,
"UserAgent":"Mozilla/5.0 (Windows NT 6.1; gekuerzt.. like Gecko",
"averageDownloadSpeed":8.18463169463871,
"averageUploadSpeed":1.2292695318218078
},
"availablePlans":[{
"planId":"Ax4001",
"planName":"DSL 16000",
"downloadSpeed":16,
"uploadSpeed":1,
"averageDownloadSpeed":10.004244713136442,
"averageUploadSpeed":1.309694506809406,
"problemTreshold":80,
"provider":"Telekom"
}],
"UserId":"59a023d5-bc37-4553-974e-784f790b47e2"
}
Wenn die Telekom hier so genau bescheid weiß, dann muss die Anfrage vorher ja schon ermittelt haben, was ich für einen Anschluss haben.
Die Gegenstelle 78.143.14.243
Download und Ping laufen gegen diese Gegenstelle, die Laut Internet Datenbanken zur Firma link11.de gehört. Viele Stationen auf dem Weg dorthin sind per DNS nicht auflösbar, so dass ich per Whois die Adressen einem Provider zugeordnet und in Klammen den Namen addiert habe.
C:\>tracert 78.143.14.243 Routenverfolgung zu 78.143.14.243 über maximal 30 Abschnitte 1 13 ms 4 ms 15 ms fritz.box [192.168.178.1] 2 9 ms 19 ms 25 ms 87.186.225.45 (Telekom) 3 29 ms 18 ms 10 ms 217.0.92.90 (Telekom bei Kassel) 4 29 ms 28 ms 30 ms 217.239.51.10 (Telekom bei Kassel) 5 15 ms 24 ms 15 ms 194.25.210.10 (Telekom bei Kassel) 6 15 ms 23 ms 16 ms 78.143.14.243 (Telekom Frankfurt)
Interessant ist, dass man im GET-Request einen Hostnamen sieht, der auf UK verweist.
Per NSLOOKUP auf diesen Host bekomme ich zumindest auch diese IP-Adresse
C:\>nslookup speedtest-cdn.tmdev.t-motion.co.uk Server: fritz.box Address: fd00::a96:d7ff:fe49:d262 Nicht autorisierende Antwort: Name: speedtest-cdn.tmdev.t-motion.co.uk Address: 78.143.14.243
Aus den Daten lässt sich wunderbar auch die URL generieren und diese kann sogar im Browser angesprochen werden.
http://speedtest-cdn.tmdev.t-motion.co.uk/download_test.bin
Die dort hinterlegte Datei ist sicherlich groß genug, um auch zukünftige schnelle Verbindungen für einige Sekunden zu beschäftigen.
Die Gegenstelle 191.233.93.31
Für den Upload kommt eine andere Gegenstelle zum Einsatz. Der TraceRoute zeigt eine überraschende Information: Die Gegenstelle scheint in Office 365/Azure angesiedelt zu sein.
C:\>tracert 191.233.93.31 Routenverfolgung zu 191.233.93.31 über maximal 30 Abschnitte 1 2 ms 12 ms 19 ms fritz.box [192.168.178.1] 2 16 ms 21 ms 9 ms 87.186.225.45 3 11 ms 12 ms 9 ms 217.0.92.86 4 19 ms 48 ms 19 ms 217.239.52.146 5 15 ms 16 ms 15 ms 87.128.238.186 6 22 ms 36 ms 38 ms be-3-0.ibr02.ams.ntwk.msn.net [104.44.5.16] 7 23 ms 40 ms 23 ms ae73-0.am3-96c-1b.ntwk.msn.net [104.44.5.3] 8 21 ms 21 ms 33 ms ae0-0.am3-96c-1a.ntwk.msn.net [207.46.42.60] 9 * * * Zeitüberschreitung der Anforderung. 10 * * * Zeitüberschreitung der Anforderung. 11 * * * Zeitüberschreitung der Anforderung. 12 * * * Zeitüberschreitung der Anforderung.
Das hätte ich nun nicht erwartet. Sicher hat Microsoft ein vitales Interesse daran, schnelle Anbindungen zu allen Providern als direktes Peering aufzubauen und nicht auf DECIX und andere Peering-Punkte zu vertrauen. Aber Azure ist zwar gut angebunden aber wird auch nach Bandbreite berechnet. Allerdings ist da auch gut zu sehen, dass "eingehende Bandbreite" nicht kostet:
Quelle:
https://azure.microsoft.com/en-us/pricing/details/bandwidth/
Da war wohl jemand pfiffig, wenn er Azure als digitalen Mülleimer zum Upload von Testdaten verwendet und nur ab und an eine Quittung zurück senden muss
Bewertung
Bandbreite zu messen ist immer ein gutes Werkzeug um Probleme bei der Verbindung zu verifizieren. Dies gilt insbesondere bei der Messung eines neuen Anschlusses, ob dieser die versprochene Bandbreite liefert. Dabei ist aber die Wahl des Zielsystems essentiell, um verlässliche und unverfälschte Zahlen zu erhalten.
Für einen Teilnehmer, für den ein bestimmtes Ziel wie z.B. Office 365, wichtig ist, kommt dem allgemeinen Telekom-test nicht weit. Er ist darauf ausgelegt, dem Anwender möglichst neutral seine lokale Anbindung zu messen. Ich bin dennoch überrascht, dass die Telekom die Pakete so weit durch ihr LAN und sogar über Peerings zu anderen Diensten überträgt und nicht selbst in ihrem eigenen Netzwerk "nahe beim Kunden" einen entsprechenden Service betreibt. Es muss ja kein UDP-Echo eines Routers sein aber ich gehe schon davon aus, dass die Radius-Server für die Anmeldung an einige Standorte verteilt sind und sich dort sicher auch Gegenstellen für einen "lokalen" Bandbreiten-Test aufstellen ließen.
Mit dem hier sichtbaren Aufbau (Stand 2016) sind Fremdeinflüsse möglich, die die Messwerte verschlechtern. Aber selbst wenn die Messwerte "gut" sind, ist es noch lange keine Garantie für eine gute Performance zu anderen Diensten. Dazu gibt es einfach viele anderen Provider. Das Bild bleibt lückenhaft, solange der Anwender nicht seine "gängigen Ziele" selbst anspricht. Einen automatischen Test, der zu den häufig besuchten Webseiten (YouTube, Google, Netflix, Amazon etc.) die Laufzeiten misst, kenne ich auch nicht.
Ich nutze den Test dennoch gerne bei einem Telekom-Anschluss und wenn die erreichten Bandbreiten an die versprochenen Datenraten heranreichen, sind zumindest die ersten Hops qualitativ zum Zeitpunkt der Messing gesichert.
