OSI / TCP-IP Model

The OSI model is a seven-layer map of the jobs a network conversation has to do. TCP/IP groups the jobs into four layers. On this Ethernet + IP + TCP path, Transport, Internet, and Link contribute the same three lower-layer wrappers — TCP, IP, Ethernet — not seven generic OSI headers. Session and Presentation add none.

Think of sending a gift. You write a note (the HTTP request), put it in a box with a room number (TCP ports), put that box in a crate with a street address (IP), and hand the crate to a courier who only looks at the building next door (Ethernet). A post office on the way peels the courier bag, reads the street address, and puts the same crate in a new bag. Nobody at the post office opens the note. That is the whole point of layers.

This is also the distinction you use when a packet reaches a host but not the program listening on it.

How the OSI and TCP/IP models work

OSI names seven responsibilities, top to bottom:

• Application — the message the program meant to send. Here that is GET / HTTP/1.1.
• Presentation — syntax and encryption. TLS lives here in spirit, and only if the conversation is HTTPS.
• Session — which conversation this is. In this stack the socket does that naming; it is not a separate OSI header.
• Transport — ports, so two programs on the same machine can share a host.
• Network — host addresses, so the packet can cross networks.
• Data Link — the next hop's MAC, so the frame can cross one link.
• Physical — bits on a wire. Encoding, not a header.

TCP/IP, as RFC 1122 draws it, keeps four names: Application, Transport, Internet, Link. Session and Presentation fold into Application. Physical folds into Link. Same three wraps. The popular five-layer textbook picture is just OSI with those two folds already done.

A PDU — protocol data unit — is whatever the current layer is holding: a message, then a segment, then a packet, then a frame, then bits.

wrap is identity for Application, Presentation, Session, and Physical. It calls Header(...) only for Transport, Network, and Data Link. to_bits runs after the loop. That is why the onion on a happy request has three shells, never five or seven. HTTP's own headers stay inside the payload; they are not a fourth wrap around some other body.

A router is the proof that the split is a permission, not wallpaper. It unwraps Link, looks at the IP destination, writes a new Ethernet header for the next hop, and never touches TCP or HTTP. If it had to unwrap to Application, it would need a parser for every application protocol it forwards.

OSI / TCP-IP Model Step by Step

The default run is OSI 7 on a direct link: GET / HTTP/1.1 from 10.0.0.2:49152 to 93.184.216.34:80.

1. The map. Two stacks sit empty. Seven OSI names on the client, the same seven on the origin. The TCP/IP name of each band is already printed on it.
2. Application writes the message. GET / HTTP/1.1 appears in the onion. Headers = 0. HTTP is the payload — we do not invent a fourth on-wire header around some other body.
3. Presentation. The band lights up; the onion does not grow. If this were HTTPS, TLS would encrypt here, and it would ride inside TCP, not as an OSI header. This run is plaintext HTTP on port 80, so nothing is added.
4. Session. Same grammar. Session would name the conversation; here the TCP socket does that job. Still no extra header.
5. Transport wraps. A TCP shell appears: sport=49152 dport=80. The PDU is now a segment. Headers = 1.
6. Network wraps. An IP shell appears: 10.0.0.2 → 93.184.216.34. The PDU is a packet. Headers = 2.
7. Link wraps. An Ethernet shell appears, client MAC to origin MAC. The PDU is a frame. Headers = 3.
8. Physical encodes. The onion compresses to a bits chip. Same three shells, no fourth one. to_bits is encoding.
9. On the wire. The chip rides the rail. Both Physical bands are live; everything above them recedes.
10. The origin decodes the bits back into the same three-shell frame.
11. Link unwraps. Ethernet comes off. Link does not look at ports or URLs.
12. Network unwraps. IP comes off. This host was the destination.
13. Transport unwraps. TCP comes off; port 80 demuxes to the listening socket. The PDU is a message again.
14. Session on the way up is still identity.
15. Presentation on the way up is still identity. It would decrypt here if this were HTTPS; on port 80 the PDU does not change.
16. Application reads GET / HTTP/1.1. Same bytes that left the client.
17. Done. Three lower-layer headers on the wire, seven names on the map, two of which never touched the onion.

