Cookie-based сессия — механизм сохранения состояния пользователя между HTTP-запросами с использованием cookies. Поскольку HTTP stateless (каждый запрос независим), сессии позволяют серверу «помнить» пользователя: факт авторизации, корзину, настройки. Cookie с идентификатором сессии (session_id) хранится в браузере и автоматически передаётся с каждым запросом к домену.
Как работает
Жизненный цикл сессии:
- Пользователь входит — сервер проверяет логин/пароль
- Сервер создаёт запись в хранилище сессий (файл, БД или Redis) с уникальным session_id
- Сервер отправляет заголовок:
Set-Cookie: PHPSESSID=abc123; HttpOnly; Secure; SameSite=Strict - Браузер сохраняет cookie и отправляет его с каждым последующим запросом
- Сервер по session_id находит данные сессии в хранилище
В PHP сессии управляются нативно: session_start(), $_SESSION['user_id'] = 123. По умолчанию хранятся в файлах (/tmp/sess_*). Для масштабируемости — переключить на Redis: session.save_handler = redis в php.ini.
Хранилища сессий:
- Файлы — дефолт PHP, не работает при нескольких серверах
- Redis — быстро, TTL автоматически, работает в кластере
- Memcached — аналог Redis, чуть быстрее, без persistence
- БД — надёжно, но медленнее; подходит если нужна история сессий
Cookie-based session vs JWT
Главное отличие от JWT: при сессионном подходе данные хранятся на сервере, в браузере только идентификатор. При JWT данные хранятся в самом токене. Сессии легко отзывать (удалить запись из Redis), JWT — сложнее. Сессии требуют общего хранилища при масштабировании, JWT — нет.
История
Cookies изобрёл Лу Монтулли в Netscape в 1994 году для решения проблемы состояния корзины покупок. Session cookies стали стандартным механизмом авторизации в веб-приложениях 1990-х–2000-х. PHP, ASP, JSP — все реализовали сессии через cookies. С приходом SPA и мобильных API в 2010-х JWT стал альтернативой, но cookie-сессии остаются стандартом для традиционных веб-приложений.
На что обращать внимание
Атрибуты cookie критически важны для безопасности:
HttpOnly— JS не может прочитать cookie, защита от XSSSecure— cookie передаётся только по HTTPSSameSite=Strict— защита от CSRF
Session fixation — атака, при которой злоумышленник подбрасывает жертве известный session_id. Защита: всегда регенерировать session_id после авторизации (session_regenerate_id(true) в PHP). Время жизни сессии настраивается через session.gc_maxlifetime и TTL в Redis.
Масштабирование сессий
При горизонтальном масштабировании (несколько серверов за балансировщиком) файловые сессии не работают — пользователь попадает на разные серверы при разных запросах. Решение: вынести хранение сессий в общий Redis или использовать sticky sessions (балансировщик всегда направляет пользователя на один сервер). Sticky sessions — костыль: при падении сервера все его сессии теряются. Redis-based sessions — правильное архитектурное решение для масштабируемых приложений.