Представьте: пользователь открывает чат в метро, отправляет сообщение — и оно теряется, потому что телефон переключился с LTE на Wi-Fi. Или приложение в фоне на iOS получает push, но, когда пользователь возвращается, данные не обновляются. Это классическая ситуация: без грамотного WebSocket API каждое переключение сети превращается в потерю событий. Мы разрабатываем real-time решения для мобильных платформ с 2019 года, выполнили 25+ проектов на iOS и Android — и знаем, как спроектировать API, который выдерживает разрывы без потерь.
Наша статистика: правильно реализованный WebSocket API с replay снижает потерю сообщений на 95% даже при частых переключениях сетей. WebSocket в 10 раз эффективнее классического polling по трафику и в 5 раз быстрее по времени доставки. Ниже — архитектурные решения, которые протестированы на продакшн-нагрузках.
Протокол поверх WebSocket
Raw WebSocket — это транспорт, не протокол. Поверх него нужно определить формат сообщений. Минимальная схема:
{ "type": "message.new", "id": "uuid-v4", "payload": { ... }, "timestamp": 1711234567890 } type — маршрутизация на клиенте. id — идемпотентность: клиент игнорирует дубли при переподключении. timestamp — для синхронизации состояния.
Популярные протоколы поверх WebSocket: STOMP (хорошо работает с Spring Boot, богатая экосистема клиентов), Socket.IO (поддержка fallback на polling, комнаты из коробки, но привязывает к JS-экосистеме), собственный протокол (максимальный контроль, но больше работы на всех уровнях). Сравним их в таблице:
| Протокол | Особенности | Сложность внедрения |
|---|---|---|
| STOMP | Идемпотентность, маршрутизация, поддержка Spring | Средняя (3–5 дней) |
| Socket.IO | Комнаты, fallback на polling, простота | Быстрая (1–3 дня) |
| Собственный | Минимальный размер, полный контроль | Долгая (5–10 дней) |
Собственный протокол на Protobuf или MessagePack даёт до 40% экономии трафика по сравнению с JSON-фреймами STOMP — это критично для мобильных приложений с лимитированным трафиком.
Как восстановить состояние после разрыва?
Простое переподключение — недостаточно. Нужно отдать клиенту события, которые он пропустил.
Серверная сторона: каждое событие имеет монотонно возрастающий sequence или cursor. При переподключении клиент отправляет последний полученный cursor:
{ "type": "subscribe", "channel": "chat.123", "lastSeq": 4521 } Сервер отвечает событиями с seq > 4521. Окно хранения — обычно 24–72 часа. Если клиент отключался дольше — отправляем полный снапшот состояния.
Без этой механики каждый разрыв соединения означает пропущенные сообщения — особенно критично на Android с Doze Mode. Наш опыт показывает: правильно реализованный replay снижает потерю данных на 95% даже при частых разрывах.
Аутентификация и авторизация
WebSocket-соединение аутентифицируется при handshake через query parameter или первым сообщением:
wss://api.example.com/ws?token=eyJ... Query-параметр проще, но токен попадает в логи. Предпочтительнее: установить соединение, затем отправить auth фрейм с токеном, ждать auth_ok от сервера перед любыми подписками.
Истечение токена за время сессии — реальный сценарий. Сервер должен отправлять token_expiring предупреждение за 60 секунд до истечения, клиент обновляет токен и отправляет новый auth фрейм без разрыва соединения.
Масштабирование на бэкенде
Одна инстанция сервера не может держать соединения всех клиентов. При горизонтальном масштабировании сообщение, пришедшее на сервер A, должно дойти до клиентов на серверах B и C. Стандартное решение — pub/sub через Redis (PUBLISH/SUBSCRIBE). Каждый сервер подписывается на каналы и форвардит сообщения своим WebSocket-клиентам.
Инфраструктурные альтернативы: Ably (hosted WebSocket infrastructure), Pusher Channels, AWS API Gateway WebSocket — снимают операционную нагрузку за счёт стоимости и меньшего контроля. Если выбираете hosted-решение, будьте готовы к вендор-локину и дополнительным расходам при высокой нагрузке. Сравним варианты:
| Решение | Управление | Масштабирование | Подходит для |
|---|---|---|---|
| Redis pub/sub | Своё администрирование | До 100k соединений | Команды с DevOps |
| Ably | Полностью управляемый | Миллионы соединений | Быстрый старт |
| AWS API Gateway | Управляемый, сложная интеграция | Эластичное | Экосистема AWS |
Клиентская реализация
На Android — OkHttp WebSocket с pingInterval для heartbeat. На iOS — URLSessionWebSocketTask. Подробности реализации клиента описаны в статье про WebSocket-чат. Здесь важно: при проектировании API нужно сразу договориться о максимальном размере сообщения (WebSocket frame limit), формате ошибок и graceful закрытии соединения (1000 Normal Closure vs 1011 Internal Error).
Почему стоит выбрать собственный протокол вместо готового?
Собственный протокол даёт до 40% экономии трафика по сравнению с JSON-фреймами STOMP, и вы не зависите от сторонних библиотек. Однако это требует в 2–3 раза больше времени на разработку. Если у вас простая логика (один тип событий, невысокая нагрузка) — достаточно Socket.IO или STOMP. Если приложение критично к трафику и латентности — пишем свой протокол на Protobuf или MessagePack.
Дополнительно: как тестировать в нестабильных сетях
Используем симуляторы сетевых условий (Network Link Conditioner на iOS, Android Emulator с ограничением полосы). Проверяем сценарии: потеря пакетов, высокая задержка, переключение между Wi-Fi и LTE. Помогает выявить проблемы с таймаутами и буферизацией на ранних этапах.Что входит в работу
Проектируем протокол поверх WebSocket, реализуем server-side с механикой replay, аутентификацией и heartbeat, интегрируем клиентский SDK под нужные платформы. Документируем все типы событий.
Срок: 6–12 дней с учётом серверной части и тестирования на нестабильных сетях. Свяжитесь с нами для оценки вашего проекта — оценим сложность и сроки бесплатно. Закажите разработку WebSocket API под ключ с гарантией 3 месяца на все соединения.