Begriff

0-RTT (Zero Round Trip Time)

Networking Performance S4

2 Quellen 0 Lernpfade 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Normalerweise:

Client: "Hallo Server!" (Ping)
Server: "Hallo Client!" (Pong)
Client: "Gib mir /index.html" (Request) Das sind Round Trips. Das dauert. Bei 0-RTT (in TLS 1.3 und QUIC) kennt der Client den Server schon von früher. Er hat ein "Ticket". Er sagt: "Hallo Server! Hier ist mein Ticket UND gib mir sofort /index.html!" Alles im allerallerersten Paket. Null Wartezeit. Schneller geht es physikalisch nicht.

Merksatz: Ein Feature von TLS 1.3 und QUIC, das es Clients ermöglicht, verschlüsselte Anwendungsdaten bereits im allerersten Paket des Handshakes zu senden, wenn sie den Server bereits kennen (Session Resumption).

1. Replay Protection & Anti-Replay Tokens

Da 0-RTT Pakete keine frische Nonce des Servers enthalten können, sind sie von Natur aus anfällig für Replays. Server-Betreiber nutzen oft zwei Strategien:

Strike-Register: Der Server speichert einen Hash aller 0-RTT-Kürzel, die er in einem kurzen Zeitfenster gesehen hat. Kommt der gleiche Hash nochmal, wird er abgelehnt. Das Problem: In einem verteilten System (viele Edge-Server) müssten diese Register weltweit synchronisiert werden – ein Albtraum für die Latenz.
Client Hello Recording: Alternativ wird 0-RTT nur akzeptiert, wenn das Protokoll "idempotent" ist. Ein modernes CDN wie Cloudflare prüft den HTTP-Verb: Ein GET auf ein statisches Bild wird via 0-RTT durchgelassen, ein POST /payment wird vom Server gepuffert, bis der vollständige Handshake (der 1-RTT Teil) die Identität des Clients zweifelsfrei bestätigt hat.

2. PFS (Perfect Forward Secrecy) Gap

Ein technisches Detail, das oft übersehen wird: 0-RTT-Daten haben keine vollständige Forward Secrecy. Die Early Data werden mit einem Schlüssel verschlüsselt, der aus dem Ticket (dem PSK - Pre-Shared Key) abgeleitet wurde. Wenn ein Hacker den Ticket-Schlüssel des Servers stiehlt (z. B. durch Auslesen des Speichers), kann er alle aufgezeichneten 0-RTT-Daten der Vergangenheit entschlüsseln. Erst die Daten, die nach dem vollständigen Diffie-Hellman-Key-Exchange gesendet werden, sind wieder "Forward Secret". Für hochsensible Apps bedeutet das: Schicke niemals Passwörter oder Geheimnisse in den Early Data, auch wenn es ein "GET" ist.

3. QUIC vs. TCP 0-RTT

In QUIC ist 0-RTT tief im Transport-Layer verankert. Während TCP 0-RTT (TFO - TCP Fast Open) oft an Firewalls scheitert, die unbekannte TCP-Optionen einfach löschen, ist QUIC komplett verschlüsselt (UDP). Firewalls können den 0-RTT-Teil gar nicht sehen und somit nicht blockieren. Zudem erlaubt QUIC das sogenannte Connection Migration: Wenn du vom WLAN ins LTE-Netz wechselst, kann QUIC die Verbindung ohne neuen Handshake fortsetzen. In Kombination mit 0-RTT fühlt sich das Internet auf mobilen Geräten damit fast "instant" an.

Quick-Check

Sicher?
Ja, gegen Abhören (PFS gilt aber oft NICHT für die 0-RTT Daten selbst, erst für die Daten NACH dem Handshake!). Und Gefahr von Replay.
Wie viel Daten?
Nur wenig (typisch einige KB). Genug für einen HTTP-GET Header, aber nicht für einen Datei-Upload.
Wer braucht das?
Mobile Apps. Jede Millisekunde zählt beim App-Start. 0-RTT spart 50-100ms.