Hallo Welt – die Reise eines Pakets durch die Frickelfabrik

Ein erster Blogbeitrag heißt traditionell „Hallo Welt“. Man stellt sich vor, verspricht regelmäßige Beiträge und hält sich dann nicht daran.

Ich mache es anders. Ich begleite dich auf dem Weg, den du gerade selbst zurückgelegt hast, um diese Seite zu sehen. Ein einzelner Aufruf, vom Klick bis zum fertigen Bild. Mit echten Messwerten, einem echten Mitschnitt und allem, was mir dabei aufgefallen ist. Denn genau darum geht es hier: Sachen selbst bauen, verstehen, warum sie funktionieren – und ehrlich sagen, wo es noch hakt.

Kleine Vorwarnung: Bei meiner allerersten Messung war die Route verdächtig kurz. Genau ein Hop, direkt zum Ziel. Ich saß selbst im VPN-Tunnel zu meinem Server. Also: VPN aus, nochmal von vorn.

Etappe 1: Wo wohnt frickelfabrik.de?

Bevor dein Browser irgendetwas schicken kann, muss er wissen, wohin. Er fragt also das DNS – das Telefonbuch des Internets. Und das funktioniert wie eine Kette von Auskünften:

1. Die Root-Server sagen: „Für .de frag bei der DENIC nach.“
2. Die DENIC-Server sagen: „Für frickelfabrik.de sind die Nameserver von Hetzner zuständig.“
3. Hetzners Nameserver liefern die Antwort: 138.201.35.220.

Mit dig +trace lässt sich diese Kette Schritt für Schritt verfolgen. Aus dem Rechenzentrum heraus antworten die Hetzner-Nameserver übrigens in 4 Millisekunden – die stehen quasi im Nachbarrack.

Für dich als Leser geht es meistens noch schneller, weil dein Router oder Provider die Antwort schon kennt. Bei mir lag die Auflösung je nach Cache zwischen 5 und 70 Millisekunden.

Baustelle Nr. 1: Auf die Frage nach einer IPv6-Adresse (AAAA-Record) bekommt man nur ein Schulterzucken. Die Frickelfabrik spricht aktuell nur IPv4. Und DNSSEC ist für die Domain auch noch nicht eingerichtet. Beides steht auf der Liste.

Etappe 2: Von Bremen nach Nürnberg – über Frankfurt

Jetzt kennt dein Rechner die Adresse und schickt das erste Paket los. Wohin genau, zeigt tracert (unter Linux traceroute oder mtr). Von meinem Anschluss in Bremen aus sieht das so aus:

Das Schöne daran: Von Bremen nach Nürnberg geht es über Frankfurt. Am DE-CIX, einem der größten Internetknoten der Welt, übergibt mein Provider das Paket an Hetzner. Klingt nach Umweg, kostet aber fast nichts. Nach rund 20 Millisekunden ist das Paket in Nürnberg.

Kasten: Warum dir pathping Angst macht, obwohl alles gut ist

Unter Windows gibt es pathping, das pro Hop auch den Paketverlust misst. Bei mir zeigte es an drei Routern in der Mitte 100 % Verlust – und am Ziel 0 %.

Kein Grund zur Panik: Router leiten fremde Pakete mit Höchstgeschwindigkeit weiter, beantworten aber Anfragen an sich selbst (ICMP) nur, wenn sie gerade Lust haben. Oder gar nicht. Entscheidend ist der Wert am Ziel und die Spalte für die Verbindungen dazwischen. Und die stand überall auf 0 %.

Etappe 3: Anklopfen – TCP und TLS

Jetzt wird es spannend. Um mitzuschneiden, was in Nürnberg ankommt, habe ich auf dem Server tshark laufen lassen (die Kommandozeilen-Version von Wireshark) und die Seite von zu Hause aufgerufen. So sieht ein Verbindungsaufbau aus Sicht des Servers aus:

Die 20 Millisekunden zwischen SYN/ACK und ACK sind die Strecke Nürnberg–Bremen–Nürnberg. Der Server selbst braucht für seine Antworten Bruchteile einer Millisekunde.

