Инструмент онлайн-тестирования WebSocket
Онлайн тест подключения WebSocket, отправка и получение сообщений инструмент отладки
Что такое WebSocket?
WebSocket Test подключается к WebSocket URL и помогает проверить, открывается ли real-time канал, можно ли отправлять сообщения и получать ответы. WebSocket используют для чатов, live dashboards, уведомлений, multiplayer-функций, рыночных данных, связи с устройствами и других долгоживущих двусторонних соединений. Инструмент полезен при разработке, troubleshooting, настройке proxy, проверке TLS и сравнении ws:// с wss:// endpoints. Это не нагрузочный тест и не полный анализатор протокола. Аутентификацию, subprotocols, heartbeat, reconnect, формат сообщений, backpressure и лимиты сервера нужно проверять в реальном клиенте и окружении. Успешное соединение доказывает только один путь при текущих условиях. Для реальной диагностики результат нужно сопоставлять с permissions, средой браузера, сетевым путем и состоянием устройства или сервера.
Как пользоваться
Инструкция по использованию
- Введите адрес сервера WebSocket в поле URL (ws:// или wss://)
- При необходимости укажите субпротоколы через запятую
- Нажмите «Подключить» для установки WebSocket-соединения
- Введите содержимое сообщения в поле ввода
- Выберите тип сообщения (Текст или JSON); для типа JSON формат проверяется автоматически
- Нажмите «Отправить» или Ctrl + Enter для отправки сообщения
- Просматривайте отправленные и полученные сообщения в списке, нажмите для копирования
Подсказки по подключению
- Используйте wss:// при тестировании на странице HTTPS; браузеры часто блокируют небезопасные соединения ws:// из защищенных источников.
- Перед отключением, обновлением или переключением конечных точек во время отладки экспортируйте или скопируйте важные журналы сообщений.
Применение
Технический принцип
Основа протокола WebSocket — механизм HTTP Upgrade. Клиент сначала отправляет обычный HTTP GET-запрос с заголовками Upgrade: websocket и Connection: Upgrade, а также случайно сгенерированным Sec-WebSocket-Key. После проверки этих заголовков сервер отвечает 101 Switching Protocols, включая значение Sec-WebSocket-Accept, которое получается путём SHA-1 хеширования ключа, конкатенированного с фиксированным GUID, и последующего Base64-кодирования. После ответа 101 TCP-соединение переключается с HTTP на WebSocket, и дальнейшие данные передаются в виде WebSocket-фреймов. Заголовок WebSocket-фрейма занимает минимум 2 байта и содержит флаг FIN, опкод (0x1 — текст, 0x2 — бинарные данные, 0x8 — закрытие, 0x9 — ping, 0xA — pong) и длину полезной нагрузки. Фреймы ping/pong используются для heartbeat-проверки; браузерный API не отправляет их автоматически, поэтому реализация на уровне приложения обязательна. wss:// — это аналог HTTPS+WebSocket: сначала выполняется TLS-рукопожатие, затем обновление до WebSocket; ws:// — незашифрованное соединение, и браузер отклоняет ws://-эндпоинты на HTTPS-страницах для предотвращения атак понижения уровня. Один фрейм по умолчанию ограничен примерно 1 МБ; более длинные сообщения разбиваются на несколько фреймов.
- Рукопожатие: клиент отправляет HTTP GET с заголовком Upgrade: websocket, а сервер возвращает 101 Switching Protocols, сигнализируя об успешном обновлении
- Sec-WebSocket-Key — это 16-байтовая Base64-строка, случайно сгенерированная браузером; сервер конкатенирует её с фиксированным GUID, вычисляет SHA-1 и проверяет через Sec-WebSocket-Accept
- Фреймирование: каждый фрейм содержит заголовок минимум из 2 байтов с FIN, опкодом (текст/бинарные данные/ping/pong/закрытие) и длиной полезной нагрузки
- ws:// — незашифрованное соединение, wss:// — WebSocket поверх HTTPS; браузеры отклоняют ws:// на HTTPS-сайтах для предотвращения атак понижения уровня
- Фреймы ping/pong для heartbeat: RFC 6455 требует отправки pong в ответ на каждый ping; браузер не отправляет heartbeat автоматически, это должна реализовать сторона приложения
- Последовательность закрытия: каждая сторона отправляет фрейм закрытия 0x8 с кодом состояния, собеседник отвечает аналогичным фреймом, и только после этого TCP-соединение фактически освобождается
Примеры
Подключение к публичному echo-сервису
wss://echo.websocket.org — рукопожатие 101 Switching Protocols успешно, отправка "hello" немедленно возвращает "hello"Отладка собственного WebSocket-сервиса
wss://api.example.com/ws — субпротокол graphql-ws, подключение успешно, сообщения подписки приходят нормальноВоспроизведение разрыва соединения
wss://api.example.com/ws — сервер активно закрывает соединение через 30 секунд после установки, код закрытия 1006 (аномальное закрытие)Часто задаваемые вопросы
Что делает тестер WebSocket?
Позволяет подключиться к любой точке ws:// или wss://, отправлять и получать сообщения, инспектировать обмен по протоколу. Удобно для тестирования WebSocket-API, MQTT-over-WS брокеров, серверов реал-тайм игр, чат-систем и потоков биржевых котировок при разработке.
Сообщения проходят через ваши серверы?
Нет. Браузер открывает WebSocket-соединение напрямую к целевому хосту. Никаких посредников, никакого логирования с нашей стороны. Целевой хост видит ваш IP так же, как у любого другого клиента.
Почему не получается подключиться к localhost?
Правила mixed-content: если эта страница отдаётся по HTTPS, браузеры блокируют (небезопасные) ws://-соединения. Используйте wss:// или открывайте страницу по обычному HTTP для локального тестирования. Точную причину отказа покажет консоль браузера.
Можно ли отправлять бинарные данные?
Да. Большинство сборок поддерживают и текстовые, и бинарные кадры. Бинарный ввод обычно задаётся в Base64 или hex; страница декодирует его перед отправкой. Бинарные ответы по умолчанию отображаются в hex или Base64.
Как добавить кастомные заголовки?
WebSocket-API браузера не разрешает кастомные заголовки — это ограничение Web-платформы. Единственный заголовок, который можно задать, — Sec-WebSocket-Protocol (субпротокол). Для авторизации через Bearer-токен используйте параметр запроса или авторизацию в первом сообщении; некоторые серверы принимают Cookie.
Тестируются ли сжатие и расширения?
Браузеры автоматически согласуют per-message-deflate с серверами, которые его анонсируют. Страница обычно показывает согласованное расширение. Кастомные расширения не тестируются — браузеры не дают такого уровня контроля.
Почему соединение постоянно обрывается?
Частые причины: idle-таймаут сервера (часто 30–120 с), таймаут прокси/балансировщика, обрыв сети или уход ноутбука в сон. Современные WebSocket нуждаются в ping/pong-сердцебиениях; убедитесь, что сервер шлёт ping, или отправляйте периодические сообщения с клиента.