HTTP Slow Request and TTFB in PCAP: Proving Whether the Delay Is DNS, TCP, TLS, or Server Time

"Website is slow" and "API request takes 10 seconds" are not diagnoses. A packet capture can split the delay into phases: DNS lookup, TCP handshake, TLS handshake, request upload, server processing, response download, retransmissions, and client behavior.

Time to first byte is often the phrase users search. In packet evidence, TTFB is not a single magic field. It is a timeline.

Build the Request Timeline

For an HTTP or HTTPS request, inspect:

• DNS query start
• DNS response time
• TCP SYN
• TCP handshake completion
• TLS ClientHello
• TLS ServerHello and certificate
• HTTP request bytes sent
• first response byte
• full response completion
• retransmissions or resets

If DNS takes five seconds, the server is not slow yet. If TCP handshake is fast but first response byte is late, server processing or upstream dependency may be the issue. If TLS stalls before HTTP, focus on certificate, cipher, SNI, or middlebox behavior.

HTTP over TLS Needs Careful Boundaries

In HTTPS captures, payload may be encrypted, but timing still matters. You can often identify:

• connection start
• handshake duration
• encrypted application data from client
• first encrypted application data from server
• packet loss or retransmission
• connection close or reset

Even without decrypting content, the capture can show whether the delay happened before or after the request was sent.

Watch for Retransmissions

Slow HTTP can come from packet loss. If TCP retransmissions or duplicate ACKs appear during request upload or response delivery, the server may not be the primary owner. A large response with loss on the server-to-client path can look like backend latency to users.

The report should separate:

• time before request leaves client
• time server appears to process
• time spent retransmitting response
• client-side receive window behavior

That distinction prevents backend teams from chasing network problems.

Where PCAP Surgery Fits

PCAP Surgery is useful when the original capture is too large or too sensitive. A focused HTTP latency handoff should preserve:

• DNS window
• TCP handshake
• TLS handshake if present
• request/response timing
• retransmission evidence
• resets or alerts
• original timestamps

If anonymization is needed, preserve timing and packet sizes when they matter. Removing too much context can make TTFB analysis impossible.

For searches like "HTTP slow request pcap," "time to first byte packet capture," or "API latency Wireshark," the answer is a phase-by-phase timeline, not a single blame label.