Analyze Network Traffic with Wireshark

Capture and dissect live network packets using Wireshark.

Introduction

30 Second Summary

Have you ever been temporarily blocked from a website while on a coffee shop or office network? That happens because the server sees dozens of people sharing one internet address and mistakes the combined traffic for an attack.

In this project, you will set up a network traffic analysis lab using Wireshark, capture live packets from a local server, and dissect the exact traffic patterns that confuse rate limiters.

What You'll Build

A network traffic analysis lab on your Windows machine where you capture, filter, and analyze real packets using Wireshark.

By the end of this project, you'll have:

  • A saved .pcap capture file containing live traffic you generated and analyzed.
  • A dissected TCP three-way handshake and HTTP request/response exchange at the packet level.
  • Display filter skills and traffic statistics that reveal why shared-IP networks get falsely rate-limited.
  • Secret Mission: Download a real-world sample capture and identify which traffic patterns look like a DDoS attack vs. normal multi-user NAT traffic.

Are there any prerequisites?

None. This guide includes setup instructions for all required tools. You just need a Windows PC with admin rights and a web browser.

Install Wireshark and Set Up Your Lab

To capture and analyze network traffic, you need a packet analyzer that can intercept data flowing through your network interface. Wireshark is the industry-standard tool for this.

In this step, you will install Wireshark, create a set of HTML files for your lab, and launch a local HTTP server that generates traffic you can capture.

In this step, get ready to:
  • Install Wireshark with packet capture capability.
  • Create a local HTTP server to generate readable traffic.
  • Identify your capture interfaces in Wireshark.
Download and install Wireshark

Wireshark is a free, open-source packet analyzer that lets you see every byte flowing across your network. It ships with Npcap, a driver that gives Wireshark permission to tap into your network interfaces.

  • Press the Windows key to open your search bar.
  • Type Wireshark and check whether it appears in the results.

✔️ I have Wireshark 4.6 or higher

If Wireshark is already installed, open it and click Help in the menu bar, then About Wireshark.

If the version shown starts with 4.6 or higher, you are all set. Close the About dialog and skip ahead to the next substep.

ⓧ I see an older version of Wireshark

The Wireshark installer upgrades in place. Download the latest version and run the installer to replace your current version.

  • Open your browser and go to https://www.wireshark.org/download.html.
  • Click the Windows x64 Installer link to download the 4.6.6 installer.
  • Run the downloaded .exe file and accept all default settings.
  • When prompted about Npcap, keep the checkbox selected.
  • Click through the remaining prompts and restart your computer if prompted.

Why Npcap?

Npcap is the packet capture driver for Windows. Without it, Wireshark cannot access raw network traffic on your interfaces.

ⓧ Wireshark is not on my computer

  • Open your browser and go to https://www.wireshark.org/download.html.
  • Click the Windows x64 Installer link to download version 4.6.6.
  • Run the downloaded .exe file.
  • Accept all default settings in the installer wizard.
  • When prompted about Npcap, keep the checkbox selected. Npcap is the driver that lets Wireshark capture live packets.
  • Click Install and wait for the process to finish.
  • Restart your computer if prompted.

Installer asks for admin rights?

Wireshark and Npcap require administrator privileges to install the capture driver. Right-click the installer and select Run as administrator if the installer does not launch.

Help me troubleshoot the Wireshark installer on Windows.

Set up your lab environment

You need a folder on your Desktop to hold the lab files, and a local web server to generate the unencrypted HTTP traffic that Wireshark will capture.

  • Press the Windows key to open your search bar.
  • Type PowerShell and press Enter to open it.
  • Check your network configuration by running this command:
ipconfig

What should I look for?

Find the section labelled Wireless LAN adapter Wi-Fi or Ethernet adapter. Note the IPv4 Address value (something like 192.168.1.x) and the interface name. You will use this information later to identify your traffic.

  • Move to your Desktop by running this command:
cd ~/Desktop
  • Create your lab folder and move into it by running these commands:
mkdir network-lab
cd network-lab

Now you will create three HTML files that your local server will serve. These pages give you clickable links that generate distinct HTTP requests for Wireshark to capture.

  • Create the home page by running this command:
@"
<!DOCTYPE html>
<html>
<head>
    <title>Network Lab Server</title>
