---
title: 'TCP/IP Model'
source: 'https://academia.sh/en/courses/network-models/tcp-ip-model'
course: 'Network Models and Protocols'
language: en
updated: '2026-08-17T18:07:07+00:00'
license: 'CC BY-SA 4.0'
---

# TCP/IP Model

The four-layer practical model, its mapping onto OSI, the hourglass architecture, and the end-to-end principle's effect on design.

The previous lesson introduced a seven-layer reference model and noted that it
does not fit implemented stacks exactly. The stack that runs on the Internet
comes from a different lineage: the protocols were written first, and the
model was described afterward to describe them.

This lesson's question is how that stack is actually divided, and what design
decisions the division forces. The resulting structure is distinguished not by
its number of layers, but by the singularity of the one layer in the middle.

## The Four Layers

The TCP/IP model defines four layers:

| No | Layer | Responsibility | Example protocol class |
|---|---|---|---|
| 4 | Application | Application-specific exchange rules | Resource transfer, name resolution, mail |
| 3 | Transport | End-to-end multiplexing and optional reliability | TCP, UDP |
| 2 | Internet | Inter-network addressing and path selection | IP, ICMP |
| 1 | Link | Frame delivery on a single network | Ethernet, wireless LAN |

The model's name comes from its two central protocols: **IP (Internet
Protocol)** and **TCP (Transmission Control Protocol)**. The name can be
misleading: the Transport layer holds other protocols besides TCP, and the
model does not exclude them.

Two points where the model departs from OSI stand out. First, OSI's Physical
and Data Link layers merge here into a single **Link layer**. This merger is
deliberate: IP promises not to know the details of the network technology
beneath it, so how many layers those details are divided into is not its
concern. Second, OSI's Session and Presentation layers do not exist as
separate layers; their functions are left to the Application layer.

## Mapping the Two Models

| OSI | TCP/IP | Note |
|---|---|---|
| 7 Application | Application | Direct correspondence |
| 6 Presentation | Application | Encoding and encryption fall to the application or a library |
| 5 Session | Application | Dialog management is not a separate layer |
| 4 Transport | Transport | Direct correspondence |
| 3 Network | Internet | Direct correspondence |
| 2 Data Link | Link | Merger |
| 1 Physical | Link | Merger |

The places where the mapping breaks down need to be known. Secure transport
protocols use the Transport layer's stream and encrypt the application data;
they fall to the Presentation layer in the OSI vocabulary and to the
Application layer in the TCP/IP vocabulary. An address resolution protocol
translates a Network-layer address into a Link-layer address and belongs to
both layers at once. When tunneling is used, a Network-layer packet becomes
the payload of another Network-layer packet; the layer sequence repeats.

For this reason, the practical value of layer numbers is not precise
classification but a shared vocabulary. Saying a problem is "a Layer 3
problem" is a shorthand for saying the problem has to do with path selection.

## The Hourglass Architecture

The distinguishing feature of the TCP/IP stack is not its number of layers,
but **the distribution of protocol diversity per layer**.

The Link layer holds a large number of technologies: wired LANs, wireless
LANs, cellular connections, satellite links, point-to-point serial lines. The
Application layer likewise holds countless protocols. In the middle, however,
stands **a single protocol**: IP.

This structure is called the **hourglass**: width at both ends, a narrow neck
in the middle. The narrowness of the neck is not a limitation but the
architecture itself. Because there is a single protocol in the middle:

- The moment a new link technology learns to carry IP packets, it becomes
  available to every application. None of the applications need to change.
- The moment a new application protocol runs over IP, it becomes reachable
  over every link technology. No change is needed in the network
  infrastructure.

A product turns into a sum here: for $n$ link technologies and $m$
application protocols, instead of writing $n \times m$ adaptations, $n + m$
adaptations suffice. The cost of the neck is the difficulty of changing IP
itself: touching the narrow neck concerns everything at both ends. This
structure is why widening the address space is a project that has spanned
decades — a subject taken up in the IPv6 lesson.

