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 become the normal deployed Internet architecture. RFC 1122 explicitly maps OSI Presentation and Application into the Internet Application layer. The Session layer is different: TCP/IP does not expose it as a separate layer, so dialogue state is normally implemented by application protocols, libraries, or transport features. HTTP manages cookies and persistent connections. TLS provides a secure channel. JSON and XML provide serialised data formats.

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 made the upper floors less rigid. The functions are still there, but they are usually implemented inside application-space protocols, libraries, or transport designs rather than as three separately exposed Internet layers.

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 normally sits between TCP and HTTP in HTTPS over TCP. It performs a handshake, authenticates peers with certificates, derives traffic keys, encrypts records, and protects record integrity. In OSI vocabulary, those are mostly Presentation and Session responsibilities. TLS does not provide TCP's delivery guarantees, so calling it Layer 4 is too broad for TCP-based HTTPS. In TCP/IP terms it belongs to the application space even though many applications use it as a transparent secure channel.

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 the OSI vocabulary is more detailed than the Internet model exposes.

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 for API traffic, 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.