The OSI Model

Why the OSI model matters

Networking is a stack of hard problems piled on top of each other: getting a voltage onto a copper pair, agreeing whose turn it is to transmit, finding a path across the planet, recovering lost data, keeping a conversation coherent, encrypting it, and finally rendering it as a web page. If you tried to solve all of that in one monolithic program, no two vendors could ever interoperate.

The OSI model's contribution is decomposition. It cuts that pile into seven layers, each with a narrow contract: a layer provides a defined service to the layer above and consumes the service of the layer below, communicating with its peer layer on the remote machine through a standardized protocol. Because the interfaces between layers are fixed, you can swap Ethernet for Wi-Fi at Layer 2 without the TCP code at Layer 4 knowing or caring. That principle — abstraction with stable interfaces — is why the model still shapes how engineers talk, design, and debug, four decades on.

Practically, the payoff shows up three ways. It gives networking a shared vocabulary ("that's a Layer 2 loop," "this is a Layer 7 load balancer"). It gives troubleshooting a method: start at Layer 1 and climb — is there a link light, a MAC entry, an IP route, an open port, a healthy application response? And it scopes security: each layer has its own attack surface, from physical tapping (L1) to ARP spoofing (L2) to BGP hijacks (L3) to application injection (L7).

The seven layers, top to bottom

The layers are numbered 1 (Physical) at the bottom to 7 (Application) at the top. Data descends the stack on send and ascends on receive. Here is what each layer owns.

• Layer 7 — Application. The protocols that programs actually speak: HTTP, DNS, SMTP, FTP, SSH, gRPC. This is not your browser or mail client — it is the network-facing protocol they use. PDU: data.
• Layer 6 — Presentation. Data representation: character encoding (ASCII, UTF-8), serialization, compression, and encryption/decryption. TLS's record and cipher work lives here conceptually. PDU: data.
• Layer 5 — Session. Establishes, manages, and tears down conversations between applications, including dialog control and checkpointing for recovery. Examples: RPC session semantics, NetBIOS, and the "session" half of TLS. PDU: data.
• Layer 4 — Transport. End-to-end delivery between processes, identified by port numbers. TCP adds reliability, ordering, and flow/congestion control; UDP offers bare, connectionless best-effort. PDU: segment (TCP) or datagram (UDP).
• Layer 3 — Network. Logical addressing and routing across networks. IP (v4/v6) lives here, along with ICMP, and routing protocols like OSPF and BGP. Routers operate here. PDU: packet.
• Layer 2 — Data Link. Node-to-node delivery on a single link, framing, MAC addressing, and error detection. Ethernet, Wi-Fi (802.11), ARP, and switches live here. Often split into LLC and MAC sublayers. PDU: frame.
• Layer 1 — Physical. The actual transmission of bits as electrical, optical, or radio signals: cables, connectors, voltages, pinouts, modulation. Hubs and repeaters operate here. PDU: bit (or symbol).

Remembering the order

Two mnemonics do the heavy lifting. Bottom-up (Layer 1 → 7): "Please Do Not Throw Sausage Pizza Away" — Physical, Data Link, Network, Transport, Session, Presentation, Application. Top-down (Layer 7 → 1): "All People Seem To Need Data Processing". Pick one and be consistent, because "Layer 3" is unambiguous only if everyone counts from the same end — and the industry counts Physical as Layer 1.

Encapsulation: how a message becomes bits

The mechanism that ties the layers together is encapsulation. When you send data, each layer prepends its own header (Layer 2 also appends a trailer) to whatever it received from the layer above, treating that entire chunk as an opaque payload. The result is a set of nested envelopes — a Layer 3 packet is literally sitting inside a Layer 2 frame's payload field.

SEND  (descend the stack)                RECEIVE  (ascend the stack)
─────────────────────────────           ─────────────────────────────
L7  [ data ]                             L7            [ data ]
L4  [ TCPhdr | data ]      = segment     L4        [ TCPhdr | data ]
L3  [ IPhdr | segment ]    = packet      L3     [ IPhdr | segment ]
L2  [ ETHhdr | packet | ETHtrl ] = frame L2  [ ETHhdr | packet | ETHtrl ]
L1  101101...              = bits        L1  101101...
        │                                        ▲
        └──────────  the wire / medium  ─────────┘

