Computer Networks

Foundations Of Networking

Encapsulation

Each layer takes what the layer above gave it,

JrCodex·7 min read

Jr Codex Computer Networks Notes

Level: Beginner Prerequisites: Chapter 2: The OSI and TCP/IP Models Time to complete: ~20 minutes


Table of Contents

  1. How Layers Actually Cooperate
  2. The Journey Down
  3. The Journey Up
  4. Protocol Data Units
  5. Overhead
  6. MTU and Fragmentation
  7. Summary & Next Steps

1. How Layers Actually Cooperate

The Mechanism
─────────────────────────────────────────
  Each layer takes what the layer above gave it,
  treats it as OPAQUE DATA, and wraps it in its own
  HEADER.

  The header carries exactly what that layer needs
  to do its job — and nothing about the layers
  above or below.

  This is Chapter 1's "hide what is below", made
  concrete: the network layer never parses the HTTP
  inside it, and does not need to.
─────────────────────────────────────────
The Postal Analogy
─────────────────────────────────────────
  A letter (the data)
    inside an envelope with a name (transport:
      which person)
      inside a bigger envelope with a street
      address (network: which building)
        handed to a courier who knows only the next
        depot (link: the next hop)

  Each layer of wrapping is read and removed by the
  matching layer at the destination. The courier
  never reads the letter.
─────────────────────────────────────────

2. The Journey Down

Sending "GET /index.html"
─────────────────────────────────────────
  APPLICATION
    GET /index.html HTTP/1.1
    Host: example.com
                            ── the DATA
        ▼
  TRANSPORT (TCP) adds:
    source port 51234, destination port 443,
    sequence number, ACK number, flags, checksum
    [TCP hdr | GET /index.html ...]
                            ── a SEGMENT
        ▼
  NETWORK (IP) adds:
    source IP 192.168.1.10, destination IP
    93.184.216.34, TTL, protocol=6
    [IP hdr | TCP hdr | GET ...]
                            ── a PACKET
        ▼
  LINK (Ethernet) adds:
    source MAC, destination MAC, EtherType
    ...and a trailer: FCS checksum
    [Eth hdr | IP hdr | TCP hdr | GET ... | FCS]
                            ── a FRAME
        ▼
  PHYSICAL
    the frame as voltages, light or radio
                            ── BITS
─────────────────────────────────────────
Notice What Each Header Carries
─────────────────────────────────────────
  TCP   PORTS — which PROGRAM
  IP    ADDRESSES — which MACHINE, anywhere
  ETH   MAC ADDRESSES — which device on THIS LINK

  Three different scopes of "who", each answering
  a different question. That is why all three
  exist, and Chapter 2's address table becomes
  obvious once you see it here.
─────────────────────────────────────────

3. The Journey Up

Arriving at the Server
─────────────────────────────────────────
  PHYSICAL     bits ──► a frame

  LINK         check the FCS; corrupt? DISCARD.
               Is the destination MAC mine?
               Strip the Ethernet header.
               EtherType says 0x0800 ──► IPv4,
               so hand it to IP.

  NETWORK      Is the destination IP mine?
               Strip the IP header.
               Protocol field says 6 ──► TCP, so
               hand it to TCP.

  TRANSPORT    Verify the checksum. Reorder by
               sequence number. Send an ACK.
               Destination port 443 ──► hand it to
               whatever is listening there.

  APPLICATION  Parse the HTTP request. Respond.
─────────────────────────────────────────
The DEMULTIPLEXING Field
─────────────────────────────────────────
  Every header contains a field naming WHAT IS
  INSIDE it:

    Ethernet  EtherType     0x0800=IPv4,
                            0x86DD=IPv6, 0x0806=ARP
    IP        Protocol      6=TCP, 17=UDP, 1=ICMP
    TCP/UDP   Dest. port    443=HTTPS, 53=DNS

  Without these, a layer would receive bytes with
  no idea which protocol above it should handle
  them.

  Encapsulation only works because each wrapper
  labels its contents.
─────────────────────────────────────────

4. Protocol Data Units

The Names
─────────────────────────────────────────
  LAYER        PDU NAME    Contains
  ─────────────────────────────────────────
  Application  DATA / message
  Transport    SEGMENT     (TCP)
               DATAGRAM    (UDP)
  Network      PACKET
  Data Link    FRAME
  Physical     BIT

  These names are used precisely in documentation
  and interviews. "Packet" is used loosely in
  conversation for anything, but "frame" and
  "segment" are specific.
