Основы WebSocket
Основы WebSocket
Введение
Мы изучили HTTP — протокол запрос-ответ, где клиент всегда инициирует общение. Но что делать, когда серверу нужно самому послать данные клиенту? Например, мгновенное сообщение в чате или уведомление о новом заказе. Здесь HTTP начинает буксовать, а на помощь приходит WebSocket.
Ограничение HTTP
В обычном HTTP:
- Клиент отправляет запрос
- Сервер отвечает
- Соединение закрывается
Если сервер хочет уведомить клиента о чём-то новом — клиент должен постоянно спрашивать: "Есть что-нибудь новое? А теперь? А сейчас?" — это называется polling и очень неэффективно.
Что такое WebSocket
WebSocket — протокол для создания постоянного двустороннего соединения между клиентом и сервером.
HTTP (классика): WebSocket:
Client → Request → Server Client ←→ Server
Client ← Response ← Server (соединение открыто)
(соединение закрыто) Server → Client (в любой момент!)
Client → Server (в любой момент!)
После установки WebSocket-соединения обе стороны могут отправлять сообщения в любой момент, не ожидая очереди.
Где используется WebSocket
| Сценарий | Почему WebSocket |
|---|---|
| Чат в реальном времени | Сервер сразу доставляет новые сообщения |
| Live-уведомления | "У вас новый заказ" без перезагрузки страницы |
| Биржевые котировки | Цены обновляются мгновенно |
| Совместное редактирование | Google Docs — все видят изменения сразу |
| Онлайн-игры | Быстрый обмен данными о позициях игроков |
| Live-мониторинг | Метрики сервера в реальном времени |
Как это выглядит технически
Соединение начинается с HTTP-запроса (Upgrade):
GET /ws HTTP/1.1
Upgrade: websocket
Connection: Upgrade
После подтверждения сервером соединение "переключается" в режим WebSocket:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Теперь соединение открыто, и сообщения летят в обе стороны без лишних заголовков.
WebSocket vs HTTP: ключевые отличия
| Параметр | HTTP | WebSocket |
|---|---|---|
| Кто инициирует | Только клиент | Любая сторона |
| Соединение | Открывается и закрывается | Остаётся открытым |
| Накладные расходы | Заголовки при каждом запросе | Только при установке |
| Подходит для | Классических CRUD-операций | Реального времени |
Тестирование WebSocket: что проверять
WebSocket сложнее тестировать вручную, чем REST API. Нужны специальные инструменты: Postman (поддерживает WS), websocat (консольный), Browser DevTools (вкладка Network).
Что важно проверять в real-time функциях:
- Установка соединения — успешно ли клиент подключается к серверу?
- Аутентификация — нельзя ли подключиться без токена?
- Формат сообщений — соответствует ли JSON-структура ожидаемой?
- Получение сообщений — доставляются ли они всем нужным клиентам?
- Переподключение — что происходит при потере соединения? Восстанавливается ли?
- Масштаб — работает ли при 100 одновременных подключениях?
- Нагрузка — что случается при спаме сообщениями?
Типичные баги в real-time функциях
- Сообщение не доставляется другому пользователю (пришло только отправителю)
- При потере интернета и восстановлении — сообщения теряются
- Соединение "зависает": клиент думает, что подключён, но сервер уже закрыл соединение
- Сообщения дублируются при переподключении
- Нет индикации, что соединение разорвано
Что мы запомним
- HTTP = запрос-ответ, клиент всегда инициирует, соединение закрывается
- WebSocket = постоянное двустороннее соединение, сервер тоже может инициировать
- WebSocket нужен для real-time: чат, уведомления, биржи, совместная работа
- Тестировать WebSocket сложнее — нужны специальные инструменты
- В real-time функциях особо важны: переподключение, доставка всем получателям, формат сообщений