Подключение к WebSocket-серверу, отправка сообщений, просмотр фреймов
wss://echo.websocket.org ws://localhost:8080WebSocket — протокол двусторонней связи поверх TCP, стандартизированный в RFC 6455. В отличие от HTTP, WebSocket устанавливает постоянное соединение: сервер может в любой момент отправить данные клиенту без запроса. Это делает WebSocket идеальным для чатов, онлайн-игр, торговых платформ, push-уведомлений и мониторинга в реальном времени.
Соединение WebSocket начинается как обычный HTTP-запрос: браузер отправляет GET-запрос с заголовком Upgrade: websocket, Connection: Upgrade и случайным ключом Sec-WebSocket-Key. Если сервер поддерживает протокол, он отвечает статусом 101 Switching Protocols и заголовком Sec-WebSocket-Accept, вычисленным из полученного ключа по алгоритму из RFC 6455 — это подтверждает, что сервер действительно понимает WebSocket, а не просто эхом вернул заголовок. После этого TCP-соединение остаётся открытым, но переключается на бинарный фреймовый протокол: обе стороны могут в любой момент отправить фрейм с текстовыми данными, бинарными данными или служебным ping/pong/close без повторного HTTP-запроса.
До WebSocket веб-приложения имитировали реальное время через polling — клиент раз в несколько секунд опрашивал сервер новым HTTP-запросом, что создавало лишнюю нагрузку и задержку. Long polling улучшал ситуацию: сервер задерживал ответ до появления новых данных, но всё равно требовал новое соединение после каждого ответа. Server-Sent Events (SSE) решает половину задачи — сервер может непрерывно отправлять события клиенту по одному HTTP-соединению, но обратный канал от клиента к серверу отсутствует, и приходится комбинировать SSE с обычными POST-запросами. WebSocket — единственный из этих подходов, где после одного handshake открывается полностью двусторонний канал с минимальными накладными расходами на фрейм (от 2 байт заголовка), что делает его предпочтительным для сценариев с частым обменом сообщениями в обе стороны.
Если подключение не устанавливается, первым делом стоит проверить в консоли браузера (DevTools → Network → фильтр WS) сам факт handshake-запроса и код ответа сервера. Код 101 означает успешное переключение протокола; 403 обычно говорит о блокировке по CORS-политике или проверке заголовка Origin на сервере; полное отсутствие ответа — о том, что порт закрыт файрволом или обратный прокси (Nginx, Cloudflare) не настроен на проксирование заголовков Upgrade/Connection. Смешанный контент — частая ловушка: страница на HTTPS не может открыть незащищённый ws://, браузер молча блокирует такое соединение, поэтому для продакшн-серверов обязательно нужен действующий TLS-сертификат и адрес wss://.
ws:// — незашифрованный WebSocket. wss:// — WebSocket поверх TLS. Браузеры блокируют ws:// с HTTPS-страниц. Для продакшена всегда используйте wss://.
Введите адрес сервера и нажмите «Подключиться». Успешное соединение покажет Connected. Также проверьте заголовок Upgrade: websocket во вкладке Network браузера.
WebSocket имеет встроенные управляющие фреймы ping и pong для проверки состояния соединения. Сервер отправляет ping, клиент обязан ответить pong. Таймаут без pong обычно означает закрытие соединения.