</head>
<body>
    <h1>Network Traffic Analysis Lab</h1>
    <p>This page is served by Python's built-in HTTP server.</p>
    <p>Every time you load this page, Wireshark captures the packets.</p>
    <ul>
        <li><a href="/page1.html">Page 1</a></li>
        <li><a href="/page2.html">Page 2</a></li>
    </ul>
</body>
</html>
"@ | Set-Content -Path index.html

What does this command do?

The @"..."@ syntax is a PowerShell "here-string" that lets you write multi-line text without escaping quotes. The pipe (|) sends that text to Set-Content, which writes it to the file.

  • Create the first linked page by running this command:
@"
<!DOCTYPE html>
<html>
<head>
    <title>Page 1</title>
</head>
<body>
    <h1>Page 1 - TCP Connection</h1>
    <p>Loading this page created a new TCP connection visible in Wireshark.</p>
    <a href="/">Back to Home</a>
</body>
</html>
"@ | Set-Content -Path page1.html
  • Create the second linked page by running this command:
@"
<!DOCTYPE html>
<html>
<head>
    <title>Page 2</title>
</head>
<body>
    <h1>Page 2 - Another Request</h1>
    <p>Each page load generates HTTP GET requests you can analyze.</p>
    <a href="/">Back to Home</a>
</body>
</html>
"@ | Set-Content -Path page2.html
  • Confirm all three files exist by running:
ls

You should see index.html, page1.html, and page2.html listed in the output.

Don't see all three files?

Make sure the "@ closing marker is at the very start of its line with no spaces before it. PowerShell requires this for here-strings to work correctly.

If a command shows an error about unexpected tokens, retype it making sure @" is the last thing on its line and "@ starts a new line with nothing before it.

Help me fix the PowerShell here-string syntax for creating my HTML files.

Now start the local web server that will serve these files.

  • Start the Python HTTP server by running this command:
python -m http.server 8080

You should see Serving HTTP on :: port 8080 in the terminal. This window must stay open for the server to keep running.

Why a local HTTP server?

Most websites today use HTTPS, which encrypts traffic so Wireshark cannot read the contents. A local HTTP server sends unencrypted traffic, letting you see full request and response details in plain text.

Seeing "port already in use"?

Another program is using port 8080. Close any other servers or apps that might be listening on that port, then retry the command.

Help me find what is using port 8080 on Windows.

✔️ Awesome, I've got everything!

Great. Keep this PowerShell window open with the server running and move on to the next substep.

ⓧ I'd like to double check the full code

Here is the content each file should contain.

index.html:

<!DOCTYPE html>
<html>
<head>
    <title>Network Lab Server</title>
</head>
<body>
    <h1>Network Traffic Analysis Lab</h1>
    <p>This page is served by Python's built-in HTTP server.</p>
    <p>Every time you load this page, Wireshark captures the packets.</p>
    <ul>
        <li><a href="/page1.html">Page 1</a></li>
        <li><a href="/page2.html">Page 2</a></li>
    </ul>
</body>
</html>

page1.html:

<!DOCTYPE html>
<html>
<head>
    <title>Page 1</title>
</head>
<body>
    <h1>Page 1 - TCP Connection</h1>
    <p>Loading this page created a new TCP connection visible in Wireshark.</p>
    <a href="/">Back to Home</a>
</body>
</html>

page2.html:

<!DOCTYPE html>
<html>
<head>
    <title>Page 2</title>
</head>
<body>
    <h1>Page 2 - Another Request</h1>
    <p>Each page load generates HTTP GET requests you can analyze.</p>
    <a href="/">Back to Home</a>
</body>
</html>
Open Wireshark and identify capture interfaces

With your server running, you now need to open Wireshark and find the network interface that will capture traffic to your local server.

  • Press the Windows key to open your search bar.
  • Type Wireshark and press Enter to open it.

The Wireshark welcome screen shows a list of all available capture interfaces. Interfaces with live traffic have a small moving wave graph next to them.

  • Look for your active network interface (labelled Wi-Fi or Ethernet). It will have a moving sparkline showing live traffic.
  • Look for an interface called Adapter for loopback traffic capture (or Npcap Loopback Adapter). This is the interface you will use to capture traffic to your local Python server.