Der TLS-Handshake ist nach genau einer Runde fertig. Das ist das Kennzeichen von TLS 1.3. Ältere Versionen brauchten zwei Runden. Danach spricht der Browser mit dem Server HTTP/2.

Zwei Details aus dem Mitschnitt, die ich besonders mag:

Man sieht, dass ich DSL habe. Beim Verbindungsaufbau sagt jede Seite, wie große Datenpakete sie verträgt (die MSS). Der Server meldet 1460 Byte, mein Rechner nur 1452. Die fehlenden 8 Byte sind der Overhead von PPPoE, über das DSL-Anschlüsse typischerweise laufen.

Mein Browser denkt an die Zukunft. Mein Server noch nicht. Das Client Hello meines Browsers war mit gut 2 KB ungewöhnlich groß und passte nicht in ein einzelnes Paket. Der Grund: Moderne Browser schicken inzwischen zusätzlich einen Schlüssel für ein Post-Quanten-Verfahren mit (X25519MLKEM768). Das soll verhindern, dass heute mitgeschnittener Verkehr in einigen Jahren von Quantencomputern entschlüsselt werden kann.

Mein Server hat das Angebot freundlich ignoriert und das klassische X25519 gewählt. Das Windows-eigene curl hat Post-Quanten übrigens gar nicht erst angeboten.

Baustelle Nr. 2: Post-Quanten-Schlüsselaustausch auf dem Server aktivieren. Das wird ein eigener Beitrag.

Kasten: Die 139 Millisekunden, die nie wiederkamen

Bei meiner allerersten Messung brauchte der TLS-Handshake 139 ms statt der üblichen 30. Ich hatte sofort eine Theorie: Windows prüft beim ersten Kontakt, ob das Zertifikat gesperrt wurde, und das dauert. Also Sperrprüfung abgeschaltet – kein Unterschied. Zweite Theorie: Der Cache für diese Prüfungen war kalt. Cache geleert – kein Unterschied.

Zwei Theorien, beide widerlegt, und den Wert habe ich nie wieder gesehen. Auch das ist Frickeln.

Etappe 4: Ankunft in Nürnberg

In Nürnberg steht ein Dedicated Server bei Hetzner, auf dem Proxmox läuft. Auf diesem Host laufen mehrere virtuelle Maschinen und Container. Dein Paket kommt dort an der öffentlichen Adresse an und wird dann intern weitergereicht:

Die Proxy-VM ist die Empfangsdame des Hauses. Sie nimmt alle verschlüsselten Verbindungen an, schaut nach, welche Seite gemeint ist, und reicht die Anfrage an den richtigen Container weiter. Hinter ihr wohnen noch einige andere Projekte, aber das ist eine Geschichte für einen anderen Tag.

Zwei Dinge haben mich im Mitschnitt gefreut:

• Die Proxy-VM hält ständig Verbindungen zum Blog offen. Sie muss nicht für jeden Leser eine neue Verbindung aufbauen, sondern hat schon eine warm laufen.
• Der Blog-Container ist schnell. Die Maschinenraum-Seite liefert er in 1,9 Millisekunden aus, Bilder und Logos in unter einer Millisekunde. Das ist der Vorteil einer statischen Seite: Es gibt nichts zu berechnen, nur Dateien auszuliefern.

Beim Aufruf im Browser kamen insgesamt rund 30 Dateien zusammen: HTML, CSS, JavaScript, Logos, mein Foto und Schriften. Alles über eine einzige Verbindung, dank HTTP/2.

Baustelle Nr. 3: Die Schriften. Mein Browser hat 14 Schriftdateien geladen, zusammen rund 305 KB. Zum Vergleich: Mein Foto wiegt 46 KB. Ich lade jede Schriftstärke einzeln und dazu noch Zeichensätze, die ich kaum brauche. Da lässt sich viel sparen. Auch das wird ein eigener Beitrag.

Die Zahl, um die es eigentlich geht

Hier ist ein einzelner Aufruf der Maschinenraum-Seite, gemessen von meinem Rechner zu Hause:

