Una request no es magia: DNS, TCP, HTTP y latencia

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.com

Eso devuelve una o varias direcciones. El resultado puede variar según el momento y el resolver:

<IPv4 observada>

Para ver el detalle completo:

dig example.com

Mirá 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. Esta salida es ilustrativa:

;; ANSWER SECTION:
example.com.        3600    IN    A    <IPv4 observada>

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.com

Leelo 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).

Un fragmento ilustrativo se ve así; la IP, los headers y la versión de TLS/HTTP pueden cambiar:

*   Trying <IPv4 observada>:443...
* Connected to example.com (<IPv4 observada>) port 443
* SSL connection using TLSv1.3
> GET / HTTP/2
< HTTP/2 200
< content-type: text/html

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 -sS -w \
  "dns:       %{time_namelookup}s\nconexion:  %{time_connect}s\ntls:       %{time_appconnect}s\nprimer byte: %{time_starttransfer}s\ntotal:     %{time_total}s\n" \
  https://example.com

La terminal imprime los tiempos medidos en segundos. Estos números son ilustrativos:

dns:       0.024180s
conexion:  0.081240s
tls:       0.158320s
primer byte: 0.190450s
total:     0.210450s

Estos valores son acumulados desde el inicio, no la duración aislada de cada etapa. En el ejemplo, TCP tomó aproximadamente time_connect - time_namelookup (0,057 s), TLS tomó time_appconnect - time_connect (0,077 s), y la espera hasta el primer byte tomó time_starttransfer - time_appconnect (0,032 s). El resto incluye recibir la respuesta. Si time_total es alto, compará también time_starttransfer antes de culpar al servidor: el cuerpo puede tardar en descargarse.

Para repetir la prueba sin la resolución DNS normal de curl, primero obtené una IPv4 actual y pasásela con --resolve. Conservás el nombre de la URL para HTTP y TLS:

resolved_ip=$(dig +short A example.com | head -n 1)
curl --resolve "example.com:443:$resolved_ip" -o /dev/null -sS -w \
  "dns: %{time_namelookup}s\ntotal: %{time_total}s\n" \
  https://example.com

Compará time_namelookup entre ejecuciones; con --resolve puede quedar cerca de cero. Los demás tiempos pueden variar entre pruebas. Si usás un proxy, la ruta y los tiempos medidos pueden ser distintos.

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.

Evidencia esperada

Para completar este lab y guardar tu evidencia técnica, documentá tu prueba con una estructura similar a esta:

[1] Trace de conexión (curl -v redactado):
* Connected to example.com (<IPv4 observada>) port 443
* TLS handshake completado (TLSv1.3)
> GET / HTTP/2
< HTTP/2 200

[2] Desglose de latencias (curl -w):
- DNS lookup:    0.024s
- Conexión TCP:  0.057s
- Handshake TLS: 0.077s
- Espera hasta el primer byte: 0.032s
- Tiempo total:  0.210s

[3] Conclusión técnica:
La etapa de mayor impacto fue el handshake TLS (cifrado y negociación de certificados).
Al fijar la IP con --resolve, curl evita su consulta DNS normal para ese host y puerto;
time_namelookup puede acercarse a 0s. La URL mantiene el nombre para HTTP y TLS.