WebSocket-котировки на сайте

WebSocket-котировки на сайте пушат тики в браузер без постоянного HTTP-опроса. REST остаётся для истории свечей и снапшотов; сокет — для last и обновления текущего бара, когда рынок двигается чаще, чем вы готовы долбить endpoint.

В терминале брокера и на живой витрине разница заметна сразу: polling раз в секунду на десятках вкладок греет PHP и прокси, а клиент всё равно видит ступени. Сокет с подпиской на видимые символы дешевле и ровнее, если вы не подписали мир целиком.

Схема контура

• Источник market data (биржа, агрегатор, ваш нормализатор).
• Шина или прокси WebSocket с авторизацией/лимитами.
• Клиент: виджет таблицы, тикер или datafeed графика.
• Reconnect и статус «лента жива / stale» в UI.

API целиком: котировки REST/WS. Продуктовая лента: quotes. График: TradingView.

Подписка и символы

Клиент шлёт subscribe со списком id. Сервер отвечает кадрами {symbol, price, ts, ...}. Имена символов — те же, что в REST и в кабинете. Рассинхрон BTCUSDT vs BTC/USDT даёт «тихий» сокет: соединение есть, обновлений по ожидаемому ключу нет.

1. Проверьте handshake и первый кадр после subscribe.
2. Сверьте ts с часами сервера и браузера.
3. Сравните price с REST-снапшотом того же символа.
4. Оборвите сеть — должен быть reconnect, не вечный спиннер без текста.

Нагрузка и фанаты «подписать всё»

Подписка на 300 пар с главной витрины убивает и канал, и телефон клиента. Для таблицы рынка чаще хватает короткого REST-снапшота; сокет оставьте для открытой карточки, терминала и тикера с коротким списком. Тикер: тикер криптовалют. Витрина: CoinMarket.

На бэкенде ограничивайте число подписок на соединение и число соединений с IP. Без лимитов один «исследователь» в DevTools устроит вам DoS дешевле, чем рынок.

Терминал БО и Forex

Для экспирации опционов критичен тик около времени закрытия. Для Forex — непрерывность потока под маржу. Индикатор обрыва сокета в терминале обязателен: трейдер должен понимать, что цена не обновляется. Продукты: терминал, БО, Forex, white label.

Не считайте сделку по одному каналу, а рисуйте график по другому «временному» WS — получите претензии к цене. Один нормализатор → один поток → UI и matching/expiration logic.

Прокси, SSL, .loc

WSS за nginx должен пробрасывать Upgrade-заголовки. Битый прокси проявляется как мгновенный close после open. На локальном стенде следите за схемой: https-страница и ws:// — смешанный контент. Сертификат на wss — тот же класс проблем, что у API REST.

Whitelist доменов и токены подписки не оставляйте в публичном репозитории шаблонов. Ротация ключа без обновления фронта = массовый отвал ленты после деплоя.

Наблюдаемость

Метрики: активные соединения, кадры/сек, средний lag ts, ошибки апстрима, частота reconnect на клиенте (если шлёте телеметрию). Алерт stale по ключевым символам важнее красивого дашборда. Когда лаг растёт, сначала смотрят апстрим и CPU нормализатора, не «оптимизацию CSS графика».

Логи subscribe/unsubscribe с symbol помогают ловить опечатки после добавления инструмента в админке.

Приёмка

Скрипт/видео: подключение, тик, обрыв, reconnect, совпадение с REST. Список символов демо-набора. Лимиты. URL wss. Поведение при 100% CPU на VDS — хотя бы коротко в runbook. Панель машины: MicroPanel.

WebSocket не заменяет историю свечей и не отменяет словарь символов. Он снимает нагрузку polling и делает last живым — при условии коротких подписок, честного статуса обрыва и единого контура с REST.

Формат кадра и сжатие

Держите кадр коротким: symbol, price, ts, опционально bid, ask, volume. Не тащите в каждый тик полные метаданные монеты — для этого REST справочник. Если канал узкий, включите permessage-deflate осторожно и проверьте CPU на нормализаторе: иногда сжатие мелочи тиков дороже, чем сырой JSON.

Батчинг: можно буферизовать тики на 50–100 мс и слать пачкой, если UI рисует не каждый микротик. Для экспирации БО уточните, нужна ли максимальная свежесть в момент закрытия — тогда батчинг у края экспирации уменьшают или отключают для этих символов.

Авторизация WS: токен с коротким TTL и refresh через REST, либо cookie session на том же домене. Публичный анонимный сокет витрины ограничьте по символам и частоте. Приватный сокет терминала не публикуйте на тот же endpoint без auth.

Фейловер апстрима

Если источников несколько, пропишите приоритет и условие переключения. При переключении возможен скачок last — UI должен либо сгладить, либо показать маркер разрыва. Логируйте switchover: иначе «внезапно другая цена» разбирают как баг расчёта сделки.

Тест на стенде: убить апстрим, увидеть stale, поднять апстрим, увидеть live без перезагрузки страницы. Добавьте это в приёмку вместе с reconnect клиента.

Клиентский код без сюрпризов

Экспоненциальный backoff reconnect, лимит попыток с понятным текстом, ping/pong если прокси режет тишину. Не открывайте второй WebSocket на каждую смену таймфрейма графика — меняйте подписку. При hidden tab снижайте частоту или ставьте на паузу обновления DOM, чтобы после возврата не получить шторм кадров.

Тесты: сон ноутбука, смена сети Wi-Fi→LTE, прокси корпоративный. Это реальные условия трейдеров с телефона.

Итоговый критерий: минута тиков, обрыв, reconnect, совпадение с REST, лимиты, статус в UI терминала и витрины. Документы рядом — quotes и API.

Сопровождение сокета

Следите за ростом числа соединений после промо. Лимиты поднимайте осознанно, не «в бесконечность». Раз в квартал тест failover апстрима. Клиентские SDK/JS виджеты версионируйте: старый терминал на кэше CDN не должен ломать новый формат кадра. При смене формата держите совместимость поле price хотя бы один релиз.

Документируйте максимальную длину списка subscribe. Клиент, отправивший 2000 символов, должен получить понятную ошибку, а не обрыв.