Wireshark is a free, open-source network protocol analyzer that captures packets from a network interface or reads saved capture files and decodes every protocol layer into readable fields. In network monitoring, it is the standard tool for answering the question that counters and dashboards cannot: what exactly happened on the wire, packet by packet.
Wireshark runs on Windows, macOS and Linux and includes dissectors for thousands of protocols, from Ethernet and TCP to HTTP/2, DNS, SIP and industrial protocols. Its command-line companion TShark offers the same decoding engine for scripts and remote servers.
How Wireshark captures and decodes packets
Wireshark does not capture traffic by itself; it relies on a capture library, libpcap on Unix-like systems and Npcap on Windows. The library copies frames from the network interface driver to user space, applies an optional capture filter in the kernel and passes the packets to Wireshark, which writes them to a file and displays them.
Each captured frame then passes through a chain of protocol dissectors. The Ethernet dissector reads the EtherType and hands the payload to the IPv4 or IPv6 dissector, which hands it to TCP or UDP, which selects an application dissector by port number or by heuristic pattern matching. The result is the familiar three-pane view: packet list, protocol tree and raw bytes.
Beyond single packets, Wireshark performs stateful analysis. It tracks TCP sequence numbers to flag retransmissions, duplicate acknowledgments, zero windows and out-of-order segments, and it reassembles streams so that a full HTTP response or file transfer can be inspected as one object.
| Component | Role | Typical use |
|---|---|---|
| Wireshark GUI | Interactive capture, decoding and analysis | Troubleshooting on an analyst workstation |
| TShark | Command-line capture and decoding | Scripts, remote servers, automated extraction |
| dumpcap | Lightweight capture engine | Long-running captures with ring buffers |
| editcap and mergecap | Edit, split and merge capture files | Trimming large files, combining sources |
| libpcap or Npcap | Kernel-level packet access | Required driver layer for live capture |
Capture filters and display filters
Wireshark uses two different filter languages, and confusing them is one of the most common beginner mistakes. Capture filters use the Berkeley Packet Filter syntax, are applied before packets are stored and permanently discard anything that does not match. Display filters use Wireshark’s own field-based syntax, are applied after capture and only hide packets from view.
The practical rule is to capture broadly and filter on display whenever disk space and traffic volume allow, because a packet discarded by a capture filter can never be recovered. On busy links, a narrow capture filter becomes necessary to avoid dropped packets and enormous files.
| Goal | Capture filter (BPF) | Display filter |
|---|---|---|
| Traffic to or from one host | host 10.0.0.5 | ip.addr == 10.0.0.5 |
| Only DNS | port 53 | dns |
| Only TCP SYN packets | tcp[tcpflags] & tcp-syn != 0 | tcp.flags.syn == 1 |
| TCP retransmissions | Not possible | tcp.analysis.retransmission |
| HTTP requests to one path | Not practical | http.request.uri contains "/login" |
The last two rows show why display filters are more powerful: they can match analysis results and decoded fields that only exist after dissection, whereas capture filters see only raw header bytes.
Where to capture: placement and visibility
Wireshark can only analyze packets that physically reach the capturing interface. On a modern switched network, a laptop plugged into a random access port sees mainly its own traffic and broadcasts, so the capture point must be chosen deliberately.
| Capture point | Visibility | Main caveat |
|---|---|---|
| On the endpoint itself | That host’s traffic only | Host load can distort timing |
| Switch port mirroring (SPAN) | Copied traffic from chosen ports or VLANs | Drops packets when the mirror port is oversubscribed |
| Network TAP | Full-duplex copy of a link | Requires hardware and a brief link interruption to install |
| Wi-Fi monitor mode | 802.11 frames on one channel | Adapter and driver support varies widely |
| Remote capture with TShark or dumpcap | Traffic on a server or router | Capture traffic must not loop into itself |
A full-duplex 1 Gbit/s link can carry up to 2 Gbit/s of combined traffic, which a single 1 Gbit/s mirror port cannot deliver without loss. For accurate analysis of busy links, a hardware TAP or a faster mirror port is the reliable choice.
Wireshark compared with other monitoring tools
Wireshark is a deep, short-term investigation tool, not a continuous monitoring platform. Other tools in network monitoring trade detail for scale: SNMP polls device counters such as interface errors and utilization, while NetFlow and IPFIX summarize conversations as flow records without payloads. Full packet capture with Wireshark provides the highest fidelity but generates the most data.
| Tool or method | Data collected | Retention scale | Best for |
|---|---|---|---|
| Wireshark packet capture | Every packet with payload | Minutes to hours | Root cause of protocol problems |
| NetFlow or IPFIX | Flow summaries: who, when, how much | Weeks to months | Traffic patterns, capacity, anomaly detection |
| SNMP | Device counters and status | Months to years | Utilization trends, interface errors |
| tcpdump | Every packet, minimal decoding | Minutes to hours | Quick capture on headless systems |
A typical workflow combines them: SNMP or flow data shows that a problem exists and where, and a targeted Wireshark capture shows why it happens, for example whether packet loss, high latency or jitter originates in the network or in an application.
Limitations and responsible use
Most modern application traffic is protected by TLS encryption, so Wireshark shows handshakes, certificates, timing and sizes but not content. Decryption is possible only when the analyst controls an endpoint and exports session keys, for example through the SSLKEYLOGFILE mechanism supported by common browsers.
- Capture files contain sensitive data, including credentials sent over unencrypted protocols, personal data and internal addresses; store and share them accordingly.
- Capturing traffic requires authorization; on networks the analyst does not own or administer, it may violate law or policy.
- Timestamps reflect the capture host, so latency measured from a busy laptop can include its own delays.
- Dissectors themselves have had vulnerabilities, so captures from untrusted sources should be opened with an up-to-date version and without elevated privileges.
The idea in brief
Computers talk to each other by sending small packets of data, much like a conversation made of short messages. Wireshark records those messages and translates them into a form a person can read, showing who said what, in which order and how long each reply took.
Ordinary monitoring tools tell an administrator that a network is slow. Wireshark lets the administrator look at the actual conversation and see whether a message was lost, repeated or answered too late, which usually points straight at the cause.
A practical scenario
Staff at a mid-sized company complain that a web-based ordering application freezes for several seconds at random. SNMP graphs show the 1 Gbit/s uplink at only 30 percent utilization, so bandwidth is ruled out. A network engineer configures port mirroring on the switch that serves the application server and records ten minutes of traffic with dumpcap into a ring buffer of 100 MB files.
In Wireshark, the display filter tcp.analysis.retransmission or tcp.analysis.zero_window reveals that the server repeatedly advertises a TCP zero window, meaning its receive buffer is full and clients must wait. The freezes line up exactly with these events, and the time between a request and the first response byte rises from about 20 ms to over 3 seconds.
The network is therefore not at fault. The engineer passes the evidence to the application team, which finds a database call blocking the receiving thread. After the fix, a new capture shows no zero-window events, and the freezes disappear.