Wireshark is most useful when you turn a capture into a narrative: DNS lookup, connection setup, TLS if present, HTTP request, response, retransmissions, closure. Filtering and packet detail then become tools for answering specific questions instead of a wall of protocol fields.
Remember the shape, not the sentence
“Imagine reading a security camera timeline with timestamps. You first identify the conversation, then zoom into suspicious moments. Do not inspect every pixel when one event is enough to explain the incident.”
Capture carefully
Use a capture point where the traffic you need is actually visible. Modern HTTPS encrypts application payloads, so packet capture alone does not expose the HTTP text without appropriate session keys or endpoint instrumentation.
Follow the stream
The 'Follow TCP Stream' view reconstructs a conversation's payload order, making it easier to see request/response boundaries when the payload is available.
Correlate layers
A web request can be related to DNS, TCP, TLS and HTTP records. Use timestamps and stream identifiers to connect them rather than analyzing each protocol in isolation.
See the mechanism before you memorize it
One diagram, one causal story, one reconstruction task.
Wireshark: follow one full HTTP conversation — causal map
DNS
Find which destination address was resolved.
TCP
Check handshake and transport state.
TLS
Inspect handshake metadata and certificate exchange, not plaintext application data.
HTTP
Inspect method/status/headers when the payload is visible.
Draw the idea yourself
Rebuild the core flow on a real canvas before moving to the worked walkthrough.
Walk the system
DNS
Find which destination address was resolved.
TCP
Check handshake and transport state.
TLS
Inspect handshake metadata and certificate exchange, not plaintext application data.
HTTP
Inspect method/status/headers when the payload is visible.
Timing
Correlate delays with retransmissions, waiting periods and server responses.
Useful filters
Filters should narrow the evidence space. Start from a host, stream or protocol and then add anomaly filters.
dns
tcp.stream == 0
tls.handshake
http
tcp.analysis.retransmission
frame.time_delta_displayed > 0.2What usually goes wrong
Close the tab. Rebuild it from memory.
Read the question, answer aloud, then reveal.
Why is 'Follow TCP Stream' useful?Reveal answer
It groups packets belonging to one TCP conversation and reconstructs the payload ordering so the analyst can see the application exchange coherently.
Why might HTTP not be visible?Reveal answer
HTTPS encrypts HTTP application data inside TLS. You may need endpoint keys, decryption support, or server-side logs to inspect the plaintext.
What does a retransmission tell you?Reveal answer
TCP considered previous delivery insufficiently acknowledged and sent the data again; correlate timing and ACK behavior to understand the likely cause.
Make this idea travel.
Connect it next to: osi-model • tcp-packet-analysis • devtools.