Transporte TCP/UDP y puertos en redes de computadoras

Puertos: puntos de servicio en un host

Un puerto es un número (0–65535) que identifica un punto de servicio dentro de un sistema operativo. Mientras la IP identifica al host, el puerto identifica qué aplicación (o proceso) debe recibir el tráfico. En servidores, esto permite que múltiples servicios convivan en la misma IP: por ejemplo, un servidor puede ofrecer SSH y HTTPS simultáneamente porque escuchan en puertos distintos.

En términos prácticos, una conexión suele identificarse por la tupla:

(IP_origen, puerto_origen, IP_destino, puerto_destino, protocolo)

Ejemplo: tu laptop abre una conexión TCP desde un puerto local alto hacia el puerto 443 del servidor web.

Puertos bien conocidos, registrados y efímeros

• Bien conocidos (0–1023): reservados para servicios estándar. En muchos sistemas, abrir (escuchar) en estos puertos requiere privilegios elevados.
• Registrados (1024–49151): usados por aplicaciones comunes, a menudo asignados por convención.
• Efímeros (49152–65535) (rango típico, puede variar por SO): puertos temporales que el sistema asigna a clientes para iniciar conexiones salientes. No “identifican un servicio” estable; identifican una sesión/flujo en el lado cliente.

Idea clave: el servidor suele escuchar en un puerto fijo (p. ej., 22/443), mientras que el cliente usa un puerto efímero para esa conexión.

Ejemplos de servicios típicos de servidor (puerto/protocolo)

TCP: transporte orientado a conexión y confiable

TCP está diseñado para entregar un flujo de bytes de forma ordenada y con control de errores. Para administración de servidores, TCP es la base de la mayoría de servicios donde importa la integridad (SSH, HTTP/HTTPS, SMTP, etc.).

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

3-way handshake (establecimiento de conexión)

Antes de enviar datos, TCP crea una conexión lógica mediante el 3-way handshake:

• SYN: el cliente solicita iniciar conexión y propone números de secuencia.
• SYN-ACK: el servidor acepta y responde con sus propios números de secuencia.
• ACK: el cliente confirma y la conexión queda lista para datos.

Esto permite sincronizar números de secuencia y negociar opciones (por ejemplo, MSS, window scaling), lo cual impacta rendimiento y compatibilidad.

Confiabilidad: ACKs y retransmisión

TCP numera los bytes (secuencia) y usa ACKs para confirmar recepción. Si un segmento no es confirmado a tiempo, TCP asume pérdida y retransmite. Esto es crucial en redes con pérdida o congestión: la aplicación (por ejemplo, SSH) no tiene que “rearmar” datos perdidos; TCP lo hace.

Implicación práctica: si hay pérdida, verás latencia y reintentos aunque el enlace “esté arriba”. En diagnósticos, esto se refleja en conexiones lentas, timeouts o ventanas que se reducen.

Control de flujo (ventana TCP)

TCP implementa control de flujo para no saturar al receptor. El receptor anuncia una ventana (cuántos bytes puede aceptar sin desbordar buffers). El emisor limita lo que envía según esa ventana.

Ejemplo práctico: si un servidor está bajo carga y su aplicación no consume datos rápido, el buffer de recepción puede llenarse y la ventana anunciada disminuir; el cliente enviará más lento aunque la red sea rápida.

UDP: transporte sin conexión y de baja sobrecarga

UDP es un protocolo de datagramas: no establece conexión, no garantiza entrega, orden ni retransmisión. A cambio, tiene baja sobrecarga y menor latencia en escenarios donde la aplicación tolera pérdidas o implementa su propia lógica.

Cuándo se usa UDP en servidores

• DNS: consultas rápidas; si se pierde un datagrama, el cliente reintenta.
• NTP: mensajes pequeños y periódicos; la pérdida ocasional suele ser aceptable.
• Streaming/VoIP/juegos: priorizan latencia sobre confiabilidad estricta (la aplicación decide).

Idea clave: UDP no es “peor”; es una elección. Si necesitas confiabilidad, la implementas arriba (o usas TCP).

Sección práctica: inspección y pruebas de puertos y estados TCP

1) Verificar puertos abiertos/escuchando en un servidor (ss/netstat)

Objetivo: confirmar qué servicios están escuchando y en qué interfaces (0.0.0.0, 127.0.0.1, IP pública, etc.).

Paso a paso con ss (recomendado)

