Protocoles / Sérialisation binaire

décodeur de trames WebSocketretrouver les limites

Collez les octets hexadécimaux dès l’en-tête de trame. Des exemples montrent masque, fragments et données tronquées.

décodeur de trames WebSocket

Octets de trame (hex)

Dès l’en-tête : 81 05 48 65 6c 6c 6f. Octets complets séparés par espaces, virgules ou deux-points ; 0x par octet.

Résultat

Saisissez des octets ou choisissez un exemple.

Tout est traité dans cet onglet. Les entrées ne sont ni envoyées ni sauvegardées.

Options

Saisissez des octets ou choisissez un exemple.

Un bloc capturé ne correspond pas forcément à un message. Ce décodeur de trames WebSocket conserve chaque position de départ : un ping intercalé entre deux fragments reste ainsi distinct du texte. Comparez ces positions au journal pour comprendre un décalage dans votre propre analyseur.

Les événements message du navigateur fournissent généralement des données dont l’en-tête a déjà été retiré. Il faut ici les octets bruts après la mise à niveau HTTP. Un paquet TCP complet ou une chaîne applicative ne constitue pas une entrée équivalente.

Pourquoi ce décodeur de trames WebSocket ?

Suivre toutes les trames

Le décodeur de trames WebSocket avance selon la taille de l’en-tête et la charge annoncée. Si une trame suivante est incomplète, les précédentes restent consultables. L’export est bloqué pour ne pas faire passer une analyse partielle pour un rapport complet.

Un flux d’octets se sépare en trames de données avec une petite trame de contrôle entre deux fragments.

Comparer avant et après le masque

Le masquage WebSocket applique une clé de quatre octets en boucle par XOR. Les octets transmis et ceux obtenus sont affichés séparément. La boucle repart au début de la clé propre à chaque trame, sans modifier la longueur des données.

Quatre octets de clé colorés se répètent sur la charge et produisent une seconde rangée d’octets démasqués.

Préparer une lecture cohérente

01

Garder un seul sens de transmission

Le choix client ou serveur vérifie la règle du bit MASK. Sans direction, seule cette vérification est omise. Un dialogue mélangé n’est pas séparé automatiquement : fournissez les trames d’un même sens dans leur ordre d’origine.

02

Distinguer aperçu et troncature

L’aperçu s’arrête à 256 octets par charge. Un manque d’octets par rapport à la longueur annoncée est une erreur différente, avec position et quantité. La limite d’affichage ne réduit pas le rapport, alors qu’une troncature empêche son export.

03

Choisir le moment du calcul

Le mode automatique attend 350 ms après une modification. Désactivez-le pour afficher le bouton et utiliser Ctrl/Cmd+Enter. Modifier l’entrée ou la direction bloque immédiatement l’ancien export. Exemple et Effacer proposent un aperçu du remplacement et une annulation commune aux données et au résultat.

Relier les champs aux octets

Lire les longueurs étendues

Les formes de 7, 16 et 64 bits sont lues dans l’ordre réseau. Une grande déclaration est comparée exactement à la limite avant toute allocation. Un encodage de longueur inutilement long est conservé avec un avertissement.

Examiner les trames de contrôle

Close, ping et pong restent séparés. Pour close, deux octets donnent le code, suivis du motif UTF-8. Les valeurs FIN, longueurs et codes anormaux sont signalés. Lire une fermeture ne prouve pas que les deux interlocuteurs ont achevé leur échange.

Respecter le contexte du texte

Une trame texte complète et isolée passe par un contrôle UTF-8 strict. Le texte lisible d’une charge binaire reste un aperçu. Les fragments et extensions ne deviennent pas artificiellement des messages complets ; un caractère coupé par l’aperçu n’est pas affiché à moitié.

Retrouver l’endroit du manque

Un en-tête, une longueur, une clé ou une charge incomplète arrête la lecture avec un décalage en octets et une ligne-colonne. Les bits RSV et opcodes réservés restent des avertissements lorsque les limites des octets sont connues.

Périmètre et limites de lecture

Uniquement des octets hexadécimaux
Accepte une suite de longueur paire ou des octets complets séparés par espaces, virgules ou deux-points. Le préfixe 0x ne porte que sur un octet. Base64, suites de bits, fichiers et colonnes d’adresse de hexdump ne sont pas importés.
La fragmentation des messages reste visible
Début, continuation, fin, début absent et message inachevé sont signalés. Les contrôles ne terminent pas une suite active. Les charges ne sont pas assemblées et UTF-8 n’est pas vérifié entre fragments. Une lecture réussie ne valide donc pas tout le message.
Pas d’interprétation des extensions
RSV ne suffit pas à connaître une négociation. Il n’y a ni décompression permessage-deflate, ni déchiffrement TLS, ni détection automatique de JSON, Socket.IO ou Protobuf. Un masque XOR réversible ne protège pas la confidentialité.
Des plafonds indépendants
Limites : 1 Mio d’octets décodés, 6 Mio de caractères et 1 000 trames ; une charge déclarée ne peut dépasser 1 Mio. L’affichage progresse par 50 trames. Le rapport JSON conserve la charge utile WebSocket complète et le texte disponible au-delà de l’aperçu de 256 octets.
Conserver les anomalies
Les avertissements de protocole peuvent être exportés ; les erreurs de structure bloquent le rapport. Aucun octet n’est réparé. Le contrôle des codes de fermeture ne prouve ni leur enregistrement applicatif ni la réussite de la fermeture.

Questions sur le décodeur de trames WebSocket

Pourquoi la charge utile du client est-elle masquée ?

Une clé de quatre octets modifie les données émises par le client afin de ne pas laisser des octets contrôlés tromper des intermédiaires. Le même XOR les rétablit. La clé voyage dans la trame : ce n’est pas du chiffrement. Les trames serveur ne sont pas masquées dans le protocole de base.

Que signifient les longueurs 126 et 127 ?

Ces valeurs annoncent un champ de longueur de deux ou huit octets en grand-boutiste. Ce ne sont pas les tailles réelles. Le bit de poids fort de la forme 64 bits doit être nul. L’en-tête et la clé de masque ne sont pas inclus dans la longueur de charge.

Peut-on coller plusieurs trames à la fois ?

Oui, dans leur ordre de transmission et pour une seule direction. Les charges vides et contrôles intercalés apparaissent séparément. En cas de trame incomplète, corrigez le découpage ou complétez la capture avant d’exporter le rapport.

Comment les trames de fermeture sont-elles interprétées ?

Une charge vide ne contient pas de code. Sinon, les deux premiers octets indiquent le statut et le reste est un motif UTF-8. Un seul octet, un code interdit ou un motif invalide déclenche un avertissement. Aucun code de fermeture normale n’est inventé pour une charge vide.

L’outil décode-t-il aussi la poignée de main HTTP de WebSocket ?

Non. Les requêtes et réponses HTTP Upgrade précèdent ce format. Extrayez d’abord les trames brutes suivantes. L’outil ne retire pas les couches TCP/IP ou TLS, ne se connecte pas au serveur et ne valide pas sa négociation.

Un résultat ou une erreur semble incorrect ?

Revenir aux octets capturés

Utilisez le décodeur de trames WebSocket pour comparer clé et positions, puis isoler la première trame incomplète avant de modifier votre analyseur applicatif.