2. The TCP/IP model (and how it maps to OSI)

2.1 The four layers

TCP/IP is usually drawn with 4 layers (the original RFC 1122 "host requirements" model). The 7-layer OSI model is a teaching tool; the wire only cares about the 4.

+----------------------+   Data unit        Example protocols
| 4. Application        |   "message"/data   HTTP, DNS, TLS, SSH, SMTP, gRPC
+----------------------+
| 3. Transport          |   segment (TCP)    TCP, UDP, QUIC(*), SCTP
|                       |   datagram (UDP)
+----------------------+
| 2. Internet           |   packet/datagram  IPv4, IPv6, ICMP, IGMP
+----------------------+
| 1. Link (Network      |   frame            Ethernet, Wi-Fi (802.11), PPP, ARP
|    Access)            |   bits             (plus the physical medium)
+----------------------+

(*) QUIC technically rides inside UDP but functionally replaces TCP; more in Chapter 39.

2.2 Mapping to OSI

OSI #	OSI name	TCP/IP layer	What lives here in practice
7	Application	Application	HTTP semantics, DNS queries
6	Presentation	Application	TLS encryption, character encoding, gzip
5	Session	Application	TLS session resumption, SIP dialogs, RPC
4	Transport	Transport	TCP, UDP — ports, reliability
3	Network	Internet	IP addressing and routing
2	Data Link	Link	Ethernet/Wi-Fi framing, MAC, switching
1	Physical	Link	Copper, fiber, radio, voltage/light levels

People still say "Layer 3" for IP, "Layer 4" for TCP/UDP, and "Layer 7" for application content because that vocabulary is baked into product names:

L2 switch — forwards Ethernet frames by MAC address.
L3 switch / router — forwards IP packets by destination address.
L4 load balancer — picks a backend using IP + port, never looks at payload.
L7 load balancer / proxy — parses HTTP, routes by URL path or Host header.
"Layer 8 problem" — a joke: the user.

2.3 What each layer promises the one above it

Link → Internet: "I will deliver this frame to another interface on this same physical network, or drop it. No promises about order or success."
Internet → Transport: "I will make a best effort to deliver this packet to the destination IP anywhere on the internet. It may be lost, duplicated, reordered, delayed, or corrupted (header checksum only in v4)."
Transport (UDP) → App: "Same as IP, plus I'll tell you which port it's for and checksum the payload."
Transport (TCP) → App: "You get a bidirectional byte stream. Bytes arrive exactly once, in order, or the connection breaks and you find out."

Every layer is a contract. Debugging is usually the act of finding which layer broke its contract.

2.4 War story

An engineer swore "the network is dropping my data" because a large HTTP response was truncated. Packet capture showed every TCP segment ACKed and the connection cleanly closed with FIN. TCP kept its contract perfectly. The real bug: the application server had a 30-second write timeout and stopped sending mid-body while returning HTTP 200. Lesson: "the network" is the last place to look, not the first. Verify the transport-layer contract held before blaming lower layers.

Try it yourself

# Watch which layer a tool operates at
ip -br addr          # Layer 3 config (addresses)
ip -br link          # Layer 2 config (MAC, state)
ss -tan              # Layer 4 (TCP sockets and states)
curl -v https://example.com   # Layer 7 (HTTP request/response)