Every network engineer eventually reaches the point where dashboards, logs, and ping tests stop helping. The application team reports that the network is slow. The network team points to healthy utilization graphs. Both claims can be true, and neither explains what users are actually experiencing.

The answer usually sits in the packets themselves. Every TCP handshake, retransmission, window update, and reset is a record of what each endpoint observed and how it reacted. A packet trace is the closest thing networking has to ground truth, because it shows behavior rather than summaries of behavior.

Wireshark is the standard tool for reading that record, but opening it on a busy interface produces a flood of data, not insight. Effective analysis depends on three skills: capturing the right traffic from the right place, decoding protocol behavior against a known baseline, and recognizing the patterns that point to specific faults. Each skill narrows the problem, until a vague complaint becomes a precise diagnosis.

The most consequential decision in packet analysis happens before Wireshark opens: where you capture. A client-side trace shows the connection as the client experiences it, including delays introduced anywhere along the path. A server-side trace shows the server's view. When a retransmission appears at the sender, the original segment may have been lost anywhere downstream. Capturing at both endpoints at the same time and comparing the traces is often the fastest way to localize a fault.

Switched networks complicate visibility. A switch forwards unicast frames only to the port where the destination lives, so promiscuous mode on a laptop sees little beyond its own traffic and broadcasts. The usual options are a SPAN or mirror port, which copies selected traffic to a monitoring port, or a dedicated network TAP, which copies the signal passively. SPAN is convenient but can drop frames under load and may discard errored frames. A TAP provides a complete copy, which matters when chasing intermittent faults.

Filtering comes in two distinct forms. Capture filters use BPF syntax, such as 'host 10.1.1.20 and tcp port 443', and discard packets before they reach disk. Display filters use Wireshark's own syntax, such as 'ip.addr == 10.1.1.20 and tcp.port == 443', and hide packets without deleting them. On busy links, a narrow capture filter combined with a dumpcap ring buffer keeps files manageable while you wait for an intermittent problem to recur.

Encryption is the final obstacle. With ephemeral key exchange, a server's RSA private key can no longer decrypt captured sessions, and TLS 1.3 removed static RSA key exchange entirely. The practical route is session key logging: set the SSLKEYLOGFILE environment variable on a supporting client, such as Chrome, Firefox, or curl, and point Wireshark's TLS preferences at the resulting file. Even without decryption, TCP behavior and the TLS handshake remain visible, and they reveal more than most engineers expect.

Takeaway

A packet trace is a view from one point in the network, not a view of the whole network. Choose the capture point based on the question you need answered.

Resist the urge to scroll through individual packets first. Start with 'Statistics > Conversations' and 'Protocol Hierarchy' to see the shape of the traffic: which hosts are talking, how much data moves, and which protocols dominate. Once a suspicious flow emerges, isolate it with a display filter such as 'tcp.stream eq 7'. 'Follow TCP Stream' then reconstructs the application payload, turning hundreds of segments into a readable exchange of requests and responses.

The packet details pane exposes every field the dissectors understand, and the TCP handshake deserves particular attention. The SYN and SYN/ACK carry the options that govern the entire connection: maximum segment size, window scaling, SACK permission, and timestamps. A middlebox that strips the window scale option silently caps throughput on high-latency paths. Wireshark can only interpret scaled windows if it sees the handshake, so always try to capture connections from the beginning.

Distinguishing normal from abnormal requires knowing what normal looks like. A healthy HTTPS session shows a clean three-way handshake, a ClientHello and ServerHello, steady data with regular ACKs, and an orderly FIN exchange. A DNS response should arrive within milliseconds and carry a matching transaction ID. Capturing known-good traffic during quiet periods gives you a reference trace. The 'Expert Information' panel helps flag anomalies, but its findings are heuristics, not verdicts.

Time is the most underused field in Wireshark. Within a filtered stream, set the time display to 'Seconds Since Previous Displayed Packet', or enable conversation timestamps in the TCP preferences and add tcp.time_delta as a column. Long gaps become immediately visible. Also be aware of false alarms: when capturing on the sending host, checksum offloading means Wireshark sees packets before the NIC computes the checksum, producing warnings that indicate nothing wrong.

Takeaway

Wireshark's dissectors tell you what each field contains. Only a baseline of healthy traffic tells you what those values mean.

Retransmissions, found with 'tcp.analysis.retransmission', indicate that a segment was lost or delayed beyond the sender's patience. The type matters. Fast retransmissions follow duplicate ACKs and recover within roughly one round trip, which is typical of congestion or occasional drops. Timeout-based retransmissions mean the sender waited out its RTO timer, which costs at least 200 milliseconds on Linux and often more. Repeated SYN retransmissions at doubling intervals usually indicate a firewall silently dropping traffic or a full listen queue.

Resets, filtered with 'tcp.flags.reset == 1', carry meaning based on context. A RST in reply to a SYN means nothing is listening on that port, or a firewall is actively rejecting the connection. A RST in the middle of an established session often points to an application abort or a stateful device, such as a firewall or load balancer, that timed out its connection entry. Compare the IP TTL and IP ID of the reset with earlier packets from the same address; a mismatch suggests a middlebox generated it.

Timing analysis separates network delay from application delay. Measure the round-trip time from the handshake, then compare it with request-response intervals. If the server ACKs a request within one RTT but the response arrives 800 milliseconds later, the network delivered promptly and the server spent that time processing. Zero window advertisements, found with 'tcp.analysis.zero_window', mean the receiving application is not draining its socket buffer, a host problem rather than a network one. Recurring 40 or 200 millisecond stalls often trace to Nagle's algorithm interacting with delayed ACKs.

Real faults rarely present a single symptom. IO Graphs with overlaid display filters can correlate retransmission bursts with throughput drops, while TCP Stream Graphs in Stevens or tcptrace format show exactly where a sender stalled. The goal is to turn 'the network is slow' into a specific, defensible statement: packets are being dropped between two named hops, or the server takes 800 milliseconds to answer a particular request type.

Takeaway

Every TCP anomaly is an endpoint reacting to something it observed. Read each pattern as a symptom and ask which side of the connection, and which layer, produced it.

Effective packet analysis is a narrowing process. Capture location determines what you can see, filters determine how much noise you must wade through, and protocol knowledge determines whether you recognize the signal when it appears.

A few practices hold across nearly every investigation. Capture at both ends when the fault location is unclear. Record connections from the handshake onward. Keep reference traces of healthy traffic. Measure time explicitly, and separate network delay from application delay before assigning blame.

Jon Postel's robustness principle asked implementations to be conservative in what they send and liberal in what they accept. Packet traces show precisely where that tolerance has been exhausted. The packets rarely lie, but they only answer the questions you know how to ask.