Wireshark is a cross-platform network capture and analysis tool that gives you insight into your network traffic, including a detailed breakdown of each data packet. It can be used for improving network and application performance, detecting security threats, troubleshooting networking issues, and more.

Unlike other network analysis tools, such as tcpdump, Wireshark has a graphical user interface that allows you to inspect network packets visually, without the use of a command line interface. This post looks into how packet capturing with Wireshark works in practice.

If you are interested in the brief theory of network packet analysis, check out the first part of this article, too, which discusses TCP/IP layers, protocols, packets, and internet communication overall.

What are Wireshark frames?

Packets in Wireshark are called frames. A frame is a pseudo-protocol developed by Wireshark that you can see at the top of each Wireshark capture — it's essentially the summary of all the underlying data managed by a set of communication protocols (e.g. total byte size, arrival time, frame number, etc.).

Network packets, overall, are not static entities. A Wireshark capture is the snapshot of one moment — when Wireshark recognizes the presence of the packet. However, the packet is built up gradually, and each protocol involved in the process adds data to it.

Start capturing

Wireshark can capture packets both exchanged with external servers via the internet and used within a local network.

Before getting started with packet capturing, you need to decide which of your network connections you want to capture. Wireshark lets you choose from wired, wireless, and Bluetooth connections:

What does a Wireshark packet look like?

Each network packet has a layered structure defined by the Internet Protocol Suite. A Wireshark capture is named after its top-level protocol, which can belong to the application (HTTP, TLS, DNS, etc.), transport (UDP, TCP, QUIC), or link layer (e.g. ARP) — for example, you can have HTTP, QUIC, DNS, TCP, and other captures.

Example 1: UDP + DNS

Here's a screenshot of the overall look of the Wireshark UI and the breakdown of a DNS (Domain Name Server) query — the DNS conversation (request: Frame 10 and response: Frame 11) is colored in red:

In the top pane (Packet List), you can see the packets captured by Wireshark, the middle pane (Packet Details) shows the used protocol stack (Ethernet, IPv4, UDP, DNS), and the bottom pane (Packet Bytes) shows the canonical hex dump of the packet data.

The data encapsulated in the packet is added by four communication protocols — each belonging to a different TCP/IP layer.

For example, Frame 10 weighs 81 bytes in total, of which:

• 14 bytes are link-layer data added by the Ethernet protocol
• 20 bytes are internet-layer data added by IPv4
• 8 bytes are transport-layer data added by UDP
• 39 bytes are application-layer data added by the DNS protocol

Wireshark is showing the number of bytes added by each protocol in the bottom-left corner of the UI as you're clicking through the protocols in the Packet Details pane.

Other examples of Wireshark captures

Now, let's see some other examples of Wireshark captures of different protocol stacks, too.

As we're on an Ethernet connection, the link layer always uses the Ethernet protocol, and the internet layer is always handled by IPv4 on this connection.

The transport layer is either TCP or UDP — these are the two transport protocols that all operating systems and devices support. QUIC, which is a new transport protocol, runs on top of UDP and extends it with additional features — it can be thought of as a high-level transport protocol that includes performance and security features.

Application-layer data is delivered to the destination by either TCP or UDP — e.g. HTTP/1.1, HTTP/2, and TLS use TCP, while QUIC, DNS, and HTTP/3 use UDP for transport.

Example 2: TCP three-way handshake + unencrypted HTTP/1.1 request

HTTP/1.1 uses TCP (Transmission Control Protocol) as transport protocol. The communication starts with TCP's (SYN, SYN-ACK, ACK) handshake that establishes the connection between the client and server. The client sends the first HTTP request (Frame 240) to the server immediately after the ACK packet (Frame 239).

On the screenshots below:

• Red border = packets sent by the client
• Blue border = packets sent by the server

Example 3: TLS v1.2 handshake + secured HTTPS application data

The TLS (Transport Layer Security) protocol is an application-layer security protocol used for encrypting data sent by other application-layer protocols such as HTTP, SMTP, and FTP.

