AlgoInsight

Free lesson · Computer Networking

Hands On Seeing Layers In Action With Wireshark

Easy11 min readnetworkingcomputer-networkstcp-ip

Why Capture Packets?

Everything you have learned in this module - network models, layers, encapsulation, protocols - has been conceptual. The OSI model is a diagram. Encapsulation is a nesting-doll metaphor. Protocols are described in words. This topic changes that. By the end of this lesson, you will have captured actual network traffic, opened a real packet, and pointed to the specific bytes that represent each layer's header.

Packet capture is also one of the most valuable debugging skills a software engineer can have. When your API call returns a mysterious error, when a service-to-service connection times out, when data arrives corrupted - a packet capture shows you exactly what happened on the wire. It removes guessing from network troubleshooting and replaces it with evidence.

The primary tool for packet capture and analysis is Wireshark - a free, open-source packet analyzer that runs on Windows, macOS, and Linux. It is the industry standard and has been for over two decades.

Installing Wireshark

macOS

The simplest approach is to download the installer directly from the Wireshark website at https://www.wireshark.org/download.html. Download the macOS disk image (.dmg) for your architecture (Intel or Apple Silicon), open it, and drag the Wireshark application to your Applications folder. On first launch, macOS may prompt you to install the "ChmodBPF" helper tool - accept this, as it grants Wireshark the necessary permissions to capture network traffic.

Alternatively, if you use Homebrew:

brew install --cask wireshark

Windows

Download the Windows installer (.exe) from the Wireshark website. During installation, you will be prompted to install Npcap - a packet capture library that Wireshark needs. Accept this, and use the default Npcap settings. After installation, you may need to run Wireshark as Administrator for the first capture.

Linux (Ubuntu/Debian)

sudo apt update
sudo apt install wireshark

During installation, you will be asked whether non-root users should be able to capture packets. Select "Yes." Then add your user to the wireshark group:

sudo usermod -aG wireshark $USER

Log out and log back in for the group change to take effect.

Warning: Wireshark captures all network traffic visible to your network interface. On a shared network, this may include traffic from other devices. Use packet capture responsibly and only on networks you own or have explicit permission to analyze. Capturing network traffic on networks you do not control may violate laws and organizational policies.

Your First Capture - An HTTP Request

For this exercise, we will capture an unencrypted HTTP request so that every layer is fully visible. Most modern web traffic uses HTTPS, which encrypts the application-layer data and makes it unreadable in a packet capture. By using a plain HTTP site, we can see the full content of every layer.

Step 1 - Start the Capture

Open Wireshark. You will see a list of network interfaces - these are the network connections on your machine. Look for the interface with active traffic (Wireshark shows a small activity graph next to each interface). Typically:

Double-click the interface to start capturing. You will immediately see packets appearing in the capture window - potentially hundreds per second. Do not panic - we will filter these down momentarily.

Step 2 - Generate the Traffic

Open a terminal and run the following command to make a simple HTTP request to a known plaintext HTTP server:

curl http://httpbin.org/get

This sends an HTTP GET request to httpbin.org over port 80 (unencrypted HTTP). You should see a JSON response in your terminal showing your request headers.

If you prefer not to use the command line, you can type http://httpbin.org/get into your browser's address bar. However, browsers may automatically upgrade to HTTPS, so the command-line approach is more reliable for this exercise.

Step 3 - Stop the Capture and Filter

Go back to Wireshark and click the red square button to stop the capture. You now have a capture file containing all network traffic during that period.

To find your HTTP request in the flood of traffic, use Wireshark's display filter. In the filter bar at the top, type:

http

Press Enter. The capture list now shows only HTTP packets. You should see your GET request to httpbin.org and the response.

graph TD
    A["Wireshark Capture Window"] --> B["Display Filter: http"]
    B --> C["HTTP GET /get<br/>Your request to httpbin.org"]
    B --> D["HTTP 200 OK<br/>Server's response"]
    
    C --> E["Click to expand<br/>each layer"]
    
    E --> F["▸ Ethernet II<br/>Source MAC → Dest MAC"]
    E --> G["▸ Internet Protocol v4<br/>Source IP → Dest IP"]
    E --> H["▸ Transmission Control Protocol<br/>Source Port → Dest Port 80"]
    E --> I["▸ Hypertext Transfer Protocol<br/>GET /get HTTP/1.1"]

    style A fill:#4f46e5,stroke:#4338ca,color:#fff
    style C fill:#7c3aed,stroke:#6d28d9,color:#fff
    style D fill:#7c3aed,stroke:#6d28d9,color:#fff
    style F fill:#a78bfa,stroke:#8b5cf6,color:#fff
    style G fill:#8b5cf6,stroke:#7c3aed,color:#fff
    style H fill:#7c3aed,stroke:#6d28d9,color:#fff
    style I fill:#4f46e5,stroke:#4338ca,color:#fff

