Redes de computadores

Cuando tu backend recibe una petición HTTP, cuando tu base de datos escucha en el puerto 5432, cuando tu curl sale a internet… hay una torre de protocolos trabajando en conjunto. Entender redes no es teoría de universidad: es la base para diagnosticar por qué algo no conecta, por qué algo va lento, y cómo diseñar sistemas distribuidos.

Esta página te da el mapa completo. La wiki del sitio tiene el tema a fondo en TCP/IP y el viaje de un paquete — lee ambas.

El modelo de capas

La red se organiza en capas, cada una resolviendo un problema. El modelo OSI (7 capas) y el TCP/IP (4 capas):

💡 Truco mental: cada capa resuelve un problema. Aplicación = formato del dato. Transporte = entrega entre procesos. Internet = entre máquinas. Enlace = entre vecinos inmediatos.

Encapsulación

Cada capa envuelve los datos de la superior con su cabecera:

Datos HTTP ──▶ [TCP] ──▶ [IP] ──▶ [Ethernet] ──▶ cable

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

Al llegar se desenvuelve en orden inverso (desencapsulación). Esa sobrecarga (~54 bytes por paquete) es por qué las peticiones HTTP pequeñas “desperdician” ancho de banda: casi todo es cabecera.

TCP vs UDP

El transporte tiene dos protagonistas:

Handshake TCP (3 vías)

Cliente                         Servidor
  │  SYN ───────────────────────▶ │
  │  SYN-ACK ◀─────────────────── │
  │  ACK ───────────────────────▶ │
  │        conexión establecida   │

TCP garantiza entrega ordenada y sin errores gracias a números de secuencia y confirmaciones (ACKs). El costo: latencia. Cada byte tiene un número de secuencia; el receptor confirma con ack = último recibido + 1.

💡 Puertos: IP:puerto identifica un proceso en todo internet. 192.168.1.20:5432 = máquina 192.168.1.20, proceso en el puerto 5432. Puertos famosos: 22 (SSH), 80 (HTTP), 443 (HTTPS), 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis).

IP y direccionamiento

• IPv4: 32 bits, ~4.3 mil millones de direcciones (insuficientes → NAT e IPv6).
• IPv6: 128 bits, hex: 2001:db8::1.
• CIDR: 192.168.1.0/24 = los 24 primeros bits son la red (256 direcciones, 254 utilizables).

⚠️ Las direcciones privadas no son enrutables en internet. Tu máquina habla por la IP pública del router, que aplica NAT (mapea 192.168.1.20:5432 ↔ 88.x.x.x:50231).

DNS: de nombre a dirección

DNS traduce x.com → IP. Es distribuido y jerárquico — no hay una sola máquina que lo sepa todo:

Cliente → resolutor (8.8.8.8, tu router)
  → raíz (.) → "pregunta a .com"
  → servidor .com → "pregunta a los NS de x.com"
  → servidor autoritativo de x.com → 104.244.42.1
  → guarda en caché (TTL)

dig +trace x.com      # muestra los 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.

HTTP y HTTPS

HTTP es el protocolo de la web (página completa en la wiki: HTTP y REST APIs). Lo esencial:

Petición

GET /usuarios/42 HTTP/1.1
Host: api.misitio.com
Accept: application/json

Respuesta

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 42, "nombre": "Ana"}

Métodos y códigos que debes saber

HTTPS = HTTP + TLS

HTTPS cifra la comunicación con TLS (la evolución de SSL). Antes de la petición, hay un handshake TLS que negocia cifrado y autentica el servidor con su certificado (la “cerradura” del navegador).

HTTP  (texto plano: cualquiera en la red lo lee)
HTTPS = HTTP sobre TLS (cifrado + autenticación)

💡 TLS en una frase: el cliente y el servidor acuerdan una clave de sesión sin que nadie más la sepa (usando cifrado asimétrico con certificados), y a partir de ahí cifran todo con cifrado simétrico (rápido).

Qué pasa al hacer curl https://x.com

Cuenta los round-trips:

1. DNS: x.com → IP (1 round-trip, con caché si ya se preguntó).
2. TCP: handshake de 3 vías (1 round-trip).
3. TLS: handshake de cifrado (1 round-trip).
4. HTTP: la petición ya sale.

= 3 round-trips antes de la petición HTTP. De ahí que la caché DNS, keep-alive y HTTP/2 reduzcan tanto la latencia percibida.

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

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

Sockets

Un socket es la interfaz de programación de red: el extremo de una conexión en tu proceso. Todo backend los usa (aunque tu framework lo oculte).

# Cliente TCP con socket en Python
import socket

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("api.misitio.com", 443))   # TCP
s.sendall(b"GET / HTTP/1.1\r\nHost: api.misitio.com\r\n\r\n")
data = s.recv(4096)
print(data[:100])
s.close()

# Con las herramientas del SO
netstat -tulpn          # puertos en escucha y conexiones
ss -tulpn               # igual, más moderno
lsof -i :5432           # qué proceso usa el puerto 5432
ping google.com         # ICMP: ¿está vivo y a qué latencia?
traceroute google.com   # los saltos hasta el destino

Cheatsheet de herramientas de diagnóstico

Terminología clave

Práctica propuesta

1. Ejecuta curl -v https://google.com y identifica cada paso en la salida (DNS, TCP, TLS, HTTP).
2. Con dig +trace google.com observa los saltos DNS. ¿Cuántos niveles pasan?
3. Levanta un servidor HTTP mínimo en Python (python3 -m http.server 8000) y conéctate con nc localhost 8000.
4. Escribe un cliente TCP que se conecte a google.com:80 y envíe una petición HTTP a mano (como el ejemplo).
5. Con ss -tulpn identifica los puertos en escucha de tu máquina.
6. Abre Wireshark (o tcpdump) y captura un ping o una petición HTTP: mira la encapsulación real.

Para profundizar

• TCP/IP y el viaje de un paquete: la wiki de este sitio con el tema a fondo.
• HTTP y REST APIs: las wikis de protocolo y diseño de APIs.
• Computer Networking: A Top-Down Approach (Kurose/Ross): el libro de redes más usado en universidades, con labs de Wireshark gratis.
• Beej’s Guide to Network Programming: sockets en C, directa y práctica.
• Stanford CS144: implementas una pila TCP mínima en C++.
• Cloudflare Learning: todo el stack explicado con claridad.
• Redes y seguridad (DevOps): la parte de operaciones: firewalls, SSH, fail2ban.
• Sigue con 🗄️ Bases de datos.