01
送信方向をそろえる
クライアントとサーバーではMASKの規則が異なります。方向を指定しない場合は方向チェックだけを省略します。双方向のキャプチャを自動分離する機能ではないため、一方向のデータを順序どおりに入力します。
プロトコル／バイナリ形式
WebSocketフレーム解析境界から調べる
フレームヘッダーから始まる16進数を入力してください。マスク付き・分割・欠損の例を選べます。
WebSocketフレーム解析
ヘッダーから入力：81 05 48 65 6c 6c 6f。完全なバイトを空白・コンマ・コロンで区切れます。0xは各バイトに付けます。
結果
バイト列を入力するか例を選んでください。
このタブ内で処理します。入力の送信や保存は行いません。
オプション
バイト列を入力するか例を選んでください。
受信ログの一つの塊が、一つのメッセージとは限りません。WebSocketフレーム解析では各フレームの開始位置を残すため、分割されたデータの間に入るpingも独立して確認できます。自作パーサーの読み取り位置がずれたときは、次のヘッダーまでの距離を比べてください。
ブラウザーのmessageイベントでは、通常フレームヘッダーがすでに取り除かれています。WebSocketデコードの対象はHTTP Upgrade後の生のフレームです。アプリの文字列やTCPパケット全体を、そのまま入力形式と取り違えないことが大切です。
WebSocketフレーム解析で見つける差異
複数の境界を追う
WebSocketフレーム解析は先頭の一つで止まらず、ヘッダーとペイロード長を使って次へ進みます。後続フレームが欠けていても、それ以前の完全なフレームは表示されます。不完全な解析を完全な報告として持ち出さないよう、エクスポートは停止します。
マスク適用前後を比べる
4バイトのキーがペイロード全体を繰り返しXORします。画面では通信路上の値と復元後の値を別々に表示します。次のフレームでは新しいキーの先頭から計算し直すため、前のフレームの位置を引き継ぎません。
キャプチャの読み違いを防ぐ
02
短い表示と欠損を区別する
各ペイロードの表示は先頭256バイトまでです。これは表示上の制限です。宣言された長さに入力が足りない場合は構造エラーとなり、位置と必要な長さが示され、報告を保存できません。
03
更新時点を決める
自動解析は変更後350ミリ秒待ちます。オフにすると解析ボタンとCtrl/Cmd+Enterが使えます。入力や方向を変えた直後は旧結果をコピーできません。例とクリアは置換を確認して適用し、元の入力と結果を一度戻せます。
ヘッダーから終了理由まで確認
長さの表現を読み分ける
7ビットの値と、16ビットまたは64ビットの拡張長をネットワークバイト順で読みます。巨大な宣言値は精度を失わずに上限と比較します。必要以上に長い形式で表現された長さは警告として残ります。
制御フレームを区別する
close、ping、pongをデータと分けて表示します。closeの先頭2バイトはコード、残りはUTF-8の理由です。制御フレームの分割、過大な長さ、不正なコードを指摘しますが、接続終了の成功までは判定しません。
文字列を過信しない
独立した完全なテキストは厳密なUTF-8で検査します。バイナリの読める表示は参考情報です。継続フレームと拡張データは完全な文字列に見せず、表示境界にまたがる文字も壊して表示しません。
元の位置を残す
ヘッダー、拡張長、マスクキー、載荷の不足は解析を止めます。バイト位置は0始まり、入力の行と列は1始まりです。RSVや予約opcodeは警告とともに保持し、元データを調べられるようにします。
入力形式と解析の範囲
- 16進数のみ
- 連続した偶数桁、または空白・コンマ・コロンで区切った完全なバイトを受け付けます。0xは1バイトごとの接頭辞です。Base64、ビット列、ファイル、アドレス付きhexdumpには対応しません。
- 分割は通知のみ
- 開始、継続、終了、先頭欠落、未完了を表示します。制御フレームは進行中の分割を終了させません。メッセージの再構成と分割をまたぐUTF-8検査は行わないため、解析完了はメッセージ全体の正当性を意味しません。
- 拡張を推測しない
- RSVからpermessage-deflateを推測して解凍しません。TLS復号、Socket.IOやProtobufなどのアプリ形式の自動判定も対象外です。マスク解除は可逆のXORであり、暗号の復号ではありません。
- 処理量には上限がある
- 入力は復元したバイト数で1MiB、文字数で6MiB、最大1000フレームです。宣言ペイロードも1MiBまで。50件ずつ表示し、JSON報告には256バイトの表示を超えた完全な載荷と利用可能な文字列を含めます。
- 異常を修正しない
- プロトコル警告は原文とともに保存できますが、構造エラーではエクスポートを無効にします。長さやマスクを勝手に修正しません。終了コードの範囲検査はアプリ登録や終了ハンドシェイクの証明ではありません。
WebSocketフレーム解析のよくある質問
クライアントのペイロードがマスクされるのはなぜですか？
クライアントが通信路の載荷を自由に選んで中継機器を誤認させないよう、4バイトのキーでXORします。キー自体がフレームに含まれるため秘密を守る仕組みではありません。基本仕様ではサーバーからのフレームはマスクしません。
ペイロード長の126と127は何を意味しますか？
126と127は長さそのものではなく、後続の2バイトまたは8バイトを使う印です。値はビッグエンディアンで読み、8バイト形式の最上位ビットは0でなければなりません。長さにヘッダーやマスクキーは含めません。
複数のフレームを一度に貼り付けられますか？
はい。一方向のフレームを順に連結して入力できます。空の載荷や途中の制御フレームも別々に表示します。途中で不足が見つかった場合は、キャプチャを補ってから報告を保存してください。
クローズフレームはどのように解釈されますか？
空の載荷ならコードはありません。それ以外は先頭2バイトがコード、残りがUTF-8の理由です。1バイトだけの載荷、送信できないコード、不正なUTF-8は警告になります。空のcloseに正常終了コードを補うことはしません。
WebSocketのHTTPハンドシェイクもデコードできますか？
いいえ。HTTP Upgradeの要求と応答はフレームより前の段階です。その後の生のフレームを取り出してください。TCP/IPやTLSの外枠の除去、接続、サーバーのハンドシェイク検証には対応しません。
計算や入力判定に問題がありましたか？