TCP/IP y el viaje de un paquete

Cada vez que tu código hace un fetch, una query a la base de datos o un curl, se está montando sobre una torre de protocolos que funcionan en conjunto. Entender TCP/IP no es teoría de universidad: es la base para diagnosticar latencia, timeouts, puertos y por qué algo no conecta.

Modelo OSI vs modelo TCP/IP

El modelo TCP/IP fusiona las capas 5-7 del OSI en “Aplicación” y las 1-2 en “Acceso a red”. En la práctica, quien importa para ti son cuatro: Aplicación → Transporte → Internet → Enlace.

💡 El truco mental: cada capa resuelve un problema concreto. Aplicación = formato del dato. Transporte = entrega de extremo a extremo entre procesos. Internet = encaminar entre máquinas. Enlace = mover tramas entre dos máquinas vecinas.

Encapsulación: cómo viaja un paquete

Cada capa envuelve los datos de la capa superior con su propia cabecera. El proceso se llama encapsulación:

+----------------------  Segmento TCP (datos HTTP + cabecera TCP)
+------------------  Paquete IP (segmento + cabecera IP)
+-------------  Trama Ethernet (paquete + cabecera MAC)
Datos HTTP → [TCP] → [IP] → [Ethernet] → cable

Al llegar al destino se desenvuelve en orden inverso (desencapsulación), capa por capa. Una trama Ethernet real se ve así:

| Cabecera MAC (14 B) | Cabecera IP (20-60 B) | Cabecera TCP (20-60 B) | Datos HTTP | FCS |

⚠️ Cada cabecera suma bytes. Un paquete típico lleva ~54 bytes de sobrecarga entre cabeceras Ethernet + IP + TCP antes de los datos. Por eso los cuerpos HTTP pequeños desperdician ancho de banda: casi todo es cabecera.

TCP: el transporte fiable

TCP garantiza entrega ordenada, sin errores y sin pérdidas, a costa de latencia. Sus tres pilares:

1. Handshake de tres vías (3-way handshake): establece la conexión.
2. Números de secuencia y ACKs: confirma cada byte recibido.
3. Control de flujo y congestión: ventana deslizante.

Handshake de tres vías

Cliente                          Servidor
   │   SYN (seq=100)                 │
   │──────────────────────────────▶ │
   │   SYN-ACK (seq=500, ack=101)    │
   │◀────────────────────────────── │
   │   ACK (seq=101, ack=501)        │
   │──────────────────────────────▶ │
   │      conexión establecida       │

El seq es el número de secuencia inicial de cada lado; el ack confirma el siguiente byte esperado. Solo se necesitan 3 mensajes porque el SYN del cliente y el ACK del servidor viajan juntos en el SYN-ACK.

curl -v https://x.com 2>&1 | grep -E "Connected|HTTP|TLS"

* Connected to x.com (104.244.42.1) port 443
* TLS 1.3 handshake completed
> GET / HTTP/2
< HTTP/2 200

Números de secuencia, ventana y puertos

• Cada byte de la conexión tiene un número de secuencia. El receptor confirma con ack = último recibido + 1.
• Ventana deslizante (window): cuántos bytes puede enviar el emisor sin esperar ACK. Si la ventana es 64 KB, puede lanzar 64 KB de golpe y luego esperar confirmación.
• Puertos: identifican el proceso dentro de la máquina. IP:puerto es la dirección de un proceso en todo internet.

💡 El cuello de botella que ves en las mediciones de red casi siempre es el control de congestión (TCP ajusta la ventana según la pérdida), no el ancho de banda contratado.

UDP vs TCP

# Los 8 bytes de la cabecera UDP: puerto origen, destino, longitud, checksum
| src port (2) | dst port (2) | length (2) | checksum (2) |

💡 DNS usa UDP (peticiones de 50 bytes, sin necesidad de conexión) y solo cae a TCP si la respuesta no cabe en un paquete UDP. HTTP/3 abandona TCP y usa QUIC sobre UDP para evitar el bloqueo de head-of-line del transporte.

IP y direccionamiento

• IPv4: 32 bits, ~4.300 millones de direcciones (insuficientes → NAT y IPv6).
• IPv6: 128 bits, representado en hexadecimal: 2001:db8::1.
• CIDR: notación de red con máscara. 192.168.1.0/24 = los primeros 24 bits son la red (256 direcciones, 254 utilizables).

