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.
21 conceptos · un diagrama para cada uno · hoja de referencia al final
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).
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.
- 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.
- 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.
- 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.
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.
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.
- 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.
- 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.
- 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.
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.
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.
- 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.
- 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.
- 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
80es HTTP,443es 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.
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 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.
- 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.
- 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.
- 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/jsondice 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.
- 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.
- 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.
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 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.
- 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.
- 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.
- 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).
HTTPS sella el mensaje con cifrado y prueba la identidad del servidor con un certificado — privacidad y confianza, en un solo candado.
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.
- 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.
- 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.
- 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.
- 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 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.
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.
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.
- 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.
- 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
- Packetpaquete de red
Un pedazo de datos rotulado con «de» y «para».
- IP Addressdirección IP, Internet Protocol address
Un número que identifica a una máquina en la red.
- Client–Servermodelo solicitud–respuesta
El cliente pregunta, el servidor responde.
Nombres
- Domain Namenombre de dominio
El nombre legible de un sitio, hecho para las personas.
- DNSDomain Name System
La guía telefónica: nombre → dirección IP.
- DNS Caching · TTLcaché DNS
La respuesta se recuerda; el TTL dice cuánto confiar en ella.
Conexión
- TCPTransmission Control Protocol
Una línea confiable: handshake, todo en orden, pérdidas reenviadas.
- UDPUser Datagram Protocol
Una línea rápida sin garantías: lanzar y olvidar.
- Portpuerto
El número de puerta: qué servicio de la máquina.
HTTP
- HTTPHyperText Transfer Protocol
El idioma de la web: solicitud y respuesta.
- HTTP MethodsGET · POST · PUT · DELETE
El verbo de la solicitud — tu intención.
- Headers · Bodymetadatos y carga
Los detalles del mensaje y la carga en sí.
- Status Codescódigos de estado HTTP
2xx éxito, 3xx redirección, 4xx tu error, 5xx el del servidor.
- Stateless · Cookiesin memoria del servidor
El servidor te olvida; una cookie viaja en cada solicitud.
HTTPS
- TLS · HTTPScifrado
Sella la conversación; HTTPS = HTTP + TLS.
- Certificatecertificado TLS, CA
Una identificación firmada: el servidor es dueño de su nombre.
- Man-in-the-MiddleMITM
Un atacante en el medio; HTTPS se defiende de él.
Velocidad
- Latency · Bandwidthla espera y el ancho
Cuánto esperás y cuántos datos por segundo. Cosas distintas.
- Round TripRTT, ida y vuelta
Ir y volver; cada viaje cuesta tiempo.
- CDNContent Delivery Network
Copias del contenido cerca de los usuarios.
- Load Balancerbalanceador 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.