Derselbe Aufruf im Mitschnitt auf dem Server zeigt: Der Blog-Container war damit 1,9 Millisekunden beschäftigt.

Das sind 1,3 Prozent. Die restlichen 98,7 Prozent verbringt das Paket unterwegs: beim Nachschlagen der Adresse, auf der Strecke über Frankfurt, beim Händeschütteln und bei der Übertragung.

Mein Server ist schnell. Das Internet ist weit.

Und was ist mit Bremen?

Auf der Startseite steht, dass ein Raspberry Pi in meinem Hauswirtschaftsraum Teil der Frickelfabrik ist. Ich war selbst überzeugt, dass dein Aufruf durch den WireGuard-Tunnel zu ihm reist.

Der Mitschnitt sagt etwas anderes: Dein Paket fährt nie nach Bremen. Die komplette Seite wird in Nürnberg ausgeliefert.

Der Pi spielt trotzdem mit, nur andersherum. Auf dem Proxmox-Host läuft ein kleines Skript, das jede Minute einmal alles abklopft: die virtuellen Maschinen, die Dienste und durch den verschlüsselten Tunnel auch den Pi und alles, was in Bremen läuft. Das Ergebnis landet als kleine Datei beim Blog. Genau diese Datei liest der Maschinenraum, wenn du ihn öffnest.

Mit anderen Worten: Jede Minute schickt Nürnberg einen Boten durch den Tunnel nach Bremen und fragt den Pi: „Lebst du noch?“ Was er zurückbringt, siehst du im Maschinenraum.

Was sonst noch vorbeikommt

Mein Mitschnitt lief insgesamt nur wenige Minuten. In dieser Zeit kamen neben mir noch ein paar andere Besucher vorbei:

• Ein Bot, der auf einer der anderen Seiten hier nach einer WordPress-Anmeldeseite gesucht hat. Er hat sie gefunden, ist aber nicht weit gekommen.
• Ein Suchmaschinen-Crawler, der sich gerade für Veranstaltungskalender-Seiten aus dem Jahr 2019 interessierte.
• Mein eigener Monitor, der jede Minute pünktlich nachfragt, ob noch alles läuft.

Wer einen Server ins Internet stellt, ist nie allein.

Die Baustellenliste

Ehrlich ist ehrlich. Bei dieser kleinen Reise sind vier Dinge aufgefallen, die noch besser gehen:

1. IPv6 fehlt komplett.
2. DNSSEC ist nicht eingerichtet.
3. Post-Quanten-Schlüsselaustausch bietet der Server noch nicht an.
4. Die Schriften sind viel zu schwer.

Jeder dieser Punkte wird ein eigener Beitrag. Mit allem, was dabei schiefgeht, und wie es am Ende doch klappt.

Zum Nachmachen

Wer seine eigene Seite so durchleuchten möchte, kommt mit wenigen Befehlen weit.

Zeiten pro Phase messen (Linux/macOS):

curl -o /dev/null -s -w "DNS:    %{time_namelookup}s\nTCP:    %{time_connect}s\nTLS:    %{time_appconnect}s\nTTFB:   %{time_starttransfer}s\nGesamt: %{time_total}s\n" https://example.org/

Unter Windows in der PowerShell heißt es curl.exe, statt /dev/null steht NUL und statt \n steht `n.

DNS-Kette und Route verfolgen:

dig +trace example.org
mtr -rwc 20 example.org      # Windows: tracert bzw. pathping

Auf dem Server mitschneiden und die Handshakes ansehen:

sudo tshark -i eth0 -f "tcp port 443" -a duration:60 -w /tmp/mitschnitt.pcapng
sudo tshark -r /tmp/mitschnitt.pcapng -Y "tls.handshake" \
  -T fields -e frame.time_relative -e tls.handshake.extensions_server_name -e _ws.col.Info

Ein Tipp aus eigener Erfahrung: Vor dem Messen das VPN ausschalten.

Das war die Frickelfabrik in 148 Millisekunden. Schön, dass du da bist.