Langsame Anwendung: Latenz-Breakdown (DNS→TCP→TLS→HTTP)

Eine langsame Anwendung ist selten „einfach langsam“. In modernen Umgebungen entsteht gefühlte Trägheit aus mehreren Teilstrecken: Namensauflösung (DNS), Verbindungsaufbau (TCP), Verschlüsselung (TLS) und eigentliche Anfrage/Antwort (HTTP). Genau hier setzt ein Latenz-Breakdown (DNS→TCP→TLS→HTTP) an: Statt pauschal das Netzwerk oder die Anwendung verantwortlich zu machen, zerlegen Sie die End-to-End-Zeit in messbare Komponenten. Das ist operativ wertvoll, weil jede Komponente eigene Failure Modes hat – von DNS-Cache-Misses über SYN-Retransmits bis zu langsamen TLS-Handshakes oder überlasteten Upstreams. Dieser Artikel zeigt eine strukturierte Vorgehensweise, mit der Einsteiger und Fortgeschrittene in kurzer Zeit belastbare Hypothesen bilden, passende Telemetrie sammeln und die richtige Owner-Zuordnung treffen. Sie lernen, welche Zeiten Sie erfassen müssen, wie Sie Browser- und CLI-Messungen interpretieren, welche Log-Felder in NOC/Ops wirklich helfen und wie Sie eine Performance-Regressionsanalyse sauber dokumentieren – ohne Rätselraten und ohne Keyword-Stuffing.

Warum ein Latenz-Breakdown die schnellste Diagnose liefert

„Die App ist langsam“ ist ein Symptom, keine Ursache. Ohne Zerlegung vermischen sich Effekte: Ein langsamer DNS-Lookup kann sich wie „TCP ist kaputt“ anfühlen, TLS-Probleme wirken wie „HTTP hängt“ und ein überlasteter Backend-Server sieht aus wie „das Netz hat Paketverlust“. Ein Latenz-Breakdown ordnet Beobachtungen vier klaren Phasen zu:

• DNS: Zeit bis zur IP-Adresse (Resolver, Cache, Autoritative, DNSSEC, NXDOMAIN/Timeout).
• TCP: Zeit bis zum erfolgreichen 3-Wege-Handshake (SYN/SYN-ACK/ACK), inkl. Retransmits.
• TLS: Zeit bis zum Abschluss des Handshakes (Zertifikatkette, Cipher, OCSP, Session Resumption).
• HTTP: Zeit bis zur ersten Antwort und vollständigen Datenübertragung (TTFB, Serververarbeitung, Transfer).

Das Ziel ist nicht akademisch: Sobald klar ist, in welcher Phase die Zeit verbrannt wird, können Sie gezielt eskalieren und Messpunkte ergänzen (z. B. Resolver-Logs vs. LB-Telemetrie vs. App-Traces).

Messmodell: Welche Zeiten gehören in den Breakdown?

Damit der Latenz-Breakdown vergleichbar wird, brauchen Sie ein einheitliches Messmodell. In der Praxis hat sich die Zerlegung in vier Hauptzeiten plus eine optionale Transferzeit bewährt:

• T_DNS: Dauer der Namensauflösung (inkl. Cache-Lookups).
• T_TCP: Dauer des TCP-Verbindungsaufbaus (Handshake).
• T_TLS: Dauer des TLS-Handshakes (bei HTTPS).
• T_HTTP: Zeit bis zur ersten Byte-Antwort (TTFB) oder bis Response-Header.
• T_Transfer (optional): Dauer der Datenübertragung (Payload).

Als einfache Beziehung gilt:

$T\_\mathrm{gesamt}=T\_\mathrm{DNS}+T\_\mathrm{TCP}+T\_\mathrm{TLS}+T\_\mathrm{HTTP}+T\_\mathrm{Transfer}$

Wichtig: Bei wiederverwendeten Verbindungen (Keepalive/HTTP/2/HTTP/3) entfallen TCP/TLS oft teilweise. Dann müssen Sie im Incident klar notieren, ob Ihre Messung „Cold“ (neue Verbindung) oder „Warm“ (Reuse) ist.

