Wireshark Network Packet Analysis

A step-by-step hands-on guide to diagnosing the root cause of intermittent web application latency at the network level through Wireshark packet capture and analysis.

wireshark packet analysisnetwork traffic captureTCP handshakepacket filteringnetwork debuggingdisplay filtertsharktcpdumpHTTP analysisTCP retransmissionnetwork latencypacket capture

Problem

A web application is experiencing intermittent slowdowns. No specific errors can be found in the application logs, and server CPU and memory are within normal ranges. User complaints persist, so packets need to be captured at the network level to analyze TCP connection states, HTTP request/response times, retransmission rates, and more. In particular, there is a pattern of occurrences concentrated during specific time periods, requiring both real-time capture and post-capture analysis.

Required Tools

Wireshark

A GUI-based network protocol analyzer. Decodes hundreds of protocols and provides powerful filtering and statistical capabilities.

tshark (CLI)

The command-line version of Wireshark. Performs packet capture and analysis in server environments without a GUI.

tcpdump

A lightweight packet capture tool. Quickly captures packets on remote servers and saves them as pcap files for analysis in local Wireshark.

Solution Steps

Start packet capture on the server with tcpdump

On production servers without a GUI, use tcpdump to capture packets and save them as pcap files. When capturing, properly configure the interface (-i), port filter, file size limit (-C), and rotation (-W) options to prevent disk space issues. It is important to perform the capture during the time period when the issue reproduces.

# Capture only web traffic on a specific interface (ports 80, 443)
sudo tcpdump -i eth0 'port 80 or port 443' -w /tmp/web_traffic.pcap

# Rotate files at 100MB, keep a maximum of 10 files
sudo tcpdump -i eth0 'port 80 or port 443' \
  -C 100 -W 10 -w /tmp/capture.pcap

# Capture only traffic to/from a specific host
sudo tcpdump -i eth0 'host 10.0.1.50 and (port 80 or port 443)' \
  -s 0 -w /tmp/specific_host.pcap

# Run capture in the background (auto-terminate after 30 minutes)
timeout 1800 sudo tcpdump -i eth0 'port 80 or port 443' \
  -w /tmp/capture_$(date +%H%M).pcap &

Open pcap file in Wireshark and apply display filters

Open the captured pcap file in local Wireshark and extract traffic of interest using display filters. Unlike BPF (Berkeley Packet Filter), display filters use Wireshark's own powerful filter syntax. You can filter by protocol, IP, port, status code, and various other conditions.

# === Wireshark Display Filter Examples ===

# Show only HTTP requests
http.request

# Show traffic for a specific server IP only
ip.addr == 10.0.1.50

# Show only HTTP 500-level response codes
http.response.code >= 500

# Show only TCP retransmission packets (key for latency analysis)
tcp.analysis.retransmission

# Show only TCP connection setup packets (SYN)
tcp.flags.syn == 1 && tcp.flags.ack == 0

# HTTP requests with response time >= 1 second
http.time >= 1

# Filter by specific URI pattern
http.request.uri contains "/api/v1/users"

# Combined filter: specific server + TCP issues
ip.addr == 10.0.1.50 && (tcp.analysis.retransmission || tcp.analysis.duplicate_ack)

Analyze individual connections with TCP stream tracking

Track the full TCP stream of a specific connection where latency occurred. In Wireshark, right-click a packet and select "Follow > TCP Stream" to see the complete request/response sequence for that connection. Observe TCP handshake time, data transfer delays, and FIN/RST patterns to identify bottleneck points.

# Check TCP stream statistics with tshark
tshark -r capture.pcap -q -z conv,tcp

# Extract packets for a specific stream number only
tshark -r capture.pcap -Y "tcp.stream eq 15" -T fields \
  -e frame.time_relative -e ip.src -e ip.dst \
  -e tcp.len -e tcp.analysis.ack_rtt

# Extract HTTP request/response pairs and elapsed time
tshark -r capture.pcap -Y "http" -T fields \
  -e frame.time_relative -e http.request.method \
  -e http.request.uri -e http.response.code \
  -e http.time

HTTP request/response analysis and timing measurement

Measure the response time of each request at the HTTP layer to identify slow API endpoints. Check overall HTTP request statistics in Wireshark's Statistics > HTTP > Requests menu, and visualize traffic patterns and retransmission rates over time in Statistics > IO Graphs.

# === HTTP analysis with tshark ===

# Analyze response time per HTTP request (identify slow requests)
tshark -r capture.pcap -Y "http.response" -T fields \
  -e http.request.uri -e http.time \
  -E separator=, | sort -t, -k2 -rn | head -20

# Statistics by HTTP status code
tshark -r capture.pcap -Y "http.response" -T fields \
  -e http.response.code | sort | uniq -c | sort -rn

# Extract only HTTP responses that took more than 1 second
tshark -r capture.pcap -Y "http.time >= 1.0" -T fields \
  -e frame.time -e http.request.uri -e http.time \
  -e http.response.code

