Visual walkthrough — TCP - IP model — 4 layers, mapping to OSI

Before anything, let's fix the four names we'll live inside. Top means "closest to you, the human"; bottom means "closest to the copper/fiber/radio".

Keep the Encapsulation and Decapsulation note open alongside this — it is the general principle; here we do the concrete TCP/IP walk.

---

Step 1 — Start from the raw message (absolute zero)

WHAT. You type a web address and hit Enter. Your browser produces a chunk of text — an HTTP request. It looks roughly like GET /index.html. This text is called the message (some books say data). It carries zero networking machinery yet: no addresses, no ports, nothing about wires.

WHY. Every derivation needs an atom that isn't made of smaller parts. The message is that atom. Everything below will be built by wrapping this, never by changing it. That "never change the payload, only wrap it" rule is the whole idea of layering — the HTTP and the Application Layer speaks its own language and trusts the layers below to be a blind delivery service.

PICTURE. A single chalk box holding the words GET /index.html, floating with nothing around it.

---

Step 2 — Transport wraps it: the message becomes a segment

WHAT. The Transport layer takes the whole message as payload and glues a block of bookkeeping in front of it. That block is the Transport header. The message + this header together is now called a segment (this is the TCP name; UDP calls it a datagram).

WHY. The Internet only knows how to move data from one machine to another. But a machine runs dozens of programs at once — a browser, an email client, a game. Which one gets this data? The answer is the port number. And beyond just addressing the program, TCP promises the data arrives complete, in order, and un-corrupted — that promise needs more fields than just ports, so the header is bigger than you'd first guess.

PICTURE. The Step-1 box is now nested inside a slightly bigger box. The new front slice carries several fields, not just two:

$\underset{\text{TCP header}}{\underbrace{[\text{src port},\text{dst port},\text{seq},\text{ack},\text{flags},\text{window},\text{checksum}]}}+\underset{\text{payload (untouched)}}{\underbrace{\left[\text{GET /index.html}\right]}}=\text{segment}$

Reading the fields left to right:

• src port — a number identifying your browser's temporary socket, so replies come back to it. (See Port Numbers and Sockets.)
• dst port — the number identifying the service you want (e.g. $443$ for HTTPS).
• seq (sequence number) — labels where in the byte-stream this chunk sits, so the receiver can put pieces back in order even if they arrive shuffled.
• ack (acknowledgment number) — says "I have safely received everything up to this byte", the heartbeat of reliable delivery.
• flags — one-bit switches like SYN (start a connection) and FIN (end it) that drive the handshake.
• window — how many more bytes the receiver is willing to accept right now, so a fast sender can't drown a slow receiver (flow control).
• checksum — an end-to-end integrity number covering the header and payload; it lets the final machine detect corruption even if every hop's frame checked out.

---

Step 3 — Internet wraps the segment: it becomes a packet

WHAT. The Internet layer takes the entire segment (header and payload — all of it) as its new opaque payload, and prepends the IP header. The result is a packet.

WHY. Ports told us which program; they said nothing about which machine on Earth. The IP header carries the source IP and destination IP — globally meaningful addresses — so routers along the way know where to forward this (the job of IP Addressing and Routing). But a router also needs to survive loops, hand the payload to the right transport protocol, and cope with links that can't carry a big packet — so the IP header holds several more fields than just two addresses.

PICTURE. The Step-2 box is now nested inside a bigger box, with a fresh front slice carrying the mandatory IP fields:

$\underset{\text{IP header}}{\underbrace{[\text{src IP},\text{dst IP},\text{protocol},\text{TTL},\text{total len},\text{ID/frag},\text{hdr checksum}]}}+\underset{\text{payload = whole segment}}{\underbrace{[\text{TCP hdr}\mid \text{message}]}}=\text{packet}$

Term by term:

• src IP — your computer's address, e.g. 192.168.0.5.
• dst IP — the server's address, e.g. 93.184.216.34.
• protocol — a small number saying what's inside the payload: 6 = TCP, 17 = UDP, 1 = ICMP. This is how the receiver's Internet layer knows to hand the payload up to TCP vs UDP — without it, demultiplexing above IP would be impossible.
• TTL (time-to-live, called hop-limit in IPv6) — a counter decremented by 1 at every router; when it hits $0$ the packet is dropped. This guarantees a mis-routed packet can't circle the internet forever.
• total len — the length of the whole packet in bytes, so the receiver knows where the packet ends.
• ID / frag fields — an identifier plus offset/flags used when a packet must be fragmented (see Step 5) and later reassembled.
• hdr checksum (IPv4) — an integrity check over the IP header only (IPv6 drops this and relies on lower/upper layers).

---

Step 4 — Resolving the next hop: from IP to MAC (ARP / ND)

WHAT. Before the packet can be wrapped for the wire, one question must be answered: what is the hardware address of the next device I hand this to? We have the next hop's IP (either the server itself if it's on our local link, or our router otherwise), but the wire needs a MAC address, not an IP. The Address Resolution Protocol (ARP in IPv4; Neighbor Discovery / ND in IPv6) does this translation.