Praktische Messquellen: Browser, CLI und Observability richtig kombinieren

Für eine belastbare Diagnose sollten Sie Messungen aus mindestens zwei Perspektiven haben: Client-nah (Browser/CLI) und Infrastruktur-nah (Edge/LB/App). Das reduziert Fehlinterpretationen durch lokale Effekte (z. B. DNS-Cache auf dem Laptop).

• Browser (DevTools): zeigt DNS/Connect/SSL/TTFB als Timing-Phasen pro Request; gut für Enduser-Sicht.
• CLI (curl/wrk): reproduzierbar, automatisierbar, Vergleich von Regionen/Netzen möglich.
• Edge/CDN/WAF: hat Sicht auf Client-Handshake, TLS, Request-Routing und Origin-Fetch.
• Load Balancer/Ingress: liefert Upstream-Connect-Time, Backend-Response-Time, Retries.
• APM/Tracing: erklärt serverseitige Zeit (DB, Cache, externe Dependencies) innerhalb von HTTP.

DNS-Latenz: Wenn die Langsamkeit schon vor der IP beginnt

DNS ist oft der unsichtbare Zeitfresser. Gerade bei Microservices, vielen Domains oder strengen Sicherheitsfeatures (DNSSEC, DoH/DoT) kann die Namensauflösung spürbar werden. Typische Muster:

• Cache-Miss: erste Anfrage langsam, Folgeanfragen schnell (typisch bei niedrigen TTLs oder leeren Caches).
• Resolver-Overload: viele Timeouts/ServFail, erhöhte Retry-Rate, lange T_DNS über alle Clients.
• Autoritative Latenz: nur bestimmte Zonen/Records langsam, abhängig vom autoritativen Provider.
• Negative Caching: NXDOMAIN-Spikes können Lookup-Zeiten treiben, wenn Retries auftreten.

Operativer Schnellcheck:

• Vergleichen Sie T_DNS zwischen mehreren Resolvern (z. B. Unternehmensresolver vs. öffentlicher Resolver) und Standorten.
• Prüfen Sie TTLs: Zu niedrige TTLs erhöhen Cache-Misses und Last; zu hohe TTLs verzögern Rollbacks/Failovers.
• Erfassen Sie Query-Typen (A/AAAA/CNAME) und Kettenlängen: Viele CNAME-Hops erhöhen Latenz.

DNS-Telemetrie, die Sie im Ticket brauchen

• Domain/Record (A/AAAA/CNAME), beobachtete TTL, Antwortcodes (NOERROR, NXDOMAIN, SERVFAIL).
• Resolver-IP/Standort, Retry-Anzahl, Median/p95 von T_DNS.
• Falls vorhanden: Resolver-Logs (Cache-Hit/Miss, Upstream-Lookups, Response-Time).

TCP-Latenz: Handshake-Zeit, Retransmits und „unsichtbarer“ Paketverlust

Wenn DNS schnell ist, aber der Verbindungsaufbau hängt, liegt die Ursache häufig in Netzwerkpfaden, Firewalls, NAT oder Überlast an einem Zwischenpunkt. TCP-Latenz zeigt sich als erhöhte T_TCP – oder als sporadische Verbindungsabbrüche. Typische Gründe:

• RTT-Problem: lange Wege, suboptimales Routing, Peering-Probleme; T_TCP korreliert stark mit RTT.
• SYN-Retransmits: Paketverlust oder Filter; der Client sendet SYN erneut, Handshake verzögert sich.
• Stateful Firewall/NAT: Conntrack/Sessions nahe Limit, Port-Exhaustion, aggressive Timeouts.
• Rate Limiting auf L4: SYN-Cookies, Connection-Limits am LB, Schutzmechanismen in der Edge.

Operativ ist entscheidend, ob das Problem breit (viele Clients/Regions) oder pfadspezifisch ist (nur bestimmte Netze/ISPs). Ein Dutzend Messpunkte aus verschiedenen Quellen ist oft aussagekräftiger als ein einzelner Packet Capture.

TCP-Indikatoren in Logs und Metriken

