Layered Models: OSI and TCP/IP

A computer network is extraordinarily complex: radio waves, copper electrons, fibre photons, routers, switches, operating systems, and web servers all need to work together. The only way to manage this complexity is modular design through layering. Each layer provides a well-defined service to the layer above it and depends only on the service offered by the layer below. Internal implementation details are hidden — a change inside one layer (e.g. upgrading from copper to fibre) doesn't require changes in other layers.

This idea gave rise to two reference models that you'll encounter everywhere: OSI (a theoretical framework from ISO) and TCP/IP (the practical model the internet actually uses).

The OSI model (7 layers)

The Open Systems Interconnection model (ISO/IEC 7498-1) was published in 1984 as a vendor-neutral reference framework intended to allow different manufacturers' systems to interoperate. It was never widely implemented as a complete protocol suite, but its layer terminology is still universally used for diagnosis and discussion.

Exam note: The OSI model is only a theoretical model (on a "nice-to-know" level), and the exam will NOT ask questions about the Presentation (Layer 6) or Session (Layer 5) layers. The TCP/IP model is used in practice.

A useful mnemonic for layers 7→1: "All People Seem To Need Data Processing". For 1→7: "Please Do Not Throw Sausage Pizza Away."

The TCP/IP model (4 layers) and the 5-layer Internet model

The original TCP/IP model (RFC 1122), derived from ARPANET design documents, describes the internet's protocol stack in 4 layers. It merges OSI's top three layers into one Application layer, and merges the Data Link and Physical layers into a single Link (or Network Access) layer. However, computer networking textbooks (such as Kurose & Ross or Tanenbaum) and university exams frequently teach a 5-layer model that splits the bottom layer into separate Link and Physical layers, providing a clearer distinction between framing/addressing and physical bit transmission.

* Note: ARP is technically link-layer (operates over local broadcast domains) but is often grouped with the Internet/Network layer because it directly resolves addresses for IP. Textbooks and academic courses overwhelmingly adopt the 5-layer model because isolating physical transmission properties (cables, modulation) from framing algorithms is essential for conceptual clarity.

Why layers matter: the service model

Each layer provides a service to the layer above via a well-defined interface, and uses the service of the layer below. For example:

• The Transport layer asks the Internet layer: "Deliver this segment to 203.0.113.10 (illustrative address)." It doesn't care whether the path uses Ethernet, Wi-Fi, or a 4G radio link.
• The Application layer asks the Transport layer: "Give me a reliable byte stream to port 443." It doesn't care about sequence numbers or retransmissions.

This abstraction is what allowed HTTP, which was designed in 1991, to run over HTTP/3+QUIC in 2022 without any changes to what HTTP means — only the layers underneath changed.

Encapsulation and decapsulation — in detail

When data travels down the stack at the sender, each layer wraps the payload from the layer above with its own header (and sometimes a trailer). This is encapsulation. At the receiver, each layer peels off its header — decapsulation.

The PDU names at each layer:

• Application → produces data (e.g. an HTTP message)
• Transport → adds TCP/UDP header → segment (TCP) or datagram (UDP)
• Internet → adds IP header → packet
• Link → adds Ethernet header + FCS trailer → frame
• Physical → encodes as electrical/optical/radio signals → bits

How decapsulation knows which upper-layer protocol to call

When an incoming frame arrives at a network interface card (NIC), the receiving operating system must determine which software protocol handler should process the inner payload at each step up the stack. Every layer solves this by embedding a standardised demultiplexing key (a type/protocol identifier field) inside its header:

Note that an Ethernet frame carrying a minimum-sized TCP segment over IPv4 has:

Ethernet header (14 B) + IP header (20 B) + TCP header (20 B) + data + FCS (4 B)
= 58 bytes of overhead before any application data even begins