What is the loopback adapter?

The loopback adapter captures traffic that stays on your own machine. When your browser talks to localhost:8080, the packets never leave your computer. The loopback adapter is where Wireshark can see them.

Don't see any interfaces?

This usually means Npcap did not install correctly. Close Wireshark, re-run the installer, and make sure the Npcap checkbox is selected during installation. Restart your computer after reinstalling.

Help me fix missing capture interfaces in Wireshark on Windows.

Your lab is ready. Next up, you will start a live capture and see real packets flowing between your browser and the Python server.

Capture Your First Packets

Your lab is set up. Wireshark is installed, your Python server is running on port 8080, and you have HTML pages ready to generate traffic.

In this step, you'll perform your first live packet capture. You'll watch real network data flow between your browser and server, then save it for analysis.

In this step, get ready to:
  • Start a live packet capture on the loopback adapter.
  • Save captured packets as a .pcapng file.
  • Filter for HTTP traffic and explore Wireshark's three-pane layout.
Start a live capture on the loopback adapter

Wireshark captures packets by listening on a network interface. Since your Python server runs locally on localhost, the traffic between your browser and server travels through the loopback adapter instead of your physical network card.

  • In Wireshark, double-click the Adapter for loopback traffic capture interface to start capturing.

Don't see that interface name?

Some systems list it as Loopback or Npcap Loopback Adapter instead. Look for the interface that does NOT have a moving wave graph (loopback traffic is quiet until you generate it).

help me find the loopback adapter in Wireshark on Windows

Packets begin flooding into the Packet List pane immediately. Each row represents one packet traveling between programs on your machine.

  • Open your web browser.
  • In the address bar, type http://localhost:8080 and press Enter.
  • You should see the Network Traffic Analysis Lab page served by your Python server.
  • Click the Page 1 link.
  • Click the Page 2 link.
  • Click Back to Home on either page to return to the main page.

Each page load generates new TCP and HTTP packets that Wireshark is recording in real time.

Why the loopback adapter?

Your browser and Python server are both on the same machine. Traffic between them never leaves your computer or hits your Wi-Fi card.

The loopback adapter captures this internal traffic. If you captured on your Wi-Fi interface instead, you would not see any of the localhost traffic.

Stop the capture and save your file

You have generated enough traffic for analysis. Now you'll stop the capture and save the data to a file so you can revisit it later.

  • Switch back to Wireshark.
  • Press Ctrl+E to stop the capture.
  • Click File in the menu bar.
  • Click Save As.
  • Name the file lab_capture.pcapng and save it to your lab folder.

Look at the Protocol column in the Packet List pane. You should see TCP, HTTP, and possibly other protocols listed.

What are all these protocols?

TCP handles reliable delivery of data between your browser and server. HTTP rides on top of TCP to carry the actual web page content.

You might also see protocols like ARP (address resolution) or LLMNR (local name resolution). These are normal background network activity on your machine.

Capture file is empty or has no HTTP packets?

Make sure you captured on the loopback adapter, not your Wi-Fi or Ethernet interface. Localhost traffic only appears on the loopback adapter.

Also confirm your Python server is still running in the other PowerShell window. If it stopped, restart it with python -m http.server 8080 and try a new capture.

help me troubleshoot why my Wireshark capture has no HTTP packets

Filter for HTTP traffic and explore the packet details

Your capture contains hundreds of packets across multiple protocols. Display filters let you narrow down to only the packets you care about.

  • Find the display filter bar at the top of the Wireshark window (it says "Apply a display filter" in gray text).
  • Type http and press Enter.

The Packet List now shows only HTTP packets. You should see your GET requests and the server's responses marked as HTTP/1.0 200 OK.

  • Click on any packet that shows GET in the Info column.

Three panes appear below the filter bar, each showing the same packet at a different level of detail.

What are the three panes?

  • Packet List (top) shows every packet matching your filter as one row.
  • Packet Details (middle) expands the selected packet into its protocol layers. Click the arrows to expand each layer.
  • Packet Bytes (bottom) shows the raw hexadecimal and ASCII data that actually traveled over the wire.
  • In the Packet Details pane, click the arrow next to Hypertext Transfer Protocol to expand it.
  • Observe the request method, host, and other HTTP headers listed inside.

