TCP/IP Model — How the 4/5-Layer Model Maps to Reality vs OSI

Concrete Example

Take a single ordinary act: a program fetches https://example.com/. Reading the layers off that one request is the fastest way to make the model stop feeling like trivia.

At the Application layer, two protocols are stacked inside one layer — TLS wrapping HTTP — with no layer boundary between them, because TCP/IP has nowhere else to put encryption:

Application  ──  TLS record  { HTTP/1.1 request }
                    GET / HTTP/1.1
                    Host: example.com

The application hands those bytes down through a socket. This is the App↔Transport boundary made literal — every line below is the application layer, and send() is the exact moment the Transport layer takes over:

import socket, ssl

raw = socket.socket(socket.AF_INET, socket.SOCK_STREAM)  # SOCK_STREAM → TCP
raw.connect(("93.184.216.34", 443))                       # (IP address, port)

# TLS is *not* a separate layer — it is application code wrapping the socket.
tls = ssl.create_default_context().wrap_socket(raw, server_hostname="example.com")

tls.send(b"GET / HTTP/1.1\r\nHost: example.com\r\n\r\n")   # ← App hands bytes to Transport
print(tls.recv(4096))

Notice what the socket call already contains: a port (443 — a Transport-layer concept) and an IP address (93.184.216.34 — an Internet-layer concept). The API deliberately exposes exactly the two layers below it and nothing further down. Your code never names an Ethernet MAC address or a Wi-Fi channel; those are the Link layer's business, decided hop by hop and invisible from here.

On the wire, the same request appears as nested headers, one per layer below the application — the shape that encapsulation produces:

Link      | Ethernet dst=aa:bb:cc:dd:ee:ff src=... type=0x0800   ← one hop only
Internet  |   IP  src=192.168.1.20  dst=93.184.216.34  proto=6   ← host to host
Transport |     TCP src=51514  dst=443  seq=...                  ← process to process
Application|      TLS record → HTTP/1.1 GET /                    ← what the app means

Each layer answers a different question, and each answer has a different lifetime. The Ethernet header is rewritten at every router hop, because "the next machine on this cable" changes constantly. The IP header survives the whole journey end to end. The TCP header identifies the two processes. And the application payload is the only part anyone actually wanted to send.

Mapping the things a working engineer touches onto that stack:

Visual Model

Two questions usually get asked separately, so they get answered separately — and that is why the topic feels muddled. "How does OSI map onto TCP/IP?" and "why is IP special?" are the same picture seen from two sides. Line the models up as columns and the mapping is obvious: the middle never moves, and only the top and bottom get reorganized. Now look at the same vertical bands from the right, counting how many real protocols sit in each one, and the stack stops being a rectangle. It bulges at the top (every app protocol ever written), bulges at the bottom (every transmission technology ever built), and pinches to a single point in the middle. That pinch is IP.

The diagram below is one figure doing both jobs. Height means layer on both sides: whatever row you are reading in the columns on the left is the same row you are reading in the hourglass on the right. Step through it, then hover or click any protocol name in the hourglass to watch it funnel through the waist.

The payoff of the right-hand side is historical, not aesthetic. Because the only thing every party had to agree on was IP, a new application could be invented without asking any network operator's permission, and a new transmission technology could be deployed without asking any application author's permission. Neither side had to coordinate with the other — they only had to meet at the waist. That is the concrete mechanism behind "the internet scaled explosively," and it is the same narrow-waist argument that shows up later in API and platform design.