• Listar sockets TCP en escucha:

sudo ss -lntp

• Listar sockets UDP en escucha:

sudo ss -lnup

• Filtrar por puerto (ej. 22):

sudo ss -lntp '( sport = :22 )'

Qué mirar: Local Address:Port (dónde escucha), Process (qué servicio/proceso), y si está ligado a 127.0.0.1 (solo local) o a 0.0.0.0/:: (todas las interfaces).

Alternativa con netstat (si está disponible)

sudo netstat -lntp   # TCP escuchando + proceso
sudo netstat -lnup   # UDP escuchando + proceso

Nota operativa: en sistemas modernos, ss suele ser la herramienta preferida.

2) Probar conectividad hacia un puerto (telnet/nc)

Objetivo: desde un cliente, validar si un puerto remoto responde (útil para distinguir “servicio caído” vs “firewall/ruta”).

Probar TCP con nc (netcat)

• Probar si el puerto está accesible (modo escaneo simple):

nc -vz servidor.ejemplo.com 22
nc -vz servidor.ejemplo.com 443

• Probar con timeout (evita esperar demasiado):

nc -vz -w 3 servidor.ejemplo.com 25

Interpretación típica: “succeeded/open” indica que el 3-way handshake se completó; “timed out” sugiere filtrado o pérdida; “refused” suele indicar que el host está alcanzable pero no hay proceso escuchando en ese puerto.

Probar TCP con telnet

telnet servidor.ejemplo.com 80

Si conecta, puedes incluso escribir una petición HTTP mínima para comprobar respuesta:

GET / HTTP/1.1
Host: servidor.ejemplo.com

(En muchos entornos telnet no viene instalado por defecto; nc suele ser más versátil.)

Probar UDP (limitación importante)

UDP no tiene handshake, así que “probar conectividad” es menos directo. nc puede enviar datagramas, pero la ausencia de respuesta no confirma bloqueo. Aun así, puedes hacer pruebas básicas cuando el servicio responde por diseño.

nc -vu -w 2 servidor.ejemplo.com 123

Para diagnósticos serios de UDP, normalmente se usan herramientas específicas del servicio (por ejemplo, clientes NTP) o capturas de tráfico.

3) Entender estados TCP en diagnósticos (SYN-SENT, ESTABLISHED, TIME-WAIT)

Los estados TCP describen en qué fase está una conexión. Verlos te ayuda a inferir si el problema es de red, firewall, servicio o saturación.

Ver estados con ss

• Ver conexiones TCP y estados:

ss -tan

• Filtrar por destino/puerto (ej. conexiones hacia 443):

ss -tan '( dport = :443 )'

Estados clave y cómo interpretarlos

• SYN-SENT: el cliente envió SYN y espera respuesta. Si se queda aquí, suele indicar filtrado (firewall), ruta problemática o pérdida. En servidores, ver muchos SYN-SENT desde un host puede indicar que ese host no recibe SYN-ACK o que hay asimetría de rutas.
• ESTABLISHED: conexión activa; handshake completado y hay intercambio de datos. Si hay quejas de lentitud con muchas conexiones ESTABLISHED, piensa en cuellos de botella (aplicación, CPU, disco, congestión, retransmisiones).
• TIME-WAIT: estado tras cerrar una conexión, para asegurar que segmentos tardíos no interfieran con conexiones nuevas. Ver muchos TIME-WAIT es común en servidores con muchas conexiones cortas (por ejemplo, HTTP sin keep-alive o ciertos patrones de balanceo). No es necesariamente un error, pero puede consumir puertos efímeros si el volumen es muy alto.

Ejercicio guiado: diagnóstico rápido de “no puedo conectar al puerto”

1. En el servidor, confirma que el servicio escucha:

   sudo ss -lntp '( sport = :22 )'

2. En el cliente, prueba conexión TCP:

   nc -vz -w 3 servidor.ejemplo.com 22

3. Si falla, en el cliente revisa si queda en SYN-SENT:

   ss -tan | grep ':22'

4. Interpreta:

   • “refused” + en servidor no hay escucha: iniciar/ajustar servicio.
   • Timeout + SYN-SENT persistente: revisar firewall, reglas de seguridad, ACLs, rutas, o filtrado intermedio.
   • Conecta pero se corta: revisar logs del servicio y posibles límites (por ejemplo, max conexiones), además de retransmisiones.