Reading a Packet Capture: A Real Bug

A backend request takes a little over six seconds, even though the server begins returning data almost immediately. Metrics show no server CPU spike, and a route test shows ordinary latency. The team needs to find where the request spent its time.

This chapter works through a packet capture from that incident pattern. The trace is a sanitized teaching reconstruction: addresses use documentation ranges, names have been removed, and repeated ordinary data packets are collapsed in the excerpts. The packet relationships and failure behavior are preserved.

The bug is a stalled receiver. A client-side operation blocks the same worker responsible for reading from a TLS socket. The operating system's receive buffer fills, the client advertises a TCP receive window of zero, and the server pauses. Packet evidence locates the wait at the receiving endpoint; application evidence identifies the blocking operation.

The goal is not to identify the answer from one colored Wireshark row. It is to build a defensible timeline, distinguish packet facts from inferences, test competing explanations, and correlate the remaining uncertainty with host evidence.