Applications exchange meaningful data such as HTTP requests, DNS queries, and database commands. Network devices cannot forward those messages using application meaning alone. They need addresses, protocol identifiers, delivery state, integrity checks, and information about the current link.

Networking protocols add that control information in layers. A transport protocol wraps application data, IP wraps the transport unit, and a link protocol wraps the IP packet. The receiver removes the information in reverse order.

This process is called encapsulation and decapsulation.

Understanding the structure of the resulting data units makes packet captures easier to read and explains why the same transmission can be called application data, a segment, a packet, or a frame depending on which layer is being discussed.

Consider an HTTP request sent over TCP, IPv4, and Ethernet. The request moves down the sender's protocol stack:

Each lower layer treats the complete unit from the layer above as its payload.

The TCP segment carries application bytes as its payload. The IP packet carries the complete TCP segment as its payload. The Ethernet frame carries the complete IP packet as its payload.

This nested structure lets every layer attach the information needed for its own responsibility without changing what the higher-layer data means.

A protocol data unit, or PDU, is the unit of data handled by a protocol layer. Different layers use different names because their units have different structures and scopes.

The word packet is also used informally for almost any captured network unit. Context determines whether "packet" means an IP packet specifically or network traffic in general.

PDU boundaries are not always aligned. A single application message can span several TCP segments. One TCP segment can also contain bytes from more than one application message. TCP presents a byte stream and does not preserve application message boundaries.

UDP behaves differently. Each application write normally becomes one UDP datagram, and the receiver observes datagram boundaries. The datagram can still encounter size limits at lower layers.

Most protocol data units contain a header followed by a payload. Some also contain a trailer.

The header appears before the payload and carries control information. Depending on the protocol, it may include:

The payload contains data received from the layer above. A protocol usually treats this payload as bytes. It may identify the next protocol, but it does not need to understand the payload's application meaning.

A trailer appears after the payload. Ethernet uses a trailer containing a Frame Check Sequence, or FCS, to detect damage to the frame during local-link transmission.

The layered layout can be represented as:

This diagram shows logical nesting after the units have been placed on the wire. The exact bytes depend on the selected protocols, optional fields, and whether encryption or tunneling adds more layers.

Application data is the content a program intends to exchange. It often includes its own protocol headers.

An HTTP request contains an HTTP request line and headers:

These lines are application data from TCP's perspective. TCP does not interpret GET, Host, or the blank line that ends the HTTP header section. It delivers an ordered sequence of bytes.

The term header therefore depends on context. An HTTP header is application metadata, but the complete HTTP message becomes payload for TCP. A TCP header is transport metadata, and the complete TCP segment becomes payload for IP.

If TLS protects the connection, it transforms application bytes into TLS records before transport carries them. A packet capture can then expose TCP and IP headers while the HTTP method, path, headers, and body remain encrypted.

A TCP segment contains a TCP header followed by zero or more payload bytes.

The TCP header has a minimum size of 20 bytes and can be larger when options are present. Its main fields include:

Source and destination ports: Identify the sending and receiving transport endpoints.

Sequence number: Identifies where the segment's payload belongs in the TCP byte stream.

Acknowledgment number: Indicates the next byte the sender expects to receive from the other endpoint when acknowledgment is enabled.

Flags: Describe control events such as connection setup, acknowledgment, reset, and connection closure.

Window: Advertises how much data the receiver can currently accept.

Checksum: Detects corruption across the TCP header and payload, with selected IP information included in the calculation.

Options: Carry additional capabilities such as maximum segment size, timestamps, and selective acknowledgment information.

TCP may send a segment with no application payload. Connection-establishment and acknowledgment segments often consist primarily of header information.

A TCP segment does not represent a complete application operation. A 100 KB HTTP response will usually span many segments. The receiving TCP implementation reorders and combines delivered bytes before making them available to the application.

A UDP datagram has an 8-byte header followed by its payload. The header contains four fields:

The UDP length covers both header and payload. UDP adds less control information than TCP because it does not implement TCP-style connection management, acknowledgments, retransmission, ordering, or flow control.

The checksum protects the UDP header and payload using a calculation that also includes selected IP information. It is mandatory in IPv6. In IPv4, a zero checksum can indicate that checksum protection was not used, although normal applications should use it.

UDP preserves datagram boundaries. If an application sends two datagrams and both arrive, the receiving application observes two datagrams rather than one combined byte stream. Delivery is still best effort, so the IP network can lose, duplicate, or reorder them.

An IP packet contains an IP header and payload. The payload commonly holds a TCP segment, UDP datagram, ICMP message, or another encapsulated protocol.

IPv4

An IPv4 header is at least 20 bytes. Important fields include:

Version and header length: Identify IPv4 and the size of the header.

Total length: Gives the size of the entire IPv4 packet, including its header.

Identification, flags, and fragment offset: Support IPv4 fragmentation and reassembly.

