Decodificador de flags TCP
0x12, es decir 18, es SYN más ACK y no un SYN solo: escriba el byte en decimal, hexadecimal o binario para ver cada bit de control por su nombre, o indique nombres como SYN y ACK para recuperar el byte. Gratis en su navegador.
- Gratis
- Funciona en su navegador
- Sin registro
- Sus datos no salen de su equipo
Ejecutar — gratis
Ejemplo resuelto
- Valor
- 0x12
- Modo de cálculo
- Decode
- Valor decimal
- 18
- Valor en hexadecimal
- 0x12
- Valor en binario
- 0b00010010
- Indicadores
- SYN, ACK
Un segmento TCP lleva un octeto compacto de flags que decide si el paquete abre una negociación, reconoce datos, fuerza la entrega del búfer, restablece un socket o señala congestión. Las capturas, las columnas de Wireshark y los rastros de sockets suelen mostrar ese byte en hex, mientras que los manuales y las reglas de cortafuegos hablan de bits con nombre como SYN, ACK, FIN, RST, PSH y URG. Traducir a mano entre ambas vistas es donde se esconden los errores de uno: un SYN-ACK es 0x12, no 0x03, y ACK es el bit 4, no el bit 0. Este decodificador de flags TCP acepta un byte en decimal, hex 0x o binario 0b y devuelve cada bit de control nombrado, o bien acepta un conjunto de nombres y los vuelve a codificar en el mismo byte.
Qué significa el byte de flags TCP y qué bits nombra este decodificador
El decimotercer octeto de una cabecera TCP es el campo de bits de control. RFC 793 definió seis flags en los bits bajos: FIN (0x01) cierra la mitad emisora de la conexión, SYN (0x02) sincroniza números de secuencia al inicio de la negociación, RST (0x04) aborta un socket, PSH (0x08) pide al receptor que entregue el búfer de inmediato, ACK (0x10) marca un número de reconocimiento válido, y URG (0x20) señala datos del puntero urgente.
RFC 3168 destinó después los dos bits altos a la notificación explícita de congestión: ECE (0x40) ecoa una marca de congestión sufrida, y CWR (0x80) indica que el emisor redujo su ventana de congestión. Esas ocho máscaras llenan el byte por completo, así que un valor de 0 a 255 es una codificación sin pérdida del conjunto. El tráfico clásico de negociación a tres vías se reconoce en cuanto se nombran los bits: un SYN solo es 0x02, la respuesta SYN-ACK es 0x12 y el ACK final es 0x10.
Un cierre ordenado suele ser FIN más ACK (0x11); un aborto es RST, a veces con ACK. Este decodificador enumera los bits activos en el orden de RFC desde FIN hasta CWR, emite hex y binario de ocho bits, y también imprime las letras al estilo de tcpdump donde ACK es un punto, de modo que S. es el glifo familiar de SYN-ACK. El nonce NS de RFC 3540 vive en el nibble reservado del byte anterior, no en este octeto, y por tanto queda fuera de alcance.
Dónde un decodificador de flags TCP aporta valor real
Los laboratorios de protocolos y los ejercicios de entrevista siguen pidiendo a los alumnos que lean un volcado hex y digan si un segmento es un SYN, un SYN-ACK o un RST suelto; un decodificador compartido es el oráculo que puntúa esas respuestas sin discutir la numeración de bits. Las tuberías de captura que ya guardan el octeto de flags TCP como entero pueden llamar a este extremo para adjuntar nombres humanos antes de mostrar un ticket o una celda de panel al ingeniero de guardia.
Quienes escriben cortafuegos y BPF codifican un conjunto de nombres en el byte que colocan junto a una máscara, y luego decodifican los aciertos de producción para confirmar que la regla coincidió con SYN y no con SYN-ACK. Fije el hex, el array ordenado de flags y el glifo de tcpdump en las pruebas, y obtendrá aritmética de negociación reproducible para workers de borde, cuestionarios de paquetes y rastros de sockets sin montar una pila completa de disectores solo para nombrar ocho bits.
Qué puede hacer con ella
Leer un SYN-ACK en un volcado hexadecimal
Pegue 0x12 o 18 para confirmar que el segmento es SYN más ACK, no un SYN aislado, antes de explicar una negociación a tres vías o una conexión rechazada.
Construir una máscara de flags para cortafuegos o BPF
Codifique nombres como SYN, ACK o RST en el byte exacto que coloca junto a una máscara en un filtro, y luego decodifique los aciertos para demostrar que la regla vio los bits previstos.
Anotar tuberías de captura y exámenes
Convierta enteros de flags almacenados en nombres ordenados y letras tcpdump para paneles, tickets y preguntas de examen, sin enviar un disector de paquetes completo.
Preguntas frecuentes
¿Cómo se decodifica un byte de flags TCP en SYN, ACK y el resto de bits?
Fije mode en decode y envíe value como decimal 0–255, hex 0x o binario 0b. La respuesta enumera cada nombre activo en orden RFC, más hex, binario, booleanos y un glifo tcpdump.
¿Cómo se vuelven a codificar SYN y ACK en un byte de flags?
El codificador combina las máscaras con OR; SYN más ACK es 0x12 (decimal 18).
¿Qué flags TCP admite esta herramienta?
El bit nonce NS no forma parte de este byte.
¿Qué significa el campo tcpdump?
Es la cadena compacta de letras que tcpdump imprime para los mismos bits: FIN es F, SYN es S, RST es R, PSH es P, ACK es un punto, URG es U, ECE es E y CWR es W. Por eso SYN-ACK aparece como S seguido de un punto.
¿Qué valores usa el saludo de tres pasos de TCP?
Un SYN solo es 0x02, la respuesta SYN-ACK es 0x12 y el ACK final es 0x10. Un cierre ordenado suele ser FIN más ACK, 0x11, mientras que una conexión abortada muestra RST, a veces junto con ACK.
Herramientas relacionadas
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.
Llámela desde su 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)Ejemplo de solicitud
{
"mode": "decode"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.tcp_flags_decode",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
Notas técnicas
Contrato de entrada, decodificar frente a codificar, y forma de la respuesta
Fije mode en decode o encode. La coincidencia no distingue mayúsculas; también se aceptan espacios, tuberías y puntos y coma como separadores; los nombres duplicados se ignoran porque el OR bit a bit es idempotente. Un array flags vacío codifica el byte cero, inusual en el cable pero legal como máscara. Las claves opcionales se omiten en lugar de ir a null. La validación fallida no se factura. En mode decode, value es obligatorio y puede ser un número JSON o una cadena: el decimal 18, el hexadecimal 0x12 o el binario 0b00010010 significan el mismo byte SYN-ACK. Los enteros fuera de 0 a 255, los no enteros, las cadenas vacías y el texto sin prefijo fallan con invalid_input nombrando value. En mode encode, flags es obligatorio y puede ser una cadena separada por comas como SYN,ACK o un array JSON de esos nombres. Los tokens desconocidos, incluido NS o apodos inventados, fallan con invalid_input que lista los ocho nombres legales. En caso de éxito el cuerpo incluye siempre mode, value_decimal, value_hex (dos dígitos en minúsculas), value_binary (ocho bits), flags como array ordenado, flags_string con los mismos nombres unidos por comas, letras tcpdump, ocho campos booleanos de fin a cwr, y una cadena formula que reitera los pesos de cada bit. Ejemplo: decode 0x12 produce flags SYN y ACK, tcpdump S. y value_decimal 18; encode SYN,ACK produce el byte idéntico, de modo que ambos modos son inversos exactos.
Dónde un decodificador de flags TCP aporta valor real
Como la implementación es parse pura de nivel A, cada llamada exitosa cuesta el precio base publicado $0.002 sin tokens de modelo ni red saliente.
Preguntas técnicas
¿Cuánto cuesta el decodificador de flags TCP?
La herramienta en el navegador es gratuita. Las peticiones a la API usan saldo KIT prepago a $0.002 por llamada exitosa; la entrada inválida no se factura.