Networking¶

De un vistazo

Materia: Capa 2 · Dar forma al sistema · Tiempo de lectura: ~35 min · Requisitos previos: Capa 0 y APIs.

En una frase: vas a entender cómo viaja un byte de una máquina a otra —por qué la red se parte en capas, qué diferencia a TCP de UDP, qué pasa exactamente entre pulsar Enter y ver la página, y por qué la latencia manda sobre el ancho de banda y no la arreglas pagando más megas.

Por qué esto importa¶

Escribes un servicio, llama a otro por HTTP, y funciona en tu máquina. Entonces empieza el misterio:

¿Por qué la misma consulta que tarda 2 ms en local tarda 180 ms cuando el servicio está en otra región, si la base de datos es igual de rápida?
¿Por qué mi petición muere con Connection timed out unas veces y con Connection refused otras, y qué me está diciendo cada una?
¿Por qué juntar 50 llamadas pequeñas a una API es dramáticamente más lento que una sola llamada que traiga lo mismo, aunque el total de bytes sea idéntico?
¿Por qué "subir el ancho de banda" del servidor no arregló nada?
¿Qué es realmente un puerto, y por qué mi contenedor "no expone" el 5432?

Todas tienen la misma raíz: cómo los datos cruzan una red que ni es fiable, ni es instantánea, ni es privada. Sin este modelo mental, cada timeout es un misterio que resuelves reintentando a ciegas. Con él, son consecuencias predecibles de dónde está la máquina y de qué garantías da (o no da) el protocolo que usas. Ese es el salto de "llamo a la API y ya" a "entiendo qué le estoy pidiendo a la red".

Intuición primero: la carta, el sobre y el cartero tonto¶

Imagina que quieres mandar un libro entero a un amigo en otra ciudad, pero el correo solo acepta postales y no garantiza nada: cada postal puede perderse, llegar tarde, o llegar desordenada respecto a las otras.

¿Qué haces? Partes el libro en trozos que quepan en una postal, numeras cada postal ("1 de 40", "2 de 40"…), y las echas al buzón. Tu amigo, al otro lado, va recibiendo postales sueltas, las ordena por su número, detecta si falta alguna y te pide que la reenvíes, y cuando las tiene todas reconstruye el libro.

Eso es, casi literalmente, cómo funciona internet:

El libro es tu mensaje (una petición HTTP, un correo, un frame de vídeo).
Las postales son los paquetes: internet no mueve "conexiones", mueve paquetes sueltos.
El cartero es la red: un montón de máquinas (routers) que se pasan paquetes de mano en mano sin entender ni preocuparse por qué llevan dentro. Es rápido pero tonto y poco fiable: pierde postales, las reordena, a veces las duplica.
El sistema de numerar, ordenar, detectar pérdidas y reenviar es lo que llamaremos TCP. Es la inteligencia que ponemos en los extremos para convertir un correo poco fiable en una conversación fiable.

graph LR
  A["Tu máquina<br/>parte el mensaje<br/>en paquetes numerados"] -->|"paquete 1"| R["Red · routers<br/>(carteros tontos:<br/>reenvían de mano en mano,<br/>pueden perder/reordenar)"]
  A -->|"paquete 2"| R
  A -->|"paquete 3"| R
  R -->|"llegan sueltos<br/>y desordenados"| B["Máquina destino<br/>reordena, pide reenvíos,<br/>reconstruye el mensaje"]

Guarda esta imagen: red tonta y poco fiable en medio, inteligencia en los extremos. Es el principio de diseño que explica por qué internet escala a miles de millones de máquinas. Vamos a colgar el resto de la lección de ella.

El detalle¶

1. Por qué la red se parte en capas¶

Mandar un byte de tu portátil por WiFi a un servidor en Fráncfort implica problemas de naturalezas completamente distintas: modular una señal de radio, encontrar la ruta entre routers, recuperarse de paquetes perdidos, y entender que esos bytes son una petición HTTP. Meter todo eso en un solo programa gigante sería iningobernable.

