TCP-Flags-Dekodierer
0x12, also 18, ist SYN plus ACK und kein einzelnes SYN: Geben Sie das Byte dezimal, hexadezimal oder binär ein, um jedes Steuerbit mit Namen zu sehen, oder nennen Sie Namen wie SYN und ACK, um das Byte zurückzubekommen. Kostenlos in Ihrem Browser.
- Kostenlos
- Läuft in Ihrem Browser
- Ohne Anmeldung
- Ihre Daten bleiben auf Ihrem Gerät
Im Browser ausführen – kostenlos
Rechenbeispiel
- Wert
- 0x12
- Berechnungsmodus
- Decode
- Dezimalwert
- 18
- Wert (hexadezimal)
- 0x12
- Wert (binär)
- 0b00010010
- Flags
- SYN, ACK
Ein TCP-Segment trägt ein kompaktes Flags-Oktett, das entscheidet, ob das Paket eine Verbindung eröffnet, Daten bestätigt, einen Puffer anstößt, einen Socket zurücksetzt oder Überlastung markiert. Mitschnitte, Wireshark-Spalten und Socket-Spuren zeigen dieses Byte meist als Hex, während Lehrbücher und Firewall-Regeln von benannten Bits wie SYN, ACK, FIN, RST, PSH und URG sprechen. Genau beim händischen Übersetzen zwischen beiden Sichten verstecken sich Fehler um eins: ein SYN-ACK ist 0x12, nicht 0x03, und ACK ist Bit 4, nicht Bit 0. Dieser TCP-Flags-Dekodierer nimmt ein Flags-Byte in Dezimal, 0x-Hex oder 0b-Binär entgegen und liefert jedes benannte Steuerbit, oder er nimmt eine Menge von Namen entgegen und kodiert sie zurück in dasselbe Byte.
Was das TCP-Flags-Byte bedeutet und welche Bits dieser Dekodierer benennt
Das dreizehnte Oktett eines TCP-Headers ist das Steuerbitfeld. RFC 793 definierte sechs Flags in den niedrigen Bits: FIN (0x01) schließt die sendende Hälfte der Verbindung, SYN (0x02) synchronisiert Sequenznummern zu Beginn des Handshakes, RST (0x04) bricht einen Socket ab, PSH (0x08) fordert den Empfänger auf, den Puffer zügig auszuliefern, ACK (0x10) kennzeichnet eine gültige Bestätigungsnummer, und URG (0x20) markiert Daten des Urgent-Zeigers. RFC 3168 verwendete später die zwei hohen Bits für explizite Überlastanzeige: ECE (0x40) spiegelt eine erlebte Überlastmarke wider, und CWR (0x80) sagt, der Sender habe sein Überlastfenster verkleinert.
Zusammen füllen diese acht Masken das Flags-Byte vollständig, sodass ein Wert von 0 bis 255 eine verlustfreie Kodierung der Menge ist. Klassischer Drei-Wege-Handshake-Verkehr ist leicht zu erkennen, sobald die Bits Namen tragen: ein alleiniges SYN ist 0x02, die SYN-ACK-Antwort ist 0x12, und das abschließende ACK ist 0x10. Ein sauberes Schließen ist oft FIN plus ACK (0x11); ein Abbruch ist RST, manchmal mit ACK.
Dieser Dekodierer listet gesetzte Bits in RFC-Bitreihenfolge von FIN bis CWR, gibt Hex und achtbitiges Binär aus und druckt außerdem tcpdump-artige Buchstaben, bei denen ACK ein Punkt ist, sodass S. das vertraute SYN-ACK-Zeichen ist. Der NS-Nonce aus RFC 3540 lebt im reservierten Nibble des vorherigen Bytes, nicht in diesem Oktett, und liegt daher außerhalb des Geltungsbereichs.
Wo ein TCP-Flags-Dekodierer seinen Unterhalt verdient
Protokollpraktika und Vorstellungsübungen verlangen von Lernenden noch immer, einen Hex-Dump zu lesen und zu sagen, ob ein Segment ein SYN, ein SYN-ACK oder ein verirrtes RST ist; ein gemeinsamer Dekodierer ist das Orakel, das jene Antworten bewertet, ohne über Bitnummern zu streiten. Erfassungspipelines, die das TCP-Flags-Oktett bereits als Ganzzahl speichern, können diesen Endpunkt aufrufen, um menschliche Namen anzuheften, bevor ein Ticket oder eine Dashboard-Zelle der diensthabenden Ingenieurin gezeigt wird.
Firewall- und BPF-Autorinnen kodieren eine Namensmenge in das Byte, das sie neben eine Maske setzen, und dekodieren dann ProduktionsTreffer, um zu bestätigen, dass die Regel SYN und nicht SYN-ACK getroffen hat. Heften Sie das Hex, das geordnete flags-Array und das tcpdump-Zeichen in Prüfungen fest, und Sie erhalten reproduzierbare Handshake-Arithmetik für Rand-Worker, Paketquiz und Socket-Spuren, ohne einen vollen Dissektorstapel nur zum Benennen von acht Bits aufzustellen.
Anwendungsfälle
Ein SYN-ACK aus einem Hex-Dump lesen
Fügen Sie 0x12 oder 18 ein, um zu bestätigen, dass das Segment SYN plus ACK ist, nicht ein einzelnes SYN, bevor Sie einen Drei-Wege-Handshake oder eine abgelehnte Verbindung erklären.
Eine Firewall- oder BPF-Flagmaske bauen
Kodieren Sie Namen wie SYN, ACK oder RST in das genaue Byte, das Sie neben eine Maske in einem Filter setzen, und dekodieren Sie Treffer, um zu belegen, dass die Regel die beabsichtigten Bits gesehen hat.
Erfassungspipelines und Prüfungen annotieren
Wandeln Sie gespeicherte Flags-Ganzzahlen in geordnete Namen und tcpdump-Buchstaben für Dashboards, Tickets und Prüfungsaufgaben um, ohne einen vollständigen Paketdissektor auszuliefern.
Häufige Fragen
Wie dekodieren Sie ein TCP-Flags-Byte in SYN, ACK und die übrigen Bits?
Setzen Sie mode auf decode und senden Sie value als Dezimal 0–255, 0x-Hex oder 0b-Binär. Die Antwort listet jeden gesetzten Namen in RFC-Reihenfolge, plus Hex, Binär, Boolesche Werte und ein tcpdump-Zeichen.
Wie kodieren Sie SYN und ACK zurück in ein Flags-Byte?
Der Kodierer verknüpft die Bitmasken per ODER; SYN plus ACK ist 0x12 (Dezimal 18).
Welche TCP-Flags werden unterstützt?
Die acht Bits des Flags-Oktetts: FIN 0x01, SYN 0x02, RST 0x04, PSH 0x08, ACK 0x10, URG 0x20, ECE 0x40 und CWR 0x80. Das NS-Nonce-Bit gehört nicht zu diesem Byte.
Was bedeutet das Feld tcpdump?
Es ist die kompakte Buchstabenkette, die tcpdump für dieselben Bits druckt: FIN ist F, SYN ist S, RST ist R, PSH ist P, ACK ist ein Punkt, URG ist U, ECE ist E und CWR ist W. SYN-ACK erscheint daher als S gefolgt von einem Punkt.
Welche Werte nutzt der TCP-Drei-Wege-Handshake?
Ein einzelnes SYN ist 0x02, die SYN-ACK-Antwort ist 0x12 und das abschließende ACK ist 0x10. Ein sauberes Schließen ist oft FIN plus ACK, also 0x11, während ein Abbruch RST zeigt, manchmal zusammen mit ACK.
Verwandte Tools
Für Entwickler — API-Zugang
Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.
Endpunkt
Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.
Aufruf aus Ihrem Stack
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)Beispiel-Anfrage
{
"mode": "decode"
}Beispiel-Antwort
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.tcp_flags_decode",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.
Preis
Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.
Fehler
| HTTP | Code | Bedeutung |
|---|---|---|
401 | unauthorized | Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer). |
402 | insufficient_balance | Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht. |
404 | unknown_type | Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog. |
429 | rate_limited | Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt. |
Technische Hinweise
Eingabevertrag, Dekodieren gegenüber Kodieren, und die Antwortform
Setzen Sie mode auf decode oder encode. Der Abgleich ignoriert Groß- und Kleinschreibung; Leerzeichen, Senkrechtstriche und Semikolons gelten ebenfalls als Trenner; doppelte Namen werden ignoriert, weil bitweises ODER idempotent ist. Ein leeres flags-Array kodiert das Nullbyte, ungewöhnlich auf der Leitung, aber als Maske zulässig. Optionale Schlüssel werden weggelassen statt auf null gesetzt. Fehlgeschlagene Prüfung wird nicht berechnet. Im mode decode ist value Pflicht und darf eine JSON-Zahl oder eine Zeichenkette sein: Dezimal 18, Hexadezimal 0x12 oder Binär 0b00010010 meinen dasselbe SYN-ACK-Byte. Ganzzahlen außerhalb von 0 bis 255, Nichtganzzahlen, leere Zeichenketten und unpräfixierter Unsinn scheitern mit invalid_input und nennen value. Im mode encode ist flags Pflicht und darf eine kommagetrennte Zeichenkette wie SYN,ACK oder ein JSON-Array derselben Namen sein. Unbekannte Token, einschließlich NS oder erfundener Spitznamen, scheitern mit invalid_input, das die acht zulässigen Namen auflistet. Bei Erfolg enthält der Körper stets mode, value_decimal, value_hex (zwei Kleinbuchstaben-Ziffern), value_binary (acht Bits), flags als geordnetes Array, flags_string mit denselben Namen durch Kommas verbunden, tcpdump-Buchstaben, acht boolesche Felder von fin bis cwr sowie eine formula-Zeichenkette, die die Bitgewichte wiederholt. Beispiel: decode 0x12 liefert flags SYN und ACK, tcpdump S. und value_decimal 18; encode SYN,ACK liefert dasselbe Byte, die beiden Modi sind also genaue Umkehrungen.
Wo ein TCP-Flags-Dekodierer seinen Unterhalt verdient
Weil die Umsetzung reines Parse der Stufe A ist, kostet jeder erfolgreiche Aufruf den veröffentlichten Grundpreis $0.002 ohne Modell-Token und ohne ausgehendes Netz.
Technische Fragen
Was kostet der TCP-Flags-Dekodierer?
Das Werkzeug im Browser ist kostenlos. API-Anfragen nutzen vorausbezahltes KIT-Guthaben zu $0.002 je erfolgreichem Aufruf; ungültige Eingabe wird nicht berechnet.