Packet Structure — Protocol Analysis | OneNoughtOne

0/107

Computer NetworksProtocol Analysis

Protocol Analysis

LevelAdvanced

Duration90 mins

TopicProtocol Analysis

3 / 5

Packet Structure

The Anatomy of Network Communication

Every byte that traverses a network is part of a carefully structured message. From the Ethernet preamble that synchronizes receivers to the TCP sequence number that enables reliable delivery, packet structure is the vocabulary of network communication. Understanding this structure at the field level is what separates network engineers from network users. Packet analysis is the skill of reading raw bytes and understanding their meaning—identifying protocols, extracting addresses, diagnosing errors, and even detecting attacks. With tools like Wireshark, tcpdump, or a raw hex dump, a skilled analyst can reconstruct exactly what happened on a network, byte by byte. This page provides an exhaustive guide to packet structure across all major protocols, from physical framing through application headers. By the end, you will be able to examine any network capture and confidently interpret its contents.

What You Will Learn

By the end of this page, you will understand: (1) Ethernet frame structure and MAC addressing, (2) IPv4 and IPv6 packet headers field-by-field, (3) TCP segment structure including options, (4) UDP datagram format, (5) Common application protocol headers, and (6) Practical packet analysis techniques.

Ethernet Frame Structure

The Ethernet frame (IEEE 802.3) is the fundamental unit of data transmission on wired LANs. Every IP packet, every TCP segment, every HTTP request travels encapsulated within Ethernet frames on local networks. Complete Ethernet Frame Structure:

ethernet-frame-structure.txt
┌─────────────────────────────────────────────────────────────────────────────┐
│                         ETHERNET FRAME STRUCTURE                            │
├─────────────────────────────────────────────────────────────────────────────┤
│  Field              │ Size      │ Description                              │
├─────────────────────┼───────────┼──────────────────────────────────────────┤
│  Preamble           │ 7 bytes   │ Alternating 10101010... for clock sync   │
│  SFD (Start Frame   │ 1 byte    │ 10101011 - signals frame start           │
│       Delimiter)    │           │                                          │
├─────────────────────┼───────────┼──────────────────────────────────────────┤
│  Destination MAC    │ 6 bytes   │ Recipient hardware address               │
│  Source MAC         │ 6 bytes   │ Sender hardware address                  │
│  EtherType/Length   │ 2 bytes   │ Protocol (≥1536) or length (≤1500)       │
├─────────────────────┼───────────┼──────────────────────────────────────────┤
│  Payload            │ 46-1500   │ IP packet or other upper layer data      │
│                     │ bytes     │ (padded if < 46 bytes)                   │
├─────────────────────┼───────────┼──────────────────────────────────────────┤
│  FCS (Frame Check   │ 4 bytes   │ CRC-32 for error detection               │
│       Sequence)     │           │                                          │
└─────────────────────┴───────────┴──────────────────────────────────────────┘
 
TOTAL: 64-1518 bytes (without preamble/SFD typically counted in captures)
       18 bytes overhead + 46-1500 bytes payload
 
Note: 802.1Q VLAN tag adds 4 bytes between Source MAC and EtherType

Common EtherType Values
EtherType (hex)	Protocol	Description
0x0800	IPv4	Internet Protocol version 4
0x86DD	IPv6	Internet Protocol version 6
0x0806	ARP	Address Resolution Protocol
0x8100	802.1Q	VLAN tagged frame
0x8847	MPLS	MPLS unicast
0x88CC	LLDP	Link Layer Discovery Protocol
0x8863/0x8864	PPPoE	PPP over Ethernet (Discovery/Session)

MAC Address Format: MAC (Media Access Control) addresses are 48-bit identifiers: AA:BB:CC:DD:EE:FF └──┬──┘ └──┬──┘ OUI NIC-specific OUI (Organizationally Unique Identifier) : First 3 bytes, assigned to manufacturers by IEEE NIC-specific : Last 3 bytes, assigned by manufacturing vendor Special MAC addresses: FF:FF:FF:FF:FF:FF — Broadcast (all hosts on segment) 01:00:5E:xx:xx:xx — IPv4 multicast 33:33:xx:xx:xx:xx — IPv6 multicast Bit 0 of first byte = 1 indicates multicast Bit 1 of first byte = 1 indicates locally administered

Jumbo Frames

Standard Ethernet limits payload to 1500 bytes (MTU). Jumbo frames extend this to 9000+ bytes for high-performance environments (storage networks, cluster interconnects). They reduce overhead and CPU interrupts but require end-to-end support—a single non-jumbo link will fragment traffic.

IPv4 Packet Header: Field-by-Field Analysis