La solución es la misma que en cualquier sistema complejo: capas. Cada capa resuelve un problema y ofrece un servicio limpio a la de arriba, sin que esta sepa cómo lo hace. El modelo práctico de internet (TCP/IP) tiene cuatro:

graph TB
  APP["<b>4 · Aplicación</b><br/>HTTP, DNS, SMTP, gRPC<br/>«¿qué significan estos bytes?»"]
  TRA["<b>3 · Transporte</b><br/>TCP, UDP · puertos<br/>«entregar de proceso a proceso,<br/>¿con fiabilidad o sin ella?»"]
  RED["<b>2 · Red (Internet)</b><br/>IP · direcciones y enrutado<br/>«llevar un paquete de máquina<br/>a máquina por todo el mundo»"]
  ENL["<b>1 · Enlace</b><br/>Ethernet, WiFi<br/>«mover bits al siguiente salto físico»"]
  APP --> TRA --> RED --> ENL

La idea clave es el encapsulado: cada capa envuelve el dato de la de arriba con su propia cabecera, como muñecas rusas. Tu petición HTTP se mete dentro de un segmento TCP (que añade puertos y números de secuencia), que se mete dentro de un paquete IP (que añade las direcciones de origen y destino), que se mete dentro de una trama Ethernet/WiFi (que añade la dirección física del siguiente salto). En destino se desenvuelve en orden inverso.

graph LR
  subgraph TRAMA["Trama de enlace"]
    subgraph IP["Paquete IP"]
      subgraph TCP["Segmento TCP"]
        DATOS["Tu petición HTTP"]
      end
    end
  end

Por qué esto es una idea enorme, no burocracia

Gracias a las capas, puedes cambiar una sin tocar las demás. Pasaste de cable a WiFi (cambió la capa 1) y tu navegador no se enteró. Internet migró de HTTP/1.1 a HTTP/2 (capa 4) sin tocar IP. Cada capa razona sobre "su" problema como si estuviera sola, igual que un proceso razona sobre "su" memoria (ver Modelo de ejecución). Es separación de responsabilidades a escala planetaria.

2. Direcciones IP y enrutado (la intuición)¶

La capa de red (IP) tiene un único trabajo: llevar un paquete de una máquina a otra, estén donde estén. Para eso cada máquina tiene una dirección IP, que funciona como una dirección postal global.

IPv4: cuatro números de 0 a 255, como 93.184.216.34. Hay ~4.300 millones, que se agotaron hace años (de ahí NAT, que veremos).
IPv6: direcciones enormes (2606:2800:220:1:248:1893:25c8:1946) porque hay tantas que no se acaban en la práctica.

¿Cómo llega un paquete de Madrid a Fráncfort? Nadie conoce la ruta completa. Cada router solo sabe una cosa: "para esta zona de direcciones, el siguiente salto es por aquí". El paquete va saltando de router en router (cada salto se llama hop), y cada uno lo acerca un poco más, como preguntar la dirección de calle en calle. Ningún router tiene el mapa entero; entre todos, colaborando con reglas locales, emerge la ruta. Es enrutado salto a salto, no un plan maestro.

Ver los saltos con tus ojos

traceroute (o tracert en Windows) te muestra la lista de routers por los que pasa tu paquete hasta el destino, con el tiempo de cada salto. Es la forma más directa de ver que internet es una cadena de máquinas tontas colaborando, y de descubrir en qué salto se dispara la latencia.

Un detalle que confunde a mucha gente: la IP identifica a la máquina, pero en una máquina hay muchos procesos (tu servidor web, tu base de datos, tu SSH). ¿Cómo sabe el sistema a cuál entregar el paquete? Con el puerto, que es cosa de la capa de transporte. Vamos a ella.

3. Transporte: TCP vs UDP¶

La capa de red entrega paquetes de máquina a máquina, y hace ese trabajo lo mejor que puede pero sin prometer nada: un paquete IP puede perderse, duplicarse o llegar desordenado. La capa de transporte añade dos cosas encima: entrega de proceso a proceso (mediante puertos) y, opcionalmente, fiabilidad. Aquí es donde eliges entre las dos herramientas fundamentales.

