⚠️
Maintenance. Notice: the site is currently in maintenance mode, so the amount of available material is temporarily limited.
Short answers to the questions readers send most. For the long versions, follow the links into the tutorials.
wss:// is WebSocket over TLS — the same relationship as https to http. Always use wss:// in production: browsers block ws:// from secure pages, and unencrypted frames are readable by anything on the path.
The protocol allows enormous frames, but servers and proxies set limits to protect memory — often around 1 MiB by default in libraries like ws. For large payloads, fragment them or stream binary chunks and watch bufferedAmount.
An idle connection is usually killed by a proxy or load balancer timeout. Add a heartbeat that sends traffic well within that window, and raise the proxy's read timeout above your heartbeat interval.
No. The native WebSocket never reconnects on its own — that's EventSource's job. You implement it yourself with exponential backoff.
Not necessarily. socket.io adds rooms, automatic reconnection, fallbacks and a Redis adapter — convenient, but it's its own protocol, not raw WebSocket. If you control both ends and want minimal overhead, the native API plus the patterns in this series is often enough.
Yes. A single socket can carry both text and binary frames. On the client, check typeof event.data === "string" to tell them apart, and set binaryType to choose how binary arrives.
Tens of thousands of idle sockets per Node process is realistic; the real limits are memory per connection and file descriptors. Measure your own message rate, then scale horizontally with sticky routing and a pub/sub backplane.
Classic WebSocket runs over HTTP/1.1's upgrade. RFC 8441 defines bootstrapping it over HTTP/2, and support is uneven. In practice most deployments still upgrade over HTTP/1.1 at the edge proxy, which is well supported everywhere.
Короткие ответы на вопросы, которые присылают чаще всего. Развёрнутые версии — по ссылкам в уроках.
wss:// — это WebSocket поверх TLS, как https относится к http. В продакшене всегда используйте wss://: браузеры блокируют ws:// с защищённых страниц, а незашифрованные кадры читаемы всем на пути.
Протокол допускает огромные кадры, но серверы и прокси ставят лимиты ради памяти — часто около 1 МиБ по умолчанию в библиотеках вроде ws. Для больших данных фрагментируйте их или стримьте бинарными чанками и следите за bufferedAmount.
Простаивающее соединение обычно убивает таймаут прокси или балансировщика. Добавьте heartbeat, шлющий трафик внутри этого окна, и поднимите read-timeout прокси выше интервала heartbeat.
Нет. Нативный WebSocket никогда не переподключается самостоятельно — это работа EventSource. Вы реализуете это сами через экспоненциальный backoff.
Не обязательно. socket.io добавляет комнаты, авто-переподключение, фолбэки и Redis-адаптер — удобно, но это собственный протокол, а не «голый» WebSocket. Если вы контролируете обе стороны и хотите минимум накладных, нативного API плюс паттернов из этой серии часто достаточно.
Да. Один сокет может нести и текстовые, и бинарные кадры. На клиенте проверяйте typeof event.data === "string", чтобы различать их, и задавайте binaryType для формата бинарных данных.
Десятки тысяч простаивающих сокетов на процесс Node — реалистично; реальные ограничения — память на соединение и файловые дескрипторы. Измерьте свою частоту сообщений, затем масштабируйтесь горизонтально со sticky-маршрутизацией и шиной pub/sub.
Классический WebSocket работает поверх upgrade из HTTP/1.1. RFC 8441 описывает его запуск поверх HTTP/2, но поддержка неравномерна. На практике большинство развёртываний по-прежнему делают upgrade по HTTP/1.1 на крайнем прокси — это поддержано везде.