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 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/2200OKDate:<fecha>Server:Nginx 18Last-Modified:<fecha>Content-Length:13Connection:closeContent-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.
El navegador le hace una petición al sistema operativo para ver si tiene una versión en caché.
GET le pide al servidor los datos y se los envía a la IP del servidor.
El servidor responde con un número, como 200 (OK), 404 (No encontrado), 500 (error del servidor).
Assets request.
La cookies son datos guardados en variables y van en el request y en el response del servidor. Las cookies pesan, entonces es importante limitarlas para no afectar la velocidad de las peticiones.
gracias a ti y a las personas que hacen resumen del video , esto ayuda a los que no han entendido y se les agradece mucho
Buen resumen maldeadora…SLds…
Anotaciones de la Clase
Muchas gracias ❤️!
Que genial
Con la herramienta de Software de Ccleaner, tambn es posible ver que cookies viven desde tu PC, y se pueden eliminar o mantener.
En los estados de las conexiones, generalmente los mayores a 500 son errores en el servidor, los de 400 son problemas en la peticiones, los que están entre 300 indican redirecciones y los códigos 200 significan un response correcto
Excelente información.
¡Gracias por el aporte y la información!
soy tecnólogo ADSI llevo 8 meses sin hacer una línea de código, por coincidencia pude comprar pazti Basic llevo 3 días y son los 3 días más felices, motivantes y con más ganas de romper por fin con todas las metas que me eh planteado ya hace 2 años.
muchas gracias
Es un sentimiento compartido, son muchas las espectactivas que genera cada curso 😄
Hola Cristian estoy haciendo mi etapa práctica, y me gustaría saber en qué va tu carrera, si hay futuro aquí, cómo estás profesional y económicamente.
Yo inspeccionando: Me parece que he visto un lindo gatito!!
Huevo de pascua de regalo. Adoro a estos geeks. 💚
Hola. Encontré las cookies de cualquier sitio así (Chrome):
F12
Desplazar hacia la pestaña que dice Application
En la barra izquierda dice "Cookies"
muchas gracias por compartir
Muchas gracias amigo!
El navegador le hace una petición al sistema operativo para ver si tiene en caché el DNS pedido (Si entramos a los mismos sitios webs muchas veces no tiene sentido estar yendo todo el tiempo a los sevidores de DNS).
El navegador una vez entiende cual es la IP forma internamente en la RAM un HTTP Request (métodos de petición para indicar la acción que se desea realizar para un recurso determinado) y este lo organiza con el metodo GET (Mira aqui todos los metodos ) que le dice algo asi:
La peticion empieza por la palabra GET
Fundamentos porque intentamos ir a fundamentos
HTTP/2 es la version del protocolo (El estandar de http exige que cuando se envie se coloque /)
Despues se escribe Host: dominioquequieresacceder (Si te preguntas que si ya tienes la IP para que quiero el dominio, es porque en un mismo servidor pueden correr diferentes dominios, por ejemplo en el servidor de platzi corre tambien maestros del web, cristallab, etc…)
Luego le mencionamos nuestro User-Agent (Aqui es como descubren los servidores que navegador estan usando Y ESTO NO LO VE EL USUARIO, ESTO VIAJA ESCONDIDO EN LAS CABECEDERAS HTTP)
Todos estos datos se empaquetan y se envian a la IP del servidor que recibe la peticion en el puerto 80 (porque es http)
El servidor responde con un numero, como 200 (ok), 404 (Not Found), 500 (error del servidor)
Llega la fecha en que se hizo la peticion
El tipo de servidor
La ultima fecha modificada (ESTO ES MUY IMPORTANTE, COLOCAMOS LA ULTIMA FECHA EN QUE SE MODIFICO PORQUE PUEDE QUE EN CACHE EN ESTE MISMO INSTANTE ESTE EL MISMO ARCHIVO, ENTONCES NO NECESITAMOS CARGAR OTROS ARCHIVOS). TE PERMITE INMEDIATAMENTE QUE EL NAVEGADOR SEPA “ESTE ES EL MISMO ARCHIVO QUE DESCARGUE AYER, NO LO HAN MODIFICADO. ENTONCES NO TENGO QUE VOLVER A DESCARGAR LOS ASSETS, MODIFICAR CSS, NO TENGO QUE CARGAR OTRAS IMAGENES, ETC…SIMPLEMENTE LO DEJO ASI”. ESTO ES UN INDICADOR PARA QUE EL CACHE SEPA CAUNTO TIEMPO LLEVA CACHEADO UN SITIO WEB
El content-lenght: numero (Este numero es la cantidad de bytes que tiene la peticion http. Cuando son muy largas necesitamos mostrar una barra de carga)
Connection: close (Le decimos que la conexion va a quedar completamente cerrada de manera inmediata, porque http tb puede mantener conexiones abiertas esto lo hace para mantener conexiones de sockets, como por ejemplo cuando hacemos un chat (un chat tiene que estar enviando y recibiendo conexiones todo el tiempo. Y eso hace que la conexion se abra))
Por ultimo le decimos el tipo de dato que le estamos enviando Content-type: text/html en este caso es un html y se manda ahi el html tal cual. Si fuera una imagen pondria image/jpg, etc…
FIJATE QUE EL ARCHIVO HTML QUE LE ENVIAMOS TIENE 13 BYTES Y EL CONTENT-LENGHTH LO INDICA
TODO ESTO SE LE LLAMA UN HTTP Response
SI EN EL HTML YO ESTOY PIDIENDO OTRA SERIE DE RECURSOS POR EJEMPLO QUE EN EL HTML ANTERIOR TENGO UNA IMAGEN, UN BACKGROUND EN CSS DE FONDO, UN CODIGO EN JS, ETC… VUELVO A PASAR POR EL MISMO CAMINO Y ESTE CAMINO ES LO QUE SE LLAMA UN ASSETS REQUEST
Assets Request: Es cuando empiezo a pedir cada uno de ellos de manera independiente y lo unico que tengo que hacer aqui es volver al punto 1 pero con la url del asset que sale de nuestro codigo html (Aqui yo abre enlazado una imagen, un css, un js, etc…). Y el navegador se encarga de conectarse al servidor de platzi de resolver todo de nuevo y de traer el assets correcto
COOKIES: LAS COOKIES VAN TANTO EN EL REQUEST, COMO EN EL RESPONSE DEL SERVIDOR. SON DATOS EN VARIABLES, ES DECIR UN NOMBRE Y UN VALOR (SIMILAR A LOS DNS). LAS COOKIES SE PEGAN AL REQUEST (TODOS LOS REQUEST QUE YO HAGA AL SERVIDOR TRAEN LA COOKIE YA INSTALADA. Y ESTA VIENE COMO OTRO ELEMENTO DEL PROTOCOLO HTTP Y SE METE DENTRO DEL SERVIDOR CUANDO YO HAGO LA PETICION). DEL LADO DEL SERVIDOR YO PUEDO CAMBIAR LAS COOKIES, por ejemplo: Quiero recordar cuantas veces entro un usuario, entonces visitas en vez de 22 tengo 23, y donde actualizo esta? En el momento en el que le respondo al servidor enviandole el HTML, es decir el servidor manda la cookie cambiada como parte de la cabecedera antes de enviar la respuesta HTML del protocolo HTTP.
LAS COOKIES ES UNA FORMA “ESCONDIDA” DE ENVIAR DATOS ENTRE CLIENTE Y SERVIDOR
IMPORTANTEE!!: LAS COOKIES PESAN BYTES, SI SIEMPRE VAN PEGADAS TANTO EN LA PETICION COMO EN LA RESPUESTA, LA CANTIDAD DE COOKIES QUE NOSOTROS COMO PROGRAMADORES LE AGREGUEN A UN SITIO WEB VAN A HACER MAS PESADO TANTO EL ENVIO DE LOS DATOS COMO LA RESPUESTA DE ESTOS. SI TENEMOS 100KB DE COOKIES SIEMPRE LA CONEXION VA A TENER 100KB DE IDA Y 100KB DE VUELTA, 200KB DE TRANSFERENCIA!
NUNCA ABUSES DE LAS COOKIES, ESTAS DEBERIAN SER EXTREMADAMENTE LIMITADAS A PEQUEÑAS VARIABLES.
Si quieres ver que cookies guarda un sitio web de ustedes puedes ir a la console/application y os muestra las cookies
En el punto 3 de este video, Freddy se ha olvidado comentar que la petición viaja hasta la IP Publica (o fija en caso de ser servicio dedicado) del servidor y esta es ruteada hasta la IP y puertos internos configurados para devolver el HTTP Response al GET del lado del servidor.
Gracias por el resumen!!!
Esto explica exactamente como funciona el DNS:
Muy buen comic, me gusta y explica muy a detalle como funciona un request :)
Muy bueno el cómic!
**Para ver las cookies en chrome vamos a **
La parte superior derecha, haz clic en los tres puntos, luego en configuración.
En la parte inferior, haz clic en Configuración avanzada para desplegar mas opciones.
En la sección “Privacidad y seguridad”, haz clic en Configuración de contenido.
Haz clic en Cookies y luego en Ver todas las cookies y todos los datos del sitio web.
Las cokies se pueden borrar para liberar espacio en la ram ???
No lo creo, las cookies se almacenan en el disco duro, no en la ram.
Con Freddy en 20 clases he aprendido más que con las clases de sistemas en todo el colegio, excelente servicio ⭐⭐⭐⭐⭐
Cookies: Eran herramientas anteriormente utilizadas, para guardar las preferencias que tenias al momento de ingresar a una pagina y como por ejemplo cambiar el idioma, aqui el cookie cuando volvias a entrar ya sabia que preferencia de idiomas tenias anteriormente y te hace la carga automatica, pero ahora se utilizan para el marketing. Otro caso tambien es que funcionan como una base de datos para guardar la informacion que introduzcas en ese momento dentro de la pagina web, como por ejemplo tu usuario. Entonces basicamente una cookie es un forma de mandar datos entre el cliente y el servidor.
--> Ademas tambien los cookies funcionan para hacer un track de lo que hizo un usuario dentro de la pagina web, es decir sabe cuales fueron los items que agregaste a un carrito de compra, cuanto tiempo duraste en sesion, cuales fueron los links que viste dentro de la pagina, el tipo de dato que puede guardar un cookie depende del programador y como se estableca pero es casi ilimitada las opciones que se tienen
Muy buena explicación
Gracias
Hola Adolfo Jimmy Saldivias Valarezo, muchas gracias por el resumen de la clase,!
Muchas gracias ❤️!
Estos elementos de petición y recursos hay que tenerlos en cuenta para realizar una pagina Web o ya al subirlas por un servidor el servidor ya lo realizar por si solo??
Todo lo hace el servidor web de manera automática.
Abre Chrome en tu ordenador.
Arriba a la derecha, haz clic en Más Más y luego Configuración.
Abajo, haz clic en Configuración avanzada.
En "Privacidad y seguridad", haz clic en Configuración del sitio web.
Haz clic en Cookies y luego Ver todas las cookies y datos de sitios web
Mi resumen de la clase
El navegador hace peticiones al SO, para ver si tiene en cache los DNS para resolver el sitio que va a buscar.
El navegador cuando cuando entiende cuàl es la IP, forma internamente en la memoria RAM un HTTP REQUEST, en formato GET.
3)El servidor responde con un código, que representa un mensaje.
Assets Request, cuando el html que se pidió puede requeriri más elementos , como imágenes, sonidos, backgrounds, código javascript, si el código javascript empeiza a hacer más peticiones de AJAX se repite todo el proceso por cada uno de los elementso de manera independiente, con la url del asset que sale del HTML.
Cookies, van en el request y en response, son variables con un valor, se debe tener en cuenta de utilizar las necesarios, pues tienen un peso y puede afectar la velocidad de las peticiones.
2xx: Peticiones correctas
200 OK
201 Created
202 Accepted
203 Non-Authoritative Information (desde HTTP/1.1)
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status (Multi-Status, WebDAV)
208 Already Reported (WebDAV)
3xx: Redirecciones
300 Multiple Choices
301 Moved Permanently
302 Found (antes "Moved Temporarily")
303 See Other (desde HTTP/1.1)
304 Not Modified
305 Use Proxy (desde HTTP/1.1)
306 Switch Proxy
307 Temporary Redirect (desde HTTP/1.1)
308 Permanent Redirect
4xx: Errores del cliente
400 Bad Request
401 Unauthorized4
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Request Entity Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Requested Range Not Satisfiable
417 Expectation Failed
418 I'm a teapot
422 Unprocessable Entity (WebDAV - RFC 4918)
423 Locked (WebDAV - RFC 4918)
424 Failed Dependency (WebDAV) (RFC 4918)
425 Unassigned
426 Upgrade Required (RFC 7231)
428 Precondition Required
429 Too Many Requests
431 Request Header Fields Too Large)
449 Una extensión de Microsoft: La petición debería ser reintentada después de hacer la
acción apropiada.
451 Unavailable for Legal Reasons
5xx: Errores de servidor
500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates (RFC 2295)
507 Insufficient Storage (WebDAV - RFC 4918)
508 Loop Detected (WebDAV)
509 Bandwidth Limit Exceeded
510 Not Extended (RFC 2774)
511 Network Authentication Required
512 Not updated
521 Version Mismatch
Vengo del futuro y gracias a las APIs se están dejando de usar cookies.
Las cookies tiene muchos usos como el guardar alguna preferencia o incluso el dato de la sesión del usuario, también se usan mucho para analytics y tracking de usuarios para hacer estrategias de marketing y remarketing.
