A note on scope: in the classic OSI model, Layer 5 handles session setup, dialog control, and synchronization. In the TCP/IP stack most networks actually run, that job is absorbed into the application layer (cookies, session tokens, RPC binds, SIP dialogs) — so this sheet covers the real-world mechanisms that do session-layer work today, not command output from a router.
Negotiates and opens a logical session between two applications — separate from, and on top of, the underlying transport connection.
Keeps track of session state across multiple requests/exchanges — even if the underlying TCP connection is closed and reopened.
Graceful teardown (logout, BYE, session expiry) or abrupt end (timeout, crash, forced revoke).
One direction only — e.g. a syslog feed or a broadcast stream with no return channel.
Both directions possible, but only one talks at a time — e.g. classic request/response turn-taking.
Both sides send simultaneously — e.g. an active voice call, or a WebSocket session.
The session layer can insert checkpoints into a long-running exchange (e.g. a large file transfer). If the session drops, it resumes from the last checkpoint instead of restarting from zero — the same idea behind HTTP Range requests and resumable uploads.
| Mechanism | Role |
|---|---|
| NetBIOS Session Service | Establishes a named session between two hosts before SMB file/print sharing begins |
| RPC (Remote Procedure Call) | Binds a client to a remote service instance, maintains call context across requests |
| SIP | Sets up, modifies, and tears down real-time voice/video sessions (dialogs) |
| SOCKS | Proxy-layer session negotiation between a client and a relay server |
| NFS session state | Tracks open file handles and locks across a mount session |
| PPTP control session | Manages a VPN tunnel's control channel separately from the data tunnel |
| Web application sessions | Cookie/token-based state tying a browser to a logged-in server-side session |
Server caches session parameters keyed by an ID; on reconnect, client presents the ID to skip a full handshake.
Server encrypts session state into a ticket handed to the client — no server-side cache needed, easier to scale across load-balanced servers.
User submits username/password over an existing TCP+TLS connection. This is application-layer data — the session layer hasn't acted yet.
Pre-sessionOn success, the server generates a session record (or signs a token) representing "this user is logged in," independent of any single TCP connection.
Session establishmentSent back as a cookie or token. The client will present this on every subsequent request — this identifier is what ties disconnected HTTP requests into one continuous session.
Identifier issuanceEven though the underlying TCP connection may open and close repeatedly, the session layer's job is making each request "remember" who the user is by validating the session ID/token.
Session maintenanceServer expires the session after inactivity, or the user logs out explicitly — either way the session record is invalidated (or the token's expiry passes).
Session terminationAny further request with the old session ID/token is rejected — the user must re-establish a session (log in again) before continuing.
Post-session| Symptom | Likely Cause |
|---|---|
| User randomly logged out | Session timeout too short, or sticky-session load balancer routing to a different server without shared session store |
| Session hijacking | Session ID stolen via XSS, unsecured cookie (missing Secure/HttpOnly flags), or predictable session IDs |
| Session fixation | Server accepts a session ID the attacker already knows, instead of issuing a fresh one at login |
| Call drops mid-conversation (SIP) | Session refresh/re-INVITE failing, NAT timeout on the signaling path |
| Session lost across servers | No shared/centralized session store in a multi-server deployment |
| Mitigation | Practice |
|---|---|
| Cookie hardening | Secure, HttpOnly, SameSite flags |
| Session ID strength | Cryptographically random, high entropy |
| Regenerate on privilege change | New session ID issued after login/privilege escalation |
| Centralized session store | Redis/DB-backed sessions shared across servers |
| Explicit expiry | Idle timeout + absolute max session lifetime |