WHY. The Internet layer thinks in IP; the Network Access layer thinks in MAC. Something must bridge them, or Step 5 has no destination MAC to write. ARP works by broadcasting a tiny question to everyone on the local link — "who has IP 192.168.0.1? tell me your MAC" — and the owner replies with its MAC. The answer is cached, so we only ask once in a while.

PICTURE. Your machine shouts an ARP request to all neighbours; only the router with the matching IP answers with its MAC; that MAC is what Step 4-wrap will use as the destination.

---

Step 5 — Fitting the wire: MTU and fragmentation

WHAT. Every physical link has a maximum frame payload size, the MTU (Maximum Transmission Unit) — classic Ethernet is $1500$ bytes. If our IP packet is larger than the MTU of a link it must cross, IP fragments it: chops the packet into MTU-sized pieces, each getting its own IP header (reusing the ID field and setting fragment offset / more-fragments flags from Step 3).

WHY. You cannot force a $4000$-byte packet through a link that only carries $1500$-byte payloads. Fragmentation lets a big packet survive a small-MTU link. The pieces travel independently and are reassembled only at the final destination (not at intermediate routers) using the ID and offset fields. In IPv6 routers never fragment — instead the sender must discover the smallest MTU on the path first (Path MTU Discovery).

PICTURE. One oversized packet meeting a narrow link, splitting into three fragments each with a copy of the IP header, later glued back together at the destination.

---

Step 6 — Network Access wraps the packet: it becomes a frame

WHAT. The Network Access layer takes each (possibly fragmented) packet as payload and adds a frame header in front and a frame trailer at the back. This is the first time we add something to the back. The result is a frame.

WHY. IP addresses are global, but the wire in front of you only reaches the next device. To hand bits to that immediate neighbour you need its physical hardware address — the MAC address resolved in Step 4 (from Ethernet and MAC Addresses). But the header must also tell the receiver what kind of payload it is carrying — is the thing inside an IPv4 packet, an IPv6 packet, or an ARP message? That's the EtherType field. And the trailer carries a checksum so the receiver can reject a frame whose bits got mangled.

PICTURE. One more nesting. Now there's a slice in front (with an EtherType) and a slice behind:

$\underset{\text{frame header}}{\underbrace{[\text{dst MAC},\text{src MAC},\text{EtherType}(\text{opt. VLAN})]}}+\underset{\text{payload = whole packet}}{\underbrace{[\text{IP hdr}\mid \text{...}\mid \text{message}]}}+\underset{\text{trailer}}{\underbrace{[\text{FCS checksum}]}}=\text{frame}$

• dst MAC / src MAC — hardware addresses of this hop only (they change at every hop; the IP addresses do not).
• EtherType — a code telling the receiver how to read the payload: 0x0800 = IPv4, 0x86DD = IPv6, 0x0806 = ARP. On older frames this slot instead holds a length. An optional VLAN tag may sit here to mark which virtual LAN the frame belongs to.
• payload — the whole packet, still opaque and untouched.
• FCS checksum (Frame Check Sequence) — a number computed from all the frame's bytes; if even one bit flips on this link, it won't match and the frame is discarded.

---

Step 7 — The frame becomes bits on the medium

WHAT. The frame is finally turned into a raw sequence of bits — 0s and 1s — encoded as voltage on copper, light on fiber, or radio pulses in the air.

WHY. A wire cannot carry "a frame"; it can only carry a signal that swings between two states. This is the physical floor of the whole stack — there is nothing below it to wrap. We have hit the bottom.

PICTURE. The nested frame drawn as a stream of pulses leaving an antenna, labelled 1 0 1 1 0 0 1 ….

---

Step 8 — The mirror: decapsulation at the receiver

WHAT. The bits arrive at the server. Now the exact reverse happens. Each layer strips off its own slice and hands the inside up to the layer above:

$\text{Bits}\to \text{Frame}\stackrel{\text{check FCS, read EtherType, strip MAC}}{\to }\text{Packet}\stackrel{\text{reassemble frags, read protocol, strip IP}}{\to }\text{Segment}\stackrel{\text{verify checksum, read port}}{\to }\text{Message}$

WHY. Symmetry is forced by the design. A layer only ever added its header, so it only ever needs to remove its header. The Network Access layer first verifies the FCS (discarding the frame if corrupt), reads the EtherType to know the payload is IPv4, then peels the MAC slice. The Internet layer reassembles any fragments, reads the protocol field to know the payload is TCP, checks the header checksum, and peels the IP slice. Transport verifies its own checksum end-to-end, reads the dst port, and delivers to the right program. Finally the untouched original message pops out — identical to Step 1. This is precisely the round-trip promise of Encapsulation and Decapsulation.

PICTURE. The nested boxes being unwrapped left to right, each discarded slice fading out, until only the original GET /index.html remains.