## The End-to-End Principle

TCP/IP's second decisive design decision concerns where functions are
carried out. The **end-to-end principle** states that a function should not
be placed inside the network unless it can only be carried out by the network
itself — a function the endpoints can perform on their own should stay at the
endpoints.

The reasoning is a correctness argument. An application that wants to be sure
a file was transferred without error must verify this itself: even if every
intermediate node performs error checking on its own link, memory corruption
or a software bug inside a node falls outside those checks. Since verification
at the endpoint is required regardless, verification in between is not
necessary for correctness. Checking at intermediate nodes is only a
performance optimization: discarding a corrupted frame early is cheaper than
carrying it all the way to the endpoint and discarding it there.

The concrete consequence of this principle is that the service IP offers is
**best-effort**. IP does not prevent packet loss, reordering, or duplication.
Whoever wants these corrected corrects them at the Transport layer or in the
application. The Network layer is kept simple; complexity is pushed to the
endpoints.

There is a cost as well. Because the network does not know what traffic it is
carrying, it cannot give traffic-specific guarantees. Prioritizing a
latency-sensitive stream requires extra mechanisms. Address translation and
stateful middleboxes directly strain the principle; this tension is taken up
in the NAT and PAT lesson.

## The Layers' Counterpart on the Example Network

Over the enterprise network introduced in the previous lesson, the four
layers' counterpart is as follows. When the client at `192.168.10.196`
requests a resource from the server at `198.51.100.20`:

| Layer | What happens at this step | Address used |
|---|---|---|
| Application | The request is formatted | The resource's name |
| Transport | The request is fitted into a connection, given a sequence number | Port 49152 → 443 |
| Internet | The path is chosen based on the destination address | 192.168.10.196 → 198.51.100.20 |
| Link | The frame is delivered to the gateway | 00:00:5e:00:53:01 → the gateway's hardware address |

The distinction to notice is this: **Link-layer addresses change at every
step, Network-layer addresses do not.** In the frame from the client to the
gateway, the destination hardware address is the gateway's; in the frame from
the gateway to the provider, the destination hardware address is the
provider's router's. By contrast, the source and destination addresses in the
IP header stay the same along the entire path — the exception to this rule is
address translation.

This distinction is the direct consequence of the two layers' difference in
scope: the Link layer's scope is a single link, the Network layer's scope is
the end-to-end path.

## Which Model, When

The two models are not competitors; they serve different jobs.

The OSI model is well suited for **teaching and diagnosis**. Seven layers
give someone trying to narrow down a problem's scope a finer grid; separating
the Physical layer from the Data Link layer makes it easier to distinguish a
cable fault from an addressing fault.

The TCP/IP model is the correct description for **implementation**. An
operating system's network stack is structured around these four layers: the
socket interface sits above the Transport layer, the routing table lives at
the Internet layer, the interface drivers are at the Link layer.

This course uses both vocabularies: OSI numbering when referring to layer
numbers, TCP/IP's division when describing where protocols sit.

## Summary

- The TCP/IP model consists of four layers: Link, Internet, Transport,
  Application.
- OSI's Physical and Data Link layers merge into the Link layer; the Session
  and Presentation layers do not appear as separate layers.
- In the hourglass architecture, a single protocol (IP) stands in the
  middle; this narrowness reduces the $n \times m$ adaptation problem to
  $n + m$, at the cost of making IP itself hard to change.
- Under the end-to-end principle, a function is not placed inside the
  network if it can be carried out at the endpoints; IP offering a
  best-effort service is a consequence of this principle.
- On a packet's journey, Link-layer addresses change at every step, Network-
  layer addresses do not.
- OSI is used for diagnosis and teaching, TCP/IP for describing
  implementation.

## Next Step

Both models say that data is wrapped as it moves through the layers, but the
wrapping itself has a cost: each layer adds its own header, and these headers
take up space that could carry data. The next lesson takes up the mechanics
of encapsulation at the bit level, builds an IP header field by field, and
calculates what percentage of the payload goes to headers.