WebSocket и SSE

WebSocket — полнодуплексный, двунаправленный протокол связи, построенный поверх HTTP, устанавливающий постоянное TCP-соединение между клиентом и бэкенд-сервером и обеспечивающий push данных в реальном времени без накладных расходов polling'а повторяющихся REST API-вызовов. Рукопожатие WebSocket начинается как HTTP Upgrade-запрос, после чего соединение переключается на протокол ws:// или wss:// (TLS-защищённый), поддерживая открытый канал, через который обе стороны могут отправлять фреймы в любое время. Бэкенд WebSocket-серверы реализуются нативно в Node.js (ws, Socket.IO), Python (websockets, Django Channels на основе Redis channel layers), Go (gorilla/websocket) и Java (Spring WebSocket со STOMP); они требуют sticky sessions или внешнего pub/sub-брокера вроде Redis для распределения сообщений между горизонтально масштабируемыми экземплярами. WebSocket-соединения по своей природе stateful, что означает: балансировщики нагрузки должны быть настроены с session affinity (или состояние соединения экстернализировано в Redis), чтобы не разрывать активные соединения во время событий горизонтального масштабирования в Kubernetes. Мониторинг WebSocket-инфраструктуры требует отслеживания активных счётчиков соединений, скоростей сообщений и частот ошибок соединений через метрики Prometheus; TLS (wss://) всегда должен использоваться в продакшене для защиты потока данных теми же гарантиями безопасности, что и у HTTPS REST API-эндпоинтов.

Как это работает

WebSocket и SSE — request/response протокол поверх TCP (или QUIC для HTTP/3). Запрос имеет метод (GET, POST, PUT, DELETE, PATCH), URL, заголовки, опциональное тело; ответ — статус-код (2xx success, 3xx redirect, 4xx client, 5xx server), заголовки, тело. HTTP/1.1 — одно TCP-соединение на запрос (с keep-alive переиспользованием); HTTP/2 мультиплексирует много запросов в одно соединение; HTTP/3 — поверх UDP через QUIC. TLS (HTTPS) обязателен в 2026.

Когда применять

HTTP/REST — для большинства публичных API: lingua franca, поддерживается клиентами, тулинг для отладки повсюду. gRPC — для internal service-to-service, когда важны latency + schema-дисциплина. WebSockets — для двунаправленного realtime. SSE (Server-Sent Events) — для server-push-only. Всегда за reverse proxy (Caddy, nginx, traefik), который держит TLS, сжатие, rate limit.

Типичные ошибки

Ловушки WebSocket и SSE: 200 OK с {"error": "..."} вместо нормальной 4xx/5xx (ломает client retry и observability); игнор Idempotency-Key для POST, создающего ресурсы (retry дублируют); session-токены в URL (логируются везде); нет gzip/brotli (медленные клиенты на плохих сетях); Server: header выдаёт версию стека. Прочтите RFC 9110 (HTTP semantics) один раз.

Как это работает

Когда применять

Типичные ошибки

Связанные понятия

Полезные ресурсы