La dirección IP llega hasta la máquina, pero no hasta el proceso: eso lo hace el puerto. 192.168.1.20:5432 = máquina 192.168.1.20, proceso en puerto 5432.

⚠️ Las direcciones privadas no son enrutables en internet. Tu máquina de casa “habla” por la IP pública del router, que aplica NAT: mapea 192.168.1.20:5432 a 88.x.x.x:50231 al salir, y al revés al volver.

DNS: de nombre a dirección

DNS traduce x.com → IP. Es un sistema distribuido y jerárquico; no hay una sola máquina que lo sepa todo. Resolución completa:

Cliente
  │ 1. ¿x.com?                  → resolutor local (8.8.8.8, tu router)
  │ 2. No lo tengo en caché → raíz (.) → "pregunta a los servidores .com"
  │ 3. ¿x.com?                  → servidor .com → "pregunta a los NS de x.com"
  │ 4. ¿x.com?                  → servidor autoritativo de x.com → 104.244.42.1
  │ 5. Responde al cliente y guarda en caché (TTL)

Pasos con dig:

dig +trace x.com          # muestra los 4 saltos
dig x.com A               # registro de dirección
dig x.com MX              # servidores de correo

💡 Cuando un dominio “tarda en propagarse”, lo que ocurre es que los resolutores intermedios mantienen la respuesta en caché hasta que expira el TTL. TTL bajo (60-300 s) para cambios rápidos; TTL alto (1 día) para ahorrar consultas.

HTTP sobre TCP: la pila completa

https://x.com apila toda la torre:

HTTP/2  (datos de la petición/respuesta)
   ↓
TLS     (cifrado, handshake dentro de TCP)
   ↓
TCP     (entrega fiable, puerto 443)
   ↓
IP      (enrutado hasta 104.244.42.1)
   ↓
Ethernet/Wi-Fi (mover tramas al router)

Qué pasa exactamente al hacer curl

curl https://x.com

1. Resolución DNS: x.com → 104.244.42.1 (con caché local si ya se preguntó antes).
2. Conexión TCP: handshake de 3 vías contra 104.244.42.1:443 (SYN → SYN-ACK → ACK).
3. Handshake TLS: negociación de versión, intercambio de certificados, derivación de la clave de sesión (en TLS 1.3 son 1 round-trip).
4. Petición HTTP: GET / HTTP/2 con cabeceras (Host, User-Agent, Accept…).
5. Procesamiento en el servidor: reverse proxy (Nginx), app, base de datos.
6. Respuesta HTTP: línea de estado HTTP/2 200, cabeceras, body.
7. Cierre: el cliente envía FIN, el servidor responde FIN+ACK, se cierra la conexión (o se reutiliza con keep-alive).

curl -v https://x.com 2>&1 | head -30

*   Trying 104.244.42.1:443...
* Connected to x.com (104.244.42.1) port 443
* TLSv1.3 (IN), TLS handshake, Server hello (2):
*  SSL connection using TLSv1.3
* ALPN, server accepted protocol h2
* Using HTTP2
> GET / HTTP/2
> Host: x.com
>
< HTTP/2 200

Cuenta los round-trips: DNS (1) + TCP handshake (1) + TLS (1) = 3 round-trips antes de que la petición HTTP salga de tu máquina. De ahí que la caché DNS, keep-alive y HTTP/2 reduzcan tanto la latencia percibida.

💡 Diagnóstico rápido: si curl -v se queda en Trying <ip>:443... es un problema de red/TCP (firewall, puerto cerrado). Si conecta y se queda en el TLS handshake, es un problema de TLS (certificado, cipher). Divide y vencerás por capas.

Para profundizar

• Cloudflare Learning — Cómo funciona la red: todo el stack explicado con claridad.
• MDN — ¿Cómo funciona Internet?: introducción accesible en español.
• Beej’s Guide to Network Programming: sockets y TCP/UDP desde el código.
• RFC 9293 — Transmission Control Protocol: la especificación oficial de TCP.
• RFC 1035 — Domain names: cómo funciona el sistema DNS.