TCP — la conversación fiable. TCP coge el correo poco fiable de IP y construye encima una tubería fiable, ordenada y sin duplicados, exactamente con el truco de las postales numeradas de la intuición:

Numera cada byte (números de secuencia), así el receptor reordena lo que llega desordenado.
El receptor confirma lo que recibe (ACK). Lo que no se confirma en un tiempo, el emisor lo reenvía.
Controla la congestión: si detecta pérdidas, deduce que la red está saturada y baja el ritmo por sí solo, para no hundir la red del todo.

El precio: TCP necesita establecer conexión antes (un handshake, ida y vuelta previa) y mantener estado en ambos extremos. Da garantías fuertes a cambio de latencia y complejidad.

UDP — el disparo sin garantías. UDP es casi IP a secas más puertos. Mandas un datagrama y ya: no hay conexión previa, ni confirmaciones, ni reordenado, ni reenvíos. Puede perderse y no te enteras. A cambio: cero ceremonia, mínima latencia, y tú controlas exactamente qué pasa cuando algo se pierde.

graph TB
  subgraph U["UDP · «lo lanzo y a correr»"]
    U1["Sin conexión previa"]
    U2["Sin garantía de entrega ni orden"]
    U3["Rapidísimo, mínima sobrecarga"]
  end
  subgraph T["TCP · «hablemos con cuidado»"]
    T1["Handshake antes de enviar"]
    T2["Entrega fiable, ordenada, sin duplicados"]
    T3["Control de congestión · más latencia"]
  end

¿Cuándo cada uno? La regla: ¿me duele más perder un dato o llegar tarde?

TCP cuando la corrección manda: webs (HTTP), APIs, bases de datos, transferencia de archivos, correo. Que falte un byte corrompe todo; esperar un reenvío es aceptable.
UDP cuando la frescura manda y un dato viejo no vale: videollamadas, juegos en tiempo real, streaming en directo, DNS (una pregunta minúscula que si se pierde, repites). En una videollamada, un frame perdido no lo quieres reenviado —ya sería pasado— prefieres el siguiente frame ya.

HTTP/3 usa UDP, y no es una contradicción

Durante décadas la web fue TCP puro. HTTP/3 se monta sobre UDP y reconstruye la fiabilidad él mismo, en el espacio de aplicación (protocolo QUIC). ¿Por qué reinventar lo que TCP ya daba? Para poder mejorar el control de pérdidas y establecer conexiones más rápido sin esperar a que el TCP del sistema operativo evolucione. Volvemos a ello en la sección 5.

4. El viaje completo: escribo una URL y pulso Enter¶

Momento estrella. Tecleas https://tienda.ejemplo.com y pulsas Enter. Entre eso y ver la página pasan, en orden, cuatro fases —y cada una es al menos una ida y vuelta por la red, lo cual será clave cuando hablemos de latencia.

sequenceDiagram
    participant N as "Navegador"
    participant D as "DNS"
    participant S as "Servidor (tienda.ejemplo.com)"

    Note over N,D: FASE 1 · Resolver el nombre a IP
    N->>D: "¿Qué IP tiene tienda.ejemplo.com?"
    D-->>N: "93.184.216.34"

    Note over N,S: FASE 2 · Handshake TCP (3 pasos)
    N->>S: "SYN (quiero hablar)"
    S-->>N: "SYN-ACK (vale, y yo contigo)"
    N->>S: "ACK (hecho)"

    Note over N,S: FASE 3 · Handshake TLS (cifrado, el candado)
    N->>S: "Hola, esto es lo que soporto"
    S-->>N: "Certificado + claves"
    N->>S: "Clave de sesión acordada"

    Note over N,S: FASE 4 · Petición y respuesta HTTP
    N->>S: "GET / HTTP/2"
    S-->>N: "200 OK + HTML"
    Note over N: Renderiza y pide CSS, JS, imágenes...

Paso a paso:

DNS — del nombre a la IP. Las personas recordamos tienda.ejemplo.com; los routers solo entienden IPs. El DNS es la guía telefónica de internet: el navegador pregunta "¿qué IP tiene este nombre?" y recibe 93.184.216.34. Esta consulta suele ir por UDP (pregunta pequeña, respuesta pequeña) y se cachea a varios niveles para no repetirla cada vez.
Handshake TCP — abrir la conversación. Antes de enviar nada útil, TCP hace su saludo de tres pasos (SYN → SYN-ACK → ACK). Eso es una ida y vuelta completa solo para acordar que van a hablar. Todavía no ha viajado ni un byte de tu petición.
Handshake TLS — poner el candado. Como es https, hay que cifrar. Cliente y servidor negocian versiones, el servidor presenta su certificado (que demuestra que es quien dice ser) y acuerdan una clave de sesión. Otra(s) ida(s) y vuelta(s). Esto es Seguridad en detalle; aquí quédate con que el candado cuesta viajes de red.
Petición y respuesta HTTP. Por fin el navegador manda GET / y el servidor responde con el HTML. Al leerlo, el navegador descubre que necesita CSS, JS e imágenes, y repite peticiones por cada recurso.

Cuenta las idas y vueltas, ahí está tu tiempo

Antes del primer byte útil de HTML ya has pagado, como mínimo: 1 vuelta de DNS + 1 de TCP + 1-2 de TLS. Si cada ida y vuelta a un servidor lejano cuesta 80 ms, son ~300 ms antes de empezar. Por eso importa tanto reutilizar conexiones (no rehacer TCP+TLS por cada petición) y tener el servidor cerca del usuario (CDNs). No es el tamaño de la página: es el número de viajes.

5. HTTP/1.1 → HTTP/2 → HTTP/3: qué arregla cada salto¶

HTTP es el lenguaje de la web (capa de aplicación). Su evolución es una historia de ir eliminando el cuello de botella que quedaba tras arreglar el anterior.

HTTP/1.1 — una petición a la vez por conexión. Sobre una conexión TCP, las peticiones van en fila: hasta que no vuelve la respuesta de una, no sale la siguiente (head-of-line blocking a nivel de petición). Como una web tiene decenas de recursos, los navegadores abrían varias conexiones en paralelo (típicamente 6) para disimularlo —un parche caro: cada conexión repite su handshake TCP+TLS.
HTTP/2 — muchas peticiones multiplexadas en una conexión. Introduce el multiplexado: muchas peticiones y respuestas viajan entrelazadas por una única conexión TCP, troceadas en frames. Adiós a abrir seis conexiones. Añade también compresión de cabeceras y que el servidor pueda adelantar recursos. Gran salto... pero con una trampa heredada: como todo va por un solo TCP, si se pierde un paquete, TCP detiene el flujo entero hasta reenviarlo, aunque las demás respuestas estuvieran listas. El head-of-line blocking no desapareció; bajó a la capa TCP.
HTTP/3 — cambiar TCP por QUIC (sobre UDP). Para matar ese bloqueo hay que arreglarlo dentro del transporte, y TCP no se puede cambiar (está en el kernel de cada SO y en cada router intermedio). Así que HTTP/3 se construye sobre UDP con un protocolo nuevo, QUIC, que implementa flujos independientes: si se pierde un paquete de un flujo, solo ese espera; los demás siguen. Además funde el handshake de conexión y el de cifrado en menos idas y vueltas, y sobrevive a cambios de red (pasar de WiFi a datos móviles sin cortar la conexión).

graph TB
  H1["<b>HTTP/1.1</b><br/>1 petición a la vez por conexión<br/>→ abrir muchas conexiones (parche)"]
  H2["<b>HTTP/2</b><br/>multiplexado sobre 1 TCP<br/>→ pero 1 paquete perdido<br/>bloquea todo (HOL en TCP)"]
  H3["<b>HTTP/3</b><br/>QUIC sobre UDP · flujos independientes<br/>→ una pérdida no bloquea a los demás<br/>+ conexión más rápida"]
  H1 -->|"resuelve el HOL de petición"| H2
  H2 -->|"resuelve el HOL de TCP"| H3

El patrón que debes llevarte: cada versión resolvió el cuello de botella que la anterior dejó al descubierto. No memorices features; entiende la cadena de problemas.

