Comunicación entre servidores y clientes en redes de computadoras: flujos reales

Flujos reales extremo a extremo: cómo “viaja” una solicitud entre cliente y servidor

En operación diaria de servidores, casi nunca analizas “capas” de forma aislada: lo que importa es el recorrido completo desde que un cliente intenta usar un servicio hasta que el servidor responde. En este capítulo integrarás varios flujos típicos (web, SSH, DNS y NTP) describiendo qué ocurre en cada etapa (resolución, ARP/ND, establecimiento TCP, cifrado si aplica, respuesta) y qué métricas conviene observar para diagnosticar lentitud o fallos.

Mapa mental de un flujo (plantilla reutilizable)

Usa esta plantilla para cualquier servicio. La idea es que puedas “marcar” en qué paso se rompe o se degrada el rendimiento.

• 1) Selección de destino: nombre (FQDN) o IP, puerto, protocolo.
• 2) Resolución de nombre (si aplica): consulta DNS, cachés, TTL.
• 3) Alcance L2/L3: ¿destino en la misma red? Si no, se usa gateway. En ambos casos se necesita MAC vía ARP (IPv4) o ND (IPv6).
• 4) Establecimiento de transporte: TCP 3-way handshake o UDP “sin conexión”. Métricas: RTT, retransmisiones, MSS/PMTUD.
• 5) Seguridad/cifrado (si aplica): TLS (HTTPS) o SSH. Métricas: tiempo de handshake, versión/cifras, reintentos.
• 6) Petición y respuesta de aplicación: HTTP request/response, SSH auth, DNS answer, NTP offset/delay.
• 7) Observabilidad: correlación entre captura de paquetes y logs del servidor (y del cliente si es posible).

Métricas transversales que debes mirar siempre

• Tiempo de resolución DNS: latencia de consulta, número de consultas, fallbacks (A/AAAA), NXDOMAIN.
• RTT: tiempo ida y vuelta observado en SYN/SYN-ACK o en ICMP (si disponible). En TCP, el RTT real se ve en ACKs y en herramientas como ss.
• Retransmisiones: indican pérdida o congestión; en capturas aparecen como TCP Retransmission o por números de secuencia repetidos.
• Tiempo de handshake: TCP (SYN→SYN/ACK→ACK), TLS (ClientHello→ServerHello…), SSH (KEXINIT→NEWKEYS).
• Errores de aplicación: HTTP 5xx/4xx, SSH auth failures, SERVFAIL en DNS, “no server suitable” en NTP.
• Colas y saturación: backlog TCP, CPU del proceso, límites de archivos, latencia de disco (impacta respuestas).

Flujo 1: Acceso web a una aplicación (HTTPS)

Escenario: un cliente abre https://app.ejemplo.com y espera una respuesta de la aplicación. Este flujo es ideal para practicar porque involucra DNS, TCP, TLS y HTTP.

Qué ocurre paso a paso (capas y eventos)

• Resolución: el cliente obtiene IP(s) para app.ejemplo.com (A/AAAA). Puede haber varias IP por balanceo.
• ARP/ND: si el servidor está en la misma red, se resuelve su MAC; si no, se resuelve la MAC del gateway.
• TCP: handshake hacia :443 (SYN, SYN-ACK, ACK). Aquí ya puedes medir RTT base.
• TLS: negociación (ClientHello, ServerHello, certificado, claves). Si hay SNI, el nombre viaja en el ClientHello. Si hay reanudación (session resumption), el handshake puede ser más corto.
• HTTP: el cliente envía GET / (o la ruta) y recibe respuesta (200/302/404/500). Si es HTTP/2, verás frames multiplexados sobre una sola conexión TCP.
• Respuesta: el servidor envía datos; el cliente confirma con ACKs. Si hay pérdida, verás retransmisiones.

Qué métricas observar en este flujo

• DNS: tiempo de consulta y si hay múltiples intentos (por ejemplo, primero AAAA y luego A).
• TCP: RTT del SYN/SYN-ACK, retransmisiones en handshake (síntoma de pérdida o firewall), ventana anunciada.
• TLS: tiempo hasta “handshake finished”, versión TLS, si hay reintentos (HelloRetryRequest en TLS 1.3).
• Aplicación: TTFB (time to first byte) aproximado: desde el envío del request hasta el primer byte de respuesta; y tiempo total de descarga.