---

Step 9 — Degenerate & edge cases (the ones exams hide)

WHAT / WHY. A derivation isn't finished until the weird inputs are shown. Here are the corners:

• UDP instead of TCP. At Step 2 the unit is a datagram, not a segment, and the header is much smaller — essentially just src/dst ports, length, and a checksum (no seq/ack/flags/window). Everything else in Steps 3–8 is byte-for-byte the same, because IP treats it as opaque payload regardless. (IP's protocol field simply reads 17 instead of 6.)
• Empty payload. You can send a message with zero bytes of data (a bare TCP SYN has no HTTP content). The wrapping still happens — you just get headers wrapping nothing. The chain never breaks.
• Same-machine loopback. Sending to 127.0.0.1 (yourself). The data still walks down and back up, but never touches a real wire; the OS short-circuits at the bottom. No ARP, no MTU limit, no fragmentation applies.
• Next hop already known. If the ARP/ND cache already holds the next-hop MAC, Step 4 is instant — no broadcast needed.
• Multiple hops. Across the real internet a packet passes many routers. At every hop the frame (MAC addresses + EtherType + FCS) is stripped and a fresh frame is built for the next link — the src/dst MAC changes each hop, and each router runs its own ARP for the next next-hop. But the IP header and everything inside it never change (except TTL, decremented by 1). This is the single most important asymmetry: Network Access is per-hop, Internet is end-to-end.

PICTURE. A two-hop path: same packet inside (TTL ticking down), different frame envelopes on link 1 vs link 2.

---

The one-picture summary

Everything above in a single diagram: the message descending on the left (growing multi-field headers), ARP resolving the MAC and MTU possibly fragmenting in the middle, crossing the wire as bits at the bottom, and ascending on the right (shedding headers), with the data-unit name and the responsible layer beside each rung.

Recall Feynman retelling — the whole walkthrough in plain words

You want to send a note that says GET /index.html. First you write the note — that's the message (Application). You slip it in an envelope stamped with a service number plus a page-numbering scheme and "received-up-to" ticks so the far department can reassemble it in order and confirm it all arrived — that's the TCP header (ports + seq + ack + flags + window + checksum), and now it's a segment. You put that envelope inside a bigger one with the far building's street address, a "which department protocol" tag (TCP or UDP), a self-destruct hop counter so it can't wander forever, and — if it's too fat for a narrow road — you split it into numbered fragments; now it's a packet (Internet). Before handing it to the local courier you shout down the street "who owns the next mailbox?" (ARP) to learn their handle, then tape on a slip with that next mailbox handle, a "what's inside" label (EtherType), and a tamper-seal (FCS); now it's a frame (Network Access). Finally the courier turns it into actual motion down the road — the bits. At every street corner a new courier rips off the old slip, asks ARP for the next handle, ticks the hop counter down, and tapes on a fresh slip — the outer slip changes, the street address inside never does. When it finally arrives, the building checks the seal, reassembles any fragments, reads the labels, and opens the envelopes in reverse — biggest first — and out pops your original note, unchanged. That reverse-unwrapping is decapsulation, and it must be reverse order because the last envelope you sealed is the first one anyone can open.

Recall

Data unit after Transport wraps the message? ::: Segment (TCP) or datagram (UDP) Data unit after the Internet layer wraps the segment? ::: Packet Data unit after Network Access wraps the packet? ::: Frame (then bits) Beyond ports, name four fields a TCP header carries. ::: Sequence number, acknowledgment number, flags, window size (and a checksum) Which IP-header field lets the receiver demultiplex to TCP vs UDP? ::: The protocol field (6 = TCP, 17 = UDP) What does the IP TTL / hop-limit field prevent? ::: Packets looping forever — it is decremented by 1 each hop and dropped at 0 What resolves a next-hop IP into a MAC address? ::: ARP (IPv4) or Neighbor Discovery (IPv6) What is the MTU, and what happens if a packet exceeds it? ::: The max frame payload of a link; IP fragments the packet and reassembles it at the destination Which frame-header field tells the receiver the payload is IPv4 vs ARP? ::: The EtherType field (0x0800 = IPv4, 0x0806 = ARP) Which addresses change at every hop, and which stay constant? ::: MAC changes per hop; IP stays end-to-end (only TTL changes) Why is decapsulation in reverse order of encapsulation? ::: The last header wrapped is the outermost, so it must be the first stripped (nesting-doll rule) What does the frame trailer's FCS checksum do? ::: Lets the receiver detect if bits were corrupted on that link and discard the frame

---

Connections

• 4.3.02 TCP - IP model — 4 layers, mapping to OSI (Hinglish)
• Encapsulation and Decapsulation
• TCP vs UDP
• IP Addressing and Routing
• Port Numbers and Sockets
• Ethernet and MAC Addresses
• HTTP and the Application Layer
• OSI Model — 7 Layers

Concept Map