6. Latencia vs ancho de banda: por qué la latencia manda¶

Esta es la confusión más cara del networking, y la que más dinero se malgasta ignorando. Son dos cosas distintas:

Ancho de banda (bandwidth): cuántos datos caben por segundo. La anchura de la tubería. Se mide en Mbps/Gbps.
Latencia: cuánto tarda un dato en ir de A a B (o el ida y vuelta, RTT). La longitud de la tubería. Se mide en milisegundos.

La analogía: un camión cargado de discos duros cruzando el país tiene ancho de banda brutal (terabytes) pero latencia horrible (dos días). Una llamada de teléfono tiene poco ancho de banda pero latencia mínima. No son lo mismo y no se compensan.

Y aquí está el clavo: la latencia tiene un suelo físico que no puedes bajar con dinero. La luz tarda ~40 ms en ir y volver de Madrid a Nueva York por fibra, y eso es física, no tecnología mejorable. Puedes contratar 10 Gbps, que ese ida y vuelta sigue costando 40 ms. Más ancho de banda no acorta la distancia.

Por qué esto te muerde como backend: la mayoría de tus lentitudes no son de ancho de banda, son de latencia acumulada por hacer demasiados viajes.

// ❌ N+1 viajes: cada iteración es una ida y vuelta a la BD
$pedidos = $db->query("SELECT * FROM pedidos");     // 1 viaje
foreach ($pedidos as $p) {
    $cliente = $db->query("SELECT * FROM clientes WHERE id = ?", $p->cliente_id); // ¡+1 viaje POR pedido!
}
// 500 pedidos = 501 viajes. Si cada viaje son 1 ms de red → 500 ms solo en ir y venir.

// ✅ 1 viaje: pide todo junto
$pedidos = $db->query(
    "SELECT p.*, c.* FROM pedidos p JOIN clientes c ON c.id = p.cliente_id"
);
// 1 viaje. Los mismos bytes, pero el tiempo de red se desploma.

Los dos traen los mismos datos. La diferencia es puramente el número de idas y vueltas. Subir el ancho de banda entre app y BD no arregla nada; reducir viajes, sí. Este es el famoso problema N+1, y es latencia disfrazada.

La regla que te ahorra el 80% de los sustos de rendimiento

Ante un servicio lento, pregunta primero cuántas idas y vueltas hace, no cuántos datos mueve. Agrupar (batching), cachear y colocar los servicios cerca unos de otros ataca la latencia. Comprimir y paginar ataca el ancho de banda. Casi siempre el problema es lo primero.

7. Puertos, NAT y firewalls¶

Tres piezas que aparecen a diario en la vida de un backend y que la gente maneja de memoria sin entender.

Puertos — la extensión dentro de la máquina. La IP llega al edificio (la máquina); el puerto es el número de despacho (el proceso concreto). Un puerto es un número de 16 bits (0–65535). Hay convenciones: 80 = HTTP, 443 = HTTPS, 22 = SSH, 5432 = PostgreSQL, 3306 = MySQL. Cuando levantas un servidor "en el puerto 8080", le estás diciendo al SO "los paquetes TCP que lleguen a este puerto, entrégamelos a mí". Por eso una IP + un puerto (93.184.216.34:443) identifica un destino de proceso concreto.

Connection refused vs Connection timed out: te están diciendo cosas distintas

Connection refused: llegaste a la máquina, pero nadie escucha en ese puerto (el proceso no está levantado, o escucha en otro puerto/interfaz). La máquina te contestó activamente "aquí no hay nadie". Suele ser un servicio caído o mal configurado.
Connection timed out: nadie contestó nada. El paquete se perdió en el camino, o un firewall lo está descartando en silencio, o la máquina no es alcanzable. Suele ser red o firewall, no el servicio.

Confundirlas te hace depurar el sitio equivocado durante una hora. El primero apunta al proceso; el segundo, al camino.