When it encrypts HTTPS data (can be HTTP/1.1 or HTTP/2), it uses the TCP 443 port for the transfer. So, when you see a TLS packet in Wireshark that connects to the server's TCP 443 port, it hides either HTTP/1.1 or HTTP/2 data that you can't see by default — to read the encrypted data you need to decrypt the TLS packet (for which, you'll need the appropriate session keys).

TLS currently has two versions in use: TLS v1.2 and TLS v1.3 — the newer version coming with significant performance and security improvements.

First, let's see what the TLS v1.2 handshake looks like in Wireshark.

The TLS handshake starts immediately after the TCP handshake successfully finishes and the TCP socket between the client and the server is opened. The authentication process takes two full round-trips (one trip can include more than one frame — see how packet reassembly works in Wireshark).

The client can send the first application-layer HTTP request (Frame 6113) only after the third round-trip (one for the TCP handshake, two for the TLS v1.2 handshake).

See the detailed breakdown of the TLS v1.2 handshake on TheSecMaster.

Example 4: TLS v1.3 handshake + secured HTTPS application data

In TLS v1.3, the TLS handshake requires fewer messages between the client and server — it only takes one round-trip.

As you can see below, the client immediately sends the first HTTP request (Frame 340) once the 'Server Hello' message and the cipher spec and other server data arrive and the server starts encrypting the data (Frame 339).

See the detailed breakdown of the TLS v1.3 handshake on TheSecMaster.

Example 5: TLS v1.3 handshake with 0-RTT resumption

TLS v1.3 also has a 0-RTT (Zero Round-Trip Time or 'early data') feature that allows the client to send an HTTP request on the first flight on connections it has previously established with the server.

Example 6: UDP + QUIC with 0-RTT + HTTP/3 data

QUIC is a new-ish communication protocol (standardized in 2021, but it's already widely used) that runs on top of UDP and serves as the transport-layer protocol for HTTP/3 (+ some new application-layer protocols also use QUIC).

As QUIC includes the TLS v1.3 security protocol, it can be used to set up a fully encrypted 0-RTT connection between the client and server (QUIC encrypts more data than TLS v1.3).

Data sent with QUIC is always encrypted. If it uses the server's UDP 443 port for the connection and you see the 'Protected Payload' info in Wireshark, then it hides HTTP/3 application data — to read its contents, you need to decrypt the packet in Wireshark using the belonging cryptographic session keys.

Here are the details of the UDP header belonging to Frame 126 above. As you can see, the header is just 8 bytes: 2 bytes for the source port data in hex dump format (d8 e1), 2 bytes for the destination port (01 bb), 2 bytes for the length (05 55), and 2 bytes for the checksum (f4 39).

It transports a protected QUIC payload of 1357 bytes in total, split into three parts. This is because it's the first frame in the stream that includes different types of data — you can see the details if you expand each part in the Packet Details pane. However, most frames transport the QUIC payload in one part.

Conclusion & resources

This two-part article was a very brief intro to the theory and practice of network packet analysis and communication protocols.

It discussed:

• the composition of a network packet in theory
• the TCP/IP model and its four layers
• the step-by-step process of how an HTTP request takes place on the network
• the detailed breakdown of a Wireshark capture
• examples of UDP-DNS, TCP-HTTP/1.1, TCP-TLSv1.2-HTTPS, TCP-TLSv1.3-HTTPS (with and without 0-RTT), and UDP-QUIC-HTTP/3 packet captures

To learn more about the subject, here are some useful resources too:

Wireshark filters

• Epic List of Top Searched Wireshark Display Filters by Chase Smith on NetworkProGuide
• Top 10 Wireshark Filters by Chris Greer on NetworkDataPedia

Recommended videos

• How to decrypt HTTPS traffic with Wireshark on Chris Greer's YouTube channel

Recommended articles

• Key differences between TLS 1.2 and TLS 1.3 in A10 Network's Glossary of Terms

On this blog

• Network packet analysis – Part I: Theory – A brief intro to TCP/IP layers, protocols, packets, and internet communication overall
• The most important RFCs to understand HTTP/3 and QUIC – A non-comprehensive collection of specifications related to HTTP and the underlying security and transport-layer protocols