TCPフラグデコーダ
0x12、つまり18は、SYN単体ではなくSYNとACKの組み合わせです。十進数・十六進数・二進数でバイトを入れると各制御ビットが名前で分かり、名前からバイトに戻すこともできます。ブラウザで無料で使えます。
- 無料
- ブラウザで動作
- 登録不要
- データは端末の外に出ません
無料で実行
計算例
- 値
- 0x12
- 計算モード
- Decode
- 10進数の値
- 18
- 値 (16進数)
- 0x12
- 値 (2進数)
- 0b00010010
- フラグ
- SYN, ACK
TCPセグメントは、ハンドシェイク開始、データ確認、バッファ押し出し、ソケットリセット、輻輳通知のどれかを決める小さなフラグオクテットを運びます。パケットキャプチャ、Wiresharkの列、ソケットトレースではそのバイトが十六進で示される一方、教科書やファイアウォール規則はSYN、ACK、FIN、RST、PSH、URGといった名前付きビットで語ります。手作業で両方を行き来するとずれが生じます。SYN-ACKは0x12であり0x03ではなく、ACKはビット4であってビット0ではありません。このTCPフラグデコーダは十進、0x十六進、0b二進のフラグバイトを受け取り各制御ビット名を返すか、名前の集合を受け取り同じバイトへ戻します。
TCPフラグバイトの意味と、このデコーダが付けるビット名
TCPヘッダの第十三オクテットが制御ビット欄です。RFC 793は下位ビットに六つのフラグを定めました。
FIN（0x01）は送信側半分を閉じ、SYN（0x02）はハンドシェイク開始時にシーケンス番号を同期し、RST（0x04）はソケットを中断し、PSH（0x08）は受信側へバッファの即時引き渡しを求め、ACK（0x10）は有効な確認番号を示し、URG（0x20）は緊急ポインタのデータを示します。
RFC 3168はその後、上位二ビットを明示的輻輳通知に充てました。ECE（0x40）は輻輳経験マークをエコーし、CWR（0x80）は送信側が輻輳ウィンドウを縮小したことを示します。これら八つのマスクでフラグバイトは埋まるため、0から255までの値は集合の無損失符号化です。
三点ハンドシェイクはビットに名前が付くと見分けやすく、単独SYNは0x02、SYN-ACK応答は0x12、最後のACKは0x10です。整った終了は多くの場合FINとACK（0x11）、中断はRSTで、ACKを伴うこともあります。
このデコーダはRFCのビット順でFINからCWRまでセットされたビットを列挙し、十六進と八ビット二進を出し、ACKをピリオドとするtcpdump風の文字も印字します。そのためS. は見慣れたSYN-ACK記号です。RFC 3540のNSノンスは直前バイトの予約ニブルにあり、このオクテットには含まれないため対象外です。
入力契約、デコードとエンコード、応答の形
modeをdecodeまたはencodeに設定します。十進の18、十六進の0x12、二進の0b00010010は同じSYN-ACKバイトを意味します。照合は大文字小文字を区別せず、空白、パイプ、セミコロンも区切りとして受け付け、重複名はビット単位ORが冪等なため無視します。
空のflags配列はゼロバイトを符号化します。回線上では珍しいですがマスクとしては合法です。任意キーはnullにせず省略します。
検証失敗は課金されません。
TCPフラグデコーダが本領を発揮する場面
プロトコル実習や面接課題では、十六進ダンプを読んでセグメントがSYNかSYN-ACKか迷走RSTかを答えさせます。共有デコーダはその答えをビット番号の議論なしに採点する基準になります。TCPフラグオクテットを整数として既に保存しているキャプチャ経路は、チケットやダッシュボードのセルを当番技術者へ見せる前に、この端点を呼んで人間向けの名前を付けられます。
ファイアウォールやBPFの著者は名前集合をマスク横のバイトへ符号化し、本番の一致をデコードして規則がSYNでありSYN-ACKではないことを確認します。負荷試験やファザの固定データは、後から読めない魔法数を埋め込まずにSYNとFIN、ECEとCWRといった珍しい組合せを決定的に組み立てる必要があります。
試験では十六進、順序付きflags配列、tcpdump記号を固定すれば、八ビットに名前を付けるためだけに完全な解析器一式を立てずに、エッジワーカー、パケット小テスト、ソケットトレース向けの再現可能なハンドシェイク演算が得られます。
活用例
十六進ダンプからSYN-ACKを読む
三点ハンドシェイクや拒否された接続を説明する前に、0x12または18を貼り付け、セグメントが単独SYNではなくSYNとACKであることを確認します。
ファイアウォールやBPFのフラグマスクを作る
SYN、ACK、RSTなどの名前をフィルタのマスク横に置く正確なバイトへ符号化し、一致をデコードして規則が意図したビットを見たことを証明します。
キャプチャ経路と試験問題に注釈を付ける
保存済みのフラグ整数を、完全なパケット解析器を配らずに、ダッシュボード、チケット、試験項目向けの順序付き名前とtcpdump文字へ変えます。
よくある質問
TCPフラグバイトをSYN、ACK、その他のビットへどう展開しますか？
modeをdecodeにし、valueを十進0–255、0x十六進、または0b二進で送ります。応答はRFC順の各セット名に加え、十六進、二進、真偽値、tcpdump記号を列挙します。
SYNとACKをフラグバイトへどう戻しますか？
符号化器はビットマスクをORし、SYNとACKは0x12（十進18）です。
どのTCPフラグに対応していますか？
フラグオクテットの八ビットです。FIN 0x01、SYN 0x02、RST 0x04、PSH 0x08、ACK 0x10、URG 0x20、ECE 0x40、CWR 0x80。NSノンスビットはこのバイトに含まれません。
tcpdump欄は何を意味しますか？
同じビットに対してtcpdumpが印字する短い文字列です。FINはF、SYNはS、RSTはR、PSHはP、ACKはピリオド、URGはU、ECEはE、CWRはWです。したがってSYN-ACKはSの直後にピリオドが続きます。
TCPの3ウェイハンドシェイクではどの値が使われますか？
最初のSYNは0x02、応答のSYN-ACKは0x12、最後のACKは0x10です。通常の切断ではFINとACKの0x11がよく使われ、強制終了ではRSTが現れ、ACKを伴うこともあります。
関連ツール
開発者向け — APIアクセス
このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。
エンドポイント
Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。
お使いのスタックから呼び出す
curl -X POST https://api.kit.forhosting.com/dev/tcp-flags-decode \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"mode":"decode"}'const res = await fetch("https://api.kit.forhosting.com/dev/tcp-flags-decode", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"mode": "decode"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/tcp-flags-decode",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"mode": "decode"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/tcp-flags-decode", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"mode":"decode"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"mode":"decode"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/tcp-flags-decode", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)リクエスト例
{
"mode": "decode"
}レスポンス例
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.tcp_flags_decode",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。
料金
単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。
エラー
| HTTP | コード | 意味 |
|---|---|---|
401 | unauthorized | APIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。 |
402 | insufficient_balance | 残高が不足しています。チャージ後に再度お試しください。 |
404 | unknown_type | 指定されたタスクタイプは存在しません。タイプ名を確認してください。 |
429 | rate_limited | リクエストが多すぎます。しばらく待ってから再度お試しください。 |
技術的な注記
入力契約、デコードとエンコード、応答の形
decodeではvalueが必須で、JSON数値でも文字列でも構いません。0から255の外の整数、非整数、空文字、接頭辞のないごみはinvalid_inputで失敗し、valueを示します。encodeではflagsが必須で、SYN,ACKのようなカンマ区切り文字列、または同じ名前のJSON配列を渡せます。NSや造語を含む未知トークンは、八つの正当名を列挙するinvalid_inputで失敗します。成功時の本体には常にmode、value_decimal、value_hex（小文字二桁）、value_binary（八ビット）、順序付き配列のflags、カンマ結合のflags_string、tcpdump文字、finからcwrまでの八つの真偽フィールド、ビット重みを述べるformula文字列が含まれます。例としてdecode 0x12はflags SYNとACK、tcpdump S.、value_decimal 18を返し、encode SYN,ACKは同一バイトを返すため、二つのmodeは正確な逆写像です。
TCPフラグデコーダが本領を発揮する場面
実装は純粋なparseの段階Aのため、成功した呼び出しは毎回公表済みの基本料金$0.002であり、モデルトークンも外向き通信もありません。
技術的な質問
TCPフラグデコーダの料金はいくらですか。
ブラウザ上の用具は無料です。API要求は成功した呼び出しごとに公表料金$0.002の前払いKIT残高を使い、不正な入力は課金されません。