How do you prove whether a slowness problem is the network or the application?
Show the answer
Say this first
I split one transaction into its parts with a capture near the client. The TCP handshake (SYN to SYN-ACK) is almost pure network round trip. The time from the request to the first byte of the response, minus one round trip, is server think time. If the handshake takes 2 ms and the response 4 seconds, the network is not the problem. If the handshake is slow, or I see retransmissions and stalls in the data, the network is involved. I bring numbers, not opinions.
Go deeper
One request, timed
t=0.000 client SYN
t=0.002 server SYN-ACK <- network round trip about 2 ms
t=0.002 client ACK
t=0.003 TLS handshake begins, finished by t=0.009
t=0.010 client HTTP GET /report
t=0.012 server ACK <- request delivered
t=4.215 server first response byte <- about 4.2 s of server timeWireshark helpers
tcp.analysis.ack_rttshows how quickly segments were acknowledged.- For clear-text HTTP, the
http.timefield gives time from request to response. - Statistics, TCP Stream Graphs show steady flow versus stalls.
What points where
| Evidence | Points to |
|---|---|
| Fast handshake, long wait for the response | the server or its backend |
| Retransmissions and duplicate ACKs | loss on the path |
| Zero window from the server | the server cannot consume data |
| Slow handshake that also shows in ping | latency or congestion on the path |
| Long gaps before the client's next request | the client |
Timing from the command line
curl -o /dev/null -s -w 'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} ttfb %{time_starttransfer} total %{time_total}\n' https://app.example.com/reportThe values are cumulative from the start, so connect minus DNS time is roughly one round trip.
They will ask next
The app team insists it is the network. How do you handle it?
With a shared capture and plain numbers: "the handshake is 2 ms, the server took 4.2 seconds to answer this request". Offer to capture on the server side as well. Stay neutral; the goal is the fix.
Does a fast handshake rule out the network completely?
No. Large responses can still suffer from loss, MTU or a small window. Check the data phase for retransmissions and stalls, not just the setup.
Traps
- Pinging the server and stopping there. ICMP tells you nothing about server think time.