Curso exprés · No. 14
Cada vez que se carga una página, las máquinas mantienen una conversación rápida y precisa: encuentran la dirección de la otra, abren una línea, hacen una pregunta y sellan la respuesta en un sobre que nadie más puede leer. Nada de esto es magia — es un puñado de ideas claras con nombres intimidantes. Aprendé los nombres y toda la web se vuelve legible.
Solo lo esencial · Una imagen por idea · Aprende las palabras
Quitá la jerga y una red es una cosa simple: máquinas que se envían mensajes entre sí. Todo lo demás es el detalle de cómo esos mensajes encuentran su camino y se mantienen confiables.
Las computadoras hablan pasándose notas
Un vasto sistema postal: cualquier edificio puede enviar una nota a cualquier otro edificio, siempre que escriba la dirección correcta en el sobre.
Una red son solo computadoras conectadas para poder enviarse datos entre sí. Los datos viajan en pequeños paquetes — como notas partidas en postales, cada una rotulada con de dónde viene y a dónde va. Internet es esto llevado a escala planetaria: miles de millones de máquinas, cualquiera de las cuales puede pasarle un paquete a cualquier otra. Esa es toda la base; el resto es cómo lo hacemos confiable y con sentido.
Cada máquina tiene una dirección — su IP
Cada edificio de la Tierra con una dirección postal única. Sin una, el cartero no tiene a dónde entregar ni a dónde enviar una respuesta.
Para que un paquete llegue, el destino necesita una dirección. Esa es una dirección IP — un número que identifica a una máquina en la red, como 142.250.74.78. Cada dispositivo en línea tiene una. Cuando tu laptop envía una solicitud, estampa su propia IP como dirección de retorno para que la respuesta sepa a dónde volver. Sin dirección, no hay conversación.
El cliente pregunta, el servidor responde
Un comedor y una cocina. Un lado hace los pedidos; el otro los prepara y los devuelve. Los roles están fijos durante la comida.
Casi toda la web funciona con un modelo cliente–servidor. El cliente (tu navegador, tu app) hace una solicitud; el servidor (una máquina que corre un sitio web o servicio) devuelve una respuesta. Tu teléfono es el cliente que pide «dame esta página»; un servidor en algún lugar responde con la página. Tené presente esta pareja — cada idea de abajo trata de hacer que esa solicitud-y-respuesta funcione.
Una red son máquinas pasándose mensajes con dirección. El cliente pregunta, el servidor responde — todo lo demás es hacerlo confiable.
Escribís un nombre como example.com, pero la red solo enruta a números. Algo tiene que traducir el nombre que recordás a la dirección que la máquina necesita. Ese algo es DNS.
Los nombres son para humanos; los números, para máquinas
Recordás a tu amigo por su nombre, pero el sistema telefónico solo marca números — así que llevás una lista de contactos que convierte uno en el otro.
La gente recuerda wikipedia.org; la red necesita una dirección IP como 198.35.26.96. Un nombre de dominio es la etiqueta amigable para humanos; la IP es la dirección amigable para máquinas. Los dos tienen que estar vinculados, porque nadie quiere memorizar números y ningún router puede enrutar un nombre. Salvar esa brecha es todo un sistema, en marcha constantemente, de forma invisible, en cada clic.
DNS es la guía telefónica de internet
Un directorio gigante, siempre abierto: le das un nombre, te devuelve el número a marcar. Nunca lo ves trabajar — solo obtenés el número.
DNS — el Domain Name System — es el servicio que traduce un nombre de dominio a su dirección IP. Antes de que tu navegador pueda buscar example.com, le pregunta a DNS «¿cuál es la dirección de este nombre?» y recibe de vuelta un número. Esta búsqueda (o resolución) ocurre primero, cada vez, en milisegundos. Es el paso poco glamoroso que hace posibles las direcciones web legibles para humanos.
La respuesta se cachea para que sea rápida la próxima vez
Buscás el número de un amigo una vez y lo anotás en un papelito — la próxima vez solo leés la nota en lugar de abrir el directorio entero.
Buscar cada nombre desde cero sería lento, así que las respuestas de DNS se cachean — las recuerdan un rato tu navegador, tu sistema operativo y tu red. La dirección viene con un TTL (time to live) que dice cuánto tiempo es seguro reutilizarla antes de volver a verificar. Por esto un sitio que ya visitaste carga su dirección al instante, y por esto un cambio de DNS puede tardar en propagarse.
DNS es la guía telefónica: convierte el nombre que recordás en la dirección IP que la red necesita, y luego la cachea para que la próxima vez sea instantánea.
Conocer la dirección no es lo mismo que tener una conversación. Antes de que los mensajes fluyan de forma confiable, las dos máquinas abren una conexión — y acuerdan a qué «puerta» del servidor golpear.
TCP es una línea confiable y ordenada
Una llamada telefónica con confirmaciones: decís una frase, la otra persona dice «entendido», y nada avanza hasta que cada parte se reconoce y queda en orden.
TCP (Transmission Control Protocol) es la forma más común de enviar datos de manera confiable. Abre una conexión con un rápido handshake (ambos lados acuerdan hablar), y luego garantiza que cada paquete llegue, en orden, reenviando los que se pierden. Cambiás un poco de velocidad por la seguridad de que nada se descarte ni se desordene. La web, el correo y casi todas las apps van sobre TCP precisamente por esa confiabilidad.
UDP cambia confiabilidad por velocidad
Gritar novedades a través de una sala ruidosa — algunas palabras se pierden, pero no te detenés a confirmar cada una, porque seguir el ritmo importa más que captar cada palabra.
UDP es la alternativa rápida y sin garantías: dispara paquetes sin handshake y sin reenviar los perdidos. Perdés confiabilidad pero ganás velocidad y poca sobrecarga, que es el intercambio correcto para video en vivo, llamadas de voz y juegos — donde un cuadro perdido está bien pero esperar no. Saber que ambos existen te dice que la red siempre tiene este dial de velocidad contra confiabilidad.
Los puertos son las puertas numeradas de una máquina
Un edificio, muchas puertas, cada una numerada con un propósito — las entregas a la puerta 80, la oficina a otra. Misma dirección, distintas entradas.
Una sola máquina corre muchos servicios, así que una dirección IP por sí sola no alcanza — también necesitás un puerto, un número que elige a qué servicio llegar. El tráfico web usa el puerto 80 (HTTP) o 443 (HTTPS) por convención; una base de datos podría escuchar en otro. La dirección te lleva al edificio; el puerto te lleva a la puerta correcta. Juntos, IP más puerto nombran un destino exacto.
TCP es una línea confiable y ordenada; UDP es rápido y con pérdidas. La IP encuentra el edificio, el puerto elige la puerta.
Una vez que la línea está abierta, los dos lados necesitan un lenguaje común para preguntar y responder. En la web, ese lenguaje es HTTP — un formato simple y estricto para cada solicitud y respuesta.
HTTP es solicitud y respuesta
Un intercambio de cartas formales: sale una solicitud con estructura clara, y vuelve una respuesta con estructura clara, cada una siguiendo el mismo diseño acordado.
HTTP (HyperText Transfer Protocol) es el lenguaje de la web. El cliente envía una solicitud — lo que quiere — y el servidor devuelve una respuesta — el resultado. Cada página, imagen y llamada a una API es uno de estos intercambios. Es basado en texto y estructurado, por eso tantas herramientas pueden hablarlo. Dominá la forma de una solicitud y una respuesta, y entendés cómo se mueve toda la web.
El método dice qué querés hacer
En el mostrador de una biblioteca: podés pedir prestado un libro, devolver uno, o pedir agregar uno nuevo. Mismo mostrador, distinta intención — y el personal trata cada caso distinto.
Cada solicitud tiene un método — el verbo. GET obtiene datos (cargar una página). POST envía datos nuevos (enviar un formulario). PUT actualiza algo; DELETE lo elimina. El método le dice al servidor tu intención de un vistazo, y los sistemas bien diseñados los tratan distinto — un GET nunca debería cambiar nada, mientras que de un POST se espera que sí. Estos verbos son la columna vertebral de cómo se diseñan las APIs.
Los headers llevan los detalles; el body lleva la carga
Un sobre tiene notas por fuera — para quién es, qué hay dentro, cómo manejarlo — y la carta real adentro.
Cada solicitud y respuesta tiene headers — líneas rotuladas de metadatos como el tipo de contenido, el idioma, quién pregunta y los tokens de autenticación — y un body opcional, la carga real (los datos del formulario que suben, la página o el JSON que vuelve). Los headers son cómo los dos lados negocian detalles sin tocar la carga. La mayor parte del «cómo» de un intercambio vive en los headers.
Los códigos de estado te dicen cómo salió
Un semáforo para las respuestas: verde significa avanzar, una redirección apunta a otro lado, y una luz roja te dice qué salió mal — y de quién fue la culpa.
Cada respuesta lleva un código de estado. 2xx significa éxito (200 OK). 3xx es una redirección (andá a mirar allá). 4xx significa que el cliente se equivocó — 404 Not Found, 403 Forbidden — vos preguntaste mal. 5xx significa que el servidor se equivocó — 500 — él se rompió. Leer el primer dígito te dice al instante si funcionó, de quién es la culpa y dónde mirar. Esta es la habilidad de depuración más útil que hay en la web.
HTTP se olvida de vos entre solicitudes
Un empleado de mostrador sin memoria de tu última visita — cada vez que te acercás, tenés que volver a presentarte y mostrar tu ticket de nuevo.
HTTP es stateless (sin estado): cada solicitud se sostiene sola, y el servidor por defecto no recuerda nada de la anterior. Así que para seguir con la sesión iniciada, cada solicitud debe llevar prueba de quién sos — un cookie o un token en los headers. La ausencia de estado es lo que deja a la web escalar a miles de millones de solicitudes, y entenderlo explica por qué tu identidad viaja junto a cada llamada.
HTTP es solicitud y respuesta: un método para la intención, headers para los detalles, un body para la carga, y un código de estado que te dice exactamente cómo salió.
El HTTP plano es una postal — cualquiera que la manipule puede leerla. HTTPS es la misma conversación sellada en un sobre que solo el servidor correcto puede abrir, y firmada para que sepas con quién estás hablando.
El cifrado sella el mensaje
Cambiar una postal legible por una caja con cerradura cuya llave solo tiene el destinatario — los mensajeros la llevan, pero ninguno puede leer lo que hay dentro.
HTTPS es HTTP envuelto en cifrado usando TLS. Revuelve el contenido para que cualquiera entre vos y el servidor — el Wi-Fi de tu café, un proveedor de internet, un atacante — solo vea galimatías, no tu contraseña ni tu mensaje. El ícono del candado en la barra de direcciones significa que ese sello está puesto. En la web moderna es lo predeterminado, porque una conversación sin sellar es una conversación que cualquiera puede leer.
Los certificados prueban con quién estás hablando
Un pasaporte revisado por una autoridad de confianza — prueba que la persona es quien dice ser, no un impostor que lleva su nombre.
El cifrado por sí solo no basta; también necesitás saber que el servidor es realmente yourbank.com y no uno falso. Un certificado es una identidad digital, firmada por una autoridad de certificación de confianza, que prueba que un servidor es dueño del nombre que reclama. Tu navegador lo verifica automáticamente y te avisa cuando falta o está mal. Esto es lo que impide que un atacante se haga pasar por un sitio incluso en una conexión cifrada.
Por qué importa el candado
La diferencia entre enviar por correo una carta sellada y verificada y gritar los datos de tu banco en una sala llena de gente.
Sin HTTPS, cualquiera en el camino de la red puede leer e incluso alterar tu tráfico — un man-in-the-middle sentado calladito entre vos y el servidor. Con él, el mensaje está sellado y el remitente verificado. Por eso las páginas de inicio de sesión, los pagos y ahora prácticamente todo usan HTTPS, y por eso los navegadores marcan el HTTP plano como «no seguro». El candado es un ícono pequeño que representa una gran garantía.
HTTPS sella el mensaje con cifrado y prueba la identidad del servidor con un certificado — privacidad y confianza, en un solo candado.
La web se siente instantánea, pero la distancia y la física siempre cobran peaje. Dos palabras — latencia y ancho de banda — explican casi todo lo que hace que las cosas se sientan rápidas o lentas.
La latencia es la espera; el ancho de banda es el ancho
Un caño de agua: cuánto tarda en llegar la primera gota es una cosa; cuánto puede fluir por segundo es otra. Un caño ancho igual tiene un retraso antes de que el agua llegue al otro extremo.
La latencia es el retraso antes de que empiece una respuesta — el tiempo de ida y vuelta para que un mensaje vaya y regrese. El ancho de banda es cuántos datos podés mover por segundo. Son independientes: una conexión puede tener mucho ancho de banda y a la vez mucha latencia. Las descargas grandes dependen del ancho de banda; un sitio ágil y receptivo depende de la latencia. Confundir las dos es por qué «tengo internet rápido pero el sitio se siente lento» desconcierta a la gente.
Cada ida y vuelta cuesta, y la distancia es real
Hacerle una pregunta a alguien en otro continente: incluso a la velocidad de la luz, el ir y venir tiene un piso que no podés superar.
Una solicitud a un servidor lejano hace una ida y vuelta física, y ni siquiera la luz es instantánea a lo ancho del planeta — un viaje por el mundo tiene un piso duro de decenas de milisegundos. Peor aún, cargar una página suele necesitar muchas idas y vueltas. Por esto los diseños parlanchines se sienten lentos a distancia, y por esto reducir la cantidad de idas y vueltas es uno de los trucos de rendimiento más viejos que existen.
Poné la respuesta más cerca con un CDN
Un libro popular en stock en bibliotecas locales de todas partes, en lugar de un archivo central al que tenés que enviar un pedido por correo — la copia cerca tuyo llega mucho más rápido.
Un CDN (content delivery network) es una flota de servidores repartidos por el mundo que mantienen copias de tu contenido cerca de los usuarios. Cuando alguien en Tokio carga tu sitio, se le sirve desde una ciudad cercana, no desde tu servidor de origen al otro lado de un océano — recortando la latencia drásticamente. Los CDN son cacheo aplicado a la geografía, y son la forma en que los sitios globales se sienten locales en todas partes.
Un balanceador de carga reparte el trabajo
Un gestor de filas en un banco que dirige a los clientes a cualquier cajero que esté libre, para que ninguna ventanilla se sature mientras otras están ociosas.
Cuando un solo servidor no puede con todo el tráfico, un balanceador de carga se sienta delante de varios y reparte las solicitudes entre ellos. Así es como los sitios grandes manejan millones de usuarios — agregás más servidores detrás del balanceador — y cómo sobreviven a la caída de un servidor, ya que el balanceador simplemente lo esquiva. La palabra describe exactamente lo que hace: balancea la carga.
La latencia es la espera; el ancho de banda es el ancho. La distancia siempre cobra peaje — un CDN mueve la respuesta más cerca, un balanceador de carga reparte el trabajo.
Ahora juntá cada palabra siguiendo un clic desde la barra de direcciones hasta la página renderizada. Si podés narrar esto, entendés cómo conversa la web.
Qué pasa cuando cargás una URL
El viaje completo de una carta: buscar la dirección, abrir una línea, sellar el sobre, hacer la pregunta, recibir la respuesta — todo en bastante menos de un segundo.
Escribís example.com. DNS convierte el nombre en una dirección IP. Tu navegador abre una conexión TCP a esa IP en el puerto 443, y realizan un handshake de TLS para que la línea quede cifrada y se verifique el certificado del servidor. Sobre esa línea sellada tu navegador envía una solicitud HTTP GET; el servidor responde con un código de estado y un body. La página puede venir de un CDN cercano para recortar la latencia. Tu navegador lee la respuesta y dibuja la página. Cada término de este curso solo le puso nombre a un paso de ese único segundo, de lo más común.
- DNS resuelve el nombre de dominio a una dirección IP. - Se abre una conexión TCP a esa IP en un puerto (443 para HTTPS). - Un handshake de TLS cifra la línea y verifica el certificado del servidor. - El cliente envía una solicitud HTTP — un método, headers, quizás un body. - El servidor devuelve un código de estado, headers y un body. - Un CDN puede servirla desde cerca; un balanceador de carga puede elegir el servidor.
- dirección IP / paquete — la dirección de la máquina, y los trozos en que viajan los datos. - DNS / TTL — la búsqueda de nombre a número, y cuánto tiempo se cachea la respuesta. - TCP / UDP / puerto — línea confiable, línea rápida, y qué puerta de la máquina. - HTTP / método / headers / body / código de estado — el lenguaje de solicitud-respuesta. - HTTPS / TLS / certificado — el sobre sellado y verificado. - latencia / ancho de banda / CDN / balanceador de carga — la espera, el ancho, y cómo la escala combate a ambos.
- Un 404 frente a un 500 te dice al instante si la culpa es tuya o del servidor. - «Internet rápido pero un sitio lento» se lee como un problema de latencia, no de ancho de banda. - El candado significa cifrado y identidad verificada — sabés qué garantiza. - Podés explicar por qué seguir con la sesión iniciada necesita un cookie en cada solicitud stateless. - Podrías narrar todo el viaje de la URL de arriba sin mirar.
Cargar una página es una conversación rápida: encontrar la dirección, abrir una línea, sellarla, preguntar, responder. Cada palabra que asusta es solo un paso de ese segundo.