skip to content

In Wireshark 4.6, how do you use the Statistics menu to find the slow flow in an hour-long capture of a sluggish internal application?

level: middleimportance: must knowfreq 31%

answer

  1. narrow before you read packets
  2. what is in the file, then who
  3. sort by bytes, duration, rate
  4. flags per interval over time
  5. server think time versus transfer

basics

~20 s

Work top-down in Wireshark 4.6: Protocol Hierarchy for what the file holds, Conversations and Endpoints for who talked, an I/O Graph for when it went wrong, then TCP Stream Graphs and Service Response Time on the one flow.

solid answer

~40 s

I start with **Statistics > Protocol Hierarchy** to see what the hour actually contains, then **Statistics > Conversations**, TCP tab, sorted by bytes, duration and bits/s per direction; in 4.0 and later each row carries a **Stream ID**, so I can jump straight to `tcp.stream eq N`. Applying `tcp.analysis.flags` first and ticking *Limit to display filter* shows which conversations carry analysis flags and what share of their packets. **Statistics > Endpoints** shows whether one client or the server dominates. An **I/O Graph** with one line for all packets and one for `tcp.analysis.flags` shows when the trouble happened. On the chosen conversation, **TCP Stream Graphs** show stalls, and **Service Response Time** (for protocols such as SMB2) or a graph of a time field such as `http.time` separates a slow server from a slow transfer.

go deeper

for a junior

Recall the four general windows under the Statistics menu (Protocol Hierarchy, Conversations, Endpoints, I/O Graphs) and what each one summarises.

for a middle

Explain how to sort and filter Conversations, use Stream ID and Limit to display filter, and build an I/O Graph with a flags line and a response-time line.

for a senior

Show the judgement that turns statistics into a verdict: server think time versus loss versus a receiving host's window, each backed by the window and column that proves it.

for a principal

Talk about making this repeatable for a team: shared profiles with saved I/O graphs and columns, and a written triage path from the whole capture to one flow.

## The principle: narrow before you read An hour of server traffic can hold millions of packets. Scrolling the packet list is hopeless; Wireshark's **Statistics** menu summarises the whole file so you can pick the few conversations and the few minutes worth reading. Work from the whole capture down to one flow. ## 1. What is in the file: Protocol Hierarchy **Statistics > Protocol Hierarchy** shows a tree of every protocol with *Percent Packets*, *Packets*, *Percent Bytes*, *Bytes*, *Bits/s* and *End Packets* (packets where that protocol was the highest layer). Use it to check assumptions: is the application's protocol there at all, is a backup job eating the link, is half the traffic something nobody expected? Two reading rules: - percentages overlap, because one packet counts for Ethernet, IP, TCP and the application at once; - a parent's children rarely add up to it, because pure ACKs, segments reassembled into other frames and undecoded data carry no higher protocol. ## 2. Who talked: Conversations and Endpoints **Statistics > Conversations** lists every pair of endpoints per layer (Ethernet, IPv4, IPv6, TCP, UDP, ...). The TCP tab is where flows live. Useful columns and controls: | What | Why it helps | |---|---| | Bytes and Packets, A to B and B to A | the heavy transfers | | Rel Start and Duration | long-lived or late-starting flows | | Bits/s A to B, Bits/s B to A | a flow that moved little data over a long time is a slow one | | Stream ID (TCP and UDP, since 4.0) | jump to the flow with `tcp.stream eq N` | | Limit to display filter | restrict the table to conversations matching the current filter | | Total Packets and Percent Filtered | appear once a filter is applied: how much of each conversation matched | A quick triage trick: apply the display filter `tcp.analysis.flags` (any packet with a TCP analysis flag), then open Conversations with *Limit to display filter*. Percent Filtered now reads as "share of this conversation's packets that carry a flag". The **Follow Stream...**, **Graph...** and **I/O Graphs...** buttons act on the selected rows. **Statistics > Endpoints** is the per-host view: packets and bytes per address, sent and received. It answers "is one client hammering the server" and "which hosts are involved at all". ## 3. When it went wrong: I/O Graphs **Statistics > I/O Graphs** plots values per interval. Add graphs rather than reading one: 1. all packets (or Bits, for throughput), the baseline; 2. a graph with display filter `tcp.analysis.flags`, to see when analysis flags cluster; 3. a graph with Y Axis `MAX(Y Field)` or `AVG(Y Field)` on a response-time field such as `http.time` or `smb2.time`, to see when the server answered slowly. The interval matters: one second shows trends, ten milliseconds shows bursts. Counting graphs omit zero values in scatter plots but draw them in line and bar charts. Wireshark 4.6 also adds a **Plots** window that draws a field's individual values over time as a scatter plot, useful when each response time matters more than a per-interval summary. ## 4. Why this flow is slow: per-conversation views With one conversation chosen: - **Statistics > TCP Stream Graphs > Time Sequence (tcptrace)** shows sequence numbers against time with ACKs, SACKs and the receive window: flat steps are stalls, and you can see whether data stopped against the window or waited on something else. **Throughput** and **Round Trip Time** graphs give the same flow as numbers. - **Analyze > Expert Info** with *Limit to display filter* on `tcp.stream eq N` lists that flow's retransmissions, zero windows and gaps. - **Statistics > Service Response Time** gives request-to-response times per operation for protocols that support it (SMB, SMB2, LDAP, DCE-RPC, RADIUS and others). For SMB2 it lists each opcode with its counts and response-time statistics. ## Interpreting what you found The statistics point at one of three places: - **The server**: requests are acknowledged promptly but the response starts late; response-time statistics are high while the transfer itself is clean. - **The network**: retransmissions, duplicate ACKs and gaps cluster in the slow minutes. - **The receiving host**: zero windows or window-full flags, with the network otherwise clean. Write down which window, column and filter showed it, so someone else can repeat the path from the whole capture to the one flow.

  • Why might the Protocol Hierarchy show the application protocol on far fewer packets than TCP carries for it?
    Most TCP packets carrying a large response are segments that Wireshark reassembles into one PDU shown on the last segment, and pure ACKs carry no payload at all. Those count for TCP but not for the application protocol, so the gap is expected rather than a sign of undecoded traffic.
  • Your application protocol has no Service Response Time window. How do you still measure server time?
    Use a response-time field the dissector provides, such as `http.time`, as the Y Field of an I/O Graph with MAX or AVG per interval, or plot its values in the Plots window. Where no such field exists, measure the gap between the last request segment and the first response segment in one stream.
  • When would you open Endpoints rather than Conversations?
    When the question is about a host, not a flow: which clients generate most of the load, whether one address dominates, or how many hosts are involved at all. Conversations then breaks that host's traffic into the flows worth opening.

saying these in an interview costs you the question

  • Scroll the packet list until something looks red.
  • Protocol Hierarchy percentages should add up to 100 at each level.
  • The conversation with the most bytes is always the slow one.
  • A clean I/O Graph of packets per second proves the server is fast.
  • Retransmissions explain every slow application, so stop at the Expert Info dialog.