HTTP — протокол без состояния
HTTP — протокол без состояния
В прошлом уроке мы узнали, что HTTP работает по схеме «запрос → ответ». Теперь разберём одно из самых важных и часто непонятных свойств HTTP: он не хранит состояние (stateless). Что это значит на практике и как с этим живут современные веб-приложения.
Что значит «без состояния»
Протокол без состояния (stateless) — это протокол, в котором каждый запрос обрабатывается независимо. Сервер не помнит, что тот же клиент делал секунду назад. Каждый новый запрос — как первый.
Представь разговор, в котором собеседник забывает всё, что ты говорил до этого:
Ты: «Привет, я Степан»
Сервер: «Привет. Ты кто?»
Ты: «Я Степан, мы только что говорили»
Сервер: «Я не помню. Ты кто?»
Примерно так HTTP работает без дополнительных механизмов.
Почему HTTP сделали без состояния
Это было осознанное решение. Состояние дорого обходится серверу: нужно хранить информацию о каждом клиенте между запросами. Когда у тебя миллионы пользователей, хранение состояния для каждого — это миллионы записей в памяти или базе данных. Stateless-архитектура позволяет серверу обслужить запрос и забыть о клиенте, не тратя ресурсы.
Кроме того, stateless делает протокол проще и устойчивее: если сервер упал, другой сервер может продолжить обслуживание — он всё равно ничего не помнит. Именно поэтому HTTP масштабируется на миллиарды пользователей.
Как веб-приложения хранят состояние
Веб-приложениям состояние нужно: ты логинишься, кладёшь товары в корзину, заполняешь форму на нескольких страницах. Как это совместить со stateless-протоколом? Есть несколько механизмов:
Cookies. Маленькие фрагменты данных, которые сервер просит браузер сохранить и присылать с каждым последующим запросом:
Клиент: POST /login (логин и пароль)
Сервер: 200 OK, Set-Cookie: session_id=abc123
Клиент: GET /profile, Cookie: session_id=abc123
Сервер: «А, это Степан. Вот его профиль»
Браузер автоматически прикрепляет cookie к каждому запросу к тому же домену. Сервер по session_id находит данные сессии в базе. Детально cookies разберём в следующем модуле.
Токены (JWT, OAuth). Вместо хранения сессии на сервере, клиент получает токен — зашифрованный или подписанный набор данных. Клиент присылает токен с каждым запросом (обычно в заголовке Authorization), и сервер проверяет его валидность, не заглядывая в базу сессий.
Скрытые поля форм и URL-параметры. Самые старые методы: передавать состояние в теле формы или в URL (/checkout?step=2). Сегодня используются редко и только для навигационного состояния, не для аутентификации.
Stateless vs Stateful: сравнение
| Stateless (HTTP сам по себе) | Stateful (с сессиями) | |
|---|---|---|
| Сервер помнит клиента? | Нет | Да (через cookie или токен) |
| Масштабируемость | Отличная | Требует общего хранилища сессий |
| Отказоустойчивость | Любой сервер может ответить | Сессия привязана к данным |
| Сложность протокола | Минимальная | Выше |
| Пример | Запрос статической картинки | Личный кабинет с авторизацией |
Что это значит на практике
Для разработчика stateless-природа HTTP означает:
- Каждый запрос должен содержать всю информацию для его обработки. Сервер не «догадывается».
- Для аутентификации каждый запрос должен включать cookie или токен.
- Нельзя полагаться на то, что клиент ещё «держится» — предыдущий запрос мог обслужить другой сервер.
- REST API (модуль 9) специально проектируются stateless: каждый запрос самодостаточен.
Проверь себя
- Сервер помнит, что ты добавил товар в корзину 5 минут назад?
- Почему stateless проще масштабировать?
- Где хранится
session_id, чтобы браузер отправлял его с каждым запросом?
- Нет, если нет механизма хранения состояния. HTTP сам по себе не помнит. Корзина работает через cookie (сессия на сервере) или localStorage (состояние в браузере).
- Потому что любой сервер из кластера может обработать любой запрос. Нет привязки «клиент А обслуживается сервером 3». Новые серверы можно добавлять без перестройки.
- В cookie. Сервер устанавливает cookie с
session_id, и браузер автоматически прикрепляет его к каждому следующему запросу к тому же домену.
Что унести с урока
- HTTP — stateless протокол: каждый запрос обрабатывается независимо, сервер не помнит предыдущих.
- Stateless даёт масштабируемость и отказоустойчивость, но неудобен для приложений.
- Состояние добавляют через cookies, токены и другие надстройки над HTTP.
- REST API проектируются stateless осознанно.
Теперь, когда мы понимаем «философию» HTTP, посмотрим на конкретику. В следующем уроке разберём структуру HTTP-запроса — из чего он состоит и как выглядит «под капотом».