Time to Live: Limits how many router hops the packet can survive. Each forwarding router reduces the value.

Protocol: Identifies the payload type, such as TCP, UDP, or ICMP.

Header checksum: Detects corruption in the IPv4 header. It does not cover the payload.

Source and destination addresses: Identify the IP endpoints.

IPv4 options can increase the header beyond 20 bytes, although they are uncommon in ordinary application traffic.

IPv6

The IPv6 base header is 40 bytes. It contains source and destination addresses, a hop limit, a payload length, traffic information, and a field that identifies the following header.

IPv6 moves optional information into extension headers instead of expanding the base header in the same way as IPv4. It also omits the IPv4 header checksum. Link-layer and transport checks provide integrity detection, while removing the IP checksum avoids recalculating it at every router.

The IPv6 Hop Limit serves the same basic purpose as IPv4's Time to Live.

An Ethernet frame carries data across one Ethernet link. A common Ethernet II frame contains:

Destination MAC address, 6 bytes: Identifies the intended receiver on the local link.

Source MAC address, 6 bytes: Identifies the sender on that link.

EtherType, 2 bytes: Identifies the payload protocol, such as IPv4 or IPv6.

Payload, commonly 46 to 1500 bytes: Carries the network-layer packet. Small payloads require padding so the frame reaches its minimum size.

Frame Check Sequence, 4 bytes: Lets the receiver detect transmission errors in the frame.

The usual Ethernet frame size is 64 to 1518 bytes from the destination MAC address through the FCS. A VLAN tag adds four bytes to this structure.

Ethernet also transmits a 7-byte preamble and 1-byte Start Frame Delimiter before the frame. These bytes help receivers synchronize with the incoming transmission and are often excluded from the reported frame size. The interpacket gap separates transmissions but is not part of the frame.

Host-based packet captures may not display the preamble or FCS because network hardware processes them before the operating system receives the frame.

Assume an application sends 1200 bytes through TCP, IPv4, and Ethernet. To keep the arithmetic clear, assume a 20-byte TCP header, a 20-byte IPv4 header, no optional headers, and no encryption.

Step 1: TCP adds its header

Step 2: IPv4 adds its header

Step 3: Ethernet adds a header and trailer

The application created 1200 bytes, but the Ethernet frame carries 1258 bytes under these assumptions. The additional 58 bytes provide transport, network, and local-link control information.

The physical transmission also includes the Ethernet preamble and Start Frame Delimiter. Link timing consumes additional capacity through the interpacket gap. Those values are relevant to wire-rate calculations but are not part of the 1258-byte frame above.

Protocol overhead is not inherently waste. Addresses, ports, sequence information, and integrity checks make delivery possible. The engineering concern is whether header cost is reasonable for the payload size. Sending ten bytes in a new connection can require far more protocol traffic than the application content itself.

The destination processes the received data from the bottom upward.

The network interface first reconstructs a frame from the received signals. It checks whether the frame is relevant to the interface and commonly verifies the FCS in hardware.

The link layer identifies the payload as IPv4, IPv6, or another protocol. IP then processes the destination address and protocol identifier.

TCP or UDP uses the destination port to find the receiving socket. TCP also uses sequence information to place bytes correctly in its receive stream. When TLS is present, the TLS implementation verifies and decrypts the protected records.

The application finally receives data in the form its protocol expects. An HTTP server parses an HTTP message, while a DNS server parses a DNS query.

Any layer can discard invalid input. A damaged frame may fail its FCS check. A packet may have an invalid header. A transport checksum may fail. TLS may reject modified ciphertext. The application may reject a well-delivered message with invalid syntax.

A router is both a receiver on one link and a sender on another. It removes the incoming link encapsulation, processes the IP packet, and creates new link encapsulation for the outgoing interface.

The destination and source MAC addresses change because the outgoing frame belongs to a different link. The link technology can change as well. A router can receive an Ethernet frame and send the packet through a fiber provider link with a different frame format.

The source and destination IP addresses usually remain stable during ordinary forwarding. The router reduces the IPv4 TTL or IPv6 Hop Limit. An IPv4 router also updates the header checksum because the header changed.

The TCP ports, sequence numbers, and application bytes normally pass through untouched. A basic router does not need them to make its forwarding decision.

Middleboxes can modify more information. NAT rewrites addresses and often ports. A firewall can inspect transport fields. A proxy terminates one connection and creates a separate connection, producing a new set of transport and network headers.

Every link technology limits the amount of data it can carry in one frame. The Maximum Transmission Unit, or MTU, is the largest network-layer packet a link can carry without network-layer fragmentation.

A common Ethernet MTU is 1500 bytes. This means the Ethernet payload can hold an IP packet of up to 1500 bytes under the usual configuration.

The IP and transport headers consume part of that budget:

The Maximum Segment Size, or MSS, describes the maximum TCP payload an endpoint is prepared to receive in one segment. For a 1500-byte MTU with minimum IPv4 and TCP headers, the illustrative payload limit is:

With a 40-byte IPv6 base header and a minimum 20-byte TCP header, the equivalent value is:

Options, extension headers, tunnels, and other encapsulation can reduce the available payload. The actual segment size also depends on endpoint negotiation and path conditions.

MTU and MSS solve different problems. MTU limits the complete IP packet on a link. MSS limits TCP payload and accounts for the space required by network and transport headers.

TCP segmentation divides a byte stream into transport units that fit the network path. TCP numbers the bytes so the receiver can reconstruct the ordered stream.

IP fragmentation divides an IP packet when it is too large for a link. These fragments travel as separate IP packets and must be reassembled before the original payload can be processed.

The operations happen at different layers. TCP segmentation creates transport units from the application's byte stream. IP carries those units in packets, and fragmentation can divide an oversized packet before a link carries the resulting data in frames.

Modern networks try to avoid IP fragmentation. Lost fragments make the entire original packet unusable, filtering can interfere with fragments, and fragmentation adds processing.

IPv4 can support router fragmentation when the packet permits it, although senders commonly request that routers do not fragment. IPv6 routers do not fragment packets in transit. An IPv6 source can use a Fragment extension header when needed.

Path MTU Discovery helps a sender determine a usable packet size for the route. Transport protocols can then create appropriately sized units before transmission.

Segmentation should also be distinguished from application message framing. TCP segments are delivery units chosen by the transport stack. Applications using TCP must define their own message boundaries through lengths, delimiters, or protocol rules.

Encapsulation determines which information remains visible at each point.

With HTTPS over TCP, TLS encrypts the HTTP message before TCP carries it. Devices along the path can generally observe:

They cannot normally read the encrypted HTTP path, headers, cookies, or response content.

TLS does not encrypt the outer TCP and IP headers because routers and endpoint operating systems need those fields to deliver the traffic. A VPN can add another encrypted layer that protects an inner IP packet between tunnel endpoints, but it still needs an outer packet that the intervening network can route.

The exact visible fields depend on the protocol, capture location, and whether a proxy or tunnel endpoint removes protection.

Encapsulation can occur more than once at the same general layer. Tunnels place an existing packet inside a new protocol unit.

A VPN might take an original IP packet and protect it inside an encrypted tunnel packet. The resulting transmission contains an outer link frame, an outer IP header, a tunnel header, and the protected inner IP packet. The outer IP addresses identify the tunnel endpoints. The inner IP addresses identify the original application endpoints or private-network destinations.

This extra wrapping consumes part of the path's MTU. A tunnel that adds 60 bytes of overhead leaves less space for the inner packet. If the endpoints continue sending packets sized for a full 1500-byte path, the result can be fragmentation or dropped traffic.

Tunneling explains why an application can work on one network but fail when a VPN is enabled, especially for larger payloads. Small packets may fit while larger packets exceed the reduced inner size limit.

A packet analyzer presents the captured bytes as a hierarchy of protocol units. A single captured Ethernet frame might be decoded as:

Expanding each section reveals the header fields belonging to that protocol. The hierarchy reflects encapsulation: Ethernet carries IP, IP carries TCP, and TCP carries TLS bytes.

The capture point affects what appears.

A capture on the sending host may record a packet before the network interface calculates its checksum. The analyzer can report an apparently invalid checksum even though the interface inserts the correct value before transmission. This behavior is called checksum offload.

Segmentation offload can also make a host capture display a transport unit larger than the network MTU. The operating system gives a large buffer to the network interface, and the interface divides it into wire-sized segments. A capture taken on another machine would show the actual transmitted units.

Incoming hardware can combine several received segments before the operating system records them. This receive offload can make capture boundaries differ from the frames that crossed the wire.

These observations do not change the protocol rules. They show that a host capture can occur between software and hardware processing stages. A capture from a network tap or switch mirror observes traffic at a different point.

Consider a browser sending an HTTPS request over TCP, IPv4, and Ethernet.

The reverse response follows the same pattern with the server acting as sender. Encapsulation provides the control information needed on the way down the stack, and decapsulation exposes the original application data on the way up.

Encapsulation wraps application data in a TCP segment or UDP datagram, then an IP packet, then a link-layer frame, which is transmitted as signals. Headers carry information such as addresses, protocols, sequence numbers, lengths, and integrity checks; link protocols may also add trailers such as the Ethernet FCS.

Frames are rebuilt at each hop, IP packets provide routed delivery, and transport units connect endpoint processes. The receiver removes these layers in reverse to recover the application message.

MTU, MSS, segmentation, fragmentation, encryption, tunneling, and hardware offload can change the sizes or boundaries visible in a packet capture.

To interpret a capture, identify the nested protocols and the scope of each field.