This diagram shows the flow of analyzing a packet in Wireshark. Starting from the Wireshark capture window, you apply the display filter "http" to narrow down to HTTP traffic. You find the HTTP GET request to httpbin.org and the HTTP 200 OK response. Clicking on the GET request lets you expand each layer: Ethernet II showing source and destination MAC addresses, Internet Protocol version 4 showing source and destination IP addresses, Transmission Control Protocol showing source port and destination port 80, and Hypertext Transfer Protocol showing the GET request line.

Identifying Layers in the Capture

Click on the HTTP GET request in the capture list. In the Packet Details pane (the middle pane), you will see the packet broken down into expandable sections. Each section corresponds to a network layer - this is encapsulation made visible.

Layer 2 - Ethernet II

Click the triangle to expand the Ethernet II section. You will see:

This confirms what you learned about encapsulation: the Ethernet frame wraps the IP packet, and the destination MAC is the next hop (your router), not the final destination.

Layer 3 - Internet Protocol Version 4

Expand the Internet Protocol Version 4 section:

Notice the destination IP is the final destination (the web server), not the next hop. This is the key difference between Layer 2 and Layer 3 addressing: MAC addresses point to the next device, IP addresses point to the final destination.

Layer 4 - Transmission Control Protocol

Expand the Transmission Control Protocol section:

Port 80 is how the web server knows this data is meant for its HTTP service rather than its SSH service (port 22) or its database (port 5432).

Layer 7 - Hypertext Transfer Protocol

Expand the Hypertext Transfer Protocol section:

This is the actual application data - the HTTP request your browser or curl command sent. Everything below this section (TCP, IP, Ethernet) was infrastructure to get this message delivered. This section is the message itself.

Tip: In the Packet Bytes pane (the bottom pane), you can see the raw hexadecimal representation of the entire packet. Click on any field in the Packet Details pane, and Wireshark highlights the corresponding bytes in the hex dump. This lets you see exactly where each header field sits in the raw packet data - the Ethernet header occupies the first 14 bytes, the IP header starts at byte 15, and so on.

Reading the Response

Find the HTTP 200 OK response packet in the filtered capture. Click on it and examine the same four layers:

Notice the symmetry - the response is the mirror image of the request, with source and destination swapped at every layer. This is the round trip: your request traveled down through the layers on your machine, across the network, up through the layers on the server, back down through the layers on the server, across the network, and up through the layers on your machine.

Seeing the Three-Way Handshake

Before your HTTP request could be sent, TCP had to establish a connection. Remove the HTTP filter and replace it with:

tcp.port == 80 && ip.addr == [httpbin.org's IP]

(Replace [httpbin.org's IP] with the actual IP you saw in the packet details.)

Now you can see the full sequence:

  1. SYN - Your machine sends a TCP segment with the SYN flag set (connection request)
  2. SYN-ACK - The server responds with SYN and ACK flags set (connection accepted)
  3. ACK - Your machine sends an acknowledgment (handshake complete)
  4. HTTP GET - Your HTTP request, now carried inside an established TCP connection
  5. HTTP 200 OK - The server's response
  6. FIN, ACK - Connection teardown (may be multiple packets)

This sequence is the TCP protocol in action - the three-message handshake you learned about in Topic 6, now visible as actual packets with real sequence numbers and flags.

sequenceDiagram
    participant Y as Your Machine
    participant S as httpbin.org Server

    Note over Y,S: What you see in Wireshark
    Y->>S: TCP [SYN] Seq=0
    S->>Y: TCP [SYN, ACK] Seq=0 Ack=1
    Y->>S: TCP [ACK] Seq=1 Ack=1
    Note over Y,S: Connection established
    Y->>S: HTTP GET /get
    S->>Y: TCP [ACK]
    S->>Y: HTTP/1.1 200 OK
    Y->>S: TCP [ACK]
    Note over Y,S: Data exchanged
    Y->>S: TCP [FIN, ACK]
    S->>Y: TCP [FIN, ACK]
    Y->>S: TCP [ACK]
    Note over Y,S: Connection closed

This sequence diagram shows the complete lifecycle of a TCP connection as you would see it in Wireshark. Your machine sends a SYN to the server. The server responds with SYN-ACK. Your machine sends ACK, completing the three-way handshake. Then your machine sends the HTTP GET request. The server acknowledges it, then sends the HTTP 200 OK response. Your machine acknowledges the response. To close the connection, your machine sends FIN-ACK, the server sends its own FIN-ACK, and your machine sends a final ACK.

Beyond HTTP - Other Useful Wireshark Filters

Once you are comfortable with basic HTTP captures, these filters let you explore other protocols:

Filter What It Shows
dns DNS queries and responses - see domain name resolution in action
tcp.flags.syn == 1 All TCP connection initiations (SYN packets)
tcp.flags.rst == 1 All TCP resets - often indicates connection problems
icmp Ping requests and replies
arp ARP requests and replies - IP-to-MAC address resolution
tcp.port == 443 HTTPS traffic (encrypted - you will see TLS handshake but not the HTTP data)
ip.addr == 192.168.1.1 All traffic to/from a specific IP

Interview: Wireshark itself is unlikely to come up in a System Design interview, but the ability to reason about packet-level behavior shows deep networking understanding. If an interviewer asks "why does the first request to a new server take longer than subsequent requests?", you can explain the TCP handshake overhead (three extra packets before any data is sent) and the DNS lookup time - concepts you have now seen directly in a capture.

Being able to say "I would capture the traffic with Wireshark to diagnose this" in a debugging scenario shows practical engineering maturity that distinguishes senior candidates.

Common Pitfalls When Starting with Wireshark

"I see thousands of packets and cannot find mine." Use display filters aggressively. Start with a protocol filter (http, dns, tcp.port == 80) and add IP filters if needed. You can also start the capture, generate your specific traffic, stop the capture immediately, and then filter - minimizing the window of captured traffic.

"The HTTP data is encrypted and I cannot read it." Modern websites use HTTPS, which encrypts the application-layer data using TLS. In a Wireshark capture, HTTPS traffic appears as TLS protocol packets with encrypted application data. To practice with visible HTTP data, use plaintext HTTP sites like httpbin.org or set up a local HTTP server.

"I see my private IP but not the public IP I expected." If you are behind a router performing NAT (Network Address Translation), your machine's IP address is private (192.168.x.x or 10.x.x.x). The router replaces your private IP with its public IP before forwarding packets to the internet. In your local capture, you see the pre-NAT private address. The server sees the post-NAT public address.

"Some packets show as [TCP Retransmission]." This means a segment was sent but not acknowledged within the timeout period, so TCP automatically retransmitted it. This is the reliability mechanism of TCP in action - and it shows that the "best-effort" IP layer sometimes does lose packets, requiring the transport layer to recover.

Module Wrap-Up

You have now completed the foundational module on network models. Here is what you have built:

  1. Why models exist - to manage complexity, enable interchangeability, and standardize across vendors
  2. The OSI model - seven layers, each with a specific responsibility, providing the industry's standard vocabulary
  3. The TCP/IP model - four layers, pragmatically designed, the architecture the actual internet runs on
  4. How the two models compare - OSI for vocabulary, TCP/IP for architecture, and the practical hybrid the industry uses
  5. Encapsulation - how data is wrapped in headers at each layer and unwrapped on the receiving side
  6. Protocols - the precise rules governing communication at each layer
  7. Wireshark - the tool that makes all of these concepts visible in real network traffic

Every topic in the rest of this course builds on these foundations. When you study TCP in depth, you are studying a Layer 4 protocol. When you study DNS, you are studying a Layer 7 protocol that uses UDP at Layer 4. When you study routing, you are studying Layer 3 behavior. The models give you the map; the rest of the course fills in the terrain.

Exercise: Starter: Capture a DNS query. Open Wireshark, start a capture, then run nslookup google.com in your terminal. Stop the capture and filter by dns. Find the DNS query and response. What transport-layer protocol does DNS use? What port? What IP address did the DNS server return for google.com?

Intermediate: Capture an HTTPS request (visit any website). Compare what you see in the capture with the HTTP capture from this exercise. Which layers are still fully visible? Which layer's content is now encrypted? Can you identify the TLS handshake packets? How many round trips does the TLS handshake add before any application data is exchanged?

Advanced: Set up a local HTTP server on your machine (using Python's python3 -m http.server 8080 or Node.js) and capture the traffic between your browser and the local server. Since both the client and server are on the same machine, what do you notice about the MAC addresses? What about the IP addresses? Does the traffic go through your router, or does it stay entirely local? What does this tell you about how the networking layers handle localhost traffic?

Back to Computer Networking