Una request no es magia: DNS, TCP, HTTP y logs
Qué pasa de verdad entre que escribís una URL y ves una respuesta. Resolución de nombres, conexión, request, respuesta y dónde mirar cuando falla.
Antes de empezar necesitás
- Una terminal con dig y curl (Linux, WSL o macOS)
- Conexión a internet
Al terminar vas a poder
- Resolver un nombre a una IP con dig y entender el resultado
- Seguir una request HTTP completa con curl -v
- Leer status codes y headers sin adivinar
- Medir la latencia de cada etapa de una request
- Saber dónde mirar cuando algo falla en la red
Escribís una URL, apretás Enter y aparece una página. Parece instantáneo y parece magia. No lo es: es una secuencia de pasos bien definida, y cada uno puede fallar, demorar o mentirte. Si conocés los pasos, dejás de adivinar.
1. DNS: del nombre a la IP
Las computadoras no hablan con ejemplo.com, hablan con una IP. DNS es la guía telefónica que traduce uno en otro.
dig +short example.comEso te devuelve la IP, limpia. Para ver el detalle completo:
dig example.comMirá la sección ANSWER: ahí está el registro, su tipo (A para IPv4, AAAA para IPv6) y el TTL, los segundos que se puede cachear esa respuesta.
2. La request completa, en vivo
curl -v (verbose) te muestra cada etapa: la conexión, el handshake TLS, los headers que mandás y los que recibís.
curl -v https://example.comLeelo por símbolos:
- Líneas con
*→ lo que hace curl por debajo (conectar, TLS, etc.). - Líneas con
>→ lo que vos enviás (tu request y tus headers). - Líneas con
<→ lo que el servidor responde (status y sus headers).
3. Status codes: no los adivines
La primera línea de la respuesta trae el código. No hace falta memorizarlos todos, sí entender las familias:
2xx ✓ salió bien (200 OK, 204 No Content)
3xx → andá a otro lado (301 movido, 304 no cambió)
4xx ✗ error tuyo (401 sin auth, 403 sin permiso, 404 no existe)
5xx ✗ error del servidor (500 explotó, 502/504 problema de gateway)4. Headers: el contexto de la conversación
Los headers son metadata. Algunos que importan seguido:
Content-Type: qué formato tiene el cuerpo (application/json,text/html).Authorization: tus credenciales (un token, por ejemplo).Cache-Control: si la respuesta se puede cachear y por cuánto.Set-Cookie: el servidor te pide guardar una cookie.
5. Latencia: ¿dónde se va el tiempo?
“La página tarda” no es un diagnóstico. ¿Tarda el DNS? ¿La conexión? ¿El servidor en responder? curl -w te lo desglosa:
curl -o /dev/null -s -w \
"dns: %{time_namelookup}s\nconexion: %{time_connect}s\ntls: %{time_appconnect}s\ntotal: %{time_total}s\n" \
https://example.comAhora “está lento” se convierte en una pregunta concreta: ¿qué etapa es la que pesa? Si es time_namelookup, es DNS. Si es time_total pero las demás son bajas, el servidor tarda en pensar la respuesta.
El diagrama mental
sequenceDiagram participant N as Navegador participant D as DNS participant S as Servidor N->>D: 1. resolver nombre (dig) D-->>N: IP N->>S: 2. abrir conexión (TCP + TLS) N->>S: 3. GET /ruta + headers S-->>N: 4. status + headers + body Note over N: render
Guardá ese diagrama. Cada flecha es una etapa que podés medir con curl -w y un lugar donde algo puede fallar.
Lo que practicás en este lab
Llevátelo a tu repo si querés, pero no es obligatorio: es tu aprendizaje.
- Un trace de curl -v de una request real, con el dominio que elijas
- Diagrama simple del flujo navegador → DNS → servidor → respuesta
- Tabla con los tiempos de cada etapa (DNS, conexión, TLS, total)
Reto
Elegí un sitio, medí con curl -w el tiempo de DNS, conexión y total. Cambiá el dominio por su IP directa y compará. Explicá en dos líneas qué etapa desapareció y por qué.
Resolvelo y escribí dos líneas explicando qué pasó. Con eso lo fijás.