Filter bar turned red?

A red filter bar means Wireshark does not recognize the filter expression. Make sure you typed http in all lowercase with no extra spaces.

If the bar is yellow, the filter is valid but might not match anything. This usually means you captured on the wrong interface or your browser did not load the page during the capture.

help me fix my Wireshark display filter not working

You now have a saved capture file and can read individual packets layer by layer. Next up, you'll dissect the TCP handshake and follow a complete HTTP conversation from start to finish.

Dissect the TCP Handshake and HTTP Exchange

You have captured live packets and saved them as a .pcapng file. Now it is time to look underneath the surface and understand how your browser actually established a connection before any data was sent.

Every TCP connection begins with a "three-way handshake" that sets up the channel between client and server. In this step, you will filter for handshake packets, follow an entire conversation as readable text, and inspect the HTTP headers that servers use to identify who is making a request.

In this step, get ready to:
  • Filter for SYN packets to see TCP handshake initiation.
  • Follow a TCP stream to read the full HTTP conversation in plain text.
  • Inspect HTTP headers that reveal how a server identifies each request.
Filter for SYN packets to see the TCP handshake

Before your browser can send an HTTP request, it must first open a TCP connection to the server. This starts with a SYN packet. SYN stands for "synchronize" and is the very first message in the three-way handshake (SYN, SYN-ACK, ACK).

  • In Wireshark, click the X button next to the display filter bar to clear the current http filter.
  • Type tcp.flags.syn == 1 into the display filter bar and press Enter.

The packet list now shows only SYN packets. These are connection attempts that initiated a TCP handshake.

  • Click on any SYN packet in the list to select it.
  • In the Packet Details pane (the middle pane), click the arrow next to Transmission Control Protocol to expand it.
  • Look for the Source Port, Destination Port (which should be 8080), and the Flags field showing SYN.

What is the TCP three-way handshake?

Every TCP connection starts with three packets exchanged between client and server. The client sends a SYN ("I want to connect"). The server replies with SYN-ACK ("Okay, I acknowledge"). The client finishes with ACK ("Confirmed, let's go").

Only after this handshake completes can any HTTP data flow. The SYN packets you filtered for are the opening move of every single connection your browser made to the Python server.

Not seeing any SYN packets?

Make sure you typed the filter exactly as tcp.flags.syn == 1 with no extra spaces around the equals signs. The filter bar turns green when the syntax is valid.

If the filter bar turns red, you have a syntax error. Double-check for typos in tcp.flags.syn.

Help me troubleshoot my Wireshark display filter

Follow a TCP stream to view the full conversation

Individual packets show fragments of a conversation. Wireshark's Follow TCP Stream feature reassembles all the packets in a single connection into one readable window so you can see exactly what your browser sent and what the server replied.

  • Click the X button next to the filter bar to clear the current filter.
  • Find any packet with HTTP in the Protocol column and right-click on it.
  • Select Follow in the context menu, then click TCP Stream.

A new window opens showing the entire conversation as readable text. The text in red is what your browser sent (the HTTP request). The text in blue is what the Python server replied (the HTTP response).

What am I looking at in this stream?

The red text shows the full HTTP GET request your browser constructed. You can see the request method (GET), the path, the Host header, the User-Agent string identifying your browser, and the Accept headers telling the server what content types your browser understands.

The blue text shows the server's response. It includes the HTTP status line (HTTP/1.0 200 OK), response headers, and the full HTML body of the page. This is exactly what travelled over the wire between your browser and the Python server.

Don't see Follow in the right-click menu?

Make sure you right-clicked directly on a packet row in the Packet List pane (the top pane), not in the Packet Details or Packet Bytes panes below.

If your filter is still active, clear it first. You need to see packets with HTTP in the Protocol column to right-click one.

Help me find the Follow TCP Stream option

Filter for GET requests and read HTTP headers

