¿Qué es el TCP three-way handshake y para qué sirve?

El TCP three-way handshake (saludo en tres pasos) es el mecanismo que usa el protocolo TCP para establecer una conexión fiable entre dos equipos antes de intercambiar datos. Consta de tres pasos: el cliente envía SYN, el servidor responde con SYN-ACK y el cliente confirma con ACK. Garantiza que ambos lados están activos, acuerdan los números de secuencia iniciales (ISN) y están listos para comunicarse.

¿Qué significan SYN, SYN-ACK y ACK en TCP?

SYN (synchronize) es el paquete con el que el cliente inicia la conexión e indica su número de secuencia inicial. SYN-ACK (synchronize-acknowledge) es la respuesta del servidor: confirma el SYN del cliente y anuncia su propio número de secuencia. ACK (acknowledge) es la confirmación final del cliente, que completa el handshake y abre la conexión para la transferencia de datos.

¿Por qué TCP necesita tres pasos y no dos?

Con dos pasos solo el servidor confirmaría que recibió el SYN del cliente, pero el cliente nunca confirmaría que recibió el SYN-ACK del servidor. El tercer paso (ACK del cliente) verifica que la comunicación bidireccional funciona y permite sincronizar los números de secuencia de ambos lados. Sin él, el servidor podría abrir una conexión que el cliente nunca completó, desperdiciando recursos.

¿Cómo se cierra una conexión TCP correctamente?

El cierre de una conexión TCP se hace con un four-way handshake usando el flag FIN. El lado que quiere cerrar envía FIN, el otro responde con ACK, luego envía su propio FIN y espera el ACK final. Esto permite que cada dirección de la conexión se cierre de forma independiente (half-close), asegurando que no se pierdan datos en tránsito.

¿Qué diferencia hay entre TCP y UDP en cuanto al establecimiento de conexión?

TCP es un protocolo orientado a conexión: antes de enviar datos realiza el three-way handshake para garantizar fiabilidad, orden y control de flujo. UDP es un protocolo sin conexión: envía datagramas directamente sin establecer ningún canal previo. UDP es más rápido (sin overhead del handshake) pero no garantiza entrega ni orden, por lo que se usa en streaming, videojuegos online y DNS.

meskeIA

Handshake TCP

Visualiza el three-way handshake que establece cada conexión TCP en internet

Términos de UsoTérminos|Política de PrivacidadPrivacidad|Contacto

Configuración

ISN Cliente

ISN Servidor

Velocidad

Modo

TCP (Transmission Control Protocol) garantiza entrega ordenada y sin errores usando un proceso de establecimiento en 3 pasos: el cliente envía SYN con su Número de Secuencia Inicial (ISN), el servidor responde con SYN-ACK (su ISN + confirmación), y el cliente confirma con ACK. Los ISN son aleatorios para evitar ataques de predicción de secuencia. El cierre requiere 4 pasos porque cada dirección se cierra independientemente.

Comparativa de Protocolos de Transporte

Protocolo	Conexión	Fiabilidad	Orden	Velocidad	Uso típico
TCP	3-way handshake	Garantizada	Garantizado	Moderada	HTTP/S, SSH, FTP, correo
UDP	Sin conexión	No garantizada	No garantizado	Alta	DNS, streaming, juegos online
QUIC	1-RTT (TLS integrado)	Garantizada	Garantizado	Alta	HTTP/3, YouTube, Google
SCTP	4-way handshake	Garantizada	Configurable	Moderada	VoIP, telecomunicaciones
WebSockets	Sobre TCP+HTTP upgrade	Garantizada	Garantizado	Moderada	Chat en tiempo real
ICMP	Sin conexión	No garantizada	No aplicable	Muy alta	ping, traceroute, errores de red

Escenarios de Uso

Handshake normal

ISN cliente 1000, ISN servidor 5000 → 3 pasos perfectos + conexión establecida. La secuencia ideal para entender el protocolo básico.

Ciclo de vida completo

Los 7 pasos (apertura 3-way + cierre 4-way FIN) del ciclo de vida completo de una conexión TCP. Activa el modo "Apertura + Cierre".

Números de secuencia aleatorios

Los ISN son aleatorios para prevenir ataques de predicción de secuencia (IP spoofing). Pulsa "ISN Aleatorio" y observa cómo cambian los números.

SYN flood (DDoS)

Un atacante envía miles de SYN sin completar el handshake: el servidor mantiene conexiones "half-open" hasta agotar recursos. La defensa usa SYN cookies.

