HTTP download with TCP loss
A web download feels slow even though the server accepts and answers the request.
Runtime is an estimate for this small public sample, not an enterprise performance commitment.
Customer question
Is application processing or transport loss responsible for the observed download delay?
Capture profile: ~5 MB · performance · tcp · http · troubleshooting
TCP loss and recovery behavior is the strongest explanation for the slowdown.
Retransmissions and duplicate ACKs align with the throughput drop while the application response itself does not show a comparable stall.
Exact evidence
- tcp.analysis.retransmission
- tcp.analysis.duplicate_ack
- Affected HTTP connection and recovery window
Ruled-out alternative
A server-side request-processing stall is not supported by the sample trace.
Recommended action
Validate loss at both endpoints, compare the recovery window by capture point, and investigate the affected network segment.
Investigation prompt
Explain the TCP loss and retransmission pattern in this HTTP trace. Rank the strongest packet evidence and suggest the next operator action.
Case narrative
Users report that a web download feels slow even though the server responds. The trace contains enough TCP evidence to separate application delay from transport loss and recovery behavior.
How this was captured
- Client-side capture during a repeatable HTTP download.
- Packet list and TCP analysis flags preserved for quick validation.
- Saved as a normal PCAP so the workflow stays close to a customer upload.
What to look for
- Retransmissions, duplicate ACKs, and recovery windows.
- Whether the server stalls or the client path shows packet loss.
- The frame range where the first clear symptom appears.
Expected outcome
Conclude whether the slowdown is transport-related and point the operator to the strongest frame range, connection, or endpoint evidence.