How OSI maps to TCP/IP, and where the mapping breaks

In Module 2, you learned the PDU names at each layer (frame, packet, segment, data). Now we need to connect those layers to the model the Internet actually uses. Three areas map cleanly between OSI and TCP/IP.

Physical + Data Link maps to the Link layer. OSI splits the bottom into two layers: Physical (electrical signals, cables, connectors) and Data Link (Ethernet framing, MAC addresses, error detection). TCP/IP combines these into a single Link layer. Both models agree on what happens here: bits become frames, MAC addresses handle local delivery, and the technology varies by network type (Ethernet, Wi-Fi, fibre).

Network maps to the Internet layer. This is the cleanest one-to-one match. IP addresses, routing decisions, packet forwarding, and TTL counting all live here in both models. When someone says "Layer 3," everyone agrees they mean IP and routing.

Transport maps to Transport. TCP provides reliable, ordered delivery with flow control. UDP provides fast, connectionless delivery. Port numbers, segmentation, and congestion control live here in both models. No ambiguity.

OSI defines three layers above Transport: Session (Layer 5), Presentation (Layer 6), and Application (Layer 7). The Internet model has one: Application.

In the OSI vision, each of these would be a separate, interchangeable protocol. Session protocols would manage dialogue state. Presentation protocols would handle encoding and encryption. Application protocols would handle user-facing functions. You could mix and match them independently.

That vision did not survive contact with real engineering. Instead of building separate Session and Presentation protocols, developers built those functions directly into their applications. HTTP manages its own sessions (cookies, persistent connections). TLS handles encryption as a library, not as a separate protocol layer. JSON and XML handle data formatting as serialisation standards, not as deployed protocol layers.

Think of it like a building renovation. OSI designed a seven-story building with dedicated floors for session management, data formatting, and application logic. TCP/IP took the same building and knocked out the walls between floors 5, 6, and 7, creating one large open-plan space. The functions are still there. The walls are not.

Some protocols were designed to solve problems, not to satisfy reference models. They span multiple layers because the engineering demanded it.

TLS (Transport Layer Security). TLS sits between TCP and HTTP. It manages sessions (handshakes, resumption tickets), transforms data (encryption, compression), and provides transport-level security. In OSI terms, it performs Layer 5, 6, and 4 functions simultaneously. In TCP/IP terms, it sits within the Application layer, but applications treat it as a transparent transport wrapper. The honest answer is that TLS spans Layers 4 through 6. Picking one layer is a simplification.

QUIC (RFC 9000). QUIC goes further. It is a UDP-based transport protocol that integrates TLS 1.3 encryption directly into its connection handshake. RFC 9001 states that "QUIC assumes responsibility for the confidentiality and integrity protection of packets." QUIC also provides stream multiplexing (multiple independent data streams within one connection), which OSI would call a Session-layer function. In TCP/IP terms, QUIC is a transport protocol. In OSI terms, it spans Layers 4, 5, and 6 by design.

ARP (Address Resolution Protocol). ARP translates IP addresses (Layer 3) into MAC addresses (Layer 2). ARP packets have no IP header. They are broadcast on the local Ethernet segment using their own frame format. They serve Layer 3 but operate at Layer 2. Engineers often call ARP "Layer 2.5" because neither model handles it cleanly.

ICMP (Internet Control Message Protocol). RFC 792 describes ICMP with a famous paradox: it "uses the basic support of IP as if it were a higher level protocol, however, ICMP is actually an integral part of IP." ICMP packets ride inside IP packets (like a transport protocol would), but ICMP has no port numbers and carries no application data. It is a control protocol for IP itself. Both models put it at Layer 3, but its encapsulation inside IP makes it look like it sits above IP.

Use the tool below to map each OSI layer to its TCP/IP equivalent. Remember: the mapping at the bottom (Layers 1-2 to Link) and middle (Layers 3-4) is straightforward. The interesting part is at the top, where three OSI layers collapse into one.

Notice the note at the bottom of the tool: "A protocol can span boundaries." That is the key lesson. The mapping gives you a useful mental model, but do not treat it as an absolute rule. Real protocols cross boundaries whenever the engineering requires it.

Layer terminology shows up constantly in infrastructure conversations. Getting the mapping right helps you ask better questions and avoid buying the wrong product.

L4 vs L7 load balancers. An L4 load balancer routes connections based on IP addresses and port numbers. It is fast because it does not read packet content. An L7 load balancer terminates connections, reads HTTP headers (URLs, cookies, methods), and makes routing decisions based on application data. If your service needs content-based routing, you need L7. If you need raw throughput for non-HTTP traffic, L4 is simpler and faster.

Firewall layers. A traditional stateful firewall inspects Layers 3 and 4 (IP addresses, ports, TCP flags). It cannot see what is inside the HTTP request. A next-generation firewall (NGFW) uses deep packet inspection to read application content at Layer 7. Some vendors market L3/L4 firewalls as having "application awareness" because they map port numbers to application names. That is still L4 logic wearing an L7 label.

When to use which vocabulary. Use OSI layer numbers when troubleshooting ("the problem is at Layer 3") because the seven layers give you a more specific checklist. Use TCP/IP vocabulary when writing code or reading RFCs because it matches how protocols are actually implemented. Most engineers use OSI numbers as shorthand even when they are thinking in TCP/IP terms. Saying "L7" is faster than saying "Application layer," and everyone understands it.