Switch to TCP/IP 4 and the walk is the same three wraps without the four role-only beats. The fold is the model.

Via router inserts a hop after the bits leave. The first Ethernet destination is the router, not the origin. The router strips that header, sees dst is still 93.184.216.34, writes a new Ethernet header, and forwards. Application and Transport stay dark on that hop. HTTP is not its business. A real hop also decrements TTL; the destination address staying put does not mean the whole IP header is frozen.

Skip transport is the breaking point. omit == "transport" fires continue, so IP wraps the bare GET. The origin unwraps Ethernet and IP just fine, then unwrap raises: no TCP header or port to deliver this request to the TCP listening socket. L1–L3 succeeded. Application never sees the GET.

Why seven names and three headers

People memorize seven colored boxes and then cannot say how many headers a GET carries. The boxes are jobs. The headers are the ones wrap actually writes.

Count them on the default run: after beat 4 the onion is still a bare GET, after beat 7 it has three shells, and after beat 8 it is bits with those same three shells inside. Flip to TCP/IP and you get the same three shells under four names. That is the mapping, not two different internets.

The three addresses are three different questions. MAC is the next hop, IP is the destination host, port is the listening process. After a router hop a capture shows a new Ethernet header, the same IP destination, and the same TCP ports. That is how you tell "the packet reached the machine" from "something is listening on that port."

The router run is the other half. A hop that only needs IP does not unwrap past Network. Layers exist so the post office can forward the crate without reading the note.

Edge Cases

• Skip transport. IP and Ethernet still work. Delivery to a host is not delivery to a program. This TCP service needs a TCP header and destination port; other IP protocols and raw sockets are outside the model.
• Via router. On this ordinary forwarding hop, without NAT, the IP destination stays the same and the next-hop MAC changes. TTL also decreases in a real IPv4 packet. If the first Ethernet already named the origin, there would be no reason for the middle box.
• Role-only layers on the way up. Session and Presentation light up after TCP is gone, and the onion still does not change. The identity wrap is symmetric.
• Physical is not a header. to_bits after the loop keeps the header count honest. A "seven-header OSI frame" is a poster, not a packet capture.
• No free-form payload. The request is fixed so the addresses, ports, and header count stay exact. The knobs that teach are the model and the path.

Common Mistakes

• Counting seven headers because there are seven names. Run the default trace and pause after Presentation. The onion did not grow. Pause after Ethernet. It grew three times.
• Putting TLS in its own OSI header. TLS is Presentation-shaped and it rides inside TCP. With decryption keys, Wireshark can show TCP, then TLS, then the decrypted HTTP — not an "L6" header beside TCP.
• Thinking a router reads HTTP. The via-router hop never lights Application. If it did, the router would have to parse HTTP, and every other application protocol it forwards.
• Addressing a process with a MAC. Ethernet delivers to a host. The port is in TCP. Skip-transport is what happens when you forget that.
• Treating OSI and TCP/IP as competing stacks. They name the same jobs at different grain. The TCP/IP walk is the OSI walk with Session, Presentation, and Physical already folded.

A Note on Simplification

This is an explainer, not a packet capture. Real TCP carries options, checksums, sequence numbers, and window scaling; IP has TTL, fragmentation, and IPv6; Ethernet has VLANs and a trailer. A real path is many hops, not one. The toy Header("TCP") is a label, not a 20-byte segment. The IP destination staying put on a hop does not mean the IP header is frozen — a real IPv4 router decrements TTL and updates the header checksum; IPv6 uses Hop Limit and has no IP header checksum.

TLS and HTTP/2 fit within the TCP/IP application layer in this comparison. QUIC is a transport protocol over UDP, so it does not follow this TCP wrapping example. We send a plaintext GET to port 80; an HTTPS-over-TCP run would put TLS records inside TCP, not beside it. Port 443 alone does not enable encryption. The 5-layer hybrid some textbooks draw is this lesson's OSI walk with L5 and L6 already folded — we did not add it as a third model because it would duplicate the default run.