Декодер кадров WebSocket (RFC 6455)

Что такое WebSocket-кадр?

Каждое сообщение, отправляемое через соединение WebSocket, заключено в кадр — небольшой двоичный заголовок (определенный RFC 6455 §5.2), за которым следуют данные полезной нагрузки. Заголовок компактно упаковывает несколько полей в первый или два байта: бит FIN, три бита RSV (зарезервированные), 4-битный opcode, идентифицирующий тип кадра (text, binary, ping, pong, close…), бит MASK и длину полезной нагрузки, которая может занимать три разные ширины байтов в зависимости от размера полезной нагрузки. Если кадр замаскирован, полезная нагрузка также подвергается XOR с 4-байтовым ключом маскирования перед тем, как вы сможете его прочитать. Ничего из этого нельзя прочитать с первого взгляда — этот инструмент декодирует его поле за полем.

Как это использовать

1. Вставьте сырые байты кадра как hex (разделенные пробелом, двоеточием или 0x — 81 05 48 65 6c 6c 6f и 0x81,0x05,0x48,0x65,0x6c,0x6c,0x6f оба работают) или как двоичную строку битов (напр. 10000001 00000101 ...).
2. Frame Fields отображает FIN, RSV1–3, opcode (с его именем), MASK, как необработанное поле длины 7-бит, так и фактически разрешенную длину полезной нагрузки, ключ маскирования (если есть) и любые предупреждения протокола.
3. Byte Structure разбивает кадр по смещению байта — какие байты составляют заголовок, расширенную длину (если присутствует), ключ маскирования (если присутствует) и полезную нагрузку — отражая макет на диаграмме RFC 6455.
4. Payload показывает полезную нагрузку как полученную (все еще замаскированную, если применимо), де-XOR hex и — для текстовых кадров — декодированный текст UTF-8. Кадры закрытия получают свой 2-байтовый код состояния и фразу причины UTF-8, разделенные отдельно.
5. JSON Export предоставляет те же декодированные поля как единый объект JSON для скриптов или отчетов об ошибках.

Три формы длины полезной нагрузки

Младшие 7 бит второго байта кодируют длину, но какое значение они несут, зависит от значения:

• 0–125 — это фактическая длина полезной нагрузки.
• 126 — реальная длина следует как следующие 2 байта (big-endian, unsigned 16-bit).
• 127 — реальная длина следует как следующие 8 байтов (big-endian, unsigned 64-bit; старший бит должен быть 0 по RFC).

Маскирование

Кадры клиента к серверу должны быть замаскированы (MASK=1) — полезная нагрузка XORится побайтово с 4-байтовым ключом маскирования, который сразу же следует за полем длины, цикличeся ключ каждые 4 байта (payload[i] XOR key[i mod 4]). Кадры сервера к клиенту обычно не замаскированы. Этот инструмент автоматически демаскирует всякий раз, когда MASK=1, и показывает как необработанный, так и немаскированный hex, чтобы вы могли сравнить.

Что этот инструмент помечает как предупреждение

• Control frame (close/ping/pong, opcode 0x8–0xA) с FIN=0, или с полезной нагрузкой более 125 байтов — оба недействительны согласно RFC 6455 §5.5 (control frame не может быть фрагментирован или содержать большие полезные нагрузки).
• Любой установленный RSV бит без согласованного расширения, чтобы его определить.
• Зарезервированный opcode (0x3–0x7 или 0xB–0xF) — не определен без расширения.
• Усеченный кадр — объявленная длина превышает действительно предоставленные байты.

Что этот инструмент не делает

Декодирует заголовок одного уже захваченного кадра — не открывает активное соединение WebSocket, не собирает последовательность фрагментированных кадров (кадров продолжения opcode 0x0) в одно логическое сообщение и не валидирует handshake HTTP Upgrade, который предшествует любому трафику WebSocket.

FAQ

Где я могу получить сырые байты кадра для вставки? Захватите их на панели DevTools Network вашего браузера (вкладка WS → нажмите на кадр → сырые байты), из захвата пакетов (Wireshark's "Follow → WebSocket Stream" или hex-представление TCP payload), или из инструмента прокси, такого как Burp/mitmproxy.

Почему мой ввод не удается распарсить? Заголовок кадра составляет минимум 2 байта — убедитесь, что вы вставили полный кадр, а не только payload. Hex-вход требует четного количества hex-цифр; двоичный вход требует количества битов, кратного 8.

Мои данные куда-то загружаются? Нет — декодирование выполняется полностью в вашем браузере. Ничто, что вы вставляете, никогда не покидает ваше устройство.

Связанные инструменты

• Hex Dump Viewer — для общего просмотра на уровне байтов любого двоичного блока.
• HTTP Header Analyzer — декодируйте handshake HTTP Upgrade, который предшествует соединению WebSocket.
• Raw HTTP Request Parser — распарсьте необработанную строку HTTP-запроса и заголовки.