Cuando escribes platzi.com en tu navegador y presionas enter, activas uno de los procesos más fundamentales de internet: el modelo cliente servidor. Entender cómo viaja esa petición, qué datos invisibles se intercambian y por qué a veces ves errores como el 404 te da una base sólida para programar, diseñar o auditar cualquier producto digital.

¿Qué es el modelo cliente servidor y cómo funciona?

El cliente es tu navegador. Cuando escribes una URL, el router traduce ese dominio a una dirección IP que apunta al servidor donde viven los datos del sitio. Tu cliente envía la petición, el servidor responde y los datos viajan de vuelta usando HTTP, HyperText Transfer Protocol, o su versión segura HTTPS, donde la S significa que los datos van cifrados [00:32].

¿Qué es HTTPS? Es el protocolo HTTP con cifrado. La S significa secure e indica que cliente y servidor intercambiaron llaves de cifrado antes de transferir información.

¿Cómo sabe un sitio si entras desde móvil o escritorio?

Cada petición lleva información oculta para el usuario en los headers HTTP. Uno de esos datos se llama user agent o agente de usuario, y describe tu navegador, sistema operativo y tipo de dispositivo [01:24]. Gracias a eso, el servidor decide si te manda la versión móvil, la de escritorio o una específica para iPhone o Android.

¿Qué son las cookies y para qué sirven?

Cuando entras a Gmail y ya sabe quién eres, no es magia: son cookies. Una cookie es un dato que el servidor guarda en tu computadora asociado a un dominio específico, como google.com o platzi.com. Esas variables viajan en la cabecera del protocolo cada vez que haces una petición [02:00].

Si entras a Platzi y ya eres estudiante, el servidor lee tus cookies, identifica que eres tú y te responde con el home de estudiante en lugar del sitio público. Es una respuesta única derivada de esa identificación.

¿Cómo se construye una página web en el navegador?

El servidor no manda todo de golpe. Primero envía HTML, HyperText Markup Language, que es texto plano con la estructura de la página y referencias a otros archivos [03:10].

• CSS o Cascade Style Sheets: define el diseño gráfico del sitio.
• JavaScript: aporta los componentes interactivos, como botones que reaccionan al clic.
• Archivos referenciados: el navegador hace peticiones adicionales para cargarlos.

Cada uno de esos archivos implica una nueva petición al servidor, y el navegador los va ensamblando hasta construir la página completa que ves.

¿Cuál es la diferencia entre el método GET y el método POST?

Cuando buscas algo en Platzi, la URL muestra algo como platzi.com/buscar/?search=chatgpt. Ese signo de interrogación indica que estás enviando variables por el método GET, que las pasa directamente en la URL [04:20].

El problema es que todo lo que viaja por GET queda en el historial del navegador. Imagina enviar tu contraseña así desde un café internet: cualquiera que revise el historial podría leerla.

¿Cuándo usar GET y cuándo POST? Usa GET para búsquedas y datos públicos que pueden quedar en la URL. Usa POST para formularios sensibles como login, porque empaqueta los datos en el header y no quedan visibles en el historial.

El método POST encapsula la información del formulario en un paquete dentro del header, similar al user agent. Así el servidor recibe usuario y contraseña sin exponerlos.

¿Qué significan los códigos de respuesta HTTP?

Los servidores responden con números en la cabecera que indican qué pasó con tu petición [05:40].

• 200 OK: todo salió bien.
• 300 redirect: la dirección existía y ahora apunta a un nuevo lugar.
• 404 not found: la dirección no existe en el servidor.
• 500: error interno, servidor ocupado, trabado o mal configurado.

Estos códigos no solo aplican a páginas web. También funcionan para APIs y cualquier intercambio sobre HTTP.

¿Qué protocolos existen para el correo electrónico?

El correo usa protocolos distintos al web [06:20]:

• SMTP o Simple Message Transfer Protocol: hoy en desuso para recepción.
• POP3 o Post Office Protocol 3: descarga mensajes al cliente.
• IMAP o Internet Message Access Protocol: sincroniza mensajes con el servidor.

El correo electrónico se volvió tan complejo que la mayoría de empresas delegan su gestión a Microsoft con Outlook o a Google con Gmail. Solo las compañías más grandes mantienen sus propios servidores.

¿Cómo se comunican las apps móviles con los servidores?

Las aplicaciones nativas no usan HTML, CSS ni JavaScript. En Android se programa con Java o Kotlin y en iOS con Swift u Objective C [07:10]. Para intercambiar datos con el servidor usan estructuras como JSON (JavaScript Object Notation) o XML (eXtended Markup Language).

XML se parece a HTML, pero en lugar de describir títulos o cabeceras visuales, expresa cualquier tipo de estructura de datos. JSON hace lo mismo de forma más ligera y es el estándar actual en APIs.

Aunque cambien los formatos, la lógica es la misma: un cliente hace una petición por un protocolo, normalmente HTTPS, el servidor entiende los datos y responde. Eso es el modelo cliente servidor completo.

¿Qué parte del recorrido de una petición HTTP te sorprendió más? Cuéntame en los comentarios cómo lo aplicarías en tu próximo proyecto.