2026-06-02

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

How to diagnose slow HTTP requests in packet captures by separating DNS delay, TCP handshake, TLS handshake, request upload, server processing, and time to first byte.

For “HTTP Slow Request and TTFB in PCAP: Proving Whether the Delay Is DNS, TCP, TLS, or Server Time”, the short answer is: How to diagnose slow HTTP requests in packet captures by separating DNS delay, TCP handshake, TLS handshake, request upload, server processing, and time to first byte. Treat that statement as a result to verify, not as a promise that every input, device, project, or environment behaves identically. A complete result records the starting state, the exact action, the visible output, and the condition that proves the task is finished in PCAP Surgery.

"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.

Define the observed TTFB boundary precisely

For a capture, TTFB is usually the interval between the last client request byte observed at the capture point and the first server response byte observed there. It is not automatically application processing time: capture placement, encrypted HTTP/2 multiplexing, request upload, proxy buffering, and TCP delivery all matter. Record the definition used in the report.

Timeline phase	What the PCAP can show	What remains uncertain
DNS	Query/response timing and resolver path	DNS work before the observed query
TCP connect	SYN/SYN-ACK/ACK delays, retransmits	Server accept queue or client scheduling outside capture
TLS	Handshake progression/alerts	Decrypted HTTP route or application work without keys/logs
Request upload	Last observed client payload timing	Whether a proxy buffered/reframed the request
First response byte	When server-side data first reached this capture point	Which upstream component produced it
Response transfer	Payload delivery, loss, receive-window effects	Browser rendering or client CPU time

For HTTP/2 and HTTP/3, one connection can carry many requests. Do not borrow connection-level first-byte timing for a different multiplexed stream unless identifiers/decryption or application logs make the correlation reliable.

Diagnose delay by phase before assigning an owner

Pattern	Evidence-compatible reading	Next check
DNS dominates; TCP is fast	Name resolution is on the critical path	Resolver, cache, authoritative DNS evidence
SYN retransmits before handshake	Connection path or reachability may be impaired	Firewall, loss, server listener, another capture point
TLS pauses before application data	Certificate/SNI/middlebox or endpoint handshake behaviour may be involved	TLS alerts, server logs, controlled direct test
Request completes; long quiet gap until first response	Backend/proxy/application processing is plausible	Server/proxy request timestamps
Early response begins; transfer is slow with retransmits	Delivery path can dominate perceived latency	TCP loss, receiver window, path comparison
Client window closes	Receiver/application consumption may be limiting	Client resources and receive-window timeline

The TLS ALPN and HTTP/2 PCAP guide is useful for negotiation boundaries. The HTTP 502/504 gateway timeout guide applies after a proxy has actually returned a gateway error; do not conflate a slow successful response with a timeout status.

Preserve a minimal latency evidence window

Retain DNS if it happened in the same investigation window.
Keep the TCP handshake and complete TLS handshake where applicable.
Preserve client request completion and first server response byte timing.
Keep retransmissions, duplicate ACKs, receive-window updates, resets, and close.
Document capture point, clock source, relative-time calculation, and encrypted/decrypted limits.
Sanitize addresses/headers/payloads without changing packet order, timing, or lengths needed for analysis.

QA case	Acceptance evidence
Plain HTTP	Request-end and first-response byte are tied to one flow
HTTPS	TLS and encrypted data boundary are stated, not guessed as application time
HTTP/2	Stream correlation is verified or marked unavailable
Lossy response	Retransmission/receive-window time is separated from server quiet time
Proxy path	Client-facing and upstream-facing captures are labelled as different points

Questions about HTTP TTFB in a capture

Can a PCAP prove server processing time?

Not by itself. It can show an observed quiet interval after the request reached a capture point and before response data returned. Server, proxy, database, or application logs are needed to divide that interval among internal components.

Does a large TTFB mean the server is slow?

No. DNS, connection setup, TLS, proxy buffering, request upload, network loss, and capture placement may be involved. State the phase rather than using one global “server slow” label.

What can PCAP Surgery preserve?

It can produce a focused, sanitized window that retains timing evidence and a reproducible explanation of the calculation. It cannot decrypt traffic or reveal hidden backend spans without the required keys and logs.

The strongest latency handoff is a timeline with explicit observation boundaries: where the request completed, when the first response was seen, which transport effects occurred, and which owner must supply the next internal evidence.

Example of a bounded TTFB conclusion

Use wording that preserves the capture boundary: “At the client-side capture point, TCP and TLS completed without retransmission. The final encrypted client request data was observed at 10:01:04.120; the first encrypted server response data was observed at 10:01:08.640. The PCAP therefore shows a 4.52-second observed response-start gap, but cannot divide it between proxy and upstream application processing.” This is precise, reviewable, and does not falsely accuse a backend.