On the wire, each transmitted frame also costs an 8-byte Preamble + Start Frame Delimiter (SFD) for receiver clock synchronization, as well as a minimum 12-byte Inter-Frame Gap (IFG) of idle silence. Therefore, raw wire capacity and transmission-line calculations should add 20 bytes of physical-layer overhead per frame to the link-layer size.

Worked calculation — Protocol Efficiency and Goodput on 1 Gbps Ethernet:

1. Application payload per frame (MSS) : 1,500 (MTU) − 20 (IP) − 20 (TCP) = 1,460 bytes
2. Total link-layer frame size         : 1,460 (data) + 20 (TCP) + 20 (IP) + 14 (Eth) + 4 (FCS) = 1,518 bytes
3. Total bytes consumed on physical wire: 1,518 (frame) + 7 (Preamble) + 1 (SFD) + 12 (IFG) = 1,538 bytes
4. Wire protocol efficiency             : 1,460 ÷ 1,538 ≈ 0.949285 (94.93%)
5. Theoretical max goodput at 1 Gbps    : 1,000 Mbps × 0.949285 ≈ 949.3 Mbps

This 94.93% wire efficiency explains why an internet speed test on a 1 Gbps Gigabit Ethernet cable tops out around 940–949 Mbps, never reaching the full 1,000 Mbps link rate. Even when the physical cable is 100% saturated with data, the missing ~51–60 Mbps is fundamentally consumed by Ethernet headers, IP headers, TCP acknowledgements, and physical line framing.

Note that application-layer header compression schemes like HPACK (HTTP/2) and QPACK (HTTP/3) compress HTTP headers only, not the underlying Ethernet, IP, or TCP headers. Fixed lower-layer overhead matters most for small packets (such as TCP ACKs, DNS queries, or VoIP audio frames), where 58 bytes of headers can easily exceed the payload itself. In bandwidth-constrained environments, header compression for lower layers does exist — such as ROHC (Robust Header Compression, RFC 3095/5795) on cellular networks and 6LoWPAN (RFC 6282) in IoT sensor networks, which compress 40-byte IPv6/UDP headers down to just 2 to 4 bytes.

Peer-to-peer communication: the illusion of direct dialogue

Although data physically moves down the sender's stack, across the wire, and up the receiver's stack, each layer logically communicates with the same layer on the remote machine. The TCP layer on your laptop sends a segment that the TCP layer on the server receives — the IP and Ethernet layers are transparent to TCP. This is why we say layers communicate with their peers.

This separation creates a fundamental distinction between end-to-end layers and hop-by-hop layers across intermediate network devices:

• End hosts (Host A & Host B): Implement the full 5-layer stack (Physical up to Application). The Transport layer (Layer 4) and Application layer (Layer 5/7) are strictly end-to-end: their headers are generated by Host A and inspected only by Host B. Intermediate networking devices do not modify or terminate them.
• Link-layer Switch (Layer 2 device): Operates only through Layers 1 and 2. A switch receives physical bits (Layer 1), verifies the Ethernet FCS trailer and inspects the 6-byte destination MAC address (Layer 2), and forwards the exact same frame out the appropriate switch port. The switch never modifies MAC addresses or inspects the inner IP packet.
• Router (Layer 3 device): Operates through Layers 1, 2, and 3. A router receives incoming bits (Layer 1), validates and completely discards the incoming Layer 2 Ethernet header and FCS (Layer 2), inspects the destination IP address in the routing table, and decrements the IP TTL counter (Layer 3). It then encapsulates the IP packet inside a brand-new Layer 2 frame with new source and destination MAC addresses tailored for the next hop link.

Where TLS fits in practice

TLS technically sits between the Application and Transport layers — it's what OSI would call the Presentation layer. In the TCP/IP model it's simply part of the Application layer from a conceptual standpoint, but it's implemented as a library that wraps the TCP socket. Understanding this explains why TLS handles encryption but TCP still handles retransmission and ordering.

Interactive: click a layer to see its header