Each header carries exactly the control information its layer needs: the TCP header holds source/destination ports, sequence and acknowledgement numbers, and window size; the IP header holds source/destination IP addresses and a TTL; the Ethernet header holds source/destination MAC addresses and a type field, with a CRC in the trailer. The receiver runs the process in reverse — decapsulation — where each layer reads and strips its own header, then hands the inner PDU up to the next layer. A layer never inspects headers that aren't its own; that's the whole point of the abstraction.

PDUs: naming the unit at each layer

The same bytes have different names depending on which layer you're looking at them from. This is not pedantry — using the right term instantly tells a colleague which header set you mean.

Layer	Name	PDU	Addressing	Example protocols / devices
7	Application	Data	—	HTTP, DNS, SMTP, SSH, gRPC
6	Presentation	Data	—	TLS (record), UTF-8, JPEG, gzip
5	Session	Data	—	RPC, NetBIOS, session tickets
4	Transport	Segment / Datagram	Port number	TCP, UDP, QUIC*
3	Network	Packet	IP address	IP, ICMP, OSPF, BGP · router
2	Data Link	Frame	MAC address	Ethernet, Wi-Fi, ARP · switch
1	Physical	Bit / Symbol	—	Cables, fiber, radio · hub, repeater

*QUIC is deliberately messy for the model: it runs over UDP (L4) but implements reliability, streams, and TLS 1.3 inside itself, so it straddles L4 through L7 — another sign the model is a lens, not a rulebook.

OSI vs the TCP/IP model

The OSI model is the teaching and diagnostic map. The TCP/IP model (also called the internet protocol suite) is what the internet actually runs. TCP/IP predates the finalized OSI standard and has four layers (sometimes drawn as five). It collapses OSI's top three layers into one Application layer and merges the bottom two into a Link layer.

OSI (7 layers)	TCP/IP (4 layers)	What lives here
7 Application 6 Presentation 5 Session	Application	HTTP, DNS, TLS, SMTP, SSH
4 Transport	Transport	TCP, UDP
3 Network	Internet	IP, ICMP, routing
2 Data Link 1 Physical	Link / Network Access	Ethernet, Wi-Fi, ARP, PHY

The key distinctions: OSI was designed top-down by committee as a general reference before its protocols existed, whereas TCP/IP was designed bottom-up around protocols that already worked. OSI cleanly separates Session and Presentation concerns; TCP/IP intentionally does not, leaving those to the application. When you say "Layer 4," everyone knows you mean Transport in either model — but "Layer 5, 6, 7" only exist as separate concepts in OSI.

Worked example: loading a web page

Follow one HTTPS GET from your laptop to a web server and watch the layers do their jobs, top to bottom on the way out.

• L7 Application: the browser forms GET /index.html HTTP/2 with headers. That request is the data.
• L6 Presentation: TLS encrypts the request into a ciphertext record; the plaintext never leaves this boundary.
• L5 Session: the TLS session (negotiated by an earlier handshake) supplies keys and keeps the conversation coherent.
• L4 Transport: TCP splits the ciphertext into segments, stamps each with source/dest ports (e.g. 54321 → 443) and sequence numbers for reliable, in-order delivery.
• L3 Network: IP wraps each segment in a packet with your source IP and the server's destination IP, and a TTL. Routers use these to forward hop by hop.
• L2 Data Link: for the first hop, ARP resolves the default gateway's MAC; Ethernet wraps the packet in a frame addressed to that MAC, with a CRC trailer.
• L1 Physical: the frame is serialized into signals — voltage on copper, light on fiber, or RF on Wi-Fi — and transmitted.