# TCP retransmission statistics (by time period)
tshark -r capture.pcap -Y "tcp.analysis.retransmission" \
  -T fields -e frame.time_relative | \
  awk '{print int($1/60)" min"}' | sort | uniq -c

Comprehensive latency analysis and report generation

Consolidate the collected data to identify the root cause of the latency. Common causes of network latency include: 1) High TCP retransmissions -> Packet loss along the network path (ISP, switch, NIC issues) 2) TCP Window Size of 0 -> Processing delay on the receiving application side (Zero Window) 3) SYN handshake delays -> Server overload or SYN queue saturation 4) Only HTTP response wait times are long -> Backend application/DB processing delays 5) DNS response delays -> DNS server issues or cache expiration Take appropriate action based on each cause, such as network infrastructure checks, server tuning, or application optimization.

# === Comprehensive analysis tshark command collection ===

# Calculate TCP retransmission rate
echo "=== TCP Retransmission Rate ==="
TOTAL=$(tshark -r capture.pcap -Y "tcp" -T fields -e frame.number | wc -l)
RETRANS=$(tshark -r capture.pcap -Y "tcp.analysis.retransmission" \
  -T fields -e frame.number | wc -l)
echo "Total TCP: $TOTAL, Retransmissions: $RETRANS"
echo "Rate: $(echo "scale=2; $RETRANS * 100 / $TOTAL" | bc)%"

# Check Zero Window events
echo "=== Zero Window Events ==="
tshark -r capture.pcap -Y "tcp.window_size == 0" -T fields \
  -e frame.time -e ip.src -e ip.dst | head -10

# DNS response time analysis
echo "=== DNS Response Times ==="
tshark -r capture.pcap -Y "dns.time" -T fields \
  -e dns.qry.name -e dns.time | sort -t$'\t' -k2 -rn | head -10

# RTT (Round-Trip Time) statistics
echo "=== TCP RTT Statistics ==="
tshark -r capture.pcap -q -z io,stat,1,"AVG(tcp.analysis.ack_rtt)tcp.analysis.ack_rtt"

Core Code

Essential Wireshark display filter cheat sheet. TCP problem analysis filters are most useful for quickly identifying the cause of network latency.

# === Wireshark/tshark Essential Display Filter Cheat Sheet ===

# ---- Protocol Filters ----
http                           # HTTP traffic
tcp                            # TCP traffic
dns                            # DNS queries/responses
tls                            # TLS/SSL traffic

# ---- IP Address Filters ----
ip.addr == 10.0.1.50           # Source or destination
ip.src == 10.0.1.50            # Source only
ip.dst == 10.0.1.50            # Destination only

# ---- Port Filters ----
tcp.port == 443                # TCP port
tcp.dstport == 3306            # Destination port only

# ---- TCP Problem Analysis (Essential!) ----
tcp.analysis.retransmission    # Retransmission packets
tcp.analysis.duplicate_ack     # Duplicate ACKs
tcp.analysis.zero_window       # Zero Window
tcp.analysis.window_full       # Window Full
tcp.analysis.fast_retransmission  # Fast Retransmission
tcp.analysis.lost_segment      # Lost segments

# ---- HTTP Analysis ----
http.request.method == "POST"  # POST requests only
http.response.code == 500      # 500 errors only
http.time >= 2.0               # Responses over 2 seconds
http.request.uri contains "api" # URI containing "api"

# ---- Combined Filter Examples ----
# Slow HTTP responses from a specific server
ip.addr == 10.0.1.50 && http.time >= 1.0

# Packets with TCP problems (retransmission + duplicate ACK + Zero Window)
tcp.analysis.retransmission || tcp.analysis.duplicate_ack || tcp.analysis.zero_window

# Packets within a specific time range (relative time)
frame.time_relative >= 300 && frame.time_relative <= 600

Common Mistakes

Capturing without enabling Promiscuous Mode

In default mode, only traffic destined for your machine is captured. Check "Enable promiscuous mode on all interfaces" in Wireshark's Capture Options, or remove the -p flag in tcpdump (promiscuous is the default). In switched environments, port mirroring (SPAN) configuration is additionally required.

Capturing all traffic for extended periods without filters, resulting in excessively large files

Use capture filters (BPF) to capture only the traffic of interest. Set up rotation with tcpdump's -C (file size limit) and -W (file count limit) options, and capture only for the minimum time needed for analysis. Limiting the snapshot length (-s) allows you to capture headers only.

Confusing display filter and capture filter syntax

Capture filters (BPF) are written like "host 10.0.1.50 and port 80", while display filters are written like "ip.addr == 10.0.1.50 && tcp.port == 80". The two syntaxes are completely different. Capture filters can only be set before starting a capture, while display filters can be freely changed during or after capture.

Unable to analyze TLS-encrypted traffic

HTTPS traffic is encrypted by default, making the payload invisible. Use the server's TLS key, or set the SSLKEYLOGFILE environment variable on the client side to export session keys to a file, then specify the key file in Wireshark's Preferences > Protocols > TLS to view decrypted content.

Related liminfo Services

Wireshark Reference TCP/IP Reference