Quick reference

Why two models exist

The internet is too complex to reason about as one giant blob, so engineers divide communication into layers. Over time, two different abstractions emerged, each solving a different problem.

OSI Model (7 layers)

A conceptual and teaching framework.

It answers:

"What kinds of responsibilities exist in network communication?"

The OSI model separates concerns such as:

• data representation
• encryption
• session management
• reliability
• routing
• physical transmission

TCP/IP Model (4 layers)

The model that actually powers the internet.

It answers:

"How does data really travel from my application to another machine?"

The four layers are:

1. Application
2. Transport
3. Internet
4. Link (Network Access)

Mental shortcut

Think of them like this:

• OSI = a conceptual map explaining the jobs involved
• TCP/IP = the actual plumbing that performs those jobs

Or:

OSI tells us what concerns exist.

TCP/IP tells us what protocols actually move data.

The key insight

For everyday web traffic:

Browser
   ↓
HTTP
   ↓
TLS
   ↓
TCP
   ↓
IP
   ↓
Ethernet / WiFi

Everything that OSI calls:

• Presentation layer
• Session layer

usually becomes application-layer logic implemented by libraries.

Presentation concerns

• JSON serialization
• UTF-8 encoding
• Compression (gzip, Brotli)
• TLS encryption

Session concerns

• Cookies
• JWT tokens
• Authentication state
• WebSocket connections

These concerns are real and useful to discuss, but they are usually not separate protocol hops.

This doesn't mean OSI is wrong. It means:

OSI describes concerns, while TCP/IP describes plumbing.

They're different dimensions of describing the same system.

A more realistic picture

Instead of imagining a flat 7-layer stack, for most web applications think:

Application Layer
├── HTTP
├── JSON serialization
├── Character encoding
├── Compression
├── Cookies / JWT
├── Authentication
└── TLS libraries
        ↓
Transport Layer
├── TCP
└── UDP + QUIC
        ↓
Internet Layer
└── IP (IPv4 / IPv6)
        ↓
Link Layer
├── Ethernet
├── WiFi
└── Physical transmission

Where TLS actually sits

TLS is protocol-agnostic. HTTP, SMTP, IMAP, and many other application protocols can run over TLS without modification.

Many engineers think of it as:

HTTP
↓
TLS
↓
TCP
↓
IP
↓
Ethernet

rather than HTTP sitting directly on TCP.

Application
↓
TCP

Applications invoke TLS libraries like OpenSSL, BoringSSL, or LibreSSL, which encrypt outgoing data and decrypt incoming data.

Because TLS sits logically between application protocols and transport protocols, many engineers informally call it:

Layer 4.5

Encapsulation — how layers cooperate

As data moves downward through the stack, every layer wraps the data with its own header. This process is called encapsulation:

Application Data
        ↓
TCP Segment
        ↓
IP Packet
        ↓
Ethernet Frame
        ↓
Bits

Each layer adds information needed for its own responsibilities. On the receiving side, these headers are removed in reverse order. This is called decapsulation.

Walking through a real request: POST /hello

Suppose your application sends:

POST /hello HTTP/1.1
Host: api.example.com
Content-Type: text/plain

Hello World

1. Application layer — everything starts here

Your browser, Node.js application, Postman, or Go program decides the URL, method, headers, and body. At this point, Hello World is just data in memory.

2. Application-layer concerns

Before anything reaches TCP, several things may happen.

Serialization — objects become portable representations:

{
  message: "Hello World";
}

becomes:

{ "message": "Hello World" }

which becomes bytes: 48 65 6c 6c 6f ...

Character encoding — strings become UTF-8 bytes.

Compression — data may be compressed using gzip or Brotli to reduce network traffic.

TLS encryption — plaintext becomes encrypted binary:

Hello World
        ↓
8f a3 91 2c ...

This encryption is typically performed by OpenSSL or BoringSSL.

Session and identity — applications maintain state through:

• Cookies: Server sends Set-Cookie: sessionId=abc123; future requests automatically include Cookie: sessionId=abc123
• JWT: Authorization: Bearer eyJhbGciOi... — the server decodes the token to identify the user
• WebSockets: the connection remains open, and the live socket itself acts as session state

Everything above belongs conceptually to the OSI Presentation and Session layers, but in practice is usually handled inside the TCP/IP Application layer.

3. Transport layer — TCP, the real engine

Connection establishment — TCP performs the three-way handshake:

SYN
    ↓
SYN-ACK
    ↓
ACK

Ports — IP identifies a machine; ports identify processes running on that machine:

192.168.1.5:50123
            ↓
93.184.216.34:443

Where the IP address identifies the destination machine and port 443 identifies the HTTPS server process. Without ports, multiple applications couldn't communicate simultaneously.

Segmentation — TCP divides the byte stream into segments containing source/destination ports, sequence numbers, acknowledgements, and window information.

Reliability — TCP detects missing data and retransmits it, providing reliable delivery, ordered delivery, duplicate detection, flow control, and congestion control. To the application, TCP behaves like a reliable byte stream.

TCP is not the only transport protocol

Most traditional web traffic (HTTP/1.1, HTTP/2) uses:

HTTP → TLS → TCP → IP

However HTTP/3 uses:

HTTP → QUIC → UDP → IP

QUIC implements reliability itself on top of UDP — it isn't a peer to TCP/UDP so much as a reliable-transport layer built above UDP.

TCP is one transport protocol, not the transport layer itself.

4. Internet layer — IP, global routing

TCP segments are wrapped inside IP packets:

IP Header + TCP Segment + Application Data

IP provides source address, destination address, TTL, and fragmentation information. Routers use this to decide where packets should go. IP's responsibility is routing, not reliability — and exists in two versions in use today, IPv4 and IPv6.

5. Link layer — local delivery

The IP packet is wrapped inside a frame:

MAC Header + IP Packet + CRC

Responsibilities include Ethernet/WiFi framing, MAC addresses, error detection (CRC), and local network delivery.

What about the Physical layer?

TCP/IP combines OSI's Data Link and Physical layers into one Link layer. Underneath, information becomes physical signals — electrical pulses on copper, light pulses in fiber, radio waves for WiFi. Eventually, everything becomes a stream of bits.

010101010101...

Server side — the same process in reverse

The receiving machine performs decapsulation:

Bits
↑
Ethernet Frame
↑
IP Packet
↑
TCP Segment
↑
TLS Decryption
↑
HTTP Parsing
↑
Application

Step by step:

1. Receive electrical signals, light pulses, or radio waves.
2. Reconstruct frames.
3. Verify frame integrity.
4. Process IP packets.
5. Reassemble TCP segments.
6. Decrypt TLS.
7. Parse HTTP.
8. Extract the body.

Eventually: req.body = "Hello World"

HTTP parsing isn't done by the kernel

The path is more like:

NIC
↓
Kernel
↓
TCP Socket
↓
Nginx / Node.js / Go Server
↓
HTTP Parser
↓
Application

HTTP parsing is application-layer work, not something IP or TCP performs.

Summary

The OSI model is a conceptual framework for discussing networking responsibilities, while TCP/IP is the protocol stack that actually powers the internet. For most web applications, what OSI calls the Presentation and Session layers — serialization, compression, encryption, cookies, JWTs, and authentication — are implemented as application-layer logic rather than separate protocol layers. Data flows through four real layers: Application, Transport, Internet, and Link. During transmission, encapsulation adds headers at each layer, and the receiving side performs decapsulation in reverse. HTTP defines meaning, TLS provides security, TCP or QUIC provide reliable transport, IP handles routing, and the Link layer ultimately moves bits across the physical medium.