HTTP headers are metadata attached to every request and response. They tell the server who you are, what browser you use, and what content you accept. On a shared network, these headers are one of the few signals that can distinguish one user from another.

  • Close the Follow TCP Stream dialog by clicking Back (this restores all packets in the main view).
  • Type http.request.method == "GET" in the display filter bar and press Enter.
  • Click on one of the GET packets in the list to select it.
  • In the Packet Details pane (middle pane), click the arrow next to Hypertext Transfer Protocol to expand it.
  • Look at the Host, User-Agent, Connection, and Accept headers listed under the expanded section.

Why do these headers matter for rate limiting?

These headers are what a server uses to identify you. The User-Agent string identifies your browser and operating system. The Host header tells the server which website you are requesting.

On a shared network behind NAT, many users send requests with different User-Agent values but the same source IP. A simple rate limiter only looks at the IP address. A smarter one would notice that different User-Agent strings and session cookies indicate different humans.

Filter bar turning red?

The filter http.request.method == "GET" requires double quotes around GET. Make sure you include them. The method name must also be uppercase.

Help me fix my HTTP display filter syntax

You can now read the raw mechanics of how connections are established and what information travels in every request. Next up, you will master display filters and use Wireshark's statistics tools to spot traffic patterns at scale.

Master Display Filters and Traffic Statistics

You can now dissect individual packets and follow entire TCP streams. That is powerful for investigating a single connection, but real network analysis means finding patterns across hundreds or thousands of packets.

Display filters let you slice through noise to isolate exactly the traffic you care about. Combined with Wireshark's Statistics tools, you can spot anomalies the same way a network engineer does during incident response.

In this step, get ready to:
  • Practice essential display filters and combine them to narrow results.
  • Use Statistics > Conversations to see per-connection traffic breakdowns.
  • Use Statistics > Endpoints to understand how NAT hides users behind one IP.
Practice essential display filters

Wireshark has over 328,000 filterable fields across thousands of protocols. You only need a handful to handle most analysis tasks.

  • Return to Wireshark with your lab_capture.pcapng file loaded.
  • Click the X button next to the display filter bar to clear any existing filter.
  • Type tcp in the filter bar and press Enter. This shows all TCP traffic in your capture.
  • Clear the filter, then type dns and press Enter. This shows DNS queries and responses.
  • Clear the filter, then type http.request and press Enter. This shows only HTTP requests (not responses).
  • Clear the filter, then type ip.addr == 127.0.0.1 and press Enter. This shows traffic to and from localhost.
  • Clear the filter, then type tcp.port == 8080 and press Enter. This shows traffic on your Python server's port.
  • Clear the filter, then type tcp.flags.syn == 1 and tcp.flags.ack == 0 and press Enter. This shows only initial SYN packets, meaning brand-new connection attempts.

What makes that last filter special?

The filter tcp.flags.syn == 1 and tcp.flags.ack == 0 isolates the very first packet of every new TCP connection. A SYN with no ACK means "I want to start talking" before any response has come back.

An unusually high count of these from one IP with no corresponding data transfer is a classic SYN flood signature. Network engineers check this filter first during a suspected DDoS attack.

  • Now try combining filters. Clear the filter bar, type http.request and tcp.port == 8080 and press Enter.

This combined filter shows only HTTP requests that went to port 8080. You should see just the GET requests to your Python server with all other traffic hidden.

Filter bar color codes

If the filter bar turns green, your filter syntax is valid. If it turns red, there is a typo. Check for missing spaces around == and and operators.

Analyze traffic with Statistics > Conversations

Individual filters help you find specific packets. The Statistics menu gives you a bird's-eye view of all traffic patterns at once.

  • Clear the display filter by clicking the X button next to the filter bar.
  • Click Statistics in the menu bar.
  • Click Conversations.
  • Click the TCP tab at the top of the Conversations window.

You should see a table listing every TCP conversation in your capture. Each row shows the source and destination addresses, ports, packet counts, bytes transferred, duration, and bits per second.

Why do network engineers use this view?

This is what professionals look at to spot anomalies. If one IP has 500 conversations while others have 5, that IP might be scanning or attacking the network.

The duration and bytes columns are especially useful. A connection that lasted a long time but transferred very few bytes could be a command-and-control channel keeping a connection alive.

Explore endpoints and understand the NAT problem

The Endpoints view reveals something critical about how rate limiters see your traffic.

  • Close the Conversations window.
  • Click Statistics in the menu bar.
  • Click Endpoints.
  • Click the IPv4 tab.