At each router along the path, the frame is decapsulated up to Layer 3, the packet's TTL is decremented, the next-hop MAC is looked up, and a new Layer 2 frame is built for the next link. The IP addresses stay constant end-to-end; the MAC addresses change every hop. At the server, the stack is climbed in full, decrypting at L6 and handing the plaintext HTTP request to the web server at L7. This is why "Layer 3 is end-to-end, Layer 2 is hop-to-hop" is one of the most useful facts in all of networking.

Encapsulation in pseudocode

# A toy illustration of send-side encapsulation and receive-side decapsulation.
# Each header is just control info for one layer; the payload below is opaque.

def encapsulate(app_data, ctx):
    seg   = tcp_header(ctx.src_port, ctx.dst_port, ctx.seq) + app_data      # L4 segment
    pkt   = ip_header(ctx.src_ip, ctx.dst_ip, ttl=64)      + seg           # L3 packet
    frame = eth_header(ctx.src_mac, ctx.next_hop_mac)      + pkt + crc(pkt) # L2 frame
    return to_bits(frame)                                                   # L1 bits

def decapsulate(bits):
    frame = from_bits(bits)
    pkt   = strip_eth(frame)   # verify CRC, drop L2 header/trailer
    seg   = strip_ip(pkt)      # read dst IP, drop L3 header
    data  = strip_tcp(seg)     # reorder by seq, drop L4 header
    return data                # hand plaintext up to L7

# A router forwards at L3: it decapsulates to the packet, then re-frames it.
def router_forward(bits, routing_table):
    pkt = strip_eth(from_bits(bits))
    pkt = decrement_ttl(pkt)            # drop the packet if TTL hits 0
    nh  = routing_table.lookup(pkt.dst_ip)
    return to_bits(eth_header(nh.mac_src, nh.mac_dst) + pkt + crc(pkt))

The structure mirrors the model exactly: encapsulate adds headers going down, decapsulate strips them going up, and a router only ever touches down to Layer 3 before building a fresh Layer 2 frame — never inspecting Layer 4 or above unless it is doing deep packet inspection.

Common misconceptions and pitfalls

• "The internet runs on OSI." It doesn't. The internet runs TCP/IP. OSI's own protocol stack (TP0–TP4, CLNP) largely lost to TCP/IP in the late 1980s. OSI survives as a reference model and shared language, not a wire protocol.
• Confusing Layer 7 with the application itself. Layer 7 is the network protocol a program speaks (HTTP), not the program (your browser). Your browser is a user of Layer 7, sitting above it.
• Assuming every protocol maps to exactly one layer. TLS spans L5–L6, QUIC spans L4–L7, and ICMP is a Layer 3 protocol that carries no transport header at all. The layering is clean in theory and fuzzy in practice.
• Counting from the wrong end. Physical is Layer 1, Application is Layer 7. Some diagrams draw Application on top; the numbering is what matters. Fix the mnemonic and you'll never flip it.
• Thinking IP and MAC do the same job. IP (L3) is end-to-end and stays constant across the whole path; MAC (L2) is hop-to-hop and is rewritten at every router. Mixing these up breaks your mental model of how forwarding works.
• Believing more layers means slower. The model is conceptual; real stacks fuse layers and use zero-copy paths. The seven boxes are for reasoning, not a literal seven memory copies.

A little history

The OSI project began in the late 1970s under the International Organization for Standardization (ISO), with parallel work at the CCITT (now ITU-T). The seven-layer architecture was published as the ISO standard ISO 7498 in 1984 (later ISO/IEC 7498-1). The ambition was a complete, vendor-neutral suite of protocols so that any two systems could interoperate — a noble goal in an era of incompatible proprietary networks like IBM's SNA and DEC's DECnet.

The protocols themselves largely failed to win adoption: they were complex, arrived late, and required committee consensus while the leaner, already-deployed TCP/IP suite spread across the ARPANET and then the internet for free. By the early 1990s the "protocol war" was effectively over and TCP/IP had won. But the model outlived the protocols. Its layered abstraction was too good a teaching and design tool to discard, and it became — and remains — the lingua franca of networking.