---

You open a website and it remembers who you are. You join a video call and it feels like a smooth conversation. You SSH into a server and it stays connected until you log out.

But are these sessions real? Or are they just illusions maintained by careful design?

This post peels back the layers—literally. We’ll walk through how different layers of the network stack create the illusion of continuity, and show why there is no magic—just memory.

The Layered Illusion

To understand sessions, we need to understand where memory lives. Not human memory—but machine memory. What keeps your presence alive? What forgets you the moment you’re silent?

We’ll use the OSI model (layers 2 to 7) as a conceptual tool. Not because it’s perfect—but because it’s still useful to reason about where state lives in a system designed for stateless transmission.

And hopefully by the end you will understand that a session is not an unbreakable chain of electrons between your PC and server or someone elses PC.

Layer 2: The Wire Forgets You

At the Data Link Layer, you’re just an address on a local network.

Switches forward Ethernet frames based on your MAC address. But they only know your MAC if you’ve sent something recently. If you go quiet, they forget you.

There is no concept of session. No identity. No continuity.

Illusion: Proximity and timing simulate continuity.
Reality: You exist only as long as your frames do.

Layer 3: Delivery, Not Memory

The Network Layer (IP) is about routing. Packets are addressed to IPs, sent blindly from source to destination.

Routers don’t care who you are. They don’t track state. They don’t expect a reply. They just forward packets.

Illusion: Routing gives the appearance of consistent reachability.
Reality: Each packet is stateless cargo—your identity isn’t tracked.

Layer 4: Memory Begins to Take Shape

The Transport Layer introduces real, short-term memory.

With TCP, the operating system maintains:

• Sequence numbers
• Acknowledgments
• Connection state (open/closed)

If a TCP connection is active, your presence is known. But the moment it’s closed (or your device reboots), it’s gone.

UDP doesn’t even try—there’s no memory, no handshake, no tracking.

Illusion: TCP creates reliable streams that feel like conversations.
Reality: You’re a temporary entry in an OS table, gone on disconnect.

Layer 5: Sessions as Memory

Here’s where the word session starts to mean something.

Protocols like WebSocket, SSH, and SIP maintain persistent, stateful connections. Your authentication, permissions, and session variables live in memory.

You can stream data, exchange messages, maintain a cursor—all over a live, continuous session.

But disconnect, and that state vanishes unless the app has chosen to preserve it somewhere.

Illusion: A persistent session is real.
Reality: It’s RAM. Pull the plug, and it evaporates.

Layer 6: Presentation, Formatting, and Encryption

At the Presentation Layer, data is encoded and decoded. Think:

• TLS (encryption)
• Gzip (compression)
• JSON (serialization)

TLS session resumption allows the reuse of keys to avoid repeating handshakes. But that’s not a session in the user sense—it’s cached cryptographic context.

Illusion: The connection resumes seamlessly.
Reality: You’re renegotiating, just skipping a few steps.

Layer 7: The Grand Illusion

The Application Layer is where sessions are most obviously faked.

HTTP is stateless. Each request is independent. Yet somehow, your browser remembers you’re logged in.

How?

• Cookies hold session IDs
• Session IDs map to backend memory
• Tokens (like JWTs) carry identity in a signed package

Your session is remembered not by the network, but by the application choosing to track you.

Illusion: The server knows you.
Reality: The server just recognizes your token.

But Wait… Isn’t That All Sessions?

Yes—and that’s the point.

Every session is a construct:

• Some live in live memory (e.g. WebSocket, SSH)
• Some in persistent identifiers (e.g. HTTP cookies)
• Some in encrypted keys (e.g. TLS resumption)

Each one gives the appearance of continuity. But it’s all managed, stored, and reconstructed. Nothing about it is automatic.

There is no inherent continuity in the network stack. Only design choices that simulate it.

Real-World Sessions

Examples That Reveal the Illusion

Let’s look at real-world examples to better see how session continuity is negotiated—or simulated—across very different systems.

A user session on a website

Most of us just see the website. But that website is technically an HTML file served by a backend. That backend could be powered by Apache, Nginx, or something else—but it’s ultimately a server somewhere.

By default, web servers establish memory-based sessions. But so you don’t have to log in every day, session data can be saved in a file or database—making it persist even across a server reboot. Usually this persistence is managed by the application running behind Apache or Nginx.

