Rückblick, datiert auf das Ende des Semesters, kurz vor dem Roadtrip.
800 Mal dig: was ich in einem Semester über Internet-Messungen gelernt habe
Im englischsprachigen Kurs Introduction to Internet Measurements habe ich jede Woche eine Messung entworfen, laufen lassen und ausgewertet. Am Ende stand eine eigene RIPE-Atlas-Studie.
Fünf Domains, vier DNS-Resolver, UDP und TCP, jeweils 20 Durchläufe. Das sind 800 Mal dig, und am Ende eine Heatmap, auf der man mit einem Blick sieht, welcher Resolver wo langsam wird.
Das war die vierte von fünf Hausaufgaben in Introduction to Internet Measurements, einem Kurs am HPI, komplett auf Englisch. Das Prinzip war jede Woche dasselbe: eine Messung entwerfen, sie laufen lassen, die Daten auswerten und aufschreiben, was sie zeigen und was nicht. Alles Einzelabgaben. Über das Semester sind so rund 5.900 Zeilen Python zusammengekommen, alle von mir.
Angefangen hat es klein. Eigene Ping- und Traceroute-Reihen alle fünf Minuten, ein Wireshark-Mitschnitt. Dann Speedtest-Server per GeoIP verorten und schauen, ob Entfernung und Durchsatz zusammenhängen. Dann passive Daten: NetFlow mit SiLK, wer im Netz am meisten redet und wie sich das Volumen pro Minute verteilt. Und MAWI-Traces, echte Mitschnitte eines Backbone-Links, aus denen ich HTTP-Statuscodes und den Anteil von DNS über UDP und TCP gezogen habe.
Die DNS-Studie ist der Teil, den die Demo auf dieser Seite nachspielt, mit den 800 Messungen aus dem Kurs. Die Pipeline ist simpel. Ein Shell-Skript ruft dig für jede Kombination aus Domain, Resolver und Protokoll auf und schreibt die Antwortzeit in eine CSV. Ein Python-Skript liest die CSV, rechnet Perzentile und malt die Heatmap: Zeilen sind Domains, Spalten sind Resolver, die Farbe ist die Zeit.
- 01dnsLookUp.sh
- 02dnsTimes.csv
- 03analyseDNS.py
- 04RIPE Atlas
Kapitel 1 bis 3 nutzen meine echten Kursmessungen (800 dig-Abfragen von einem Rechner, ein Durchlauf; kein allgemeiner Benchmark). Kapitel 4 zeigt nur das Studiendesign aus meiner Hausaufgabe, mit synthetischen Probe-Positionen und ohne Messergebnisse.
Warum Perzentile? Weil der Durchschnitt bei Netzwerkzeiten lügt. Ein einziger Ausreißer von einer Sekunde zieht den Mittelwert hoch, obwohl 19 von 20 Anfragen schnell waren. Das 95. Perzentil sagt dagegen: So lange musst du in 95 von 100 Fällen höchstens warten. Das ist die Zahl, die man als Nutzer spürt. Die Verteilungsansicht in der Demo zeigt genau das, alle Messungen sortiert statt einer einzigen Zahl.
Die fünfte Aufgabe war frei. Ich habe eine eigene Studie mit RIPE Atlas entworfen, einem Netz aus Messsonden auf der ganzen Welt. Die Frage: Wie schlagen sich Cloudflare 1.1.1.1 und DNS4EU, wenn man aus dem Starlink-Netz fragt? Das Fiese bei DNS ist Caching. Fragt man zweimal dasselbe, misst man beim zweiten Mal den Cache und nicht den Resolver. Deshalb bekommt jede Sonde eine eigene Subdomain mit ihrer Sonden-ID drin, die vorher garantiert niemand gefragt hat. Dazu drei Skripte, die Messungen anlegen, die Ergebnisse herunterladen und auswerten, und ein README mit Forschungsfragen, Messmatrix und einer Rechnung, wie viele Credits das Ganze kostet.
Was ich mitnehme. Erst die Störgrößen, dann die Messung. Ohne die Subdomain-Idee hätte ich vor allem den Cache gemessen. Zweitens: Perzentile statt Mittelwerte, zumindest bei allem, was mit Wartezeit zu tun hat. Drittens: Aufschreiben ist Teil der Messung. Die DNS-Studie habe ich als LaTeX-Ausarbeitung auf Englisch abgegeben, und erst beim Schreiben wird klar, welcher Plot wirklich etwas zeigt.
Tools und Skills: Python mit pandas und matplotlib, Shell und dig, die RIPE-Atlas-API, MaxMind GeoLite2, SiLK, Wireshark, LaTeX. Und Experiment-Design, also die Frage, was man eigentlich misst, bevor man es misst.