Skip to content

Monitoring packets with Wireshark

The Wireshark article already explained the three panes, the difference between a capture filter and a display filter, and how to follow a TCP stream — all of it described against captures that were already sitting there, ready to read. This lab captures your own, live, from a single curl request you send yourself, and follows it from the very first SYN to the final FIN.

Goal and end result

By the end of this lab, you'll have captured a complete HTTP request and response over a fresh TCP connection, and matched every stage of that capture — the handshake, the request, the response, the teardown — against what this course has already explained about each of those individually. Nothing here is new theory; it's confirming the theory against packets you generated and captured yourself.

Requirements

  • Wireshark, installed on the machine that will do the capturing.
  • curl, to generate a request in a way that's easy to time and repeat exactly.
  • A wired or Wi-Fi network interface Wireshark can capture on — capturing on a loopback-only setup works for some of this lab, but the request below deliberately goes out to a real server so the capture shows a genuine multi-hop round trip, not a same-machine shortcut.

Safety note

Everything in this lab is passive observation of traffic your own machine already generates — nothing here injects, modifies, or blocks any packet. Capturing traffic on a network you don't own or administer (a shared office network, someone else's Wi-Fi) can capture other people's traffic incidentally and may violate policies you agreed to on that network; run this lab on a network you control.

Step 1: start the capture before the request

Open Wireshark, select the interface that carries your normal internet traffic, and start capturing with no filter yet — the goal is to capture everything around the request, then narrow down afterward, rather than trying to guess the right capture filter in advance and missing something.

Step 2: generate one clean HTTP request

example.com is reserved by IANA specifically for documentation and examples, which makes it a stable, always-available, plain HTTP target for exactly this kind of exercise — no authentication, no session state, nothing that complicates a first capture. Deliberately use the plain http://, not https://, for this first pass — this lab is about a stream you can read directly.

curl http://example.com

<!doctype html>
<html lang="en">
<head>
<title>Example Domain</title>
...
</head>
<body>
<div>
<h1>Example Domain</h1>
<p>This domain is for use in documentation examples without needing permission. Avoid use in operations.</p>
<p><a href="https://iana.org/domains/example">Learn more</a></p>
</div>
</body>
</html>

Stop the Wireshark capture immediately after this returns.

Step 3: filter down to just this exchange

In Wireshark's display filter bar, narrow the capture to only the relevant traffic — the Wireshark article already drew the line between a capture filter (applied while capturing) and a display filter (applied afterward, to what's already captured); this is the second kind:

http or (tcp.port == 80 and ip.addr == <the resolved IP curl printed with -v>)

A plain http filter alone is usually enough to isolate the request and response themselves, but it won't show the handshake or teardown segments around them, since Wireshark's HTTP dissector only labels packets that actually carry HTTP data. Right-click any one of the HTTP rows and choose Follow → TCP Stream to see this exact exchange end to end, exactly as the article's own section on following a stream described.

Step 4: match the capture against what this course already taught

Reading the filtered packet list top to bottom should show, in order:

  1. Three packets with no data — SYN, SYN, ACK, ACK — the three-way handshake this course already covered in depth at the packet-field level. Click the first SYN and expand its TCP layer in Wireshark's packet-detail pane; the sequence number, window size, and MSS option are all exactly the fields that article walked through individually.
  2. One packet carrying the HTTP request — GET / HTTP/1.1, along with a Host: header naming example.com. This is the same request format the HTTP article already explained, now visible in a live capture rather than a static example.
  3. One or more packets carrying the response, likely showing a 200 OK status line and a Content-Type: text/html header — note whether the response uses Content-Length or Transfer-Encoding: chunked to tell the client where the body ends, and check that framing detail against what the HTTP article already said about it. A server sitting behind a CDN, which example.com currently does, will typically also show extra headers like Server: and a cache-status header identifying the CDN — a small, concrete reminder that how a CDN works isn't abstract; it's visible in ordinary response headers the moment you look.
  4. A FIN, ACK and the matching ACK, or occasionally a FIN from each side — the connection teardown this course already covered, closing the exact connection the handshake opened three steps earlier.

Practice: repeat against HTTPS and compare

Run the identical request over https://example.com instead, capture it the same way, and compare the two captures directly. The handshake and teardown segments look almost identical; the difference shows up immediately after the handshake, where the plain-HTTP capture showed a readable GET request and the HTTPS capture instead shows a TLS Client Hello — the start of the exchange the TLS handshake article covered in depth, and the exact reason Wireshark can label and follow the plain-HTTP stream as text but can only label the HTTPS stream's encrypted application data as opaque bytes.

Troubleshooting

  • The capture shows nothing when curl runs. Confirm Wireshark is capturing on the interface actually carrying this traffic — a machine with both Wi-Fi and Ethernet active, or a VPN interface up, can easily have curl's traffic leave through an interface Wireshark isn't watching.
  • Follow → TCP Stream shows binary garbage instead of readable HTTP text. This is the HTTPS behavior described above showing up on what was meant to be the plain-HTTP capture — double-check the URL actually used http://, not https://, and that no browser extension or system proxy silently upgraded the request.
  • The response headers look different from what's shown above. example.com's exact headers, caching behavior, and hosting details can change over time — the point of this lab is matching the structure (status line, headers, body) against what this course already taught, not matching this exact byte-for-byte response.

Cleanup

Nothing to tear down — this lab only captured traffic your own machine generated; no service was started and no configuration was changed.

Evaluation criterion

You've completed this lab correctly if you can point to a live capture and correctly label, for one full request, each of: the three handshake packets, the request packet, the response packet, and the teardown packets — and explain what changed about the capture when the same request ran over HTTPS instead of plain HTTP.

Reading a capture packet by packet works well for a handful of packets from one short-lived request. It stops scaling the moment a real application under test opens dozens of connections at once — which is exactly the situation the next lab puts you in, building and testing an actual HTTP server rather than just observing someone else's.

Sources