Protocolos / Serialización binaria

decodificador de tramas WebSocketlee cada límite

Pega bytes hexadecimales desde la cabecera. Prueba los ejemplos de máscara, fragmentación y captura incompleta.

decodificador de tramas WebSocket

Bytes de trama (hex)

Desde la cabecera: 81 05 48 65 6c 6c 6f. Bytes completos con espacios, comas o dos puntos; 0x por byte.

Resultado

Introduce bytes o elige un ejemplo.

Todo se procesa en esta pestaña. Las entradas no se envían ni se guardan.

Opciones

Introduce bytes o elige un ejemplo.

Un bloque del registro puede contener más de una trama. Este decodificador de tramas WebSocket conserva el inicio de cada una para que un ping entre fragmentos no parezca texto del mensaje. Comparar los desplazamientos con la captura ayuda a encontrar dónde se desvió un lector propio.

El evento message del navegador suele entregar datos sin la cabecera original. Aquí necesitas los bytes posteriores al cambio de protocolo HTTP, empezando por la cabecera de trama. Una cadena de la aplicación o un paquete TCP completo no representa el mismo nivel de datos.

Por qué usar este decodificador de tramas WebSocket

Recorrer toda la secuencia

El decodificador de tramas WebSocket avanza según la cabecera y la longitud declarada. Si una trama posterior queda incompleta, las anteriores siguen visibles. La exportación se bloquea para que una lectura parcial no se confunda con un informe completo.

Un flujo de bytes se divide en tramas de datos y mantiene un pequeño control entre dos fragmentos.

Comparar el enmascaramiento

El enmascaramiento WebSocket repite una clave de cuatro bytes mediante XOR. La vista separa los bytes transmitidos de los recuperados. Cada trama reinicia el ciclo con su propia clave; quitar la máscara no cambia el tamaño de la carga.

Cuatro bytes de clave de distintos colores se repiten sobre la carga y producen otra fila sin máscara.

Preparar una captura que tenga sentido

01

Mantener una dirección

La opción de origen comprueba la máscara obligatoria del cliente o su ausencia en el servidor. Sin dirección solo se omite esa comprobación. No se separan conversaciones mezcladas: pega las tramas de un sentido y conserva su orden.

02

Separar vista previa y falta de bytes

La vista previa muestra hasta 256 bytes por carga. Una captura truncada contiene menos bytes de los declarados y produce un error con posición y cantidades. La limitación visual no recorta el informe; un error de estructura sí impide exportarlo.

03

Elegir cuándo analizar

El modo automático espera 350 ms tras una edición. Al desactivarlo aparecen el botón y Ctrl/Cmd+Enter. Cambiar bytes o dirección invalida el resultado anterior inmediatamente. Ejemplo y Vaciar muestran el reemplazo antes de aplicarlo, con una opción para restaurar entrada y resultado.

Campos que ayudan a explicar una captura

Las tres formas de longitud

Lee el valor de 7 bits y las extensiones de 16 o 64 bits en orden de red. Compara las declaraciones grandes con el límite usando enteros exactos antes de reservar memoria. Conserva con advertencia las longitudes que usan una codificación innecesariamente larga.

Control separado de datos

Close, ping y pong se muestran por separado. En close, los dos primeros bytes son el código y el resto el motivo UTF-8. Los controles fragmentados, demasiado largos o con valores anómalos reciben avisos, sin afirmar que la conexión terminó correctamente.

Texto con contexto

El texto completo de una sola trama se valida con UTF-8 estricto. Una carga binaria legible sigue siendo una vista orientativa. Los fragmentos y extensiones no se presentan como mensajes completos, y un carácter cortado por la vista previa no se muestra dañado.

Posiciones para investigar

Una cabecera, longitud extendida, clave o carga incompleta detiene la lectura con desplazamiento en bytes, línea y columna. Los valores RSV y opcode reservados siguen disponibles con advertencias si sus límites estructurales pueden leerse.

Alcance y límites de la interpretación

Entrada hexadecimal explícita
Acepta una secuencia de longitud par o bytes completos separados por espacios, comas o dos puntos. 0x corresponde a un solo byte. No admite Base64, cadenas de bits, archivos ni columnas de direcciones de hexdump. El formato WebSocket hexadecimal debe empezar en la cabecera.
Sin reconstrucción de mensajes
Se indican inicio, continuación, final, primer fragmento ausente y secuencia sin terminar. Los controles no cierran una fragmentación activa. No se unen cargas ni se valida UTF-8 entre fragmentos; analizar correctamente no demuestra que el mensaje completo sea válido.
Sin adivinar extensiones
RSV no revela por sí solo lo negociado. No hay descompresión permessage-deflate, descifrado TLS ni detección automática de JSON, Socket.IO o Protobuf. La máscara XOR es reversible y no ofrece confidencialidad.
Límites de trabajo y de pantalla
Hasta 1 MiB de bytes de entrada, 6 MiB de caracteres y 1000 tramas. Una carga declarada tampoco puede superar 1 MiB. Se muestran 50 tramas por lote; JSON conserva toda la carga útil WebSocket y el texto disponible dentro de esos límites, más allá de la vista de 256 bytes.
No reparar las pruebas
Los avisos de protocolo permiten exportar, mientras los errores estructurales lo impiden. No se corrigen bytes, longitudes ni máscaras. La revisión del código de cierre no acredita su registro por la aplicación ni el cierre completo entre ambos extremos.

Preguntas sobre el decodificador de tramas WebSocket

¿Por qué se enmascara la carga útil del cliente?

El cliente modifica los bytes transmitidos con una clave de cuatro bytes para evitar que contenido controlado engañe a intermediarios. El mismo XOR repetido los recupera. La clave va dentro de la trama, así que no es cifrado. El servidor envía sin máscara según el protocolo base.

¿Qué significan las longitudes 126 y 127?

Son marcadores para leer los siguientes dos u ocho bytes como longitud big-endian, no tamaños literales. En la forma de 64 bits, el bit superior debe ser cero. La longitud excluye la cabecera y los cuatro bytes de la clave.

¿Puedo pegar varias tramas a la vez?

Sí, si proceden de una misma dirección y mantienen el orden transmitido. Las cargas vacías y controles intercalados aparecen como tramas separadas. Si falta parte de una trama, completa o corrige la captura antes de exportar el informe.

¿Cómo se interpretan las tramas de cierre?

Una carga vacía no tiene código. En las demás, los primeros dos bytes son el estado y los restantes el motivo UTF-8. Un solo byte, códigos prohibidos o un motivo inválido generan avisos. No se inventa un cierre normal para una carga vacía.

¿Esta herramienta decodifica el handshake HTTP de WebSocket?

No. Las solicitudes y respuestas HTTP Upgrade ocurren antes de este formato. Extrae primero las tramas posteriores. La herramienta no retira capas TCP/IP o TLS, no abre conexiones y no valida la negociación del servidor.

¿Has detectado un error de cálculo o validación?

Volver a la captura

Usa el decodificador de tramas WebSocket para contrastar clave y posiciones, y localizar la primera trama incompleta antes de cambiar el analizador de tu aplicación.