Data Encapsulation and Packets

The International Shipping Analogy

You want to send a fragile antique vase from your home in Dhaka to a friend in London. Here is how you prepare it for the journey:

First, you wrap the vase in bubble wrap — protecting the fragile contents. Then you place it in a cardboard box with your friend's address and your return address written on it. That box gets loaded into a shipping container at the port, which has a container number and routing label for the shipping company. The container is loaded onto a cargo ship with a manifest listing which port it is heading to.

At each step, something new was added around the original item. The vase never changed — only the wrapping changed. When it arrives, your friend reverses the process: ship unloads the container, container is opened to find the box, box is opened to find the bubble-wrap, bubble-wrap is unwrapped to reveal the vase.

This is exactly how network data travels. The process of adding wrappers going down the layers is called encapsulation. The process of removing them going up is called de-encapsulation.

Why Encapsulation Exists

Encapsulation solves a fundamental problem in layered architecture: each layer must be able to do its job without knowing the details of other layers.

• The IP layer does not need to know if it is carrying HTTP or FTP data — it just carries the payload
• The Ethernet layer does not need to know if the payload is TCP or UDP — it just delivers the frame to the next hop
• The TCP layer does not need to know the physical medium — it just ensures reliable delivery

This separation means you can change one layer without breaking others. Moving from copper Ethernet to fiber optic? Only Layer 1 changes. Switching from IPv4 to IPv6? Only Layer 3 changes. HTTP/1.1 to HTTP/2? Only Layer 7 changes.

Protocol Data Units (PDUs)

At each layer, data has a different name based on what has been added to it:

Visualizing "Hello World" Through the Layers

Let us trace the text "Hello World" (a simple HTTP response body) as it travels down the network stack:

At the Application Layer:

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 11

Hello World

This is the raw application data — an HTTP response.

At the Transport Layer — TCP Segment:

+---------------------------+
| Source Port:    80        |  ← HTTP server port
| Destination Port: 54321  |  ← Client's random port
| Sequence Number: 1000    |  ← For ordering
| Ack Number:      501     |  ← Acknowledging client's last byte
| Data Offset:     5       |  ← Header length (20 bytes)
| Flags:           PSH ACK |  ← Push data now, acknowledge
| Window Size:     65535   |  ← Flow control
| Checksum:        0x4F2A  |  ← Error detection
+---------------------------+
| [ HTTP response data    ] |
+---------------------------+

TCP has segmented the data and added a 20-byte header. The sequence number allows the receiver to reassemble multiple segments in the correct order.

At the Network Layer — IP Packet:

+----------------------------------+
| Version: 4   | IHL: 5           |
| Total Length: 560 bytes         |
| TTL: 64     | Protocol: 6 (TCP) |
| Source IP:  203.0.113.50        |  ← Web server
| Dest IP:    192.168.1.105       |  ← Your computer
| Checksum:   0x8F7E              |
+----------------------------------+
| [ TCP segment (header + data) ] |
+----------------------------------+

IP adds another 20-byte header. The TTL of 64 means this packet will be discarded if it passes through more than 64 routers without arriving. Protocol field (6 = TCP) tells the receiver which transport protocol to hand data up to.

At the Data Link Layer — Ethernet Frame:

+---------------------------------------------+
| Preamble:  10101010... (7 bytes + SFD)      |  ← Sync signal
| Dest MAC:  AA:BB:CC:DD:EE:01               |  ← Next-hop router
| Source MAC: 11:22:33:44:55:66              |  ← Server's NIC
| EtherType: 0x0800 (IPv4)                   |
+---------------------------------------------+
| [ IP packet (header + TCP segment + data) ] |
+---------------------------------------------+
| FCS (Frame Check Sequence): 0xAB12CD34     |  ← Error detection
+---------------------------------------------+

Ethernet adds a header (14 bytes) and a trailer (4 bytes FCS). The destination MAC is the next-hop router's MAC address, not the final destination's MAC. MAC addresses change at every hop; IP addresses do not.

At the Physical Layer:

10110110 00101101 11010011 01001010 ... (raw bits)

The frame is converted to electrical signals (copper Ethernet), light pulses (fiber optic), or radio waves (Wi-Fi) and transmitted.

What Each Header Contains

TCP Header (20 bytes minimum)

IP Header (20 bytes minimum)

Ethernet Header (14 bytes) + Trailer (4 bytes)

De-encapsulation: The Receiver's Journey

When your computer receives the Ethernet frame:

1. Layer 1 (Physical): Receives bits from the wire, converts to digital
2. Layer 2 (Data Link): Reads Ethernet header — checks if destination MAC matches its own. Verifies FCS checksum. Strips Ethernet header/trailer, passes IP packet up
3. Layer 3 (Network): Reads IP header — verifies destination IP is this device. Decrements TTL. Strips IP header, passes TCP segment up
4. Layer 4 (Transport): Reads TCP header — identifies destination port (e.g., 80). Reassembles segments in sequence order. Strips TCP header, passes HTTP data up
5. Layer 7 (Application): The web browser (or server) reads the HTTP data

MTU: Why Packets Are Limited in Size

MTU (Maximum Transmission Unit) is the largest packet size that can be transmitted without fragmentation on a given network. For Ethernet, the standard MTU is 1500 bytes.

Why 1500 bytes? It was a practical compromise when Ethernet was designed in the 1970s. Large frames mean fewer headers (more efficient) but also mean a single corrupted frame wastes more retransmission bandwidth. 1500 bytes struck a balance.

What happens when a packet exceeds the MTU?

• IPv4: The router fragments the packet into smaller pieces, each with its own IP header. The destination reassembles them
• IPv6: Routers do not fragment. The source must discover the path MTU and send packets small enough to fit
• Path MTU Discovery (PMTUD): A technique where the sender discovers the smallest MTU along the entire path and sizes packets accordingly

If you ever notice video calls freezing or large file transfers failing while small pings work fine, MTU mismatch is often the culprit — especially common with VPN tunnels that add overhead headers, reducing the effective MTU.