Wireshark’s I/O graphs don’t just show you bandwidth; they reveal the pulse of your network, highlighting the true rhythm of traffic, not just its volume.
Let’s see it in action. Imagine you’re troubleshooting a sluggish web application. You capture traffic on the web server and then open the I/O graphs:
Statistics -> I/O Graphs
You’ll see a default graph showing "Packets/s" and "Bytes/s" over time. It looks something like this:
This graph is your first clue. Is the traffic consistently high, or are there sudden spikes and drops? Are the packet rates and byte rates moving in tandem, or is one dramatically outstripping the other? This visual tells a story.
The Problem: Seeing the Forest for the Trees
When you’re staring at thousands of packets in Wireshark, it’s easy to get lost. You see individual TCP retransmissions, DNS queries, or HTTP requests, but you miss the overarching pattern. Are these individual events symptoms of a larger problem, or are they the noise of normal operation? I/O graphs provide the macro view. They help you answer questions like:
- Is the network saturated during peak hours?
- Is a specific application flooding the network?
- When did the performance degradation begin relative to traffic patterns?
- Are there unusual patterns of traffic that coincide with user complaints?
How It Works: A Real-Time Snapshot
Wireshark’s I/O graphs are built directly from the packet capture data you provide. As Wireshark processes each packet, it increments counters for different metrics (packets per second, bytes per second, etc.) within small time intervals. The graph then plots these counters over the duration of your capture.
The power comes from the ability to customize these graphs:
- Adding New Graphs: Click the
+button to create a new graph. - Choosing Displayed Values: For each graph, you can select what to plot. Common choices include:
- Packets/s: How many packets are arriving per second. High packet rates with low byte counts often indicate chatty protocols like DNS or control traffic.
- Bytes/s: How much data is flowing per second. This is your primary indicator of raw bandwidth utilization.
- Bit/s: Similar to Bytes/s but often used for interface statistics.
- Average Packet Size: Bytes/s divided by Packets/s. A sudden drop in average packet size while Bytes/s remains high can indicate many small, inefficient transmissions.
- Filtering: Crucially, you can apply display filters before generating the graph. This allows you to isolate specific traffic types. For example, to see only HTTP traffic:
Then, in the "Display filter" box (which is shared with the main Wireshark filter bar), typeStatistics -> I/O Graphshttpand press Enter. Now, your I/O graph will only show HTTP traffic patterns.
The Mental Model: Traffic as a Heartbeat
Think of your network as a living organism. The I/O graph is like an EKG.
- Steady Beat: Normal, healthy traffic flow.
- Irregular Rhythm: Packet loss, retransmissions, or inefficient protocols.
- Sudden Tachycardia (Fast Heart Rate): A burst of activity, potentially normal (like a large file download) or problematic (a denial-of-service attack).
- Bradycardia (Slow Heart Rate): Low activity, which could be normal for a quiet period or indicate a problem if performance is expected.
- Flatline: Complete lack of traffic, usually indicating a connection issue or a stopped service.
By correlating these visual patterns with known events (e.g., "users started complaining at 10:15 AM"), you can pinpoint the cause. If the "Bytes/s" graph shows a massive spike exactly at 10:15 AM, you know the problem is bandwidth-related. If you then filter by tcp.analysis.retransmission, and that graph also spikes, you’ve found your culprit.
The Counterintuitive Truth: Zero is Not Always Zero
What most people miss is that an I/O graph showing no activity for a specific filter doesn’t always mean there’s no traffic. It means there’s no traffic matching your current display filter. If you’re graphing HTTP traffic and see nothing, but you know HTTP requests are happening, it implies the packets aren’t reaching your capture point, or they’re being dropped before Wireshark sees them, or your capture filter is too restrictive. This is especially true if you’re graphing traffic on a switch port that isn’t the actual source or destination of the traffic you expect.
The next step in mastering Wireshark’s visualization capabilities is exploring the "Protocol Hierarchy" statistics, which breaks down traffic by protocol type and percentage.