Guía práctica: seguimiento de paquete (cliente) + correlación con logs (servidor)

Objetivo: capturar el flujo completo y asociarlo con un request real en el servidor web.

1) En el cliente: medir y capturar

Ejecuta una solicitud con trazas de tiempo:

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

curl -vk --http1.1 -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}
' https://app.ejemplo.com/

Inicia captura enfocada al host y puerto (ajusta interfaz):

sudo tcpdump -i eth0 -nn -s 0 -w web_https.pcap 'host app.ejemplo.com and tcp port 443'

Repite el curl y detén la captura.

2) En la captura: ubicar fases

• DNS: si capturas también DNS, verás consultas A/AAAA. Si no, captura aparte: udp port 53 o DoH/DoT si aplica.
• TCP handshake: filtra por tcp.flags.syn==1 (en Wireshark) y mide tiempo entre SYN y SYN-ACK.
• TLS: busca Client Hello y Server Hello; mide hasta Application Data.
• HTTP: con TLS no verás el contenido sin claves, pero sí el patrón de tamaños/tiempos. Si necesitas ver HTTP, prueba en un entorno de laboratorio con HTTP sin TLS o exporta claves (si controlas el cliente) para decriptar en Wireshark.

3) En el servidor: correlacionar con logs

En el servidor web (ejemplos típicos):

• Nginx: revisa access.log y error.log. Busca por timestamp y por IP del cliente.
• Apache: revisa access.log/error.log.
• App: logs de la aplicación (por ejemplo, un request-id si lo tienes).

Ejemplo de búsqueda por IP y ventana de tiempo:

grep 'IP_DEL_CLIENTE' /var/log/nginx/access.log | tail -n 20

Correlación práctica: compara el timestamp del log con el momento en que en la captura aparece el primer Application Data del servidor (aproxima el inicio de respuesta). Si el log muestra un tiempo de respuesta alto (si lo registras), debería reflejarse como mayor separación entre request y respuesta en la captura.

Ejercicio guiado (web)

• Ejercicio A: repite el curl 5 veces y anota dns/connect/tls/ttfb/total. Identifica cuál componente domina el tiempo total.
• Ejercicio B: fuerza IPv4 vs IPv6 (curl -4 y curl -6) y compara RTT y tiempos de TLS.
• Ejercicio C: si controlas el servidor, introduce una demora artificial en la app (por ejemplo, una ruta que duerma 500 ms) y observa cómo cambia el ttfb sin cambiar el handshake TCP/TLS.

Flujo 2: Conexión SSH administrativa

SSH es un flujo crítico para administración: cuando “se siente lento”, puede ser DNS inverso, latencia, pérdida, o negociación criptográfica. Aquí verás el recorrido completo hasta autenticación.

Qué ocurre paso a paso

• Resolución: el cliente resuelve el nombre del servidor (si usas hostname). Opcionalmente, el servidor puede intentar resolución inversa del cliente (depende de configuración), lo que puede introducir demoras.
• ARP/ND: resolución de MAC del gateway o del servidor.
• TCP: handshake a :22.
• SSH (cifrado): intercambio de banners, negociación de algoritmos, intercambio de claves (KEX), establecimiento de canal cifrado.
• Autenticación: clave pública, password, MFA, etc. Luego apertura de sesión/pty.

Métricas a observar

• Tiempo hasta banner: desde TCP establecido hasta recibir SSH-2.0-....
• Tiempo de KEX: si hay CPU alta o algoritmos pesados, se nota aquí.
• Retransmisiones: afectan la percepción de “teclado lento” y demoras en login.
• Demoras por DNS inverso: típicamente se ven como pausa antes de pedir password o antes de mostrar prompt.

Guía práctica: diagnóstico paso a paso

1) Cliente: conexión con verbosidad

ssh -vvv admin@servidor.ejemplo.com

Observa en la salida tiempos aproximados entre: resolución, conexión TCP, verificación de host key, KEX, autenticación.