NAT — por qué tu IP privada no es la que ve el mundo. Como las IPv4 se agotaron, tu red local (casa, oficina, la VPC de tu nube) usa IPs privadas (192.168.x.x, 10.x.x.x) que se repiten en millones de redes y no son enrutables en internet. El router hace NAT (Network Address Translation): reescribe tus paquetes salientes para que lleven su IP pública, apunta en una tabla "esta conexión era del portátil de la cocina", y cuando vuelve la respuesta la traduce de vuelta. Por eso decenas de dispositivos comparten una IP pública. Consecuencia práctica: desde fuera no puedes conectar hacia dentro por defecto (nadie sabe a qué máquina privada va) —de ahí el port forwarding y los dolores de cabeza con contenedores y -p 8080:80.

Firewalls — el portero con lista. Un firewall es un filtro que decide qué paquetes pasan según reglas: por puerto, por IP de origen/destino, por dirección (entrante/saliente). "Permitir 443 entrante desde cualquiera, bloquear 5432 entrante desde fuera de la VPC" es una regla típica: tu web es pública pero tu base de datos solo habla con tus servicios internos. Cuando un firewall descarta un paquete en silencio (en vez de rechazarlo), obtienes el timed out de arriba.

graph LR
  PC["Portátil<br/>192.168.1.20:51000<br/>(IP privada)"] -->|"sale"| NAT["Router · NAT<br/>reescribe origen →<br/>88.20.30.40:51000"]
  NAT --> FW["Firewall<br/>¿puerto permitido?"]
  FW -->|"sí"| INET["Internet →<br/>servidor:443"]
  FW -->|"no"| DROP["descartado<br/>(→ timeout)"]

Cómo se ve en la práctica¶

Un caso que le toca a todo backend: tu API responde en 15 ms en local, pero en producción cada request tarda 250 ms y el equipo culpa a la base de datos. Miras las métricas de la BD: cada consulta tarda 1-2 ms. Entonces, ¿dónde se van 250 ms?

Instrumentas una request y descubres el reparto:

DNS interno (resolver el hostname del servicio)     20 ms
Handshake TCP + TLS (conexión nueva cada vez)        90 ms
Consulta a la BD (1 viaje, ejecución rápida)          3 ms
7 llamadas encadenadas a un microservicio           130 ms   ← 7 × ~18 ms de RTT
------------------------------------------------------------
                                                    ~243 ms

La BD no era el problema: eran 3 ms. El tiempo estaba en red y viajes: conexiones que se rehacían en cada request (no había pool), y una cascada de 7 llamadas sincrónicas a otro servicio, cada una pagando su ida y vuelta. Las soluciones son todas de esta lección: reutilizar conexiones (pool, keep-alive: matas el TCP+TLS repetido), agrupar las 7 llamadas en 1, y cachear el DNS interno. Sin este modelo mental, habrías optimizado queries que ya eran instantáneas. Con él, atacas donde de verdad se va el tiempo: la latencia acumulada de demasiados viajes.

Lo que sacrificas / errores comunes¶

Creer que TCP "garantiza que el mensaje llega". Garantiza que si llega, llega íntegro y en orden —o la conexión se rompe. No garantiza que el otro extremo esté vivo ni que procesara tu petición. Por eso a nivel de aplicación aún necesitas timeouts, reintentos e idempotencia.
Optimizar ancho de banda cuando el problema es latencia. Comprimir respuestas que ya eran pequeñas mientras haces 40 viajes secuenciales. Cuenta viajes primero.
Ignorar que cada conexión nueva cuesta handshakes. Abrir un cliente HTTP o de BD por request en vez de reutilizar un pool multiplica tu latencia por el coste de TCP+TLS cada vez. Casi todo framework serio da connection pooling; úsalo.
Tratar la red como fiable e instantánea. El error clásico del novato distribuido: llamar a otro servicio como si fuera una función local. La red falla y tarda; todo lo que la cruce necesita timeout explícito y plan B. "La red es fiable" encabeza las falacias de la computación distribuida por algo.
Confundir puerto cerrado con host inalcanzable (el refused vs timed out de arriba). Depurar la capa equivocada cuesta horas.

Resumen¶