─────────────────────────────────────────
# Encapsulation, modelled directly. Each layer wraps and labels.
def encapsulate(data, src_port, dst_port, src_ip, dst_ip, src_mac, dst_mac):
    segment = {"proto": "TCP", "src_port": src_port, "dst_port": dst_port,
               "seq": 1000, "payload": data}
 
    packet  = {"proto": "IPv4", "src_ip": src_ip, "dst_ip": dst_ip,
               "ttl": 64, "next_proto": 6,          # 6 = TCP: the demux field
               "payload": segment}
 
    frame   = {"proto": "Ethernet", "src_mac": src_mac, "dst_mac": dst_mac,
               "ethertype": 0x0800,                  # 0x0800 = IPv4: demux again
               "payload": packet, "fcs": checksum(packet)}
    return frame
 
def decapsulate(frame):
    """Each step reads the demux field to decide who handles the payload."""
    assert frame["fcs"] == checksum(frame["payload"]), "corrupt frame — discard"
    packet  = frame["payload"]      if frame["ethertype"] == 0x0800 else None
    segment = packet["payload"]     if packet["next_proto"] == 6    else None
    return segment["payload"], segment["dst_port"]      # data, and which program

5. Overhead

The Arithmetic
─────────────────────────────────────────
  Ethernet header + trailer   18 bytes
  IPv4 header                 20 bytes (minimum)
  TCP header                  20 bytes (minimum)
                             ──────────
  Total per frame             58 bytes

  Sending 1 byte of data ──► 59 bytes on the wire.
  1.7% efficiency.

  Sending 1,460 bytes ──► 1,518 bytes on the wire.
  96% efficiency.
─────────────────────────────────────────
Why This Matters Practically
─────────────────────────────────────────
  SMALL PACKETS ARE EXPENSIVE — not only in
  bandwidth but in per-packet processing, which is
  often the real bottleneck on routers and network
  cards.

  Consequences you will meet later:
    - TCP's Nagle algorithm batches small writes
      (Module 4, Chapter 5)
    - HTTP/2 multiplexes many requests over one
      connection (Module 5, Chapter 3)
    - "chatty" protocols with many tiny messages
      perform badly regardless of bandwidth

  A protocol sending 100 one-byte messages moves
  5,900 bytes. The same data in one message moves
  158.
─────────────────────────────────────────

6. MTU and Fragmentation

MTU — Maximum Transmission Unit
─────────────────────────────────────────
  The largest frame payload a link will carry.

    Ethernet            1500 bytes (standard)
    Ethernet jumbo      9000 bytes (datacentre)
    PPPoE (some DSL)    1492 bytes
    Typical VPN tunnel  ~1400 bytes

  A packet larger than the MTU cannot cross that
  link intact.
─────────────────────────────────────────
What Happens Then
─────────────────────────────────────────
  IPv4  a router MAY fragment the packet into
        pieces, reassembled at the destination.
        Costly, and losing ONE fragment loses the
        whole packet.

  IPv6  routers do NOT fragment. They drop the
        packet and send back ICMP "Packet Too Big".
        The SENDER must adjust.
─────────────────────────────────────────
PATH MTU DISCOVERY, AND HOW IT BREAKS
─────────────────────────────────────────
  The sender marks packets "Don't Fragment", and
  learns the smallest MTU on the path from the
  ICMP messages it gets back.

  THE CLASSIC FAILURE: a firewall blocks ICMP
  "because ICMP is a security risk".

  Now the sender never learns the path MTU. Small
  packets pass; large ones vanish silently.

  SYMPTOM: the connection establishes, small
  requests work, and large transfers hang forever.
  This is one of the most confusing failures in
  networking, and it is always the same cause.

  Module 3, Chapter 5 returns to ICMP; Module 8
  covers diagnosing it.
─────────────────────────────────────────
# Find the real path MTU: send DF-marked packets of decreasing size.
ping -M do -s 1472 example.com      # 1472 + 28 bytes of headers = 1500
ping -M do -s 1372 example.com      # try smaller if the above fails

7. Summary & Next Steps

Key Takeaways

  • Each layer wraps the layer above's output as opaque data and adds a header carrying only what that layer needs — which is how "hide what is below" works in practice.
  • Every header contains a demultiplexing field naming what is inside it, without which the receiving layer could not know which protocol to hand the payload to.
  • Fixed 58-byte overhead makes small packets extremely inefficient, which is why protocols batch, multiplex and avoid chattiness.
  • Blocked ICMP breaks path MTU discovery, producing the signature failure of a connection that works for small requests and hangs on large transfers.

Concept Check

  1. What three different questions do the MAC address, IP address and port number each answer?
  2. What would break if the IP header had no Protocol field?
  3. A user reports that a website loads but file uploads hang. Which mechanism should you suspect, and why?

Next Chapter

Chapter 4: Network Types and Topologies


Jr Codex — 1-on-1 Personalized Coaching | Back to Module Index | Back to Computer Networks Index