It is slow.
Everyone blames someone else.
The network team says the link is clean. The application team says the servers are fine. Both are usually telling the truth about what they can see — which is the problem.
The question is answered by where the time went, and a packet capture measures that directly. If the request left promptly, the response came back quickly, and the gap sits between them, the time was spent inside the server — that is the application. If the request or response was delayed in transit, retransmitted, fragmented or refused, the time was spent in the network. Network delay and server think-time are two different measurements, and a capture separates them by timestamp rather than by argument.
What actually settles it.
Everything else is inference. These three, taken from the same conversation at the same moment, are direct measurements.
Round-trip time
The time between a segment and its acknowledgement. This is the network's cost, and nothing else. If it is stable and low while the user experience is bad, the network has already been ruled out for that conversation.
Measured from the handshake and from ongoing acknowledgements — not from ping, which takes a different path through the device and often a different priority.
Server response time
The gap between the last byte of the request arriving and the first byte of the response leaving. This is entirely the far end: application logic, database, disk, garbage collection.
A response time that grows with concurrency while RTT stays flat is a capacity problem at the server, not on the wire.
Retransmission and error events
Retransmissions, resets, refused connections and failed handshakes are the network and the transport failing outright. Their presence points one way; their absence points the other, just as usefully.
A clean stream with high latency is a very different diagnosis from a lossy stream with low latency, even though users describe both as "slow".
The pattern over the transfer
A transfer that starts fast and collapses is usually a window or buffer problem. One that is uniformly slow is usually bandwidth or a rate limit. One that stalls in fixed pauses is usually waiting on something else entirely — often DNS or an authentication call.
The shape of the transfer is often more diagnostic than any single number in it.
Four steps to an answer nobody argues with.
- 1
Capture one real slow transaction
Not a synthetic test. The transaction the user complained about, at the time they complained, from where they were sitting. Synthetic tests take different paths and get different treatment.
- 2
Split the time at the server boundary
Add up network time and server time separately. In practice one of them dominates so clearly that the argument ends at this step.
- 3
Check whether the transport was healthy
Retransmissions, zero windows, resets, failed handshakes. A clean transport removes the network from the list regardless of how slow the user says it was.
- 4
Compare with a working case
The same transaction from a site that is fine, or from an hour when it was fine. The difference between the two captures is the answer, and it is much faster to read than either one alone.
Three sources, one verdict.
Counters say whether a link is busy. Flow records say who is talking. Only the packets carry the timestamps that separate network delay from server think-time.
Why the argument usually repeats
- Nobody was recording. The evidence that would settle it existed for a few seconds during the incident and then was gone. Net-Monitor keeps it.
- Each team measures its own side. Server metrics do not show the network and interface counters do not show the application. The capture is the one place both are visible at once.
- It ends with a document, not a hunch. A timestamped record is also what closes the conversation with an external supplier who says the problem is not theirs.
Short answers.
How do I prove it is not the network?
Show a capture of the slow transaction where round-trip time is low and stable, the transport is clean — no retransmissions, resets or zero windows — and the elapsed time sits between the request arriving and the response leaving. That places the time inside the server, and it is evidence rather than an assertion.
Is ping good enough to test this?
Rarely. ICMP is often handled on a different path inside network devices, is frequently deprioritised or rate-limited, and tells you nothing about the TCP session the application is actually using. A normal ping alongside a slow application is a very common and completely unremarkable combination.
The application team says their metrics look fine. Now what?
Their metrics usually start when the request reaches the application and stop when it hands off the response — so they can look fine while time is lost in the web server, the TLS layer, a connection pool or a dependency. The capture measures from the wire, which includes all of that.
What if it is both?
It often is, and that is worth knowing rather than resolving into a single culprit. A common pattern is mild packet loss that costs little on its own but interacts badly with a chatty application making hundreds of small round trips. The capture shows the proportion each contributes.
Still arguing about whose problem it is?
Bring us the transaction. We will show you where the time went, and the conversation usually ends there.