Internet mueve paquetes por una red tonta y poco fiable; la inteligencia (orden, reenvíos) vive en los extremos. Se organiza en capas (enlace, red/IP, transporte, aplicación) para que cada una cambie sin romper a las demás.
IP lleva paquetes de máquina a máquina saltando de router en router (nadie tiene el mapa completo); el puerto los entrega al proceso concreto dentro de la máquina.
TCP = fiable, ordenado, con handshake y control de congestión (webs, APIs, BD). UDP = rápido y sin garantías (vídeo, juegos, DNS). Eliges según si te duele más perder un dato o llegar tarde.
Abrir una URL son varias idas y vueltas apiladas (DNS → TCP → TLS → HTTP). HTTP/1.1→2→3 es la historia de ir matando el cuello de botella que dejaba el anterior. El tiempo se va en el número de viajes, no en los bytes.
La latencia tiene un suelo físico (la luz) que no bajas con más ancho de banda. La mayoría de lentitudes de backend son latencia acumulada por hacer demasiados viajes (el N+1). Reduce viajes, reutiliza conexiones, acerca los servicios.

Ejercicios socráticos¶

No busques la respuesta fuera. Razónala con el modelo de esta lección. Si te atascas, la pista está en el texto.

Una videollamada usa UDP y una transferencia de un PDF usa TCP. Justifica cada elección en términos de "qué duele más: perder un dato o llegar tarde". ¿Qué pasaría de horrible si los intercambiaras?
Tu servicio hace 30 llamadas a una API externa, secuenciales, cada una con 50 ms de RTT. Un compañero propone "contratar más ancho de banda". Explica por qué no arregla nada y di dos cosas que sí lo arreglarían, con su porqué.
Un cliente reporta Connection timed out al llamar a tu API; otro reporta Connection refused. Antes de mirar logs, ¿en qué capa/componente distinto empezarías a depurar cada uno y por qué?
HTTP/2 multiplexa muchas peticiones en una conexión TCP, lo cual suena perfecto. ¿Por qué entonces se molestaron en inventar HTTP/3 sobre UDP? ¿Qué problema seguía ahí y por qué no se podía arreglar sin cambiar de transporte?
Abrir https:// implica DNS + handshake TCP + handshake TLS antes del primer byte de HTML. Si tu página fuera http:// (sin la S), ¿qué ida(s) y vuelta(s) te ahorrarías? ¿Merece la pena el ahorro frente a lo que sacrificas?

Repaso espaciado¶

Pasa estas a Anki (repasos.md). Formato: pregunta que obligue a razonar, no a reconocer.

[ ] ¿Por qué internet se organiza en capas? Da un ejemplo concreto de un cambio en una capa que no obligó a tocar las demás.
[ ] TCP vs UDP: nombra la garantía clave de cada uno y un caso de uso donde la otra opción sería un error.
[ ] Enumera, en orden, las idas y vueltas de red entre pulsar Enter en una URL https y recibir el primer byte de HTML.
[ ] ¿Por qué más ancho de banda no reduce la latencia? Explica el "suelo físico" y cómo se relaciona con el problema N+1.
[ ] Distingue Connection refused de Connection timed out: qué le pasó al paquete en cada caso y hacia dónde apunta la causa.

Para seguir tirando del hilo¶

High Performance Browser Networking (Ilya Grigorik) — gratis online; la referencia para latencia, TCP, TLS y la evolución de HTTP. El capítulo de latencia vs ancho de banda es exactamente la sección 6 con rigor.
Computer Networking: A Top-Down Approach (Kurose & Ross) — el libro de texto clásico, precisamente "de arriba abajo" (empieza por la aplicación, como esta lección).
"The Fallacies of Distributed Computing" (Deutsch & Gosling) — las ocho falacias que todo backend acaba aprendiendo a base de golpes; la primera es "la red es fiable".
Experimento: haz traceroute a un servidor de tu país y a uno en otro continente, y compara el RTT de cada salto. Luego mide con las herramientas de red del navegador (pestaña Network) cuánto de una carga de página se va en DNS/conexión/TLS frente a descarga. Verlo con tus ojos asienta esto más que releerlo.