Wireshark for Absolute Beginners: How I Finally Understood Network Packets Without Feeling Stupid

 Three days ago, I opened Wireshark for the first time and immediately regretted it.

Packets were flying past.
Protocols, ports, hex values, strange flags.
My brain? Completely frozen.

Three days later, I opened it again—and this time, I could:

• Filter out useless noise

• Lock onto one real request

• Follow it from browser → server → response

• And clearly see where it lived in the network stack

This article is not a feature tour of Wireshark.
It’s a practical, beginner-to-human record of how I went from:

“I don’t understand anything here”
to
“Oh… so this is what’s actually happening.”

If you’ve ever opened Wireshark and immediately closed it—this is for you.

---

First: Why does Wireshark look “broken” when you start?

The MDNS problem (that isn’t actually a problem)

The first thing that annoyed me was this:

“Why are packets constantly scrolling even when I’m doing nothing?”

Most of them were MDNS (Multicast DNS).

Here’s how to recognize MDNS traffic instantly:

• Destination: 224.0.0.251:5353

• Tons of .local entries

• Appears periodically without any user action

This is normal background noise.

Your:

• Laptop

• Phone

• Printer

• Smart speaker

…are all constantly announcing themselves and discovering services on the local network.

MDNS is basically devices saying:

• “Here’s who I am”

• “Here’s what I can do”

• “Is anyone else out there?”

📌 Key realization
Wireshark is not noisy.
Your network is.

Once I understood this, my anxiety dropped immediately.

---

Filters: the skill that separates pain from clarity

Wireshark without filters is torture.
Wireshark with filters is peaceful.

You don’t need to memorize syntax.
Just right-click → Apply as Filter.

Filters I actually use

By protocol

http
dns
tcp

By IP

ip.addr == 192.168.1.1
ip.src == 192.168.1.100
ip.dst != 8.8.8.8

By port

tcp.port == 80
udp.port == 53

Combined

http and ip.addr == 192.168.1.1
tcp.port == 443 or tcp.port == 80
not arp

Two filters that changed everything for me

• tcp.stream eq N
  → Instantly isolates one complete TCP conversation

• tcp.analysis.flags
  → Shows retransmissions, out-of-order packets, and real problems

Once I started filtering, Wireshark finally quieted down.

---

What actually happens when you visit a website?

Textbooks explain this abstractly.
Wireshark lets you watch it happen live.

Step 1: Capture a simple HTTP request (not HTTPS)

I intentionally used a plaintext HTTP site to avoid encryption noise.

Steps

1. Open Wireshark

2. Select your active network interface

3. Visit: http://httpbin.org/html

4. Stop capture

5. Filter by:

http and ip.addr == <server_ip> and ip.addr == <your_ip>

Then:
👉 Right-click a packet → Follow → TCP Stream

Suddenly, everything makes sense.

---

Seeing the request and response side by side

Wireshark automatically:

• Groups packets by (src_ip, src_port, dst_ip, dst_port)

• Orders them by sequence number

• Displays client ↔ server traffic as readable text

You literally see:

HTTP Request

GET /html HTTP/1.1
Host: httpbin.org
User-Agent: Chrome/...

HTTP Response

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 3741

At that moment, I thought:

“So this is the browser talking.”

No magic. Just packets.

---

Breaking down the TCP three-way handshake (for real this time)

This part is worth rewatching again and again.

SYN — “Can you hear me?”

Client → Server

• Seq = 0 (Wireshark normalizes it)

• Window size announced

• MSS negotiated

SYN-ACK — “Yes, let’s talk”

Server → Client

• Ack = 1

• RTT can be calculated

• Window scaling applied

ACK — “Cool, sending data”

Client → Server

• Handshake complete

• Data transmission begins

This isn’t theory anymore.
You can see each byte and timestamp.

---

“Why didn’t I see the full four-way close?”

I expected the classic FIN → ACK → FIN → ACK.

Instead:

• Server sent FIN after ~65 seconds

• Client replied with ACK

• Connection entered TIME_WAIT

• Later, server sent RST

Why?

👉 Idle timeout
The server didn’t want to keep the connection alive anymore.

That’s real-world TCP—not textbook TCP.

---

The moment everything truly clicked: capture your own code

Watching browser traffic is interesting.
Capturing your own packets is transformative.

Minimal TCP server (Python)

import socket

server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind(('127.0.0.1', 9999))
server.listen()

while True:
    client, addr = server.accept()
    data = client.recv(1024)
    client.send(b"Echo: " + data)
    client.close()

Run it, then connect:

nc 127.0.0.1 9999

In Wireshark:

• Interface: lo (loopback)

• Filter: tcp.port == 9999

Now you can watch your code speak TCP.

Every SYN, ACK, FIN exists because of your lines of code.

That’s when TCP stopped being abstract.

---

UDP: even clearer by contrast

No handshake.
No connection state.
Each packet lives alone.

When you capture UDP traffic, the difference is almost visually obvious.

This comparison alone taught me more than hours of reading.

---

Final realization

Wireshark isn’t hard.

The hard part is:

Not knowing what you should be looking for.

Once you:

• Filter background noise

• Start from the application layer

• Trace real conversations

• Capture your own programs

Networking concepts stop being theory.

The real “aha” moment isn’t in a book.
It’s when you think:

“This packet exists because of the line of code I just wrote.”

That’s when Wireshark becomes powerful.