HTTP Slow Request und TTFB in PCAP: Nachweis, ob die Verzögerung DNS, TCP, TLS oder Serverzeit ist
So diagnostizieren Sie langsame HTTP-Anfragen bei Paketerfassungen durch Trennung von DNS-Verzögerung, TCP-Handshake, TLS-Handshake, Anforderungs-Upload, Serververarbeitung und Zeit bis zum ersten Byte.
„Website ist langsam“ und „API-Anfrage dauert 10 Sekunden“ sind keine Diagnosen. Eine Paketerfassung kann die Verzögerung in Phasen aufteilen: "DNS-Suche, TCP-Handshake, TLS-Handshake, Anforderungs-Upload, Serververarbeitung, Antwort-Download, erneute Übertragungen und Client-Verhalten." Zeit bis zum ersten Byte ist oft der Begriff, nach dem Benutzer suchen. Beim Paketbeweis ist TTFB kein einzelnes magisches Feld. Es ist eine Zeitleiste.
Erstellen Sie den Anforderungszeitplan
Überprüfen Sie für eine HTTP- oder HTTPS-Anfrage Folgendes:
- DNS-Abfrage starten
- DNS-Antwortzeit
- TCP-SYN
- Abschluss des TCP-Handshakes
- TLS-ClientHallo
- TLS ServerHallo und Zertifikat
- Gesendete HTTP-Anfragebytes
- erstes Antwortbyte
- Vollständiger Antwortabschluss
- Neuübertragungen oder Resets
Wenn DNS fünf Sekunden benötigt, ist der Server noch nicht langsam. Wenn der TCP-Handshake schnell erfolgt, das erste Antwortbyte jedoch zu spät kommt, kann die Serververarbeitung oder eine Upstream-Abhängigkeit das Problem sein. Wenn TLS vor HTTP ins Stocken gerät, konzentrieren Sie sich auf das Verhalten von Zertifikaten, Verschlüsselung, SNI oder Middlebox.
HTTP über TLS erfordert sorgfältige Grenzen
Bei HTTPS-Erfassungen kann die Nutzlast verschlüsselt sein, aber das Timing spielt dennoch eine Rolle. Sie können oft Folgendes erkennen:
- Verbindungsbeginn
- Handshake-Dauer
- verschlüsselte Anwendungsdaten vom Client
- erste verschlüsselte Anwendungsdaten vom Server
- Paketverlust oder Neuübertragung
- Verbindung schließen oder zurücksetzen
Auch ohne Entschlüsselung von Inhalten kann die Erfassung zeigen, ob die Verzögerung vor oder nach dem Senden der Anfrage aufgetreten ist.
Achten Sie auf Weiterübertragungen
Langsames HTTP kann durch Paketverlust verursacht werden. Wenn während des Anforderungs-Uploads oder der Antwortzustellung TCP-Neuübertragungen oder doppelte ACKs auftreten, ist der Server möglicherweise nicht der primäre Eigentümer. Eine große Antwort mit Verlust auf dem Server-zu-Client-Pfad kann für Benutzer wie eine Backend-Latenz aussehen.
Der Bericht sollte Folgendes trennen:
- Zeit, bevor die Anfrage den Kunden verlässt
- Der Zeitserver scheint zu verarbeiten
- Zeitaufwand für die erneute Übertragung der Antwort
- Verhalten des clientseitigen Empfangsfensters
Diese Unterscheidung verhindert, dass Backend-Teams Netzwerkproblemen nachjagen.
Wo die PCAP-Chirurgie passt
Die PCAP-Operation ist sinnvoll, wenn die Originalaufnahme zu groß oder zu empfindlich ist. Eine gezielte HTTP-Latenz-Übergabe sollte Folgendes bewahren:
- DNS-Fenster
- TCP-Handshake
- TLS-Handshake, falls vorhanden
- Anforderungs-/Antwortzeitpunkt
- Beweise für die Weiterverbreitung
- Resets oder Warnungen
- Original-Zeitstempel
Wenn eine Anonymisierung erforderlich ist, behalten Sie Timing und Paketgrößen bei, wenn es darauf ankommt. Das Entfernen von zu viel Kontext kann die TTFB-Analyse unmöglich machen.
Bei Suchanfragen wie „HTTP Slow Request Pcap“, „Time to First Byte Packet Capture“ oder „API Latency Wireshark“ ist die Antwort eine phasenweise Zeitleiste und keine einzelne Schuldzuweisung.