Find the request, measure the wait, then check what caused it

For decoded HTTP/1.x traffic, start with the display filter http.time > 1. It finds exchanges whose generated Time since request exceeds one second. Add that field as a column, sort the largest values first, then inspect the matching request and the surrounding TCP packets.

That finds candidates—not proof of a slow application server. Timing depends on capture location and the packets Wireshark uses for dissection. The useful question is: where does progress stop?

1. Capture the whole exchange

Inspect only systems and traffic you own or are authorized to analyze. Start the capture before reproducing the slow operation, record the time of the operation, and stop after the response or timeout. Use a capture point that sees both directions of the connection.

Keep these details with the capture:

• Whether it was taken at the client, server or an intermediate device.
• Whether the connection was new or already established.
• Which operation was slow, and how long it normally takes.
• Whether the visible endpoint is the origin server or a proxy/load balancer.

Missing or truncated packets can prevent reliable request/response matching. Wireshark also warns that starting mid-connection, missing segments and out-of-order delivery can affect higher-level dissection. Keep TCP reassembly enabled for HTTP analysis. See the Wireshark reassembly guide.

Do not publish third-party packet data. Redact payloads, tokens, addresses and identifiers from any authorized examples you share.

2. Find slow HTTP requests

This workflow applies when Wireshark actually decodes HTTP/1.x, either as plaintext or after authorized TLS decryption.

1. Enter http.response && http.time > 1 in the display-filter bar. One second is an example threshold; choose a value appropriate to your application’s baseline.
2. Select a response and expand Hypertext Transfer Protocol in Packet Details.
3. Right-click Time since request and choose Apply as Column.
4. Sort that column with the largest values first.
5. Record the response frame number and its Request in frame number. Clear the display filter so the request is visible, reselect the response, then double-click the request link to inspect it.

Wireshark documents http.time as “Time since request,” along with http.request_in and http.response_in for linking exchanges. These are HTTP display-filter fields, not timestamps supplied by the server. Apply as Column turns a selected field into a packet-list column; generated packet links let you jump between related frames.

If the filter returns nothing, try http.request || http.response. No results may mean encrypted traffic, another HTTP version or failed dissection—not that the server is fast. A request with no captured response will not appear in a response-time search; inspect requests around the reported timeout separately.

3. Measure the wait, not just the decoded response frame

Replace the HTTP-only filter with a connection filter such as:

tcp.stream == 7

Replace 7 with the selected packet’s TCP stream index. This restores ACKs and other transport packets that the HTTP filter hid. Wireshark defines tcp.stream in its TCP field reference.

Return the packet list to capture order by sorting No. ascending. Identify three boundaries at your capture point:

Boundary	What to identify
Request complete	The segment that completes the captured request, including its body if present; account for missing or out-of-order bytes
Response begins	The first server-to-client segment containing bytes of the matching final response—not an ACK-only packet
Response complete	The last bytes needed to complete that response, using the decoded protocol’s message boundaries

Measure two intervals:

Observed response wait = response begins − request complete
Response transfer time = response complete − response begins

For the first measurement, select the request-complete packet, right-click and choose Set Time Reference (toggle). Set View → Time Display Format → Seconds Since First Captured Packet. The response-start packet’s Time value now gives the interval from that reference. Clear any other references in the interval. Wireshark explains this behavior in its time-reference documentation.

Do not automatically treat http.time as time to first byte. Wireshark can attach reassembled data to the last packet of a chunk. Expand the Reassembled TCP Segments list where present and inspect its linked frames to establish when response bytes actually began arriving. This behavior is described in the reassembly guide. A large request upload and a long response download are different problems from a silent wait after a completed request.

The wait calculation assumes the final response starts after the request is complete. Keep interim responses such as 100 Continue separate; HTTP permits informational responses before a final response and can also return a final status before the entire request body is read. If upload and response overlap, report those boundaries rather than treating their difference as server processing time. See HTTP response semantics.

4. Check whether transport explains the gap

Within the selected stream, look for these indicators:

tcp.stream == 7 && (
    tcp.analysis.retransmission ||
    tcp.analysis.fast_retransmission ||
    tcp.analysis.duplicate_ack ||
    tcp.analysis.zero_window ||
    tcp.analysis.window_full
)

These fields are documented in the TCP field reference. Match flagged packets to the measured interval; warnings elsewhere in the connection may not explain this request.

Observation during the slow exchange	Next interpretation to test
Retransmissions and duplicate ACKs interrupt progress	Loss recovery may contribute; inspect sequence numbers and whether the capture itself missed packets
Client advertises a zero receive window during the response	The client is asking the sender to pause; investigate client receive capacity
Server advertises a zero receive window during upload	The receiving server-side endpoint cannot currently accept more request data
Response begins promptly but completes slowly	Investigate transfer rate, loss, receiver limits or application streaming
Request bytes are acknowledged promptly, followed by a long silence before response data	Investigate the server-side service path, including proxies and upstream dependencies

A zero window is a receiver’s flow-control instruction, not evidence of network latency. Wireshark’s TCP analysis guide also notes that retransmission and out-of-order interpretations depend on capture location and context.

For a transport comparison, inspect tcp.analysis.ack_rtt, which measures the observed time to acknowledge a segment. It is not application response time: TCP acknowledges bytes, not completed application work. ACK timing can also include endpoint acknowledgment behavior, and its meaning depends on where you captured the segment and ACK. See the TCP specification and our guide to comparing network latency in packet captures.

For example, a hypothetical client capture with nearby ACK RTT samples around 20 ms and a 1.8-second wait after a complete, acknowledged request would justify investigating the server-side path. It would not establish that the origin application spent exactly 1.78 seconds processing it.

HTTPS, HTTP/2 and HTTP/3

HTTPS without decryption: for HTTPS over TCP, you can examine TCP timing and stalls, but cannot reliably pair hidden HTTP requests with responses. TLS records are not HTTP transaction boundaries. In an authorized test, a supported application can export session secrets for Wireshark; the TLS documentation describes the key-log preference. Protect those secrets as sensitive data. For the visibility limits, see what HTTPS hides in a packet capture.

Decoded HTTP/2: use http2.time > 1 where available, then inspect the request/response links and stream identifier. Wireshark documents http2.time, http2.request_in and http2.response_in from version 4.2 onward in its HTTP/2 field reference. Narrow a transaction with a filter such as tcp.stream == 7 && http2.streamid == 3, using your actual identifiers. HTTP/2 multiplexes exchanges on one connection, so the next server packet may belong to another request. Restore the full TCP stream when checking transport problems.

HTTP/3: it runs over QUIC rather than TCP. The TCP filters above do not apply; request/response analysis requires visibility into the relevant QUIC stream. The HTTP/3 specification defines each request-response pair on a single QUIC stream.

Hand off a measured interval

Report the capture location, protocol, request and response frame numbers, boundary definitions, measured wait and any transport events inside that interval. Correlate the operation with server logs or tracing; if needed, take a second authorized capture near the server-side endpoint.

“Request complete at frame 120; final response bytes begin at frame 148; observed wait 1.8 seconds; no retransmissions observed in that interval” is a useful finding. “The server is slow” is not yet a diagnosis.