Cuando escribes una URL, ocurren varios pasos invisibles que determinan la velocidad, la seguridad y la experiencia de navegación. Aquí entenderás, con claridad y confianza, cómo el navegador, el sistema operativo, el servidor y las cookies cooperan para entregar HTML, CSS, imágenes y JavaScript usando HTTP, DNS, cabeceras y puertos.
¿Qué hace el navegador con la URL y el DNS?
Al teclear www.platzi.com/fundamentos, el navegador (ejemplo: Chrome) primero le pregunta al sistema operativo si tiene el DNS en caché para resolver la IP de platzi.com. Así evita consultar a los servidores DNS cada vez.
- Si hay IP en caché, continúa de inmediato.
- Si no, resuelve el dominio a IP con DNS.
Después, en la RAM el navegador crea un HTTP request con el método GET (pedir) o POST (enviar). Para /fundamentos usa algo como: “GET /fundamentos HTTP/2”. Además, agrega cabeceras clave:
- Host: indica el dominio, porque una misma IP puede servir múltiples sitios (virtual hosts) como platzi.com, Krystalab.com, Maestrosdelweb.com o Guiadeemprendimiento.com.
- User-Agent: informa el navegador y capacidades; por ejemplo, Chrome 28.
- Otras cabeceras: tipos de archivos aceptados, si tiene Flash, etc.
Finalmente, el navegador envía el request a la IP del servidor por el puerto 80 (HTTP).
¿Cómo luce un http request real?
GET /fundamentos HTTP/2
Host: platzi.com
User-Agent: Chrome/28
Accept: */*
¿Cómo responde el servidor con estados y cabeceras HTTP?
El servidor procesa la petición y envía un HTTP response con un código de estado. El exitoso es 200 OK, pero también puede ser 404 No encontrado o 500 Error del servidor. Además, incluye metadatos fundamentales:
- Date: fecha de la respuesta.
- Server: ejemplo, Nginx 18 sobre Linux.
- Last-Modified: fecha de última modificación. Permite al navegador decidir si reutiliza el caché y evita descargar otra vez CSS, imágenes o assets iguales.
- Content-Length: bytes del cuerpo de la respuesta. Útil para mostrar barras de progreso al descargar.
- Connection: puede ser “close” o mantenerse abierta para casos como chats con sockets.
- Content-Type: tipo de dato. Ejemplos: text/html, image/jpg, video/mp4.
Tras las cabeceras, llega el HTML “tal cual”. Si el Content-Length es 13, el cuerpo tendrá trece bytes: el navegador lo valida automáticamente.
¿Cómo luce un http response?
HTTP/2 200 OK
Date: <fecha>
Server: Nginx 18
Last-Modified: <fecha>
Content-Length: 13
Connection: close
Content-Type: text/html
<13 bytes de HTML>
¿Qué assets se piden luego del HTML?
Si el HTML referencia una imagen, un fondo, una hoja de estilos en CSS o un script de JavaScript, el navegador inicia assets requests. Cada recurso dispara su propio HTTP request, reusando el mismo proceso desde el inicio pero con la URL del asset tomada del HTML. Si el JavaScript hace peticiones de Ajax, repite la secuencia otra vez.
- HTML llega primero y se parsea.
- Por cada recurso enlazado, se hace un request independiente.
- El navegador coordina todas las respuestas y arma la página final.
¿Cómo funcionan las cookies y por qué pesan?
Las cookies son pares nombre=valor que viajan tanto en el request como en el response. Por eso el servidor puede “recordar” tu sesión, cuántas veces entraste o recuperar un texto no enviado.
- Se adjuntan a todos los requests posteriores al mismo dominio.
- El servidor puede actualizarlas en la respuesta antes del HTML.
- Son similares a un pequeño almacenamiento clave-valor.
Ejemplos frecuentes: nombre=Freddie, visitas=22 que luego pasa a 23. Incluso una recomendación clara: usar contraseñas largas, porque son más seguras cuando son así.
¿Qué impacto tienen en el rendimiento?
Las cookies pesan bytes. Si suman 100 KB, en cada ida y vuelta viajarán esos 100 KB, sumando 200 KB, incluso si el contenido de la página es menor a 1 KB. Por eso no hay que abusar: deben ser variables pequeñas y puntuales.
- Más cookies: más transferencia en ambos sentidos.
- Menos cookies: respuestas más ligeras.
- Mantenerlas limitadas: práctica esencial.
Para ver qué cookies guarda tu sitio: clic derecho, “inspeccionar elemento”, luego “resources” o “recursos”, y busca “cookies”. Cada navegador lo muestra de forma distinta; vale la pena explorarlo.
¿Te quedó alguna duda sobre HTTP, DNS, cookies o assets? Cuéntame en comentarios qué parte te interesa profundizar y qué experimentos quieres probar en tu navegador.