The IPv4 header is the workhorse of Internet routing. Despite its age (RFC 791, 1981), it remains the dominant network layer protocol. Understanding every field is essential for packet analysis.

ipv4-header-structure.txt
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options (if IHL > 5)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Minimum header size: 20 bytes (IHL = 5)
Maximum header size: 60 bytes (IHL = 15)

IPv4 Header Fields Explained
Field	Bits	Description	Typical Values
Version	4	IP version number	4 (for IPv4)
IHL (Header Length)	4	Header length in 32-bit words	5 (no options) to 15
Type of Service / DSCP+ECN	8	QoS marking (DSCP 6 bits, ECN 2 bits)	0x00 (best effort), varies
Total Length	16	Entire packet size in bytes	20-65535
Identification	16	Fragment identification	Random/sequential
Flags	3	DF (Don't Fragment), MF (More Fragments)	0x02 (DF set, typical)
Fragment Offset	13	Offset in 8-byte units	0 (unfragmented)
Time to Live (TTL)	8	Hop limit	64, 128, 255 common
Protocol	8	Upper layer protocol	6 (TCP), 17 (UDP), 1 (ICMP)
Header Checksum	16	Header integrity check	Calculated per-hop
Source Address	32	Sender's IP address	192.168.1.100, etc.
Destination Address	32	Recipient's IP address	93.184.216.34, etc.

Critical Fields in Detail: TTL (Time to Live): Despite its name, TTL is a hop count, not time. Each router decrements TTL by 1. When TTL reaches 0, the packet is discarded and ICMP Time Exceeded is sent. This prevents routing loops. Traceroute works by sending packets with increasing TTLs. Protocol Field: Identifies the encapsulated payload: 1 = ICMP 6 = TCP 17 = UDP 47 = GRE 50 = ESP (IPsec) 51 = AH (IPsec) 89 = OSPF Fragmentation: When an IP packet exceeds a link's MTU, it may be fragmented. The Identification field groups fragments; Fragment Offset indicates position; MF (More Fragments) flag indicates if more follow. IPv6 eliminates router fragmentation—only the source may fragment.

IP Fragmentation is Problematic

IP fragmentation has security implications (fragment overlap attacks), performance costs (all fragments must arrive), and firewall complications (only first fragment has port numbers). Modern best practice uses Path MTU Discovery to avoid fragmentation entirely. The DF (Don't Fragment) bit is commonly set.

IPv6 Packet Header: The Modern Alternative

The IPv6 header was designed to address IPv4's limitations: address exhaustion, header complexity, and the need for extension mechanisms. It is simpler despite supporting larger addresses. Key design improvements: Fixed 40-byte base header (no variable options in base header) Extension headers instead of options field No checksum (left to upper layers) No in-network fragmentation

ipv6-header-structure.txt
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                         (128 bits)                            +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                         (128 bits)                            +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Fixed header size: 40 bytes (always)

IPv6 Header Fields Explained
Field	Bits	Description	Notes
Version	4	IP version number	6 (for IPv6)
Traffic Class	8	QoS marking (DSCP + ECN)	Same semantics as IPv4 ToS
Flow Label	20	Flow identification for QoS	Optional, set by source
Payload Length	16	Payload size in bytes	Does NOT include 40-byte header
Next Header	8	Next header type	Same values as IPv4 Protocol field
Hop Limit	8	Hop count limit	Equivalent to IPv4 TTL
Source Address	128	Sender's IPv6 address	2001:db8::1, etc.
Destination Address	128	Recipient's IPv6 address	2001:db8::2, etc.

Extension Headers: IPv6 uses extension headers for optional functionality, chained via the Next Header field:

Next Header Value	Type	Purpose
0	Hop-by-Hop Options	Options processed at each hop
43	Routing	Source routing specification
44	Fragment	Fragmentation information
50	ESP	Encapsulating Security Payload
51	AH	Authentication Header
60	Destination Options	Options for destination only
59	No Next Header	Payload ends here

Extension header chain example: IPv6 Header (Next Header = 44) \to Fragment Header (Next Header = 6) \to TCP Segment

IPv6 Address Representation

IPv6 addresses are written as eight 16-bit groups in hexadecimal: 2001:0db8:0000:0000:0000:0000:0000:0001. Leading zeros within groups can be omitted, and consecutive groups of zeros can be replaced with :: once. Thus: 2001:db8::1. Understanding this notation is essential for packet analysis.

TCP Segment Structure: Reliable Transport Anatomy

TCP (Transmission Control Protocol) provides reliable, ordered, byte-stream communication. Its header is rich with state information—understanding each field is essential for troubleshooting connection issues, diagnosing performance problems, and analyzing application behavior.

tcp-header-structure.txt
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Data |       |C|E|U|A|P|R|S|F|                               |
| Offset| Rsrvd |W|C|R|C|S|S|Y|I|            Window             |
|       |       |R|E|G|K|H|T|N|N|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |         Urgent Pointer        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options (if Data Offset > 5)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Data                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Minimum header size: 20 bytes
Maximum header size: 60 bytes

TCP Header Fields Explained
Field	Bits	Description
Source Port	16	Sending application port (ephemeral 49152-65535 for clients)
Destination Port	16	Receiving application port (well-known 0-1023 for servers)
Sequence Number	32	Byte offset of first data byte in this segment
Acknowledgment Number	32	Next expected byte from peer (if ACK flag set)
Data Offset	4	Header length in 32-bit words (5-15)
Flags	9	Control flags (see below)
Window	16	Receive window size in bytes (scaled with Window Scale option)
Checksum	16	Header + data integrity check (includes pseudo-header)
Urgent Pointer	16	Offset of urgent data (if URG flag set)

TCP Flags in Detail:

Flag	Name	Meaning
SYN	Synchronize	Initiating connection, contains ISN
ACK	Acknowledge	Acknowledgment number field is valid
FIN	Finish	Sender has finished sending data
RST	Reset	Connection abort / error
PSH	Push	Receiver should deliver data immediately
URG	Urgent	Urgent pointer field is valid
ECE	ECN-Echo	Echoes CE (Congestion Experienced)
CWR	Congestion Window Reduced	Sender reduced congestion window
NS	ECN-nonce	Experimental nonce protection

Common flag combinations: [SYN] — Connection initiation (first packet of 3-way handshake) [SYN, ACK] — Connection acceptance (second packet) [ACK] — Acknowledgment (data flow, third packet of handshake) [FIN, ACK] — Connection termination [RST] — Connection reset (error, rejection) [PSH, ACK] — Data with immediate delivery request

Critical TCP Options

•MSS (Maximum Segment Size) — Largest segment sender can receive. Negotiated during handshake. Prevents fragmentation.
•Window Scale — Multiplier for Window field (2^scale). Enables windows > 65535 bytes. Essential for high-bandwidth networks.
•SACK (Selective Acknowledgment) — Allows acknowledging non-contiguous data. Improves retransmission efficiency.
•Timestamps — Used for RTT measurement and PAWS (Protection Against Wrapped Sequences). Two 32-bit values.
•No-Operation (NOP) — Padding for option alignment.
•End of Option List (EOL) — Marks end of options section.

Analyzing TCP in Wireshark

Wireshark's 'Statistics \to TCP Stream Graphs' provides powerful visualization of sequence numbers, round-trip times, throughput, and window scaling. The 'tcp.analysis' expert info highlights retransmissions, duplicate ACKs, and other anomalies. Mastering these tools accelerates TCP troubleshooting significantly.

UDP Datagram Structure: Lightweight Transport

UDP (User Datagram Protocol) provides minimal transport services—just port multiplexing and optional integrity checking. Its simplicity is its strength: no connection state, no retransmission logic, no ordering guarantees—just fast, lightweight datagram delivery.

udp-header-structure.txt
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Length             |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Data                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Fixed header size: 8 bytes (always)

UDP Header Fields
Field	Bits	Description	Notes
Source Port	16	Sending application port	Optional (can be 0)
Destination Port	16	Receiving application port	Required
Length	16	Total datagram size (header + data)	Minimum 8 bytes
Checksum	16	Integrity check	Optional in IPv4, mandatory in IPv6

UDP Advantages

•No connection establishment delay
•No per-connection state
•Small header overhead (8 bytes)
•Supports broadcast and multicast
•Application controls retransmission
•No head-of-line blocking

UDP Limitations

•No delivery guarantee
•No ordering guarantee
•No congestion control (by default)
•No flow control
•Application must handle reliability
•Often filtered by firewalls

Common UDP Applications:

Port	Protocol	Why UDP?
53	DNS	Fast queries; reliability at application layer
67/68	DHCP	Broadcast required; no existing IP address
123	NTP	Real-time accuracy more important than reliability
161/162	SNMP	Simple queries; traps are best-effort
500/4500	IKE/IPsec	Tunneling; reliability at IPsec layer
5060	SIP	Real-time signaling; TCP also used
Various	VoIP/RTP	Real-time media; late packets are useless
Various	Games	Latency-critical; state updates are frequent

UDP Checksum Calculation

Like TCP, UDP checksum includes a 'pseudo-header' containing IP source/destination addresses and protocol number. This binds the UDP datagram to its IP context, catching misdelivery. In IPv4, checksum is optional (0 means not computed); in IPv6, it's mandatory due to removal of IP header checksum.

ICMP Message Structure: Network Diagnostics

ICMP (Internet Control Message Protocol) provides error reporting and diagnostics for IP. It's the protocol behind ping and traceroute . Unlike TCP/UDP, ICMP operates at the network layer alongside IP.

icmp-header-structure.txt
ICMP HEADER (Minimum 8 bytes)
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Type-specific                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
ECHO REQUEST/REPLY (Type 8/0):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Identifier          |        Sequence Number        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Data ...                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Common ICMP Types (IPv4)
Type	Name	Codes	Purpose
0	Echo Reply	0	Response to ping
3	Destination Unreachable	0-15	Packet delivery failed
4	Source Quench	0	Congestion (deprecated)
5	Redirect	0-3	Better route available
8	Echo Request	0	Ping request
11	Time Exceeded	0-1	TTL expired or fragment reassembly timeout
12	Parameter Problem	0-2	Invalid header field

Destination Unreachable Codes (Type 3):

Code	Meaning	Typical Cause
0	Network Unreachable	No route to network
1	Host Unreachable	ARP failure, host down
2	Protocol Unreachable	No handler for protocol
3	Port Unreachable	No listener on UDP port
4	Fragmentation Needed	DF set, MTU exceeded
5	Source Route Failed	Source routing not supported
13	Administratively Prohibited	Firewall blocked packet

ICMPv6 Differences: ICMPv6 (RFC 4443) has additional responsibilities including Neighbor Discovery (like ARP for IPv6), Router Discovery, and Path MTU Discovery. It uses different type numbers: Echo Request is 128, Echo Reply is 129.

ICMP Security Considerations

ICMP can be abused for reconnaissance (ping sweeps), denial of service (ICMP floods), and covert channels. Many networks filter ICMP—especially inbound Echo Requests. However, blocking ALL ICMP breaks Path MTU Discovery (Type 3 Code 4) and other essential functions. Selective filtering is recommended.

Application Protocol Headers: HTTP and DNS Examples

Application layer protocols have their own header structures, though they're often text-based (HTTP) or have variable formats (DNS). Understanding these structures enables deep packet inspection and application-level troubleshooting. HTTP Request Structure:

http-request-structure.txt
GET /path/to/resource HTTP/1.1\r
     ← Request line
Host: www.example.com\r
               ← Required header
User-Agent: Mozilla/5.0 ...\r
         ← Client identification
Accept: text/html,application/xml\r
   ← Acceptable content types
Accept-Language: en-US,en\r
           ← Preferred languages
Accept-Encoding: gzip, deflate\r
      ← Compression support
Connection: keep-alive\r
              ← Connection preference
Cookie: session=abc123\r
              ← Session state
\r
                                     ← Empty line (end of headers)
[Request body if POST/PUT]               ← Optional payload
 
HTTP RESPONSE:
HTTP/1.1 200 OK\r
                     ← Status line
Date: Tue, 17 Jan 2026 12:00:00 GMT\r
 ← Response timestamp
Server: nginx/1.18.0\r
                ← Server identification
Content-Type: text/html; charset=utf-8\r
 ← Payload type
Content-Length: 3842\r
                ← Body size in bytes
Cache-Control: max-age=3600\r
         ← Caching directive
\r
                                     ← End of headers
<!DOCTYPE html>...                       ← Response body

DNS Message Structure:

dns-message-structure.txt
DNS MESSAGE FORMAT:
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Transaction ID        |             Flags             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Question Count        |          Answer Count         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Authority Count          |        Additional Count       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Questions                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Answers                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Authority                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Additional                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
FLAGS BREAKDOWN (16 bits):
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|   Opcode  |AA|TC|RD|RA|Z |AD|CD|   RCODE   |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 
QR: 0=Query, 1=Response
Opcode: 0=Standard, 1=Inverse, 2=Status
AA: Authoritative Answer
TC: Truncated (use TCP)
RD: Recursion Desired
RA: Recursion Available
RCODE: 0=OK, 3=NXDOMAIN, 5=Refused

Packet Capture Best Practices

When capturing packets: (1) Filter early to reduce capture size (capture filters vs. display filters), (2) Capture at the right point—client, server, or transit, (3) Consider encryption—TLS traffic requires keys for decryption, (4) Capture enough context—include connection setup, not just the problem packet, (5) Use ring buffers for continuous capture with limited disk.

Computer NetworksProtocol Analysis

Protocol Analysis

LevelAdvanced

Duration90 mins

TopicProtocol Analysis

3 / 5

Packet Structure

The Anatomy of Network Communication

Every byte that traverses a network is part of a carefully structured message. From the Ethernet preamble that synchronizes receivers to the TCP sequence number that enables reliable delivery, packet structure is the vocabulary of network communication. Understanding this structure at the field level is what separates network engineers from network users. Packet analysis is the skill of reading raw bytes and understanding their meaning—identifying protocols, extracting addresses, diagnosing errors, and even detecting attacks. With tools like Wireshark, tcpdump, or a raw hex dump, a skilled analyst can reconstruct exactly what happened on a network, byte by byte. This page provides an exhaustive guide to packet structure across all major protocols, from physical framing through application headers. By the end, you will be able to examine any network capture and confidently interpret its contents.

What You Will Learn

By the end of this page, you will understand: (1) Ethernet frame structure and MAC addressing, (2) IPv4 and IPv6 packet headers field-by-field, (3) TCP segment structure including options, (4) UDP datagram format, (5) Common application protocol headers, and (6) Practical packet analysis techniques.

Ethernet Frame Structure

The Ethernet frame (IEEE 802.3) is the fundamental unit of data transmission on wired LANs. Every IP packet, every TCP segment, every HTTP request travels encapsulated within Ethernet frames on local networks. Complete Ethernet Frame Structure:

ethernet-frame-structure.txt
┌─────────────────────────────────────────────────────────────────────────────┐
│                         ETHERNET FRAME STRUCTURE                            │
├─────────────────────────────────────────────────────────────────────────────┤
│  Field              │ Size      │ Description                              │
├─────────────────────┼───────────┼──────────────────────────────────────────┤
│  Preamble           │ 7 bytes   │ Alternating 10101010... for clock sync   │
│  SFD (Start Frame   │ 1 byte    │ 10101011 - signals frame start           │
│       Delimiter)    │           │                                          │
├─────────────────────┼───────────┼──────────────────────────────────────────┤
│  Destination MAC    │ 6 bytes   │ Recipient hardware address               │
│  Source MAC         │ 6 bytes   │ Sender hardware address                  │
│  EtherType/Length   │ 2 bytes   │ Protocol (≥1536) or length (≤1500)       │
├─────────────────────┼───────────┼──────────────────────────────────────────┤
│  Payload            │ 46-1500   │ IP packet or other upper layer data      │
│                     │ bytes     │ (padded if < 46 bytes)                   │
├─────────────────────┼───────────┼──────────────────────────────────────────┤
│  FCS (Frame Check   │ 4 bytes   │ CRC-32 for error detection               │
│       Sequence)     │           │                                          │
└─────────────────────┴───────────┴──────────────────────────────────────────┘
 
TOTAL: 64-1518 bytes (without preamble/SFD typically counted in captures)
       18 bytes overhead + 46-1500 bytes payload
 
Note: 802.1Q VLAN tag adds 4 bytes between Source MAC and EtherType

Common EtherType Values
EtherType (hex)	Protocol	Description
0x0800	IPv4	Internet Protocol version 4
0x86DD	IPv6	Internet Protocol version 6
0x0806	ARP	Address Resolution Protocol
0x8100	802.1Q	VLAN tagged frame
0x8847	MPLS	MPLS unicast
0x88CC	LLDP	Link Layer Discovery Protocol
0x8863/0x8864	PPPoE	PPP over Ethernet (Discovery/Session)

MAC Address Format: MAC (Media Access Control) addresses are 48-bit identifiers: AA:BB:CC:DD:EE:FF └──┬──┘ └──┬──┘ OUI NIC-specific OUI (Organizationally Unique Identifier) : First 3 bytes, assigned to manufacturers by IEEE NIC-specific : Last 3 bytes, assigned by manufacturing vendor Special MAC addresses: FF:FF:FF:FF:FF:FF — Broadcast (all hosts on segment) 01:00:5E:xx:xx:xx — IPv4 multicast 33:33:xx:xx:xx:xx — IPv6 multicast Bit 0 of first byte = 1 indicates multicast Bit 1 of first byte = 1 indicates locally administered

Jumbo Frames

Standard Ethernet limits payload to 1500 bytes (MTU). Jumbo frames extend this to 9000+ bytes for high-performance environments (storage networks, cluster interconnects). They reduce overhead and CPU interrupts but require end-to-end support—a single non-jumbo link will fragment traffic.

IPv4 Packet Header: Field-by-Field Analysis

The IPv4 header is the workhorse of Internet routing. Despite its age (RFC 791, 1981), it remains the dominant network layer protocol. Understanding every field is essential for packet analysis.

ipv4-header-structure.txt
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options (if IHL > 5)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Minimum header size: 20 bytes (IHL = 5)
Maximum header size: 60 bytes (IHL = 15)

IPv4 Header Fields Explained
Field	Bits	Description	Typical Values
Version	4	IP version number	4 (for IPv4)
IHL (Header Length)	4	Header length in 32-bit words	5 (no options) to 15
Type of Service / DSCP+ECN	8	QoS marking (DSCP 6 bits, ECN 2 bits)	0x00 (best effort), varies
Total Length	16	Entire packet size in bytes	20-65535
Identification	16	Fragment identification	Random/sequential
Flags	3	DF (Don't Fragment), MF (More Fragments)	0x02 (DF set, typical)
Fragment Offset	13	Offset in 8-byte units	0 (unfragmented)
Time to Live (TTL)	8	Hop limit	64, 128, 255 common
Protocol	8	Upper layer protocol	6 (TCP), 17 (UDP), 1 (ICMP)
Header Checksum	16	Header integrity check	Calculated per-hop
Source Address	32	Sender's IP address	192.168.1.100, etc.
Destination Address	32	Recipient's IP address	93.184.216.34, etc.

Critical Fields in Detail: TTL (Time to Live): Despite its name, TTL is a hop count, not time. Each router decrements TTL by 1. When TTL reaches 0, the packet is discarded and ICMP Time Exceeded is sent. This prevents routing loops. Traceroute works by sending packets with increasing TTLs. Protocol Field: Identifies the encapsulated payload: 1 = ICMP 6 = TCP 17 = UDP 47 = GRE 50 = ESP (IPsec) 51 = AH (IPsec) 89 = OSPF Fragmentation: When an IP packet exceeds a link's MTU, it may be fragmented. The Identification field groups fragments; Fragment Offset indicates position; MF (More Fragments) flag indicates if more follow. IPv6 eliminates router fragmentation—only the source may fragment.

IP Fragmentation is Problematic

IP fragmentation has security implications (fragment overlap attacks), performance costs (all fragments must arrive), and firewall complications (only first fragment has port numbers). Modern best practice uses Path MTU Discovery to avoid fragmentation entirely. The DF (Don't Fragment) bit is commonly set.

IPv6 Packet Header: The Modern Alternative

The IPv6 header was designed to address IPv4's limitations: address exhaustion, header complexity, and the need for extension mechanisms. It is simpler despite supporting larger addresses. Key design improvements: Fixed 40-byte base header (no variable options in base header) Extension headers instead of options field No checksum (left to upper layers) No in-network fragmentation

ipv6-header-structure.txt
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                         (128 bits)                            +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                         (128 bits)                            +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Fixed header size: 40 bytes (always)

IPv6 Header Fields Explained
Field	Bits	Description	Notes
Version	4	IP version number	6 (for IPv6)
Traffic Class	8	QoS marking (DSCP + ECN)	Same semantics as IPv4 ToS
Flow Label	20	Flow identification for QoS	Optional, set by source
Payload Length	16	Payload size in bytes	Does NOT include 40-byte header
Next Header	8	Next header type	Same values as IPv4 Protocol field
Hop Limit	8	Hop count limit	Equivalent to IPv4 TTL
Source Address	128	Sender's IPv6 address	2001:db8::1, etc.
Destination Address	128	Recipient's IPv6 address	2001:db8::2, etc.

Extension Headers: IPv6 uses extension headers for optional functionality, chained via the Next Header field:

Next Header Value	Type	Purpose
0	Hop-by-Hop Options	Options processed at each hop
43	Routing	Source routing specification
44	Fragment	Fragmentation information
50	ESP	Encapsulating Security Payload
51	AH	Authentication Header
60	Destination Options	Options for destination only
59	No Next Header	Payload ends here

Extension header chain example: IPv6 Header (Next Header = 44) \to Fragment Header (Next Header = 6) \to TCP Segment

IPv6 Address Representation

IPv6 addresses are written as eight 16-bit groups in hexadecimal: 2001:0db8:0000:0000:0000:0000:0000:0001. Leading zeros within groups can be omitted, and consecutive groups of zeros can be replaced with :: once. Thus: 2001:db8::1. Understanding this notation is essential for packet analysis.

TCP Segment Structure: Reliable Transport Anatomy

TCP (Transmission Control Protocol) provides reliable, ordered, byte-stream communication. Its header is rich with state information—understanding each field is essential for troubleshooting connection issues, diagnosing performance problems, and analyzing application behavior.

tcp-header-structure.txt
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Data |       |C|E|U|A|P|R|S|F|                               |
| Offset| Rsrvd |W|C|R|C|S|S|Y|I|            Window             |
|       |       |R|E|G|K|H|T|N|N|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |         Urgent Pointer        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options (if Data Offset > 5)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Data                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Minimum header size: 20 bytes
Maximum header size: 60 bytes

TCP Header Fields Explained
Field	Bits	Description
Source Port	16	Sending application port (ephemeral 49152-65535 for clients)
Destination Port	16	Receiving application port (well-known 0-1023 for servers)
Sequence Number	32	Byte offset of first data byte in this segment
Acknowledgment Number	32	Next expected byte from peer (if ACK flag set)
Data Offset	4	Header length in 32-bit words (5-15)
Flags	9	Control flags (see below)
Window	16	Receive window size in bytes (scaled with Window Scale option)
Checksum	16	Header + data integrity check (includes pseudo-header)
Urgent Pointer	16	Offset of urgent data (if URG flag set)

TCP Flags in Detail:

Flag	Name	Meaning
SYN	Synchronize	Initiating connection, contains ISN
ACK	Acknowledge	Acknowledgment number field is valid
FIN	Finish	Sender has finished sending data
RST	Reset	Connection abort / error
PSH	Push	Receiver should deliver data immediately
URG	Urgent	Urgent pointer field is valid
ECE	ECN-Echo	Echoes CE (Congestion Experienced)
CWR	Congestion Window Reduced	Sender reduced congestion window
NS	ECN-nonce	Experimental nonce protection

Common flag combinations: [SYN] — Connection initiation (first packet of 3-way handshake) [SYN, ACK] — Connection acceptance (second packet) [ACK] — Acknowledgment (data flow, third packet of handshake) [FIN, ACK] — Connection termination [RST] — Connection reset (error, rejection) [PSH, ACK] — Data with immediate delivery request

Critical TCP Options

•MSS (Maximum Segment Size) — Largest segment sender can receive. Negotiated during handshake. Prevents fragmentation.
•Window Scale — Multiplier for Window field (2^scale). Enables windows > 65535 bytes. Essential for high-bandwidth networks.
•SACK (Selective Acknowledgment) — Allows acknowledging non-contiguous data. Improves retransmission efficiency.
•Timestamps — Used for RTT measurement and PAWS (Protection Against Wrapped Sequences). Two 32-bit values.
•No-Operation (NOP) — Padding for option alignment.
•End of Option List (EOL) — Marks end of options section.

Analyzing TCP in Wireshark

Wireshark's 'Statistics \to TCP Stream Graphs' provides powerful visualization of sequence numbers, round-trip times, throughput, and window scaling. The 'tcp.analysis' expert info highlights retransmissions, duplicate ACKs, and other anomalies. Mastering these tools accelerates TCP troubleshooting significantly.

UDP Datagram Structure: Lightweight Transport

UDP (User Datagram Protocol) provides minimal transport services—just port multiplexing and optional integrity checking. Its simplicity is its strength: no connection state, no retransmission logic, no ordering guarantees—just fast, lightweight datagram delivery.

udp-header-structure.txt
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Length             |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Data                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Fixed header size: 8 bytes (always)

UDP Header Fields
Field	Bits	Description	Notes
Source Port	16	Sending application port	Optional (can be 0)
Destination Port	16	Receiving application port	Required
Length	16	Total datagram size (header + data)	Minimum 8 bytes
Checksum	16	Integrity check	Optional in IPv4, mandatory in IPv6

UDP Advantages

•No connection establishment delay
•No per-connection state
•Small header overhead (8 bytes)
•Supports broadcast and multicast
•Application controls retransmission
•No head-of-line blocking

UDP Limitations

•No delivery guarantee
•No ordering guarantee
•No congestion control (by default)
•No flow control
•Application must handle reliability
•Often filtered by firewalls

Common UDP Applications:

Port	Protocol	Why UDP?
53	DNS	Fast queries; reliability at application layer
67/68	DHCP	Broadcast required; no existing IP address
123	NTP	Real-time accuracy more important than reliability
161/162	SNMP	Simple queries; traps are best-effort
500/4500	IKE/IPsec	Tunneling; reliability at IPsec layer
5060	SIP	Real-time signaling; TCP also used
Various	VoIP/RTP	Real-time media; late packets are useless
Various	Games	Latency-critical; state updates are frequent

UDP Checksum Calculation

Like TCP, UDP checksum includes a 'pseudo-header' containing IP source/destination addresses and protocol number. This binds the UDP datagram to its IP context, catching misdelivery. In IPv4, checksum is optional (0 means not computed); in IPv6, it's mandatory due to removal of IP header checksum.

ICMP Message Structure: Network Diagnostics

ICMP (Internet Control Message Protocol) provides error reporting and diagnostics for IP. It's the protocol behind ping and traceroute . Unlike TCP/UDP, ICMP operates at the network layer alongside IP.

icmp-header-structure.txt
ICMP HEADER (Minimum 8 bytes)
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Type-specific                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
ECHO REQUEST/REPLY (Type 8/0):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Identifier          |        Sequence Number        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Data ...                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Common ICMP Types (IPv4)
Type	Name	Codes	Purpose
0	Echo Reply	0	Response to ping
3	Destination Unreachable	0-15	Packet delivery failed
4	Source Quench	0	Congestion (deprecated)
5	Redirect	0-3	Better route available
8	Echo Request	0	Ping request
11	Time Exceeded	0-1	TTL expired or fragment reassembly timeout
12	Parameter Problem	0-2	Invalid header field

Destination Unreachable Codes (Type 3):

Code	Meaning	Typical Cause
0	Network Unreachable	No route to network
1	Host Unreachable	ARP failure, host down
2	Protocol Unreachable	No handler for protocol
3	Port Unreachable	No listener on UDP port
4	Fragmentation Needed	DF set, MTU exceeded
5	Source Route Failed	Source routing not supported
13	Administratively Prohibited	Firewall blocked packet

ICMPv6 Differences: ICMPv6 (RFC 4443) has additional responsibilities including Neighbor Discovery (like ARP for IPv6), Router Discovery, and Path MTU Discovery. It uses different type numbers: Echo Request is 128, Echo Reply is 129.

ICMP Security Considerations

ICMP can be abused for reconnaissance (ping sweeps), denial of service (ICMP floods), and covert channels. Many networks filter ICMP—especially inbound Echo Requests. However, blocking ALL ICMP breaks Path MTU Discovery (Type 3 Code 4) and other essential functions. Selective filtering is recommended.

Application Protocol Headers: HTTP and DNS Examples

Application layer protocols have their own header structures, though they're often text-based (HTTP) or have variable formats (DNS). Understanding these structures enables deep packet inspection and application-level troubleshooting. HTTP Request Structure:

http-request-structure.txt
GET /path/to/resource HTTP/1.1\r
     ← Request line
Host: www.example.com\r
               ← Required header
User-Agent: Mozilla/5.0 ...\r
         ← Client identification
Accept: text/html,application/xml\r
   ← Acceptable content types
Accept-Language: en-US,en\r
           ← Preferred languages
Accept-Encoding: gzip, deflate\r
      ← Compression support
Connection: keep-alive\r
              ← Connection preference
Cookie: session=abc123\r
              ← Session state
\r
                                     ← Empty line (end of headers)
[Request body if POST/PUT]               ← Optional payload
 
HTTP RESPONSE:
HTTP/1.1 200 OK\r
                     ← Status line
Date: Tue, 17 Jan 2026 12:00:00 GMT\r
 ← Response timestamp
Server: nginx/1.18.0\r
                ← Server identification
Content-Type: text/html; charset=utf-8\r
 ← Payload type
Content-Length: 3842\r
                ← Body size in bytes
Cache-Control: max-age=3600\r
         ← Caching directive
\r
                                     ← End of headers
<!DOCTYPE html>...                       ← Response body

DNS Message Structure:

dns-message-structure.txt
DNS MESSAGE FORMAT:
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Transaction ID        |             Flags             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Question Count        |          Answer Count         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Authority Count          |        Additional Count       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Questions                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Answers                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Authority                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Additional                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
FLAGS BREAKDOWN (16 bits):
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|   Opcode  |AA|TC|RD|RA|Z |AD|CD|   RCODE   |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 
QR: 0=Query, 1=Response
Opcode: 0=Standard, 1=Inverse, 2=Status
AA: Authoritative Answer
TC: Truncated (use TCP)
RD: Recursion Desired
RA: Recursion Available
RCODE: 0=OK, 3=NXDOMAIN, 5=Refused

Packet Capture Best Practices

When capturing packets: (1) Filter early to reduce capture size (capture filters vs. display filters), (2) Capture at the right point—client, server, or transit, (3) Consider encryption—TLS traffic requires keys for decryption, (4) Capture enough context—include connection setup, not just the problem packet, (5) Use ring buffers for continuous capture with limited disk.

Packet Structure

The Anatomy of Network Communication

Ethernet Frame Structure

IPv4 Packet Header: Field-by-Field Analysis

IPv6 Packet Header: The Modern Alternative

TCP Segment Structure: Reliable Transport Anatomy

UDP Datagram Structure: Lightweight Transport

ICMP Message Structure: Network Diagnostics

Application Protocol Headers: HTTP and DNS Examples

There’s more to understand.

Packet Structure

The Anatomy of Network Communication

Ethernet Frame Structure

IPv4 Packet Header: Field-by-Field Analysis

IPv6 Packet Header: The Modern Alternative

TCP Segment Structure: Reliable Transport Anatomy

UDP Datagram Structure: Lightweight Transport

ICMP Message Structure: Network Diagnostics

Application Protocol Headers: HTTP and DNS Examples

There’s more to understand.