Preguntas Frecuentes

¿Por qué el handshake tiene 3 pasos y no 2?

Con 2 pasos solo el servidor confirmaría al cliente; el tercer ACK permite al cliente confirmar que el servidor recibió el SYN-ACK. Sin ese tercer paso, el servidor no sabría si el cliente recibió su respuesta: ambos extremos necesitan confirmación bidireccional.

¿Qué son los ISN y por qué son aleatorios?

Initial Sequence Numbers: identifican el byte inicial de cada flujo. Si fueran predecibles (como 0 o 1), un atacante podría inyectar paquetes falsos haciéndose pasar por la fuente legítima (IP spoofing). La aleatoriedad hace que sea estadísticamente imposible adivinar el ISN correcto.

¿Por qué el cierre necesita 4 pasos?

Porque TCP es full-duplex: cada dirección cierra su flujo independientemente con su propio FIN. El servidor puede seguir enviando datos tras recibir el FIN del cliente antes de cerrar su propio lado. Por eso FIN-ACK y FIN-servidor son pasos separados.

¿Qué diferencia hay entre SYN-ACK y dos paquetes separados?

SYN-ACK es un solo paquete con ambos flags activos simultáneamente: optimización de red que reduce la latencia del handshake. El servidor confirma el SYN del cliente y envía su propio SYN en un único viaje de red en lugar de dos.

¿Qué es TIME_WAIT y por qué dura 2×MSL?

Estado tras el último ACK del cierre que espera posibles paquetes duplicados rezagados. MSL (Maximum Segment Lifetime) ≈ 60 segundos. TIME_WAIT dura 2×MSL ≈ 120s para garantizar que ningún paquete de la conexión anterior pueda confundirse con una conexión nueva al mismo puerto.

Cómo usar el simulador

Configura los ISN de cliente y servidor (o usa los valores aleatorios por defecto).

Pulsa "Siguiente" para enviar el primer SYN — observa el número de secuencia y los flags en el panel.

Avanza con SYN-ACK — nota que el servidor confirma ack=ISN_C+1 y envía su propio ISN.

Completa con ACK — la conexión queda establecida: ambos extremos conocen los ISN del otro.

Activa "Apertura + Cierre" y observa los 4 pasos del FIN handshake.

Conceptos clave

seq+1 en el ACK

El SYN "consume" un número de secuencia (como si fuera 1 byte de datos), por eso ack = seq + 1 y no seq.

Full-duplex

TCP permite flujo de datos en ambas direcciones simultáneamente tras el handshake: uploads y downloads ocurren en paralelo.

TLS sobre TCP

HTTPS = TCP handshake (3 pasos) + TLS handshake + HTTP. QUIC (HTTP/3) combina ambos en 1 RTT para reducir latencia.

QUIC reemplaza TCP

HTTP/3 usa QUIC (sobre UDP) que combina el handshake TCP+TLS en 1 RTT. YouTube y Google ya usan QUIC para millones de conexiones.

5 errores frecuentes al estudiar TCP

Confundir seq y ack — seq es el número del byte que se envía; ack es el siguiente byte que se espera recibir del otro extremo.
Olvidar que SYN y FIN consumen 1 en la secuencia — ack = seq + 1, no seq. Es como si SYN/FIN enviaran 1 byte ficticio.
Pensar que UDP es "peor" que TCP — UDP es más rápido para streaming y juegos donde la latencia importa más que la fiabilidad de entrega.
Confundir el cierre TCP (4 pasos) con el handshake de apertura (3 pasos) — el FIN no cierra ambas direcciones a la vez: cada lado manda su propio FIN.
Ignorar TIME_WAIT — puede causar "Address already in use" en servidores que abren/cierran miles de conexiones por segundo. La solución es SO_REUSEADDR.

🔗Apps relacionadas

🌐Redes de ComputadorasTCP/IP, DNS y routing: el contexto completo donde vive el handshake 🗂️Hashing y ColisionesLos protocolos usan hashing (MD5, SHA) para verificación de integridad 🔐Cifrado CésarLos fundamentos del cifrado que protege las conexiones TLS sobre TCP 💻Sistemas OperativosEl SO gestiona los sockets TCP y el estado de las conexiones

meskeIA

Handshake TCP

Visualiza el three-way handshake que establece cada conexión TCP en internet

Términos de UsoTérminos|Política de PrivacidadPrivacidad|Contacto