# Cómo conversa de verdad la web Curso exprés sobre redes y la web. 21 conceptos — Packet, IP Address, DNS, TCP, UDP, Port, HTTP, Status Codes, TLS, Certificate, Latency, CDN, Load Balancer y más — cada uno con su nombre en inglés, un diagrama, una ficha (qué es → cómo funciona → ejemplo → trampa) y sus vínculos con los demás. Al final: todo el viaje de un clic y una hoja de referencia de una página con todas las palabras. - **Author:** Fedor Chishchin - **Level:** intro - **Reading time:** ~30 minutos de lectura - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/es/learn/networking-express --- ## 1. La red son solo mensajes 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. ### El mapa: 21 conceptos en seis grupos > Un mapa de metro: primero ves las líneas completas, luego viajás estación por estación. Cada palabra de este curso cae en uno de seis grupos. Cada grupo es un paso de la conversación: **lo básico** (quién habla con quién), **nombres** (cómo encontrar la dirección), **conexión** (cómo abrir una línea), **HTTP** (el idioma para preguntar), **HTTPS** (cómo sellarlo) y **velocidad** (por qué las cosas se vuelven lentas). _Diagram: Seis grupos de conceptos — los capítulos 1–6 los siguen._ ### Cómo leer cada concepto > Un pasaporte: los mismos campos para todos, así es fácil compararlos. Cada concepto de abajo tiene las mismas partes: su **nombre en inglés** (recordalo — es el término que vas a encontrar en la documentación), una imagen de la vida cotidiana, un **diagrama** y una **ficha** con campos: _qué es_, _cómo funciona_, _ejemplo_, _trampa_ y conceptos _relacionados_. En el último capítulo todas las palabras se juntan en un solo clic — desde la barra de direcciones hasta la página terminada. ### Packet — los datos viajan en pedazos > 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 una nota partida 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. _Diagram: El emisor corta el mensaje en paquetes, cada uno viaja por su cuenta y el receptor los vuelve a armar._ #### Packet (paquete de red, network packet) - **Qué es:** Un pedazo pequeño de datos rotulado con «de» y «para». - **Cómo funciona:** Un mensaje grande se corta en paquetes; cada uno cruza la red por su cuenta; al final se reensamblan. - **Ejemplo:** Una sola página web te llega como muchos paquetes. - **Ojo:** Los paquetes pueden perderse o llegar desordenados — **TCP** lo arregla. - **Relaciones:** La dirección de un paquete es una **dirección IP**. ### IP Address — cada máquina tiene una dirección > 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. _Diagram: La solicitud va a la IP del servidor; la respuesta vuelve a la IP del emisor — la dirección de retorno._ #### IP Address (dirección IP, Internet Protocol address) - **Qué es:** Un número que identifica a una máquina en la red. - **Cómo funciona:** Cada paquete lleva la dirección de destino y la del emisor, así la respuesta sabe a dónde ir. - **Ejemplo:** `142.250.74.78` — el servidor al que va tu solicitud. - **Ojo:** Nadie recuerda números — por eso hacen falta los nombres y el **DNS**. - **Relaciones:** Te lleva a la máquina; un **puerto** te lleva al servicio dentro de ella. ### Client–Server — 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. _Diagram: El cliente abre la conversación con una solicitud; el servidor responde._ #### Client–Server (modelo solicitud–respuesta, request–response model) - **Qué es:** Un modelo donde un lado pregunta y el otro responde. - **Cómo funciona:** El cliente envía una solicitud; el servidor la procesa y responde. - **Ejemplo:** Tu teléfono pide una página — un servidor en un centro de datos la devuelve. - **Ojo:** Los roles dependen de la conversación: un servidor puede ser cliente de otro servidor. - **Relaciones:** En la web, el idioma de esta conversación es **HTTP**. > **La pregunta de encuadre:** «¿Quién es el cliente que hace la pregunta, quién es el servidor que la responde, y qué dirección necesita cada mensaje para llegar?» > Una red son máquinas que se pasan mensajes con dirección. El cliente pregunta, el servidor responde — todo lo demás es hacerlo confiable. ## 2. Encontrar la dirección — DNS Escribís un nombre como `example.com`, pero la red solo enruta a números. Algo tiene que traducir el nombre que recordás en la dirección que la máquina necesita. Ese algo es el DNS. ### Domain Name — nombres para personas, números para máquinas > Recordás a tu amigo por el nombre, pero el sistema telefónico solo marca números — así que tenés una agenda que convierte uno en 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 las personas; la IP es la dirección amigable para las máquinas. Las dos tienen que estar vinculadas, porque nadie quiere memorizar números y ningún router puede enrutar un nombre. Tender ese puente es todo un sistema, que corre constantemente, de forma invisible, en cada clic. _Diagram: Los nombres son para las personas, las IP para las redes; el DNS está en el medio._ #### Domain Name (nombre de dominio, domain) - **Qué es:** El nombre legible de un sitio, hecho para las personas. - **Cómo funciona:** Por sí solo no lleva a ningún lado — primero se traduce a una dirección IP. - **Ejemplo:** `wikipedia.org` → `198.35.26.96`. - **Ojo:** Los routers no entienden nombres — solo números. - **Relaciones:** El **DNS** traduce el nombre a la dirección. ### DNS — la guía telefónica de internet > Un directorio gigante, siempre abierto: le das un nombre y te devuelve el número a marcar. Nunca lo ves trabajar — solo recibís el número. El **DNS** — el **Domain Name System**, o sistema de nombres de dominio — es el servicio que traduce un nombre de dominio en su dirección IP. Antes de que tu navegador pueda traer `example.com`, le pregunta al DNS «¿cuál es la dirección de este nombre?» y recibe un número. Esta **consulta** (o **resolución**) ocurre primero, cada vez, en milisegundos. Es el paso poco glamoroso que hace posibles las direcciones web legibles. _Diagram: Primero el navegador le pregunta al DNS por la dirección — solo entonces va al servidor._ #### DNS (Domain Name System, sistema de nombres de dominio) - **Qué es:** El servicio que convierte un nombre de dominio en una dirección IP. - **Cómo funciona:** El navegador pregunta «¿cuál es la IP de este nombre?» y recibe un número. - **Ejemplo:** `example.com` → una dirección IP → solo entonces una conexión al servidor. - **Ojo:** Es el primer paso de cada carga: si el DNS falla, el sitio «no existe». - **Relaciones:** Sus respuestas se guardan en la **caché DNS** con un **TTL**. ### DNS Caching y TTL — la respuesta se recuerda > Buscás el número de un amigo una vez y lo anotás en un papelito — la próxima vez lo leés en vez de abrir toda la guía. Buscar cada nombre desde cero sería lento, así que las respuestas del DNS se **guardan en caché** — se recuerdan por un tiempo en tu navegador, tu sistema operativo y tu red. La dirección viene con un **TTL** (time to live, tiempo de vida) que dice cuánto tiempo es seguro reutilizarla antes de volver a consultar. Por eso un sitio que ya visitaste encuentra su dirección al instante, y por eso un cambio de DNS puede tardar en propagarse. _Diagram: Preguntá primero a la memoria más cercana; hacé la consulta completa solo si falla. El TTL dice cuánto vive una respuesta._ #### DNS Caching · TTL (caché DNS, DNS cache, tiempo de vida, time to live) - **Qué es:** Una respuesta de DNS recordada, y por cuánto tiempo se puede confiar en ella. - **Cómo funciona:** El navegador, el SO y la red guardan la respuesta; hasta que se acaba el TTL, la dirección sale de la memoria. - **Ejemplo:** Un sitio que ya visitaste se encuentra al instante — su dirección está en una caché. - **Ojo:** Si cambiás tu DNS, la respuesta vieja sigue viva en las cachés hasta que expire su TTL. Los cambios se propagan despacio. - **Relaciones:** El mismo truco que una **CDN**: guardar la respuesta más cerca. > **La pregunta del DNS:** «Cuando escribo un nombre, ¿qué lo convierte en el número al que la red realmente enruta — y podría una respuesta vieja en caché estar mandándome al lugar equivocado?» > El 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 guarda en caché para que la próxima vez sea instantáneo. ## 3. Abrir una línea — TCP y puertos Conocer la dirección no es lo mismo que tener una conversación. Antes de que los mensajes fluyan con confiabilidad, las dos máquinas abren una conexión — y acuerdan en qué «puerta» del servidor golpear. ### TCP — 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 confirma y está 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** (apretón de manos) — ambos lados acuerdan hablar — y luego garantiza que cada paquete llegue, en orden, y que los perdidos se reenvíen. Cambiás un poco de velocidad por la seguridad de que nada se pierde ni se revuelve. La web, el correo y la mayoría de las apps viajan sobre TCP justamente por esa confiabilidad. _Diagram: Primero el handshake (SYN, SYN-ACK, ACK), luego los datos con confirmaciones; lo que se pierde se reenvía._ #### TCP (Transmission Control Protocol) - **Qué es:** Una línea confiable: todo llega, nada se pierde, todo en orden. - **Cómo funciona:** Un handshake abre la conexión; el receptor confirma los paquetes; los perdidos se reenvían. - **Ejemplo:** Páginas web, correo, la mayoría de las apps. - **Ojo:** La confiabilidad cuesta velocidad: el handshake y la espera de las confirmaciones. - **Relaciones:** La alternativa rápida es **UDP**; **HTTP** viaja sobre TCP. ### UDP — velocidad en lugar de confiabilidad > Gritar novedades a través de un salón ruidoso — algunas palabras se pierden, pero no parás a confirmar cada una, porque seguir el ritmo importa más que captar cada palabra. **UDP** (**User Datagram Protocol**) es la alternativa rápida y sin garantías: lanza paquetes sin handshake y sin reenviar los perdidos. Perdés confiabilidad pero ganás velocidad y poca sobrecarga. Es el trato correcto para el video en vivo, las llamadas de voz y los juegos — donde un cuadro perdido no importa pero esperar sí. Saber que existen ambos te dice que la red siempre tiene una perilla de **velocidad contra confiabilidad**. _Diagram: UDP envía y no mira atrás: nadie reenvía un paquete perdido._ #### UDP (User Datagram Protocol) - **Qué es:** Una línea rápida sin garantía de entrega ni de orden. - **Cómo funciona:** Sin handshake y sin reintentos: lanzar y olvidar. - **Ejemplo:** Video en vivo, llamadas de voz, juegos en línea. - **Ojo:** Los paquetes se pierden — la app tiene que tolerarlo. - **Relaciones:** El extremo opuesto de la perilla respecto de **TCP**. ### Port — las puertas numeradas de una máquina > Un edificio, muchas puertas, cada una numerada para un fin — las entregas por la puerta 80, la oficina por otra. La misma dirección, distintas entradas. Una sola máquina corre muchos servicios, así que una dirección IP sola no alcanza — también necesitás un **puerto**, un número que elige a qué servicio llegar. El tráfico web usa por convención el puerto `80` (HTTP) o `443` (HTTPS); una base de datos puede 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. _Diagram: Una IP es un edificio; el puerto elige la puerta — el servicio._ #### Port (puerto, port number) - **Qué es:** Un número que elige un servicio en una máquina. - **Cómo funciona:** Cada servicio «escucha» en su puerto; una solicitud va a IP:puerto. - **Ejemplo:** `80` es HTTP, `443` es HTTPS; una base de datos escucha en su propio puerto. - **Ojo:** La IP correcta con el puerto equivocado es golpear la puerta equivocada. - **Relaciones:** Completa la **dirección IP**; lo usan tanto **TCP** como **UDP**. > **La pregunta de la conexión:** «¿Necesito la garantía de TCP de que nada se pierde, o la velocidad de UDP — y a qué puerto, a qué puerta de la máquina, estoy golpeando realmente?» > 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. ## 4. La conversación — HTTP Una vez abierta la línea, los dos lados necesitan un idioma común para preguntar y responder. En la web, ese idioma es HTTP — un formato simple y estricto para cada solicitud y cada respuesta. ### HTTP — solicitud y respuesta > Un intercambio de cartas formales: sale una solicitud claramente estructurada y vuelve una respuesta claramente estructurada, ambas con el mismo formato acordado. **HTTP** (**HyperText Transfer Protocol**) es el idioma 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. Está basado en texto y es 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. _Diagram: Un intercambio HTTP: sale una solicitud, vuelve una respuesta._ #### HTTP (HyperText Transfer Protocol) - **Qué es:** El idioma de solicitud y respuesta de la web. - **Cómo funciona:** El cliente envía una solicitud, el servidor devuelve una respuesta; un intercambio por cada cosa. - **Ejemplo:** Una página, una imagen, una llamada a una API — cada una es su propio intercambio HTTP. - **Ojo:** El HTTP simple no está cifrado — cualquiera en el camino puede leerlo. - **Relaciones:** Se compone de **métodos**, **headers + body** y **códigos de estado**; la versión segura es **HTTPS**. ### HTTP Methods — el verbo dice qué querés > En el mostrador de una biblioteca: podés pedir prestado un libro, devolver uno o pedir que agreguen uno nuevo. El mismo mostrador, distinta intención — y el personal trata cada una de forma distinta. Cada solicitud tiene un **método** — el verbo. **GET** trae 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 hechos 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. _Diagram: Los cuatro verbos principales de HTTP y qué significan._ #### HTTP Methods (verbos HTTP, HTTP verbs) - **Qué es:** La palabra al comienzo de una solicitud que dice qué querés hacer. - **Cómo funciona:** GET trae, POST crea, PUT actualiza, DELETE elimina. - **Ejemplo:** Abrir una página es un GET; enviar un formulario es un POST. - **Ojo:** Un GET que cambia algo es un error de diseño. - **Relaciones:** Va en la primera línea de una solicitud, antes de los **headers**. ### Headers y Body — los detalles y la carga > Un sobre tiene notas por fuera — para quién es, qué contiene, cómo manejarlo — y la carta de verdad adentro. Cada solicitud y respuesta tiene **headers** (encabezados) — líneas rotuladas de metadatos como el tipo de contenido, el idioma, quién pregunta y los tokens de autenticación — y un **body** (cuerpo) opcional, la carga real (los datos del formulario que suben, la página o el JSON que vuelve). Los headers son la forma en que los dos lados negocian detalles sin tocar la carga. Gran parte del «cómo» de un intercambio vive en los headers. _Diagram: Una solicitud HTTP es solo texto: una línea con el método, luego los headers, luego el body._ #### Headers · Body (metadatos y carga, metadata and payload) - **Qué es:** Los headers son metadatos sobre el mensaje; el body son los datos en sí. - **Cómo funciona:** Los headers vienen como líneas «nombre: valor»; el body los sigue. - **Ejemplo:** `Content-Type: application/json` dice que el body es JSON; el body son los datos del formulario. - **Ojo:** No todo mensaje tiene body: un GET simple no lo tiene. - **Relaciones:** Las **cookies** viajan en los headers — así funciona el inicio de sesión sobre HTTP **sin estado**. ### Status Codes — cómo salió > Un semáforo para las respuestas: el verde significa avanzar, una redirección apunta a otro lado, y la 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 erró el cliente — `404 Not Found`, `403 Forbidden` — _vos_ pediste mal. **5xx** significa que erró el servidor — `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. Es la habilidad de depuración más útil de la web. _Diagram: El primer dígito es la mitad del diagnóstico: éxito, redirección, tu error o el del servidor._ #### Status Codes (códigos de estado HTTP, HTTP status codes) - **Qué es:** Un número de tres dígitos en la respuesta que dice cómo salió. - **Cómo funciona:** 2xx éxito, 3xx redirección, 4xx error del cliente, 5xx error del servidor. - **Ejemplo:** `404` — no existe esa página; `500` — el servidor se rompió. - **Ojo:** Confundir 4xx con 5xx es buscar el error en el lado equivocado. - **Relaciones:** Lo primero que se revisa en cada respuesta **HTTP**. ### Stateless y Cookies — HTTP te olvida > Un empleado de mostrador sin memoria de tu última visita — cada vez que te acercás, tenés que presentarte de nuevo y mostrar tu ticket otra vez. HTTP es **sin estado** (**stateless**): cada solicitud va por su cuenta, y por defecto el servidor no recuerda nada de la anterior. Así que para seguir con la sesión iniciada, cada solicitud debe llevar una prueba de quién sos — una **cookie** o un token en los headers. Que no tenga estado es lo que permite a la web escalar a miles de millones de solicitudes, y entenderlo explica por qué tu identidad viaja en cada llamada. _Diagram: El servidor no recuerda nada: cada solicitud lleva la cookie, y sin ella volvés a ser un extraño._ #### Stateless · Cookie (sin memoria del servidor; cookie de sesión) - **Qué es:** El servidor olvida las solicitudes pasadas; una cookie lleva la memoria consigo. - **Cómo funciona:** El navegador adjunta una cookie o un token a los headers de cada solicitud. - **Ejemplo:** Seguís con la sesión iniciada porque cada solicitud lleva tu cookie de sesión. - **Ojo:** Sin cookie, sos un extraño para el servidor. - **Relaciones:** La cookie viaja en los **headers**; que no haya estado le facilita la vida al **load balancer**. > **La pregunta de HTTP:** «¿Cuál es el método (la intención), qué hay en los headers y el body, y qué dice el código de estado sobre cómo salió y de quién fue la culpa?» > 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ó. ## 5. El sobre sellado — HTTPS El HTTP simple es una postal — cualquiera que la maneje 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. ### TLS y HTTPS — el cifrado sella el mensaje > Cambiar una postal legible por una caja cerrada con llave que solo el destinatario tiene — los mensajeros la llevan, pero ninguno puede leer lo que hay adentro. **HTTPS** es HTTP envuelto en **cifrado** mediante **TLS** (**Transport Layer Security**). Revuelve el contenido para que cualquiera entre vos y el servidor — el Wi-Fi del café, un proveedor de internet, un atacante — vea solo galimatías, no tu contraseña ni tu mensaje. El ícono del candado en la barra de direcciones significa que el sello está puesto. En la web moderna es lo normal, porque una conversación sin sellar es una conversación que cualquiera puede leer. _Diagram: HTTP es una postal que cualquiera en el camino puede leer; HTTPS es un sobre que solo les muestra ruido._ #### TLS · HTTPS (Transport Layer Security; HTTP + TLS) - **Qué es:** Cifrado para la línea; HTTPS es HTTP sobre TLS. - **Cómo funciona:** Tras el handshake de TLS el contenido va revuelto — el camino solo ve galimatías. - **Ejemplo:** El candado en la barra de direcciones; el puerto `443`. - **Ojo:** El cifrado no basta — también necesitás saber que el servidor es real. - **Relaciones:** La identidad del servidor se prueba con un **certificado**. ### Certificate — prueba de con quién hablás > Un pasaporte revisado por una autoridad de confianza — prueba que la persona es quien dice ser, no un impostor con su nombre. El cifrado solo no alcanza; también necesitás saber que el servidor es de verdad `yourbank.com` y no una falsificación. Un **certificado** es una identificación digital, firmada por una **autoridad certificadora** (**CA**) de confianza, que prueba que un servidor es dueño del nombre que reclama. Tu navegador lo revisa automáticamente y te avisa cuando falta o está mal. Esto es lo que impide que un atacante suplante un sitio incluso en una conexión cifrada. _Diagram: La autoridad certificadora firma el certificado; el servidor lo muestra; el navegador verifica la firma._ #### Certificate (certificado TLS, TLS certificate, autoridad certificadora (CA)) - **Qué es:** Una identificación digital: «este servidor es dueño de este nombre». - **Cómo funciona:** Una CA firma el certificado; el servidor lo presenta; el navegador verifica la firma por sí mismo. - **Ejemplo:** El navegador te avisa cuando el certificado de un sitio falta o está mal. - **Ojo:** No ignores una advertencia de certificado — puede ser una falsificación. - **Relaciones:** Le cierra la puerta a un **man-in-the-middle**. ### Man-in-the-Middle — por qué importa el candado > La diferencia entre enviar 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 **hombre en el medio** (**man-in-the-middle**, **MITM**) que se sienta en silencio entre vos y el servidor. Con HTTPS, el mensaje va sellado y el emisor 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 simple como «no seguro». El candado es un ícono pequeño que representa una garantía grande. _Diagram: Un atacante en el medio lee y cambia el HTTP simple; HTTPS no se puede leer ni falsificar._ #### Man-in-the-Middle (ataque MITM, MITM attack) - **Qué es:** Un atacante entre vos y el servidor que lee o cambia el tráfico. - **Cómo funciona:** Creés que hablás con el servidor, pero hablás a través de él. - **Ejemplo:** Una red Wi-Fi falsa que espía el HTTP simple. - **Ojo:** Es invisible: todo «funciona» mientras tus datos se filtran. - **Relaciones:** La defensa es **TLS** (el sello) + un **certificado** (la verificación de identidad). > **La pregunta de HTTPS:** «¿Está sellada esta conversación para que nadie en el medio pueda leerla — y verificada para que sepa que el servidor es quien dice ser?» > HTTPS sella el mensaje con cifrado y prueba la identidad del servidor con un certificado — privacidad y confianza, en un solo candado. ## 6. Velocidad y distancia La web parece instantánea, pero la distancia y la física siempre cobran un peaje. Dos palabras — latencia y ancho de banda — explican la mayor parte de por qué las cosas se sienten rápidas o lentas. ### Latency y Bandwidth — la espera y el ancho > Un caño de agua: cuánto tarda en llegar la primera gota es una cosa; cuánta agua pasa por segundo es otra. Un caño ancho igual tiene una demora antes de que el agua llegue al otro extremo. La **latencia** (**latency**) es la demora antes de que empiece una respuesta — el tiempo de ida y vuelta de un mensaje. El **ancho de banda** (**bandwidth**) es cuántos datos podés mover por segundo. Son independientes: una conexión puede tener mucho ancho de banda y 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 va lento» desconcierta a la gente. _Diagram: La latencia es el largo del caño, el ancho de banda es su anchura. Son cosas distintas._ #### Latency · Bandwidth (demora y caudal, delay and throughput) - **Qué es:** Latencia — cuánto esperás; ancho de banda — cuántos datos por segundo. - **Cómo funciona:** Son independientes: podés tener mucho ancho y una espera larga. - **Ejemplo:** Un archivo grande se descarga rápido, pero cada clic en un sitio lejano se demora. - **Ojo:** «Internet rápido, sitio lento» suele ser latencia, no ancho de banda. - **Relaciones:** La latencia crece con cada **ida y vuelta**; una **CDN** la reduce. ### Round Trip — cada viaje cuesta tiempo > Hacerle una pregunta a alguien en otro continente: aun a la velocidad de la luz, el ida y vuelta tiene un piso que no se puede superar. Una solicitud a un servidor lejano hace una **ida y vuelta** (**round trip**) física, y ni siquiera la luz es instantánea a través del planeta — un viaje alrededor del mundo tiene un piso duro de decenas de milisegundos. Peor aún, cargar una página suele necesitar muchas idas y vueltas. Por eso los diseños **charlatanes** (**chatty**) se sienten lentos a distancia, y por eso reducir la cantidad de idas y vueltas es uno de los trucos de rendimiento más antiguos que existen. _Diagram: DNS, TCP, TLS, HTTP — cada paso cuesta al menos un viaje al servidor lejano._ #### Round Trip (ida y vuelta, RTT, round-trip time) - **Qué es:** El viaje de un mensaje hasta el servidor y de regreso. - **Cómo funciona:** Cada paso — DNS, handshakes, la solicitud — cuesta al menos un viaje. - **Ejemplo:** Al otro lado del mundo son decenas de milisegundos, incluso para la luz. - **Ojo:** Muchas solicitudes pequeñas (un diseño «charlatán») suman la latencia. - **Relaciones:** Menos viajes o un camino más corto (**CDN**) significa menos **latencia**. ### CDN — poné la respuesta más cerca > Un libro popular que hay en las bibliotecas locales de todos lados, en vez de un archivo central al que hay que pedirle por correo — la copia cercana llega mucho más rápido. Una **CDN** (**content delivery network**, red de entrega de contenido) es una flota de servidores repartidos por el mundo que guardan copias de tu contenido cerca de los usuarios. Cuando alguien en Tokio carga tu sitio, lo atiende una ciudad cercana, no tu servidor de **origen** al otro lado de un océano — y la latencia baja drásticamente. Las CDN son caché aplicada a la geografía, y así los sitios globales se sienten locales en todas partes. _Diagram: Las copias están en servidores de borde cercanos; cada usuario va al más próximo, no al otro lado del océano._ #### CDN (Content Delivery Network, red de entrega de contenido) - **Qué es:** Una flota mundial de servidores con copias de tu contenido. - **Cómo funciona:** Al usuario lo atiende el servidor más cercano, no el de origen. - **Ejemplo:** Un usuario en Tokio recibe la página desde una ciudad cercana. - **Ojo:** Las copias son una caché: las actualizaciones no llegan al instante. - **Relaciones:** Reduce la **latencia** y las **idas y vueltas** largas; primo de la **caché DNS**. ### Load Balancer — repartí el trabajo > Un encargado de fila en un banco que manda a cada cliente a la ventanilla que esté libre, para que ninguna se sature mientras otras quedan ociosas. Cuando un servidor no puede con todo el tráfico, un **balanceador de carga** (**load balancer**) se pone delante de varios y reparte las solicitudes entre ellos. Así manejan los sitios grandes a millones de usuarios — se agregan más servidores detrás del balanceador — y así sobreviven a que se caiga un servidor, ya que el balanceador simplemente lo esquiva. El nombre describe exactamente lo que hace: balancea la carga. _Diagram: El balanceador de carga entrega las solicitudes a servidores sanos y esquiva al que falló._ #### Load Balancer (balanceador de carga, LB) - **Qué es:** Un intermediario que reparte las solicitudes entre varios servidores. - **Cómo funciona:** Cada solicitud va a uno de los servidores vivos; uno caído se saltea. - **Ejemplo:** El tráfico crece — agregás servidores detrás del balanceador. - **Ojo:** Si un servidor guarda la sesión en su memoria, los otros servidores no la conocen. - **Relaciones:** Funciona fácil porque HTTP es **sin estado** (**stateless**). > **La pregunta de la velocidad:** «¿Lo lento es la espera por cada ida y vuelta (latencia) o el volumen de datos (ancho de banda) — y ayudaría acercar la respuesta o repartir la carga?» > La latencia es la espera; el ancho de banda es la anchura. La distancia siempre cobra un peaje — una CDN acerca la respuesta, un balanceador de carga reparte el trabajo. ## 7. El viaje completo Ahora juntá todas las palabras 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`. El **DNS** convierte el nombre en una **dirección IP**. Tu navegador abre una conexión **TCP** a esa IP en el **puerto** 443, y hacen un handshake de **TLS** para que la línea quede cifrada y se verifique el **certificado** del servidor. Por 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 una **CDN** cercana para reducir la **latencia**. Tu navegador lee la respuesta y dibuja la página. Cada término de este curso nombró un paso de ese único y ordinario segundo. _Diagram: Un clic — seis pasos, cada uno con su propia palabra del curso._ ### Cómo se conectan los conceptos > Muñecas rusas: cada capa está dentro de la siguiente, y desde afuera solo ves la de arriba. Los conceptos no viven solos — se apilan en capas. Abajo de todo está **IP** con sus paquetes y direcciones. Encima viajan **TCP** o **UDP** con sus puertos. Sobre TCP está **TLS**, y en la cima está **HTTP**, el idioma de solicitud y respuesta. A los costados hay ayudantes: el **DNS** aporta la dirección para la capa de abajo, mientras que la **CDN** y el **load balancer** pelean contra la latencia y la carga. _Diagram: Las capas de la conversación y los ayudantes a su alrededor: cada capa viaja sobre la de abajo._ #### El viaje, en orden - El **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**. - Una **CDN** puede servirlo desde cerca; un **load balancer** puede elegir el servidor. #### Señales de que la web ya tiene sentido - Un **404** frente a un **500** te dice al instante si la culpa es tuya o del servidor. - «Internet rápido pero 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 una **cookie** en cada solicitud **sin estado**. - Podrías narrar todo el **viaje de la URL** de arriba sin mirar. ## Hoja de referencia: los 21 conceptos ### Lo básico - **Packet** (paquete de red): Un pedazo de datos rotulado con «de» y «para». - **IP Address** (dirección IP, Internet Protocol address): Un número que identifica a una máquina en la red. - **Client–Server** (modelo solicitud–respuesta): El cliente pregunta, el servidor responde. ### Nombres - **Domain Name** (nombre de dominio): El nombre legible de un sitio, hecho para las personas. - **DNS** (Domain Name System): La guía telefónica: nombre → dirección IP. - **DNS Caching · TTL** (caché DNS): La respuesta se recuerda; el TTL dice cuánto confiar en ella. ### Conexión - **TCP** (Transmission Control Protocol): Una línea confiable: handshake, todo en orden, pérdidas reenviadas. - **UDP** (User Datagram Protocol): Una línea rápida sin garantías: lanzar y olvidar. - **Port** (puerto): El número de puerta: qué servicio de la máquina. ### HTTP - **HTTP** (HyperText Transfer Protocol): El idioma de la web: solicitud y respuesta. - **HTTP Methods** (GET · POST · PUT · DELETE): El verbo de la solicitud — tu intención. - **Headers · Body** (metadatos y carga): Los detalles del mensaje y la carga en sí. - **Status Codes** (códigos de estado HTTP): 2xx éxito, 3xx redirección, 4xx tu error, 5xx el del servidor. - **Stateless · Cookie** (sin memoria del servidor): El servidor te olvida; una cookie viaja en cada solicitud. ### HTTPS - **TLS · HTTPS** (cifrado): Sella la conversación; HTTPS = HTTP + TLS. - **Certificate** (certificado TLS, CA): Una identificación firmada: el servidor es dueño de su nombre. - **Man-in-the-Middle** (MITM): Un atacante en el medio; HTTPS se defiende de él. ### Velocidad - **Latency · Bandwidth** (la espera y el ancho): Cuánto esperás y cuántos datos por segundo. Cosas distintas. - **Round Trip** (RTT, ida y vuelta): Ir y volver; cada viaje cuesta tiempo. - **CDN** (Content Delivery Network): Copias del contenido cerca de los usuarios. - **Load Balancer** (balanceador de carga, LB): Reparte las solicitudes entre servidores y esquiva los fallos. > 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. Fin del curso exprés · 7 capítulos · 21 conceptos Ahora toca practicar: abrí las herramientas de desarrollador de tu navegador, andá a la pestaña Network y cargá cualquier sitio. Mirá cómo aparecen las solicitudes reales — los métodos, los códigos de estado, los headers, los tiempos — y relacioná cada uno con una palabra de este curso. Las abstracciones se vuelven concretas en el momento en que las ves pasar. Pero quedate con una idea por encima de las demás: la web no es magia. Son máquinas que encuentran una dirección, abren una línea, la sellan e intercambian una pregunta por una respuesta — y ahora tenés las palabras para cada paso.