When comparing two requests, keep host, route, transport, TLS reuse state, capture point, and request size comparable. A cached HTTP/2 connection, a different CDN POP, or a large upload can make a raw elapsed-time comparison misleading. Preserve those variables in the evidence note before calling a regression.

Data to give each owner

The network owner needs SYN/retransmission/window evidence and capture placement. The edge/proxy owner needs request arrival and first upstream/downstream byte timestamps. The application owner needs the request correlation identifier and server span/log window. The client owner needs DNS cache state, connection reuse, and receive-window behaviour. Sending only a screenshot of a waterfall forces every team to recreate the same timeline; sending these bounded facts lets each owner test the part the PCAP cannot see.

If payload anonymization is required, retain packet timing, sequence/ack semantics, sizes where relevant, and a stable per-flow correlation label. A redaction that removes request-response order or TLS boundary may be safe for privacy but no longer suitable for latency analysis; label that limitation explicitly.

Repeat the capture only after the observed phase is named. Repeatedly collecting full-day PCAPs without a timing hypothesis increases privacy risk and rarely tells an owner more than one bounded, comparable request timeline.

This approach also makes later regression comparisons materially more trustworthy and faster.

A latency report that an owner can act on

State the capture point, connection/stream identity, request-end time, first-response time, phase duration, transport anomalies, and the one next evidence source required. Avoid a generic “slow server” label when the PCAP only shows an observed response-start gap.

Owner	Handoff question
Network	Were loss, retransmission, or receive-window limits present?
Proxy	When did it receive the request and first upstream byte?
Application	Which trace/span covers the bounded quiet interval?
Client	Was connection reuse, DNS, or request upload comparable?

That division keeps each team accountable only for evidence it can actually verify.

Comparable TTFB measurement table

For every request, record both the transport setup and request-response boundary. Mixing a fresh TLS connection with a reused HTTP/2 stream makes a single “TTFB” column ambiguous.

Measurement	Start boundary	End boundary	What it can show
DNS latency	query sent	matching response received	resolver/path delay at capture point
TCP setup	SYN sent	final handshake ACK	connection establishment
TLS setup	first ClientHello bytes	handshake complete/application data ready	observed TLS negotiation
Request upload	first request bytes	final request bytes	client send time and stalls
Response-start gap	final request bytes	first response bytes	bounded server/proxy/upstream interval
Response transfer	first response bytes	final response bytes	payload transfer and receiver behavior

For HTTP/2, identify the stream and account for multiplexing. Other streams may carry data while the measured stream waits. For HTTP/3, use QUIC-specific boundaries instead of forcing TCP terminology. When payload is encrypted and keys are unavailable, call the measurement an observed encrypted request-to-response gap and explain how packet direction and sizes identify the boundary.

Is TTFB the same as server processing time?

No. At a client capture point, the response-start gap includes propagation, proxy queues, upstream calls, backend processing, and the return path. Server or proxy spans are needed to divide it internally.

Can retransmissions inflate TTFB?

Yes. A lost request segment, response segment, or handshake packet can delay the observed first byte. Document retransmission timing and whether the request was fully acknowledged before assigning the gap to application work.

What if the client advertises Zero Window?

The server may be ready while the client cannot receive. Separate response generation from receiver flow control and use the TCP Zero Window analysis for that interval.

Keep a compact derivative containing DNS if relevant, connection setup, the measured request/stream, first response, and any transport anomaly. The capture-scope guide and packet preparation workflow help retain a reviewable timeline without shipping unrelated traffic.

TTFB regression test design

Use several controlled requests rather than one screenshot. Keep hostname, route, payload, authentication state, connection reuse, client location, and capture point fixed. Record median and tail behavior, but preserve individual packet timelines for outliers. Averages alone can hide one retransmission or one upstream timeout.

Test fresh DNS/TCP/TLS and reused-connection cases separately. For HTTP/2, either isolate a stream or record concurrent streams that may contend for connection-level flow control. For a CDN, record the selected edge or address so a POP change is not mislabeled as an application regression.

Test variable	Why control it
Connection reuse	Removes handshake phases from some requests
Request size	Changes upload completion boundary
Cache state	Can bypass the backend entirely
Client/capture location	Changes network path and observed timing
Concurrent streams	Can add multiplexing and flow-control delay

After a fix, repeat the same matrix and require both a smaller bounded response-start gap and absence of the transport symptom, if transport was part of the diagnosis.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: