Model Artifact: Packet Capture Analysis
Scenario
A Semester 5 learner analyzes why a client reports intermittent slow page loads against a local service.
Completed learner-quality example
Capture summary
- Capture point: client host, wired network.
- Filter:
tcp port 8443 and host 10.0.2.18. - Window: 90 seconds during three reproduced slow loads.
Observations
| Evidence | Interpretation |
|---|---|
| TCP three-way handshake completes in under 4 ms | Network reachability is healthy at connection start. |
| TLS ClientHello appears immediately after handshake | Client is not stalling before TLS. |
| Server waits 1.2-1.5 s before first application-data record on slow requests | Delay is likely server-side or upstream of server response generation. |
| No retransmission burst or duplicate ACK pattern during the stall | Packet loss is not the primary explanation. |
| Same connection later transfers response body at expected throughput | Bulk network capacity is not the bottleneck. |
Conclusion
The capture does not support a network-loss diagnosis. The dominant delay is time-to-first-byte after the request reaches the server. Next investigation should inspect server request logs, database timing, and any upstream dependency called before the first response byte.
Follow-up questions
- Do server logs show the same 1.2-1.5 s gap between request receipt and handler completion?
- Does the slow path correlate with cache misses?
- Does enabling application timing headers move the delay into a specific internal span?
How to read this example
- Passing: Names capture point, filter, timeframe, and evidence.
- Strong: Avoids claiming more than the packets show and rules out packet loss with concrete TCP observations.
- Portfolio-worthy: Turns network evidence into a precise next-step plan for cross-layer diagnosis.