OSI L5: Сеансовий рівень (Session Layer)¶
Що таке сеансовий рівень?¶
Сеансовий рівень відповідає за встановлення, управління та завершення сесій між додатками. Сесія — це логічний зв'язок між двома процесами, що дозволяє їм обмінюватися даними.
┌─────────────────────────────────────────────────────────────────┐
│ L4 = Транспортування даних (TCP/UDP з'єднання) │
│ L5 = Управління діалогом (хто говорить, коли, як довго) │
│ │
│ Приклад відеодзвінка: │
│ • Встановлення сесії (login, auth) │
│ • Підтримка сесії (keep-alive) │
│ • Синхронізація (checkpoints) │
│ • Завершення сесії (logout, timeout) │
└─────────────────────────────────────────────────────────────────┘
Примітка: У моделі TCP/IP рівні 5-7 об'єднані в один Application layer. Сеансовий рівень — концептуальний, його функції часто виконують протоколи L7.
Функції сеансового рівня¶
1. Встановлення сесії (Session Establishment)¶
┌────────────────────────────────────────────────────────────────┐
│ Session Setup │
├────────────────────────────────────────────────────────────────┤
│ │
│ Client Server │
│ │ │ │
│ │ 1. Session Request (credentials) │ │
│ │ ───────────────────────────────────────────▶ │ │
│ │ │ │
│ │ 2. Authentication / Negotiation │ │
│ │ ◀─────────────────────────────────────────── │ │
│ │ │ │
│ │ 3. Session Established (session ID) │ │
│ │ ───────────────────────────────────────────▶ │ │
│ │ │ │
│ │ ════════════ СЕСІЯ АКТИВНА ════════════ │ │
│ │
└────────────────────────────────────────────────────────────────┘
2. Підтримка сесії (Session Maintenance)¶
┌────────────────────────────────────────────────────────────────┐
│ Session Keep-Alive │
├────────────────────────────────────────────────────────────────┤
│ │
│ Client Server │
│ │ │ │
│ │ Keep-alive ping │ │
│ │ ─────────────────────────────────────────────▶ │ │
│ │ │ │
│ │ Keep-alive pong │ │
│ │ ◀───────────────────────────────────────────── │ │
│ │ │ │
│ │ ... кожні N секунд ... │ │
│ │ │ │
│ │ Якщо немає відповіді → сесія закривається │ │
│ │
└────────────────────────────────────────────────────────────────┘
3. Завершення сесії (Session Termination)¶
Нормальне завершення:
┌─────────────────────────────────────────────────────────────────┐
│ User: "Logout" │
│ Client → Server: Session Close Request │
│ Server → Client: Session Closed Acknowledgment │
│ Ресурси звільнені │
└─────────────────────────────────────────────────────────────────┘
Аварійне завершення (timeout):
┌─────────────────────────────────────────────────────────────────┐
│ Client перестав відповідати │
│ Server: Timeout (300 секунд без активності) │
│ Server: Примусове закриття сесії │
│ Ресурси звільнені │
└─────────────────────────────────────────────────────────────────┘
Режими діалогу¶
Simplex (односторонній)¶
┌────────┐ ┌────────┐
│ Sender │ ════════════════════════▶ │Receiver│
└────────┘ Тільки в один бік └────────┘
Приклад: Broadcast TV, radio
Half-Duplex (почерговий)¶
┌────────┐ ┌────────┐
│ A │ ════════════════════════▶ │ B │
└────────┘ └────────┘
Тепер B говорить:
┌────────┐ ┌────────┐
│ A │ ◀════════════════════════ │ B │
└────────┘ └────────┘
Приклад: Рація (walkie-talkie), деякі протоколи
Full-Duplex (одночасний)¶
┌────────┐ ════════════════════════▶ ┌────────┐
│ A │ │ B │
└────────┘ ◀════════════════════════ └────────┘
Одночасно в обидва боки
Приклад: Телефон, відеодзвінок, TCP з'єднання
Синхронізація та Checkpoints¶
Проблема¶
Передача великого файлу:
┌─────────────────────────────────────────────────────────────────┐
│ [████████████████████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░] │
│ 70% │ │
│ ╳ Обрив з'єднання! │
│ │
│ Без checkpoints: Почати з 0% │
│ З checkpoints: Продовжити з 70% │
└─────────────────────────────────────────────────────────────────┘
Checkpoint mechanism¶
┌────────────────────────────────────────────────────────────────┐
│ Checkpointing │
├────────────────────────────────────────────────────────────────┤
│ │
│ [Data Block 1] ──▶ Checkpoint 1 (saved) │
│ [Data Block 2] ──▶ Checkpoint 2 (saved) │
│ [Data Block 3] ──▶ Checkpoint 3 (saved) │
│ [Data Block 4] ──╳ FAILURE │
│ │
│ Recovery: Restart from Checkpoint 3 │
│ │
└────────────────────────────────────────────────────────────────┘
Протоколи та технології L5¶
NetBIOS (Network Basic Input/Output System)¶
┌─────────────────────────────────────────────────────────────────┐
│ NetBIOS — застарілий протокол для Windows мереж │
│ │
│ Сервіси: │
│ • Name Service (порт 137/UDP) — резолюція імен │
│ • Datagram Service (порт 138/UDP) — connectionless │
│ • Session Service (порт 139/TCP) — connection-oriented │
│ │
│ Використання: SMB/CIFS (Windows file sharing) │
│ Статус: Поступово заміщується DNS та Direct SMB over TCP/445 │
└─────────────────────────────────────────────────────────────────┘
RPC (Remote Procedure Call)¶
┌─────────────────────────────────────────────────────────────────┐
│ RPC дозволяє викликати функції на віддаленому комп'ютері │
│ як локальні │
│ │
│ Client Server │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ calculate(5) │ ──── RPC Request ────▶ │ function │ │
│ │ │ │ calculate(5) │ │
│ │ │ │ return 25 │ │
│ │ result = 25 │ ◀─── RPC Response ──── │ │ │
│ └──────────────┘ └──────────────┘ │
│ │
│ Реалізації: Sun RPC, DCE RPC, gRPC │
└─────────────────────────────────────────────────────────────────┘
PPTP (Point-to-Point Tunneling Protocol)¶
┌─────────────────────────────────────────────────────────────────┐
│ PPTP — VPN протокол (застарілий, небезпечний) │
│ │
│ Client ══════[PPTP Tunnel]══════▶ VPN Server │
│ GRE (протокол 47) │
│ TCP порт 1723 (control) │
│ │
│ Рекомендація: Використовувати WireGuard або OpenVPN │
└─────────────────────────────────────────────────────────────────┘
SOCKS (Socket Secure)¶
┌─────────────────────────────────────────────────────────────────┐
│ SOCKS — проксі протокол на сеансовому рівні │
│ │
│ Client ───▶ SOCKS Proxy ───▶ Internet │
│ │
│ SOCKS4: TCP only, no auth │
│ SOCKS5: TCP/UDP, authentication, IPv6 │
│ │
│ Приклад: ssh -D 1080 user@server (dynamic port forwarding) │
└─────────────────────────────────────────────────────────────────┘
Практичні приклади¶
HTTP Session (Cookies)¶
┌─────────────────────────────────────────────────────────────────┐
│ HTTP сам по собі stateless, але cookies створюють сесію │
│ │
│ 1. Login │
│ Client ────────────────────────────────────────▶ Server │
│ POST /login {user, password} │
│ │
│ 2. Session created │
│ Client ◀──────────────────────────────────────── Server │
│ Set-Cookie: session_id=abc123; HttpOnly │
│ │
│ 3. Subsequent requests │
│ Client ────────────────────────────────────────▶ Server │
│ Cookie: session_id=abc123 │
│ (Server знає, хто це) │
│ │
│ 4. Logout / Timeout │
│ Session destroyed │
└─────────────────────────────────────────────────────────────────┘
SSH Session¶
# Встановлення SSH сесії
$ ssh user@server
# Сесія включає:
# 1. TCP з'єднання (L4)
# 2. SSH handshake (key exchange)
# 3. Authentication
# 4. Session established (shell)
# Підтримка сесії (keep-alive в ~/.ssh/config):
Host *
ServerAliveInterval 60
ServerAliveCountMax 3
# Завершення
$ exit
# або Ctrl+D
# або timeout (ServerAliveCountMax exceeded)
Database Session¶
┌─────────────────────────────────────────────────────────────────┐
│ PostgreSQL Session │
│ │
│ 1. Connect │
│ psql -h server -U user -d database │
│ │
│ 2. Session parameters │
│ SET statement_timeout = '30s'; │
│ SET lock_timeout = '10s'; │
│ │
│ 3. Transaction (mini-session) │
│ BEGIN; │
│ INSERT INTO ... │
│ UPDATE ... │
│ COMMIT; │
│ │
│ 4. Disconnect │
│ \q │
│ │
│ Session timeout: idle_session_timeout (PostgreSQL 14+) │
└─────────────────────────────────────────────────────────────────┘
Video Call Session (WebRTC)¶
┌─────────────────────────────────────────────────────────────────┐
│ WebRTC Session Establishment │
│ │
│ Caller Signaling Server Callee │
│ │ │ │ │
│ │ 1. Create Offer (SDP) │ │ │
│ │ ────────────────────────────▶│ │ │
│ │ │ 2. Forward Offer │ │
│ │ │────────────────────────▶│ │
│ │ │ │ │
│ │ │ 3. Create Answer (SDP) │ │
│ │ │◀────────────────────────│ │
│ │ 4. Forward Answer │ │ │
│ │ ◀────────────────────────────│ │ │
│ │ │ │ │
│ │ 5. ICE Candidates exchange │ │
│ │ ◀═══════════════════════════════════════════════════▶ │ │
│ │ │ │ │
│ │ 6. Direct P2P connection (media) │ │
│ │ ════════════════════════════════════════════════════▶ │ │
│ │
└─────────────────────────────────────────────────────────────────┘
Session Security¶
Token-based Sessions¶
┌─────────────────────────────────────────────────────────────────┐
│ JWT (JSON Web Token) — modern approach │
│ │
│ Token structure: │
│ header.payload.signature │
│ │
│ Payload: │
│ { │
│ "sub": "user123", │
│ "exp": 1640995200, // expiration time │
│ "iat": 1640908800, // issued at │
│ "roles": ["admin"] │
│ } │
│ │
│ Переваги: │
│ • Stateless (server не зберігає сесії) │
│ • Scalable (будь-який server може перевірити) │
│ • Самодостатній (містить всю інфо) │
└─────────────────────────────────────────────────────────────────┘
Session Hijacking Prevention¶
┌─────────────────────────────────────────────────────────────────┐
│ Захист від викрадення сесії │
│ │
│ 1. HTTPS only (шифрування) │
│ 2. HttpOnly cookies (недоступні для JS) │
│ 3. Secure flag (тільки через HTTPS) │
│ 4. SameSite attribute (CSRF захист) │
│ 5. Short expiration time │
│ 6. Session rotation (нова сесія після login) │
│ 7. IP binding (опціонально) │
│ │
│ Set-Cookie: session=abc; HttpOnly; Secure; SameSite=Strict │
└─────────────────────────────────────────────────────────────────┘
Діагностика L5¶
Перевірка активних сесій¶
# SSH сесії
who
# або
w
# Показати всі login сесії
last
# Database сесії (PostgreSQL)
SELECT * FROM pg_stat_activity;
# Redis сесії
redis-cli CLIENT LIST
Session timeout налаштування¶
# SSH client timeout (~/.ssh/config)
ServerAliveInterval 60
ServerAliveCountMax 3
# SSH server timeout (/etc/ssh/sshd_config)
ClientAliveInterval 60
ClientAliveCountMax 3
# Web server session (nginx)
proxy_read_timeout 300s;
proxy_send_timeout 300s;
# PHP session
session.gc_maxlifetime = 1440
Типові проблеми та рішення¶
| Проблема | Симптоми | Рішення |
|---|---|---|
| Session timeout | "Session expired" | Збільшити timeout або refresh token |
| Lost session | Logout після перезавантаження | Persistent storage (Redis) |
| Session fixation | Атака на фіксовану сесію | Regenerate session ID після auth |
| Too many sessions | Memory exhausted | Обмежити кількість сесій на user |
| Stale connections | Zombie processes | Keep-alive + proper timeout |
Підсумок¶
Сеансовий рівень відповідає за:
- Встановлення сесій — login, authentication
- Підтримка сесій — keep-alive, heartbeat
- Завершення сесій — logout, timeout
- Синхронізація — checkpoints, recovery
- Режими діалогу — simplex, half/full duplex
У сучасних системах функції L5 часто реалізовані на L7 (HTTP sessions, WebSocket, gRPC).
Див. також¶
- Модель OSI — огляд всіх рівнів
- Транспортний рівень — попередній рівень
- Рівень представлення — наступний рівень
- TLS/SSL — безпечні сесії
Шлях: networking/basics/osi-5-session.md