There’s another option too: the session could be stored in a Redis database, keeping it in memory but shared across multiple processes or machines. This is common in high-throughput systems that handle billions of requests. Hybrid approaches are also common: Redis for speed, and Postgres or MySQL for durability.

But how does the server distinguish your request from millions of others? Easy: your browser sends a session token with each request—typically a cookie or JWT. The server checks that token and, if valid, replies with your personalized content.

This happens every time you click a link or refresh your window. Even modern single-page apps that don’t hit the server on every interaction still revalidate periodically or on page reload.

HTTP sessions are the clearest example of faked continuity. You are re-authenticated constantly—it just doesn’t feel that way.

A video call

A less obvious example is a video call. It feels like a stream—but what is actually happening?

Like a flipbook, your browser sends and receives many frames per second. That is a true, continuous stream. But what if someone turns off their camera or mutes their mic? The stream pauses, but the session is still alive.

Alive?
Indeed, unmuting resumes activity instantly because the “session” is only memory of where the stream must go—not a tether connecting 2 devices.

The difference between this and the website example is that we don’t need to preserve the session after it ends. Once the call ends, the state is gone.

However, many video conferencing apps assign unique room IDs. You can reconnect later using that ID, and reestablish the session. So what is the session in this case? Just a negotiated stream: who’s connected, what media is flowing, and where it should go. And the ID is just a place to connect.

Place?
Well, probably just a few lines of code restricting the session to the few that connect “there”.

Under the hood, video calls often involve multiple sessions: An HTTP session for login, and a WebRTC session for the media.

Types of Sessions

Below are common session types, each managing continuity in its own way:

WebSocket

Used in chat and real-time apps

A persistent connection that stays open. It can notify you when someone is typing. It feels instant. But if no one is sending messages, there’s no data—just an open socket kept alive by heartbeats. And what is an open socket, really? Just an addressable process on a server—not a hand reaching across the internet.

Push notifications, on the other hand, are a session with a different server—Google (FCM) or Apple (APNS)—not the chat app itself.

WebRTC

For peer-to-peer live video and audio

An open standard for direct peer-to-peer audio/video. In 1:1 calls, it connects users directly. But with 3+ people, everyone connects to everyone—very inefficient. That’s why larger calls use a Selective Forwarding Unit (SFU) that routes streams efficiently.

WebRTC sessions depend on:

• Signaling servers (to coordinate setup)
• STUN servers (to discover public-facing IPs)
• TURN servers (fallback relays when direct P2P fails)
• SFUs (media routers for group calls)

This is a multi-session system, often layered on top of an existing HTTP-authenticated user session.

HTTP

The most common of all, the standard of the Web

Covered above—sessions rely on cookies or tokens passed with each request, and data persisted on the backend.

TLS

It’s the “S” in HTTPS—the encrypted transport

It negotiates a session key between your browser and the server. That session protects all traffic from prying eyes, but only lasts for the duration of the connection—unless resumed later via cached key material.

SIP

Commonly recognized as VoIP—but SIP is the underlying session

Used in apps that place calls over the internet or connect to the traditional phone network (POTS). SIP negotiates a session that includes your identity, the destination, and session parameters. The session lives only while the call is active.

Like other protocols, SIP sessions are maintained while active, and not continuously streaming.

And many more

These are just a few. The key idea: a session is always a negotiation of where data should go, what it should contain, and how long it should be remembered. There is no magical thread tying you to the other side—just a shared illusion constructed from agreements and memory.

The Moment the Illusion Breaks

• Reboot your PC: TCP and WebSocket connections die.
• Kill your cookies: your HTTP session dies.
• Unplug your cable: your MAC is forgotten by the switch.
• Disable encryption cache: TLS starts fresh.

Every session you’ve ever had can be broken by simply clearing memory.

Why This Matters

Understanding this matters because it changes how you:

• Debug apps (“Where is state lost?”)
• Design protocols (“Should I hold this in memory?”)
• Handle security (“What if this token is stolen?”)
• Build user experiences (“What feels like continuity?”)

If you believe there’s magic, you’ll trust abstractions too much. If you understand the memory, you can control the illusion.

Closing Thought

The next time you hear someone say, “my session expired,” remember:

Sessions don’t expire.
They’re forgotten.

---