2) Cliente: captura de paquetes

sudo tcpdump -i eth0 -nn -s 0 -w ssh.pcap 'tcp port 22 and host IP_DEL_SERVIDOR'

Busca en Wireshark: SYN/SYN-ACK/ACK, luego segmentos con payload (SSH). Si hay retransmisiones, anota en qué fase ocurren.

3) Servidor: correlación con logs

En Linux, revisa autenticaciones SSH:

sudo journalctl -u ssh --since '10 min ago'

o archivos tradicionales:

sudo tail -n 200 /var/log/auth.log

Correlación: ubica el intento por IP del cliente y compara con el momento del handshake en la captura. Si ves pausas en cliente pero el servidor no registra intento hasta tarde, el problema está antes de llegar al daemon (red, firewall, NAT, routing). Si el servidor registra rápido pero el cliente espera, revisa respuesta de red o pérdida.

Ejercicio guiado (SSH)

• Ejercicio A: mide el tiempo total de login con time ssh ... 'exit' y repite 3 veces. Compáralo con el RTT estimado del handshake TCP.
• Ejercicio B: conecta por IP en vez de nombre y compara. Si mejora, sospecha de DNS o de resolución inversa.
• Ejercicio C: en la captura, identifica si hay retransmisiones durante KEX (paquetes grandes) y relaciónalo con MTU/PMTUD o pérdida.

Flujo 3: Consulta DNS (desde un cliente hacia un resolvedor)

Aunque ya conoces DNS, aquí lo verás como flujo operativo: el cliente consulta a un resolvedor (local o remoto) y recibe una respuesta que habilita otros flujos (web, SSH, etc.). El diagnóstico se centra en latencia, reintentos y errores.

Qué ocurre paso a paso

• Selección de resolvedor: el cliente usa el DNS configurado (por ejemplo, un resolvedor local o uno en la red).
• ARP/ND: resolución de MAC para llegar al resolvedor o al gateway.
• Transporte: típicamente UDP/53; si la respuesta es grande o hay políticas, puede caer a TCP/53.
• Respuesta: el cliente recibe el answer, lo cachea según TTL, y continúa con el flujo que dependía del nombre.

Métricas a observar

• Tiempo de respuesta: milisegundos por consulta.
• Reintentos: múltiples queries iguales indican pérdida o timeout.
• UDP→TCP fallback: puede aumentar latencia.
• Códigos de respuesta: NOERROR, NXDOMAIN, SERVFAIL.

Guía práctica: seguimiento de paquete y validación

1) Cliente: medir con herramienta de consulta

dig @IP_DEL_RESOLVEDOR app.ejemplo.com A +stats

Repite para AAAA:

dig @IP_DEL_RESOLVEDOR app.ejemplo.com AAAA +stats

2) Cliente: captura enfocada a DNS

sudo tcpdump -i eth0 -nn -s 0 -w dns.pcap 'host IP_DEL_RESOLVEDOR and (udp port 53 or tcp port 53)'

En Wireshark, verifica: ID de transacción, tiempo entre query y response, y si hay queries duplicadas.

3) Resolvedor/servidor DNS: correlación con logs

Según el software, habilita o consulta logs de queries. Si tienes un resolvedor local con systemd-resolved, puedes inspeccionar estado y estadísticas; si usas un servidor DNS dedicado, revisa su log de consultas y errores. La correlación clave es: ¿el resolvedor recibió la consulta cuando el cliente la envió? Si no, el problema está en red (L2/L3) o firewall. Si sí la recibió pero respondió tarde, el problema está en el resolvedor o en su upstream.

Ejercicio guiado (DNS)

• Ejercicio A: ejecuta 10 consultas seguidas y calcula promedio y desviación. Identifica outliers y revisa en la captura si hubo reintento.
• Ejercicio B: fuerza TCP con +tcp y compara latencia con UDP.
• Ejercicio C: consulta un nombre inexistente y observa NXDOMAIN; luego revisa si el cliente reintenta con sufijos de búsqueda (search domains) según configuración.

Flujo 4: Sincronización NTP (cliente ↔ servidor de tiempo)