• Connection Attempts/s, Connection Errors, SYN/SYN-ACK-Raten (falls verfügbar).
• LB-Metriken: Backend Connect Time, Reset/Timeout Counts, Retries.
• Client-Seite: Häufung von Timeouts vs. „Connection refused“ (das ist eher L4/Service-Exposure als Netzwerkpfad).

TLS-Latenz: Wenn Verschlüsselung der Engpass ist (oder so aussieht)

TLS ist eine häufige Quelle für „spürbare“ Latenz, weil Handshakes CPU kosten, Zertifikatsketten validiert werden und zusätzliche Netzwerk-Roundtrips entstehen können. Besonders bei mobilen Clients, strengen Proxies oder mTLS steigen die Zeiten. Typische Ursachen für erhöhtes T_TLS:

• Keine Session Resumption: Wiederaufbau jedes Mal „cold“, z. B. wegen falscher LB-Konfiguration oder kurzer Session-Tickets.
• OCSP/CRL-Delays: Client-Validierung dauert, insbesondere in restriktiven Netzwerken.
• Große Zertifikatskette: unnötige Intermediate-Zertifikate oder Fehlkonfigurationen erhöhen Payload und Parsing-Zeit.
• Cipher/Handshake-Parameter: suboptimale Cipher-Suites, fehlendes TLS 1.3, CPU-Druck auf Terminierungs-Hosts.
• mTLS: zusätzliche Client-Zertifikatsprüfung, CRL/OCSP, Policy-Evaluation.

Prüfen Sie außerdem, ob das Problem clientseitig ist: Manche Clients (alte Betriebssysteme, Enterprise-Proxies) reagieren empfindlich auf bestimmte TLS-Parameter und wirken dann „langsam“ oder brechen ab.

TLS-Schnellcheck ohne App-Zugriff

• Vergleichen Sie TLS-Handshake-Zeit aus mehreren Netzen (intern/extern) und Geräten.
• Prüfen Sie, ob TLS 1.3 genutzt wird und ob Resumption funktioniert (Ticket/Session-ID, je nach Umgebung).
• Nutzen Sie Edge-/LB-Metriken: Handshakes/s, CPU, TLS Error Rates, Resumption-Rate.

HTTP-Latenz: TTFB, Serverzeit und die „versteckten“ Abhängigkeiten

Wenn DNS/TCP/TLS schnell sind, bleibt meist HTTP beziehungsweise die serverseitige Verarbeitung. In der Praxis ist TTFB (Time To First Byte) das wichtigste Signal: Es verbindet Netzwerk und Applikation, weil es sowohl Transport als auch Backend-Verarbeitung enthält. Typische Ursachen für erhöhtes T_HTTP bzw. hohe TTFB:

• Backend-Überlast: CPU/Memory, Thread-Pools, Connection Pools, Queueing.
• Langsame Dependencies: Datenbank, Cache, externe APIs, Auth-Provider.
• Retry-/Failover-Kaskaden: LB retries, Service Mesh Retries, „Hidden“ Retries auf Client-Seite.
• Cache-Miss am CDN: Origin-Fetch wird langsam; Hit-Rate fällt, Origin wird belastet.
• Payload/Streaming: Große Responses, langsame Clients, Backpressure.

Operativ sollten Sie HTTP-Latenz immer in zwei Perspektiven trennen: Edge-Sicht (was sieht der LB/CDN?) und App-Sicht (wie lange dauert die Verarbeitung?). Wenn Edge „Upstream Response Time“ hoch ist, ist die Wahrscheinlichkeit groß, dass die Ursache im Backend oder dessen Dependencies liegt.

HTTP-Timing-Felder, die in Logs Gold wert sind

• Request Time, Upstream Connect Time, Upstream Header Time, Upstream Response Time (je nach Proxy/LB).
• Statuscodes (insbesondere 499/504/502) und Retry-Counts.
• Endpoint/Route, Tenant/Customer-Segment, Response Size, Cache Status (HIT/MISS/BYPASS).

Cold vs. Warm: Warum Messungen ohne Kontext irreführen

Ein häufiger Fehler im Troubleshooting ist, „eine Messung“ als repräsentativ zu behandeln. In Wirklichkeit unterscheiden sich Latenzen massiv zwischen Cold-Start und Warm-Path:

• Cold: DNS nicht im Cache, neue TCP-Verbindung, neuer TLS-Handshake, keine Session Resumption, keine HTTP/2-Verbindung.
• Warm: DNS aus Cache, Keepalive aktiv, TLS resumption möglich, HTTP/2 Multiplexing, CDN Cache HIT.

Für eine saubere Aussage sollten Sie beides messen: Cold zeigt strukturelle Engpässe (z. B. DNS/TLS), Warm zeigt steady-state Performance (z. B. Backend-Processing). Dokumentieren Sie im Ticket explizit, ob Sie Verbindungen wiederverwenden oder bewusst neu aufbauen.

Symptom-zu-Ursache: Typische Muster im Latenz-Breakdown

Mit einem konsistenten Breakdown lassen sich Muster schnell erkennen. Die folgenden Zuordnungen sind praxisnah und helfen bei der ersten Hypothese:

• T_DNS hoch, Rest normal: Resolver-/Cache-Problem, TTL-Design, autoritative Latenz, DNSSEC/DoH-Overhead.
• T_TCP hoch, viele Timeouts: Paketverlust, Pfadinstabilität, Firewall/NAT/Conntrack, L4-Protection.
• T_TLS hoch, nur bestimmte Clients: Proxy/Enterprise-Inspection, Cipher/Version-Mismatch, fehlende Resumption.
• T_HTTP/TTFB hoch: Backend/DB/Dependency, Retries, Cache-Miss-Problem, Queueing.
• Transfer hoch: große Payloads, langsame Clients, fehlende Kompression, Bandbreitenlimit.

Standardisierte Datensammlung fürs NOC: Checkliste in der richtigen Reihenfolge

Um in Incidents schnell zu sein, hilft eine feste Checkliste. Sie zwingt Sie nicht zu mehr Arbeit, sondern zu besserer Reihenfolge.

• 1) Scope: Welche Regionen, ISPs, Tenants, Endpoints sind betroffen? Seit wann?
• 2) Breakdown messen: Mindestens 10–20 Samples pro Region/Netz (Cold und Warm, wenn möglich).
• 3) DNS prüfen: Resolver-Vergleich, TTL/Cache-Hit, CNAME-Ketten, Response-Codes.
• 4) TCP prüfen: Connect-Errors, Timeouts, Retransmission-Indizien, LB Connect Time.
• 5) TLS prüfen: Handshake-Dauer, Resumption-Rate, TLS-Version, Error Rates.
• 6) HTTP prüfen: TTFB, Upstream Response Time, Retries, Cache HIT/MISS, 5xx-Profile.

Dokumentationsstandard: So wird der Breakdown publishable und eskalationsfähig

Ein guter Incident-Text ist nicht lang, sondern strukturiert. Wenn Sie den Latenz-Breakdown sauber dokumentieren, können andere Teams sofort handeln. Nutzen Sie im Ticket oder Postmortem-Entwurf eine kompakte Struktur:

• Beobachtung: „App-Latenz p95 von X ms auf Y ms gestiegen“ + Zeitfenster.
• Breakdown: Median/p95 für DNS/TCP/TLS/HTTP (pro Region/Client-Gruppe).
• Korrelation: Welche Metriken stiegen parallel (Errors, CPU, Cache Miss, Retries)?
• Hypothese: „Dominant ist T_DNS/T_TLS/TTFB“ + 2–3 Belege.
• Nächste Aktion: Owner-Team + konkret benötigte Logs (Resolver, LB, App-Trace).

Outbound-Links für belastbare Grundlagen

• DNS-Spezifikation (RFC 1035) für Grundlagen zur Namensauflösung und Response-Codes.
• TCP (RFC 9293) für Handshake, Retransmission-Mechanismen und typische Transport-Effekte.
• TLS 1.3 (RFC 8446) für Handshake-Flows, Performance-Aspekte und Resumption.
• HTTP Semantics (RFC 9110) für Interpretation von HTTP-Verhalten, Statuscodes und Semantik.
• Chrome DevTools Network-Dokumentation für Timing-Phasen und praktische Browser-Messung.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.