Richiesta lenta HTTP e TTFB in PCAP: dimostrare se il ritardo è DNS, TCP, TLS o l'ora del server
Come diagnosticare le richieste HTTP lente nell'acquisizione dei pacchetti separando il ritardo DNS, l'handshake TCP, l'handshake TLS, il caricamento delle richieste, l'elaborazione del server e il tempo per raggiungere il primo byte.
"Il sito Web è lento" e "La richiesta API richiede 10 secondi" non sono diagnosi. L'acquisizione di un pacchetto può suddividere il ritardo in fasi: "ricerca DNS, handshake TCP, handshake TLS, caricamento delle richieste, elaborazione del server, download delle risposte, ritrasmissioni e comportamento del client." Tempo al primo byte è spesso la frase cercata dagli utenti. Nell'evidenza dei pacchetti, il TTFB non è un singolo campo magico. È una linea temporale.
Costruisci la sequenza temporale della richiesta
Per una richiesta HTTP o HTTPS, controlla:
- Inizio della query DNS
- Tempo di risposta DNS
- TCP SYN
- Completamento dell'handshake TCP
- Cliente TLSCiao
- Server TLSCiao e certificato
- Byte di richiesta HTTP inviati
- primo byte di risposta
- completamento completo della risposta
- ritrasmissioni o reset
Se il DNS impiega cinque secondi, il server non è ancora lento. Se l'handshake TCP è veloce ma il primo byte di risposta è in ritardo, il problema potrebbe essere l'elaborazione del server o la dipendenza upstream. Se TLS si blocca prima di HTTP, concentrati sul comportamento di certificato, crittografia, SNI o middlebox.
HTTP su TLS necessita di confini attenti
Nelle acquisizioni HTTPS, il payload può essere crittografato, ma la tempistica è comunque importante. Spesso puoi identificare:
- inizio della connessione
- durata della stretta di mano
- dati dell'applicazione crittografati dal client
- primi dati dell'applicazione crittografati dal server
- perdita o ritrasmissione di pacchetti
- connessione chiusa o ripristinata
Anche senza decrittografare il contenuto, l'acquisizione può mostrare se il ritardo si è verificato prima o dopo l'invio della richiesta.
Attenzione alle ritrasmissioni
Un HTTP lento può derivare dalla perdita di pacchetti. Se vengono visualizzate ritrasmissioni TCP o ACK duplicati durante il caricamento della richiesta o la consegna della risposta, il server potrebbe non essere il proprietario principale. Una risposta ampia con perdita nel percorso da server a client può sembrare agli utenti una latenza di backend.
La relazione dovrebbe separare:
- tempo prima che la richiesta lasci il client
- il time server sembra elaborare
- tempo impiegato per ritrasmettere la risposta
- comportamento della finestra di ricezione lato client
Questa distinzione impedisce ai team di backend di inseguire problemi di rete.
Dove si adatta la chirurgia PCAP
PCAP Surgery è utile quando l'acquisizione originale è troppo grande o troppo sensibile. Un trasferimento mirato della latenza HTTP dovrebbe preservare:
- Finestra DNS
- Stretta di mano TCP
- Handshake TLS se presente
- tempi di richiesta/risposta
- prove di ritrasmissione
- reimposta o avvisa
- timestamp originali
Se è necessaria l'anonimizzazione, preserva i tempi e le dimensioni dei pacchetti quando contano. Rimuovere troppo contesto può rendere impossibile l'analisi TTFB.
Per ricerche come "HTTP slow request pcap", "time to first byte packet capture" o "API latency Wireshark", la risposta è una sequenza temporale fase per fase, non una singola etichetta di colpa.