This lists every IP address that appeared in your capture and how many packets it sent or received. Since all your traffic went through localhost, you should see everything consolidated under one IP address.

What does this have to do with rate limiting?

On a corporate network behind NAT, ALL internal users show up as a single IP address in this view. That is exactly why rate limiters get confused.

A rate limiter counting requests per IP sees one address sending hundreds of requests. It cannot tell if that is 100 legitimate users or one attacker. Your localhost traffic demonstrates this problem perfectly because everything funnels through 127.0.0.1.

Not seeing any data in the Statistics windows?

Make sure the display filter bar is cleared before opening Statistics. If a filter is active, the statistics may only reflect the filtered subset.

If the TCP tab in Conversations is empty, confirm you are looking at lab_capture.pcapng (check the title bar). Your capture must contain TCP traffic from the browser requests you made in the previous step.

Still stuck? Help me troubleshoot empty Statistics windows in Wireshark.

You now have the filtering and statistics skills to isolate any traffic pattern in a capture. Next up, you will generate burst traffic and see firsthand what a rate limiter would flag as suspicious.

Simulate the Rate-Limiting Problem

You now know how to filter packets and read traffic statistics. The big question is: what does problem traffic actually look like at the packet level?

In this step, you will generate rapid burst traffic from a single IP address and observe exactly what a server sees when it decides to block you. This is the core of the shared-IP rate limiting problem that affects everyone behind a NAT gateway.

In this step, get ready to:
  • Generate 50 rapid HTTP requests to your local server using PowerShell.
  • Analyze burst traffic patterns in Wireshark's Statistics views.
  • Identify why rate limiters mistake legitimate shared-IP traffic for attacks.
Start a new capture and generate burst traffic

Your Python server is still running on port 8080. You need a fresh capture that contains only your burst traffic so the pattern is clearly visible.

  • Switch back to Wireshark.
  • Go to Capture > Start in the menu bar (or press Ctrl+E).
  • If prompted, select the Adapter for loopback traffic capture interface (the same one you used earlier).
  • Packets will start flowing in. Leave this running and switch to your PowerShell window.
  • Simulate 50 rapid HTTP requests from a single source by running this command in PowerShell:
for ($i=1; $i -le 50; $i++) { Invoke-WebRequest -Uri http://localhost:8080 -UseBasicParsing | Out-Null; Write-Host "Request $i sent" }

What does this command do?

This is a PowerShell loop that fires off 50 HTTP GET requests back to back with no delay between them.

  • Invoke-WebRequest -Uri http://localhost:8080 -UseBasicParsing sends an HTTP request to your Python server.
  • | Out-Null discards the response body so the loop runs faster.
  • Write-Host "Request $i sent" prints progress so you can watch requests fire off one by one.
  • Wait for the script to finish. You should see Request 1 sent through Request 50 sent printed in your PowerShell window.
  • Switch back to Wireshark and press Ctrl+E to stop the capture.

Not seeing requests go through?

  • Make sure your Python server is still running in the other PowerShell window. If it stopped, restart it with python -m http.server 8080.
  • If PowerShell shows a connection error, confirm you are using http://localhost:8080 (not https).
  • If Wireshark shows no packets, confirm you started the capture on the loopback adapter, not your Wi-Fi or Ethernet interface.

Help me troubleshoot why my PowerShell requests aren't reaching my Python HTTP server on localhost:8080.

Analyze the burst traffic pattern

Your capture now contains 50 rapid-fire requests from one source. Time to see what this looks like from a server's perspective.

  • In the display filter bar, type http.request and press Enter.
  • Look at the Time column on the left side of the Packet List pane.

All 50 requests arrived within seconds from the same source IP (127.0.0.1). That density is what triggers alarm bells.

  • Go to Statistics > Conversations in the menu bar.
  • Click the TCP tab.

You will see dozens of short-lived TCP connections. Each request opened its own connection, used it briefly, then closed it.

Why does this look like an attack?

From a server's perspective, dozens of short-lived connections from one IP arriving within seconds looks identical to a DDoS attack or an automated script. A rate limiter counting requests-per-IP would block this traffic immediately.

This is the exact problem that hits users behind corporate proxies or shared NAT gateways. Fifty different humans sharing one public IP look the same as one attacker sending 50 requests.

Examine request headers to understand composite keys

Rate limiters that only count requests per IP are blunt instruments. A smarter approach uses multiple signals to identify who is actually sending the traffic.

  • Make sure http.request is still in the display filter bar.
  • Click on the first HTTP request packet in the Packet List pane.
  • In the Packet Details pane (middle), expand Hypertext Transfer Protocol.
  • Note the User-Agent, Host, and source IP address.
  • Now click on a different HTTP request packet (try the 25th or the 50th).
  • Compare the headers. They are all identical.

What would real multi-user NAT traffic look like?

In our simulation, every request has the same User-Agent, same source IP, and same timing pattern. That is because one script sent them all.

On a real shared network, 50 different humans would have different User-Agent strings (Chrome vs Firefox vs Safari), different session cookies, and irregular timing patterns. A smarter rate limiter uses composite keys (IP + session cookie + User-Agent) to tell these users apart instead of blocking the entire IP.

Secret mission

Analyze a Real-World Capture File

So far you've only analyzed traffic you generated yourself. Real network engineers analyze captures from other people's networks during incident response. Can you download a real-world capture and identify which traffic patterns look like a DDoS attack versus normal multi-user NAT traffic?

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely locally, so there are no ongoing costs. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

  • Wireshark 4.6.6 (with Npcap) installed on your machine.
  • Python HTTP server running on port 8080 in PowerShell.
  • Project files: index.html, page1.html, page2.html.
  • Capture files: lab_capture.pcapng, burst capture, and downloaded sample capture.
  • Written traffic analysis summary (Notepad file).

Keep everything running

No action needed. Choose this if you're still actively exploring packet captures or plan to revisit the lab soon.

  • Your Python HTTP server will keep running until you close the PowerShell window.
  • Wireshark stays installed and ready for future captures.
  • Your capture files remain available for further analysis.

Pause - I'll come back to this later

Shut down running processes to free up memory. Your files and installations stay in place for when you return.

  • Switch to the PowerShell window running your Python HTTP server and press Ctrl+C to stop it.
  • Close Wireshark.
  • Your capture files and HTML files stay on disk for next time.

Delete - I don't want to use this again

Remove all project resources and start fresh. This uninstalls Wireshark and deletes your project files.

  • Switch to the PowerShell window running your Python HTTP server and press Ctrl+C to stop it.
  • Close Wireshark.
  • Open Settings, then select Apps, then Apps & features.
  • Search for Wireshark, click it, and select Uninstall. Follow the prompts to remove it.
  • Search for Npcap in the same list, click it, and select Uninstall. This removes the packet capture driver.
  • Delete your project files (index.html, page1.html, page2.html) and capture files (lab_capture.pcapng, burst capture, and the downloaded sample capture). Open PowerShell and run:
# Navigate to the folder where your project files are stored
# Replace the path below with your actual folder location
cd ~/Desktop

# Delete the HTML files
Remove-Item index.html, page1.html, page2.html -ErrorAction SilentlyContinue

# Delete capture files
Remove-Item lab_capture.pcapng -ErrorAction SilentlyContinue
  • Delete the sample capture file you downloaded from the Wireshark wiki. If you saved it to your Downloads folder, run:
Remove-Item ~/Downloads/http.cap -ErrorAction SilentlyContinue
  • Delete your traffic analysis summary from Notepad if you saved it to a file.

Nice Work!

Nice Work!

You just built a network traffic analysis lab from scratch and used it to capture, dissect, and analyze real packets with Wireshark. These are the same skills network engineers use every day to troubleshoot connectivity issues and investigate security incidents.

Here's what you learned:

  • Captured live network packets and dissected TCP three-way handshakes and HTTP request/response headers at the packet level.
  • Mastered display filters and Statistics > Conversations to isolate specific traffic patterns and analyze them the way network engineers do.
  • Simulated burst traffic to understand why IP-based rate limiters falsely block legitimate users on shared networks behind NAT.
  • Secret Mission: Analyzed a real-world capture file and identified traffic patterns that distinguish DDoS attacks from legitimate multi-user NAT traffic.

Ready to quiz yourself?