NTP suele “funcionar hasta que no”: cuando hay deriva de reloj, certificados TLS fallan, logs quedan desordenados y la correlación de eventos se vuelve difícil. El flujo NTP es principalmente UDP y su diagnóstico se centra en delay, offset y reachability.

Qué ocurre paso a paso

• Selección de servidor NTP: el cliente elige un servidor configurado (o varios) y evalúa calidad.
• ARP/ND: resolución de MAC hacia servidor/gateway.
• UDP: intercambio de mensajes NTP (sin handshake como TCP).
• Cálculo: el cliente estima delay (retardo) y offset (diferencia de reloj) con timestamps.
• Ajuste: el daemon ajusta el reloj gradualmente (slew) o, en casos, con saltos controlados (step) según políticas.

Métricas a observar

• Offset: diferencia entre reloj local y referencia (ms).
• Delay: latencia estimada (ms).
• Jitter: variación del offset.
• Reach: indicador de alcanzabilidad (en algunos clientes).
• Pérdida: se manifiesta como falta de respuestas o intervalos irregulares.

Guía práctica: verificación y captura

1) Cliente: inspeccionar estado NTP

Dependiendo de tu stack, usa el comando correspondiente. En sistemas con systemd-timesyncd:

timedatectl timesync-status

En sistemas con chrony:

chronyc tracking

chronyc sources -v

2) Cliente: captura de NTP

sudo tcpdump -i eth0 -nn -s 0 -w ntp.pcap 'udp port 123 and host IP_DEL_SERVIDOR_NTP'

En Wireshark, revisa el tiempo entre request/response y si hay respuestas ausentes.

3) Servidor NTP: correlación con logs

En un servidor NTP, revisa logs del servicio (según daemon). La correlación típica es: si el cliente envía paquetes (visible en captura) pero el servidor no registra recepción, sospecha de ACL/firewall/ruta. Si el servidor recibe pero el cliente no ajusta, revisa calidad (stratum, offset alto, políticas de step/slew).

Ejercicio guiado (NTP)

• Ejercicio A: registra offset y delay cada minuto durante 10 minutos y grafica mentalmente si hay jitter alto. Si hay picos, revisa en la captura si coinciden con pérdida.
• Ejercicio B: cambia temporalmente a otro servidor NTP (si tu política lo permite) y compara métricas.
• Ejercicio C: valida correlación de logs: genera un evento en el servidor y en el cliente y verifica si los timestamps son coherentes tras estabilizar NTP.

Laboratorio integrador: una “historia” completa con correlación multi-servicio

Objetivo: ejecutar una acción real (abrir la web de la app) y demostrar con evidencia (pcaps + logs) qué dependencias se activaron: DNS → HTTPS → (opcional) llamadas internas; y verificar que NTP no introduce problemas de tiempo para TLS/logs.

Plan de trabajo

• Paso 1: valida hora del cliente (NTP) y anota offset/delay.
• Paso 2: ejecuta una consulta DNS del FQDN de la app y guarda salida.
• Paso 3: ejecuta curl con métricas y guarda resultados.
• Paso 4: abre una sesión SSH al servidor (si aplica) para revisar logs del request web.
• Paso 5: captura tráfico durante los pasos 2–4 (o en capturas separadas) y etiqueta tiempos.

Checklist de correlación (lo que debes poder demostrar)

Ejercicio final de “seguimiento de paquete” (entregable)

Entrega un reporte breve (puede ser en texto) con:

• Un recorte temporal: “a las 10:15:32.120 envié DNS; a las 10:15:32.140 recibí respuesta; a las 10:15:32.150 inicié TCP; a las 10:15:32.180 terminó TLS; a las 10:15:32.300 llegó el primer byte”.
• Capturas: 1 pcap DNS y 1 pcap HTTPS (o una sola con filtros), más 1 captura SSH si la usaste.
• Una correlación con logs del servidor: línea(s) del access log que correspondan al request y su timestamp.
• Una hipótesis de rendimiento: “el 70% del tiempo fue TLS” o “hubo retransmisiones en el handshake TCP” o “DNS tardó 200 ms por reintentos”.