The real magic of Wireshark’s protocol statistics isn’t just seeing what protocols are present, but understanding why they’re present and what that implies about your network’s behavior and security.
Let’s look at a live capture. Imagine we’re monitoring a web server. We’ve captured a few minutes of traffic and now we’re diving into the Statistics -> Protocol Hierarchy view.
| Protocol | Packets | Bytes | Percentage |
|--------------------|-----------|-----------|-----------------|
| ip.addr | 10000 | 10000000 | 100.00% |
| tcp | 8000 | 8000000 | 80.00% |
| http | 6000 | 6000000 | 60.00% |
| tls | 2000 | 2000000 | 20.00% |
| udp | 2000 | 2000000 | 20.00% |
| dns | 1500 | 1500000 | 15.00% |
| ntp | 500 | 500000 | 5.00% |
This table is a tree. ip.addr represents all IP packets. Underneath, tcp and udp are the transport layer protocols. Further down, http and tls are application layer protocols running over TCP, and dns and ntp are over UDP. The Packets and Bytes columns show the raw counts, and Percentage gives you a relative view.
So, what problem does this solve? It helps you identify unexpected traffic, pinpoint bandwidth hogs, and even spot potential security anomalies at a glance. For instance, if you see a massive spike in UDP traffic that isn’t DNS or NTP, you might have a P2P application, a broadcast storm, or something more malicious.
Internally, Wireshark dissects each packet, identifies its protocol based on port numbers, IP options, or payload patterns, and then aggregates these counts into the hierarchical tree structure. It’s essentially a real-time accounting system for your network traffic, categorized by its communication method.
The Statistics -> Conversations view is your next stop for deeper dives. It shows you communication flows between specific endpoints. You can filter this by protocol (e.g., tcp.port == 80) to see who’s talking to your web server. The Statistics -> Endpoints view is similar but lists all unique endpoints and their traffic volume.
You can control this view by applying display filters before generating the statistics. For example, to see only HTTP traffic statistics, you’d type http into the display filter bar and then go to Statistics -> Protocol Hierarchy. This allows you to zoom in on specific conversations or protocols without the noise of everything else.
A common trap is to just look at the top-level percentages and assume you understand the traffic. However, the real insights often lie in the sub-protocols. For example, a high percentage of tcp traffic might be entirely legitimate, but if the tls percentage within it is unexpectedly low, it could indicate unencrypted sensitive data transfer, or vice-versa. Conversely, a large chunk of udp traffic that isn’t DNS might be a giveaway for an unauthorized application or a denial-of-service attack.
When you start seeing a large percentage of traffic identified only as "data" or "unknown" at the application layer, it’s often because the protocol isn’t recognized by Wireshark’s dissectors or it’s running on a non-standard port. This is a prime area to investigate further using other Wireshark features like packet dissection and expert information.
The next step after understanding your traffic breakdown is to analyze the content of those conversations, which often involves diving into Statistics -> Service Response Times to understand performance.