Cómo viaja un mensaje: IP, puertos y DNS

Un protocolo es un acuerdo

Para que dos computadoras se entiendan, las dos tienen que seguir las mismas reglas: qué se manda primero, cómo se escribe cada dato, qué se contesta y qué se hace si algo falla. Ese acuerdo se llama protocolo (protocol).

Es como una llamada por teléfono. Quien contesta dice «¿bueno?», quien llamó dice quién es, hablan por turnos y se despiden antes de colgar. Nadie lo escribió en un contrato, pero si alguien no lo sigue, la llamada se vuelve confusa. La analogía se rompe en un punto: las personas improvisan y aun así se entienden. En la red el acuerdo está escrito, en documentos públicos que se llaman RFC (Request for Comments), y cada programa lo sigue al pie de la letra: un byte fuera de lugar y el otro lado ya no entiende.

En esta lección vas a conocer cuatro protocolos: IP, que lleva cada pedazo a la máquina correcta; TCP y UDP, que lo llevan al programa correcto; y el DNS, que traduce nombres en direcciones. Arriba de ellos va HTTP, el protocolo de las páginas web y de las APIs, que es el tema de la siguiente lección.

Un paquete: encabezado y carga

La red no manda la foto de una sola pieza. La parte en pedazos, y cada pedazo viaja por su cuenta dentro de un paquete (packet). Un paquete tiene dos partes:

• El encabezado (header): unos bytes al principio con los datos del viaje. De dónde viene, a dónde va, qué número de pedazo es.
• La carga (payload): el pedazo de foto.

¿Por qué en pedazos? Por tres razones. Una foto de 3 MB ocuparía el cable un buen rato y nadie más podría usarlo; en pedazos, los paquetes de muchas personas se turnan. Si se daña un pedazo, se reenvía solo ese, no la foto completa. Y cada pedazo puede tomar el camino que esté libre.

¿De qué tamaño? En casi todas las redes, un paquete lleva como máximo 1,500 bytes. Ese tope se llama MTU (maximum transmission unit). Del total, 40 bytes son encabezados (20 del protocolo IP y 20 del protocolo TCP, que vas a conocer en las siguientes secciones), así que de foto caben 1,460 bytes por paquete.

Haz la cuenta con el original de la foto de Ana, los 3 MB que guarda su celular. Así llegan las fotos que los vendedores suben desde la computadora, sin achicar:

Los routers: reenviar sin abrir

Entre el celular de Ana y Virginia hay una o dos decenas de aparatos que se pasan los paquetes de mano en mano. Cada uno es un router (enrutador): una computadora especializada que recibe un paquete, lee a dónde va y lo manda al siguiente aparato que lo acerca a su destino. A cada paso de un router al siguiente se le dice salto (hop).

El router no abre la carga ni le importa que sea una foto. Lee el destino en el encabezado, lo busca en su tabla y lo reenvía, en millonésimas de segundo. Por eso internet aguanta tanto tráfico: nadie en el camino entiende el mensaje completo; solo los dos extremos.

Esto tiene una consecuencia que vas a ver toda la lección. Como cada paquete viaja solo, pueden llegar en otro orden, llegar repetidos o no llegar: un router saturado tira los que no le caben. Alguien tiene que juntarlos, ordenarlos y pedir los que faltan. Eso lo hace TCP, más abajo.

Una dirección de 32 bits

Para que el router sepa a dónde mandar un paquete, cada aparato conectado tiene un número que lo identifica en la red: su dirección IP (IP address). IP es el Internet Protocol, el protocolo que lleva cada paquete de máquina en máquina.

En la versión 4 del protocolo, IPv4, la dirección es un número de 32 bits: 4 bytes. Para que las personas la lean, se escribe cada byte en decimal, del 0 al 255, separado por puntos: 192.168.1.20. Son los mismos 4 bytes de la lección «Cómo guarda números una computadora», escritos de otra manera.

Con 32 bits hay 2³² = 4,294,967,296 direcciones: unos 4.3 mil millones. Parecían muchísimas en 1981, cuando se diseñó IPv4. Hoy hay más personas que eso en el mundo, y cada una trae celular, computadora y tele. Las direcciones libres se acabaron: el organismo que las reparte entregó sus últimos bloques en 2011.

La salida de fondo es IPv6, con direcciones de 128 bits: 2¹²⁸ ≈ 3.4 × 10³⁸, suficientes para no acabarse nunca. Las dos versiones conviven, y en esta lección usamos IPv4, que es la que vas a ver en casi todos los ejemplos.

Una dirección también dice en qué red está

Una dirección IP tiene dos partes, como un número de teléfono con su lada: los primeros bits dicen en qué red está la máquina y los últimos, qué máquina es dentro de esa red. Una red se escribe con su primera dirección y, después de una diagonal, cuántos bits quedan fijos: 10.0.0.0/8 son todas las direcciones que empiezan con el byte 10. Quedan 24 bits libres: 2²⁴ = 16,777,216 direcciones. 192.168.1.0/24 deja fijos 3 bytes y libre el último: 256 direcciones. A diferencia de la lada, el corte entre red y máquina no se adivina viendo el número: lo dice la diagonal.

A los routers les sirve muchísimo: no guardan una fila por cada máquina del mundo, sino una por red. «Todo lo que empiece con 10.0 va por la puerta 2».

IP privada y pública

No todas las direcciones salen a internet. Tres rangos están apartados para redes internas, y cualquiera puede usarlos adentro sin pedirle permiso a nadie:

Una dirección de esos rangos es una IP privada: vale solo dentro de su red, y la misma 192.168.1.20 existe en millones de casas a la vez. Todas las demás son IP públicas: únicas en el mundo y alcanzables desde internet.

Tu casa es el ejemplo. Tu router le da a cada aparato una IP privada, 192.168.1.x, y él tiene una sola IP pública que le dio tu proveedor. Cuando tu celular sale a internet, el router cambia en cada paquete la dirección privada por la pública y anota el cambio, para saber a quién devolver la respuesta. Esa traducción se llama NAT (network address translation). Así, una IP pública alcanza para toda la casa. Las compañías de celulares hacen lo mismo en grande: en IPv4, el celular de Ana casi seguro tiene una IP privada, y miles de celulares salen por la misma pública.

En la nube pasa igual. Las máquinas de C01 viven en una red privada de AWS (Amazon Web Services, la nube de Amazon) con direcciones como 10.0.3.15, y desde internet no se pueden alcanzar: solo la puerta de entrada tiene IP pública. Esa red privada en la nube se llama VPC, y la vas a armar en la fase 8. En Kubernetes, además, cada pod (cada copia de un programa) recibe su propia IP privada al nacer y la pierde al morir: la siguiente copia tendrá otra.

import ipaddress

for texto in ("192.168.1.20", "10.0.3.15", "172.20.0.7", "8.8.8.8", "127.0.0.1"):
    ip = ipaddress.ip_address(texto)
    bits = ".".join(f"{b:08b}" for b in ip.packed)        # los 4 bytes, en binario
    tipo = "loopback" if ip.is_loopback else "privada" if ip.is_private else "pública"
    print(f"{texto:>12} → {bits}  {tipo}")

print("direcciones IPv4:", f"{2**32:,}")
print("direcciones IPv6:", f"{2**128:.2e}")
red = ipaddress.ip_network("10.0.0.0/8")
print("en 10.0.0.0/8 caben", f"{red.num_addresses:,}")
print("¿10.0.3.15 está en 10.0.0.0/8?", ipaddress.ip_address("10.0.3.15") in red)

192.168.1.20 → 11000000.10101000.00000001.00010100  privada
   10.0.3.15 → 00001010.00000000.00000011.00001111  privada
  172.20.0.7 → 10101100.00010100.00000000.00000111  privada
     8.8.8.8 → 00001000.00001000.00001000.00001000  pública
   127.0.0.1 → 01111111.00000000.00000000.00000001  loopback
direcciones IPv4: 4,294,967,296
direcciones IPv6: 3.40e+38
en 10.0.0.0/8 caben 16,777,216
¿10.0.3.15 está en 10.0.0.0/8? True

El puerto: un número para cada programa

La IP lleva el paquete a la máquina. Pero en la máquina de un pod del gateway corren varios procesos, y en la de Triton, el servidor que corre el modelo, también. ¿Cuál recibe el paquete?

Lo dice el puerto (port): un número de 16 bits, del 0 al 65,535, que va en el encabezado junto a la IP. Cada programa que quiere recibir conexiones se apunta en un puerto, y el kernel le entrega lo que llegue a ese número. Si la IP es la dirección de un edificio, el puerto es el número del departamento.

Algunos puertos son famosos, porque cada protocolo tiene uno acordado:

Los puertos del 0 al 1023 están reservados para los protocolos más conocidos, y en Linux solo root puede apuntarse en ellos, como viste en «El sistema operativo». (Docker y containerd 2.0, dos de los programas que arrancan contenedores, quitan esa regla dentro de ellos, pero la costumbre se quedó.) Por eso los programas propios, como el gateway con su 8080, usan puertos altos. Triton escucha en tres a la vez (el 8002 es para que Prometheus, el programa que junta las métricas de todos, las lea), así que un programa puede tener varios puertos; lo que no puede pasar, salvo con opciones especiales que aquí no hacen falta, es que dos programas de la misma máquina se apunten en el mismo puerto de la misma IP.

El socket: la puerta que abre un proceso

Para hablar por la red, un proceso le pide al kernel un socket: un objeto del sistema operativo por donde entran y salen los bytes, igual que un archivo abierto. Se pide con syscalls, las peticiones de un programa al kernel: socket para crearlo, bind para apuntarlo en una IP y un puerto, listen para esperar conexiones, accept para aceptar una y connect para conectarse a otro.

Con esas syscalls se ven los dos papeles de cualquier conversación por la red:

• El servidor llega primero y espera: hace bind en su puerto, listen y se queda en accept.
• El cliente (client) es quien abre la conexión: hace connect a la IP y al puerto del servidor.

Ser cliente o servidor no es un tipo de máquina: es un papel en una conexión. El gateway de C01 es servidor cuando le llega la foto y cliente cuando le habla a Triton.

El cliente también necesita un puerto, para que la respuesta tenga a dónde volver. No lo elige: el kernel le presta uno libre de un rango alto, un puerto efímero (ephemeral port), que dura lo que dure la conexión. En Linux, por omisión, sale del 32,768 al 60,999. (El organismo que reparte los números, la IANA, recomienda otro rango, del 49,152 al 65,535, y Windows usa ese.)

Así, una conexión queda identificada por cuatro números: IP y puerto del cliente, IP y puerto del servidor. Por eso un solo puerto 8080 atiende miles de conexiones a la vez: todas llegan al mismo puerto del servidor, pero cada una viene de una IP o de un puerto de cliente distinto.

import socket, threading

servidor = socket.socket(socket.AF_INET, socket.SOCK_STREAM)   # IPv4 y TCP
servidor.bind(("127.0.0.1", 0))      # 0: que el sistema elija un puerto libre
servidor.listen()                    # ya es un servidor: espera conexiones
ip, puerto = servidor.getsockname()

def atender():
    conexion, (ip_cliente, puerto_cliente) = servidor.accept()
    with conexion:
        pedido = conexion.recv(1024)                  # lee lo que llegó
        print("servidor: recibí", pedido, "desde", ip_cliente)
        print("servidor: el cliente usa otro puerto:", puerto_cliente != puerto)
        conexion.sendall(b"categoria=tenis")

hilo = threading.Thread(target=atender)
hilo.start()

with socket.create_connection((ip, puerto)) as cliente:   # el handshake pasa aquí
    cliente.sendall(b"foto de Ana")
    print("cliente: me respondieron", cliente.recv(1024))
hilo.join()
servidor.close()

servidor: recibí b'foto de Ana' desde 127.0.0.1
servidor: el cliente usa otro puerto: True
cliente: me respondieron b'categoria=tenis'

localhost y 0.0.0.0: dónde escucha un servidor

Cada máquina tiene una dirección para hablar consigo misma: 127.0.0.1, que se llama localhost. Lo que se manda ahí no sale de la máquina: el kernel lo devuelve por dentro, por una puerta de red de mentiras que se llama loopback. En IPv6 es ::1.

Una máquina tiene varias puertas de red, que se llaman interfaces: la de loopback, la del Wi-Fi o el cable, a veces más. Cada una tiene su IP. Por eso, al hacer bind, el servidor dice en cuál escucha:

• 127.0.0.1: solo en loopback. Solo le pueden hablar los programas de la misma máquina.
• 0.0.0.0: en todas las interfaces de la máquina. Le puede hablar quien llegue por cualquiera.

uvicorn, si no le dices otra cosa, escucha en 127.0.0.1:8000. En tu laptop está bien, y es a propósito: si escuchara en todas, cualquiera en la red del café podría hablarle a tu programa a medio hacer.

Dentro de un contenedor es una trampa. En «El sistema operativo» viste que un contenedor tiene su propio namespace de red: sus propias interfaces y su propio localhost. El 127.0.0.1 de adentro no es el de la máquina. Cuando Docker o Kubernetes mandan una request al contenedor, llega por su interfaz de red (en un pod, la de su IP privada, como 10.0.3.15), no por loopback. Si uvicorn escucha en 127.0.0.1, nadie escucha en esa interfaz, y la conexión se rechaza.

Es el error clásico de «el contenedor corre, los logs dicen que todo está bien y no contesta». Por eso el gateway de C01 arranca con uvicorn ... --host 0.0.0.0 --port 8080. Lo vas a vivir en la estación 7 del Dojo.

La IP lleva paquetes sueltos a una máquina, sin prometer nada: pueden perderse, llegar repetidos o desordenados. Sobre ella van dos protocolos que se encargan de llevarlos al programa, y que resuelven el problema de manera opuesta.

TCP: una conexión confiable

TCP (Transmission Control Protocol) convierte esos paquetes sueltos en una conexión: una tubería entre dos programas por la que los bytes llegan completos, sin repetirse y en el orden en que salieron. Para lograrlo usa tres ideas:

1. 1

   Numerar

   Cada paquete lleva el número de su primer byte dentro de la conversación: el número de secuencia. Del otro lado, TCP los acomoda por número, aunque lleguen desordenados, y tira los repetidos.

2. 2

   Acusar recibo

   El que recibe contesta con un acuse (acknowledgment, ACK): «ya tengo todo hasta el byte 43,800». Un solo acuse confirma muchos paquetes.

3. 3

   Reenviar

   Si un acuse no llega a tiempo, el que manda supone que el paquete se perdió y lo reenvía. El programa nunca se entera: solo ve los bytes llegar en orden, a veces un poco tarde.

TCP también cuida no ahogar a nadie: si el que recibe va lento, le pide que espere, y si la red empieza a perder paquetes, manda menos. Esa parte está en la sección extra «Dentro de TCP».

El handshake: tres pasos antes del primer byte

Antes de mandar datos, los dos lados tienen que ponerse de acuerdo: que los dos existen, que los dos escuchan y desde qué número empieza cada uno a contar. Eso se hace con un saludo de tres pasos, el handshake (three-way handshake):

1. 1

   SYN

   El cliente manda un paquete sin datos con la marca SYN (de synchronize) y su número inicial: «¿hablamos? Yo empiezo a contar en tal número».

2. 2

   SYN-ACK

   El servidor contesta con SYN y ACK a la vez: «recibí tu número; yo empiezo en este otro».

3. 3

   ACK

   El cliente acusa recibo. La conexión está abierta, y en ese mismo momento el cliente ya puede mandar su request.

Fíjate en el costo. Del SYN a recibir el SYN-ACK pasa una ida y vuelta completa, y en ella no viaja ni un byte de la foto. Esa ida y vuelta tiene nombre, RTT, y es el tema de la siguiente sección. Una conexión nueva cuesta 1 RTT antes del primer byte. Por eso los programas serios abren una conexión y la reusan para muchas requests.

UDP: mandar y olvidar

UDP (User Datagram Protocol) hace lo mínimo. Agrega a cada paquete el puerto de origen y el de destino, en un encabezado de 8 bytes, y lo manda. No hay handshake, no hay acuses, no hay reenvíos ni orden. Si un paquete se pierde, se perdió.

¿Para qué querría alguien algo así? Para cuando llegar tarde es peor que no llegar:

• Voz y videollamadas. Si se pierde un pedazo de voz, reenviarlo no sirve: cuando llegue, la conversación ya va más adelante. Es mejor un microcorte que una pausa. Por eso las llamadas por internet usan UDP siempre que pueden.
• Juegos en línea. La posición de un jugador de hace 200 ms ya no importa; importa la de ahora.
• El DNS. Una pregunta y su respuesta caben en un paquete cada una. Hacer un handshake para eso costaría más que la pregunta. Si no llega respuesta, se vuelve a preguntar.
• QUIC. Un protocolo nuevo que va encima de UDP y hace él mismo lo que hacía TCP: numera, acusa y reenvía, pero a su manera. Es la base de HTTP/3. Por qué alguien reconstruiría TCP sobre UDP lo ves en la sección extra.

Todo lo que viaja en C01, de la foto al tensor y a la respuesta, va por TCP: una categoría equivocada por un pedazo perdido sería mucho peor que unos milisegundos de espera.

Ida y vuelta

El RTT (round-trip time, tiempo de ida y vuelta) es lo que tarda un paquete en llegar del cliente al servidor más lo que tarda la respuesta en volver. Es la unidad con la que se mide cuánto le cuesta la red a cualquier conversación: el handshake es 1 RTT, una request con su respuesta es otro.

Si juegas en línea, ya lo conoces: el «ping» que muestra el juego, «32 ms», es el RTT entre tu consola y el servidor del juego. El nombre viene de ping, un programa que manda un paquete chiquito y mide cuánto tarda en volver.

El límite de la luz

El RTT tiene un piso que ninguna tecnología puede bajar: la velocidad de la luz. En el vacío, la luz recorre ≈ 300,000 km por segundo; dentro de la fibra óptica, el vidrio la frena a ≈ 200,000 km por segundo: 200 km por milisegundo. En la lección de unidades viste la regla que usa la Ronda, ≥ 1 ms de ida y vuelta por cada 100 km. Sale de aquí: 100 km de ida y 100 de vuelta son 200 km, un milisegundo.

Más ancho de banda no baja el RTT. El ancho de banda dice cuántos bits caben por segundo en el tubo; el RTT dice cuánto tarda un bit en ir y volver. Una carretera de diez carriles deja pasar más coches, pero no hace más corto el viaje de cada uno. Para bajar el RTT solo hay dos caminos: acercarse o hacer menos idas y vueltas.

La tabla usa dos palabras de la nube. Una región es un lugar del mundo donde un proveedor de nube tiene sus centros de datos: la de AWS en el norte de Virginia se llama us-east-1, y ahí vive C01. Una zona es uno o varios centros de datos dentro de una región, separados de los demás para que no fallen juntos; C01 usa dos. Las dos tienen su propia lección más adelante.

Son órdenes de magnitud, no promesas: cada red mide distinto, y lo que importa es medir la tuya.

Cuántas idas y vueltas paga una request

Ahora junta las piezas. Una request por una conexión nueva paga 1 RTT de handshake y 1 RTT de la request y su respuesta: 2 RTT. Si además va cifrada, como casi todo en internet, con TLS (el protocolo que cifra la conexión para que nadie en el camino pueda leerla), el saludo del cifrado suma, en su versión actual (TLS 1.3), otro RTT: 3 en total. La versión anterior, TLS 1.2, que todavía se usa, cobraba 2 de saludo: 4 en total. Por una conexión que ya estaba abierta: 1.

Con un RTT de 60 ms, un número redondo cerca del de Ana a Virginia (≈ 45 ms de la ruta más lo que sume el 4G), la diferencia se ve así:

Por eso existe keep-alive: dejar la conexión abierta después de una request para mandar la siguiente por ahí. Y por eso los programas que hacen muchas requests guardan varias conexiones abiertas listas para usarse, un pool de conexiones. Las dos ideas son de la lección de HTTP.

En C01, la regla se cumple en cada salto. El backend del marketplace está en la misma región que C01 y llama con conexiones abiertas. El gateway y Triton están en la misma zona y también reusan conexiones: su RTT es una fracción de milisegundo. Lo que no se controla es el tramo de Ana: por eso el SLO de 200 ms se mide del lado del servidor, desde que la request completa llega.

Las personas usan nombres; la red, números

Nadie escribe 203.0.113.10 en el navegador: escribe api.example.com. Y aunque lo escribiera, las IP cambian: una empresa muda su servicio a otra máquina y la IP vieja deja de servir. Hace falta un directorio que traduzca nombres a direcciones, que cualquiera pueda consultar y que se pueda actualizar. Ese directorio es el DNS (Domain Name System, sistema de nombres de dominio).

Usar el DNS se llama resolver un nombre. Antes de abrir cualquier conexión, el programa lo resuelve: le pregunta al DNS «¿qué IP tiene api.example.com?» y recibe «203.0.113.10». (El rango 203.0.113.x está reservado para ejemplos, como example.com: no es de nadie.)

Un árbol de nombres

Un nombre se lee de derecha a izquierda, como una dirección postal que empieza por el país: api.example.com es «la máquina api, de example, dentro de .com». Y la información también está repartida así, en un árbol: nadie tiene la lista completa de todos los nombres del mundo.

• Los servidores raíz (root) saben quién lleva cada terminación: .com, .mx, .org.
• Los servidores de cada terminación (top-level domain, TLD) saben quién lleva cada nombre: quién manda en example.com.
• El servidor autoritativo de example.com tiene la respuesta oficial: api.example.com es 203.0.113.10.

Tu programa no recorre el árbol. Le pregunta a un resolver (así, en inglés: «el que resuelve»), un servidor de DNS que hace el recorrido por él: el de tu proveedor de internet, el de la red de la nube o uno público, como el 8.8.8.8.

La caché y el TTL

Recorrer el árbol cuesta varias idas y vueltas. Si se hiciera en cada request, el DNS sería lentísimo y los servidores raíz recibirían cada búsqueda del mundo. La solución es guardar las respuestas: una caché.

Pero una respuesta guardada puede quedar vieja. Por eso cada respuesta trae su TTL (time to live, tiempo de vida): cuántos segundos se puede guardar antes de volver a preguntar. Lo decide el dueño del nombre. Un TTL de 300 s quiere decir «guárdala hasta 5 minutos».

El TTL es un trato. Uno corto cuesta más consultas pero los cambios se notan rápido; uno largo ahorra consultas pero un cambio tarda en llegar a todos. Un ejemplo con números: el TTL es de 300 s, tu programa preguntó en t = 0 y la empresa cambia de máquina en t = 150. Tu programa sigue usando la IP vieja hasta t = 300, cuando vence su caché. Si la máquina vieja ya estaba apagada, son 150 segundos de errores. Por eso, antes de mudar un servicio, se baja el TTL con días de anticipación.

registro = {"api.example.com": "203.0.113.10"}   # lo que dice el servidor autoritativo
TTL = 300                                        # segundos que se puede guardar la respuesta
cache = {}                                       # nombre → (ip, hasta cuándo vale)
consultas = 0

def resolver(nombre, ahora):
    global consultas
    if nombre in cache and ahora < cache[nombre][1]:
        return cache[nombre][0], "de la caché"
    consultas += 1                               # pregunta de verdad, por la red
    cache[nombre] = (registro[nombre], ahora + TTL)
    return registro[nombre], "preguntó"

for t in (0, 10, 120):
    print(f"t = {t:>3} s:", *resolver("api.example.com", t))
registro["api.example.com"] = "203.0.113.99"     # a los 150 s, la empresa cambia de máquina
for t in (200, 299, 300, 310):
    print(f"t = {t:>3} s:", *resolver("api.example.com", t))
print("consultas de verdad:", consultas, "de 7 búsquedas")

t =   0 s: 203.0.113.10 preguntó
t =  10 s: 203.0.113.10 de la caché
t = 120 s: 203.0.113.10 de la caché
t = 200 s: 203.0.113.10 de la caché
t = 299 s: 203.0.113.10 de la caché
t = 300 s: 203.0.113.99 preguntó
t = 310 s: 203.0.113.99 de la caché
consultas de verdad: 2 de 7 búsquedas

Nombres dentro de Kubernetes

Dentro de un clúster de Kubernetes, el grupo de máquinas que maneja los pods de C01, hay un DNS propio. El problema que resuelve es el de las IP de los pods: cambian cada vez que un pod se reinicia. Así que el gateway no apunta a la IP de un pod de Triton; apunta a un nombre:

triton.classifier.svc.cluster.local

Se lee igual, de derecha a izquierda: el dominio del clúster (cluster.local), los Services (svc), el namespace classifier y el Service triton. Ojo: un namespace de Kubernetes no es el namespace de red de Linux que viste arriba; es solo una carpeta para agrupar los objetos de un equipo, y classifier es la de C01. Un Service es un objeto de Kubernetes que pone un nombre y una IP fijos delante de los pods que hacen el mismo trabajo, y reparte entre ellos. El gateway lee ese nombre de una variable de su configuración, TRITON_URL=triton.classifier.svc.cluster.local:8000: el nombre y, después de los dos puntos, el puerto.

Cada capa responde una pregunta

Ya tienes todas las piezas. Fíjate en que cada protocolo resuelve una sola pregunta y deja las demás a otro:

• Enlace (Wi-Fi, o Ethernet, la red por cable): ¿cómo llego al siguiente aparato, el que tengo enfrente? Solo un salto.
• IP: ¿a qué máquina va, a través de todos los saltos?
• TCP o UDP: ¿a qué programa de esa máquina, y llega completo y en orden?
• HTTP (y el resto de los protocolos de los programas): ¿qué se pide y qué se contesta?

A esa pila se le dice capas de red (network layers). Cada capa usa la de abajo sin saber cómo funciona: HTTP no sabe de routers, e IP no sabe que lleva una foto. Por eso se puede cambiar una sin tocar las demás: la misma request de HTTP viaja igual por Wi-Fi, por 4G o por fibra.

En el trabajo se nombran con números, que vienen de un modelo de siete capas, el modelo OSI: el enlace es la capa 2 (L2), IP es la capa 3 (L3), TCP y UDP son la capa 4 (L4) y HTTP es la capa 7 (L7). Las otras casi no se mencionan. Internet, en realidad, se diseñó con un modelo de cuatro capas, el de TCP/IP (enlace, internet, transporte y aplicación), que son justo las cuatro de arriba; los números se tomaron prestados del OSI. En los dos, el DNS es de la capa de aplicación, como HTTP.

Sobres dentro de sobres

Al salir, cada capa envuelve lo que le dio la de arriba en su propio sobre: su encabezado. Al llegar, cada capa quita el suyo y le pasa el resto a la de arriba.

Las capas importan para la Ronda por una razón práctica: lo que ve una máquina depende de la capa en la que trabaja. Un router solo lee la capa 3: IP de origen y de destino. Un balanceador (un programa que reparte las requests entre varias copias de un mismo servidor) que trabaja en la capa 4 ve también los puertos, y nada más: reparte conexiones, sin saber qué requests van adentro. Uno de capa 7 abre HTTP y ve cada request: su ruta, sus encabezados. La Ronda (M06) dice que el Service de Kubernetes «balancea por conexión (L4)», y en la lección Balanceadores, proxies y gateways vas a ver por qué eso le complica la vida a un servidor de modelos.

El viaje completo

Ahora sí, la respuesta a la pregunta de la lección. Recorre el diagrama paso a paso:

En una frase: la app resuelve un nombre con el DNS, abre una conexión TCP a la IP y al puerto 443 del backend, y manda la foto en paquetes que los routers reenvían. El backend hace lo mismo hacia C01. El ALB (Application Load Balancer), el balanceador de AWS que es la puerta de entrada de C01, pasa la request a la IP privada de un pod del gateway, en el puerto 8080, donde uvicorn escucha en 0.0.0.0. Y el gateway, ahora como cliente, resuelve triton.classifier.svc.cluster.local y manda el tensor al puerto 8000 de Triton. Cada salto es una conexión distinta, y en cada una se repite lo mismo: nombre → IP, IP → máquina, puerto → programa, TCP → completo y en orden.

1. Escuchar en 127.0.0.1 dentro de un contenedor

El servidor arranca, los logs dicen «running on http://127.0.0.1:8000» y nadie de afuera puede hablarle. Dentro del contenedor, 127.0.0.1 es su propio localhost, y lo de afuera llega por otra interfaz. El síntoma cambia según por dónde llegues: desde otra máquina, «connection refused»; desde tu laptop, con -p (la opción de Docker que conecta un puerto de tu laptop con uno del contenedor; la ves en el error siguiente), a veces Docker acepta la conexión y luego la corta, y curl dice «Empty reply from server» o «Connection reset by peer». Es el mismo error.

Cómo evitarlo: en un contenedor, escuchar en 0.0.0.0 (uvicorn --host 0.0.0.0). En tu laptop, fuera de un contenedor, deja 127.0.0.1: así nadie de tu red le habla a tu programa a medio hacer.

2. Confundir el puerto del contenedor con el de la máquina

docker run -p 8080:8000 quiere decir «el puerto 8080 de la máquina lleva al 8000 del contenedor»: primero el de afuera, después el de adentro. Si uvicorn escucha en el 8080 dentro del contenedor, ese -p apunta a un puerto donde nadie escucha.

Cómo evitarlo: decide el puerto en un solo lugar (una variable de configuración) y revisa que coincidan el --port del programa, el -p de Docker o el containerPort de Kubernetes (el campo de su configuración que dice en qué puerto escucha el contenedor), y el puerto que piden sus clientes.

3. Abrir una conexión nueva en cada request

Cada conexión nueva paga 1 RTT de handshake (2 con TLS), empieza mandando poco a poco (el arranque lento de la sección extra «Dentro de TCP») y, al cerrarse, deja su puerto apartado un rato. A 60 ms de RTT y con TLS, una request que costaría 60 ms cuesta 180.

Cómo evitarlo: crear el cliente HTTP una vez, al arrancar el programa, y reusarlo: con keep-alive y un pool de conexiones. Nunca crear un cliente nuevo dentro de la función que atiende cada request.

4. Apuntar a la IP de un pod

Funciona hasta que el pod se reinicia y nace con otra IP. O hasta que Kubernetes agrega un pod nuevo que nadie conoce.

Cómo evitarlo: hablarle a un nombre, el del Service (triton.classifier.svc.cluster.local), que tiene una IP fija y siempre apunta a los pods vivos. En la nube, lo mismo: nombres de DNS, no IPs escritas en la configuración.

5. Olvidar el TTL al mover un servicio

Cambias la IP en el DNS y apagas la máquina vieja de inmediato. Durante lo que dure el TTL, todos los que tenían la respuesta guardada siguen llamando a la vieja. Con un TTL de un día, son hasta 24 horas de errores.

Cómo evitarlo: días antes del cambio, bajar el TTL (a 60 s, por ejemplo), esperar a que venza el viejo, cambiar la IP y dejar la máquina vieja viva hasta que se apague el tráfico. Después, volver a subir el TTL.

6. Creer que más ancho de banda arregla la latencia

Si el RTT a otro continente es de 100 ms, ningún plan de internet más rápido lo baja: más Gb/s sirve para mandar más cosas a la vez, no para que cada una llegue antes.

Cómo evitarlo: contar idas y vueltas, no solo megas. Acercar las máquinas, reusar conexiones y hacer menos viajes por request.

Resuélvelos con lápiz antes de abrir la solución. Los de distancia y de arranque lento se pueden comprobar con las calculadoras.

1. 1Fácil

   Un vendedor sube desde la web el original de una foto de 10 MB. ¿Cuántos paquetes de 1,460 bytes de datos son? ¿Cuántos bytes de encabezados de IP y TCP viajan con ellos?

   Ver la solución paso a paso

   • Paquetes: 10,000,000 ÷ 1,460 = 6,849.3 → hacia arriba, 6,850.
   • Encabezados: 6,850 × 40 bytes = 274,000 bytes, ≈ 274 KB: el 2.7 % de lo que viaja.
2. 2Fácil

   ¿Cuáles de estas direcciones son privadas? 10.2.3.4, 172.15.0.1, 172.31.255.1, 192.169.0.1 y 127.0.0.1.

   Ver la solución paso a paso

   • 10.2.3.4: privada. Empieza con 10: está en 10.0.0.0/8.
   • 172.15.0.1: pública. El rango privado de 172 va del 172.16 al 172.31; el 15 queda afuera.
   • 172.31.255.1: privada. Es la última parte del rango 172.16.0.0/12.
   • 192.169.0.1: pública. El rango privado es 192.168.x.x; 169 no entra.
   • 127.0.0.1: ninguna de las dos. Es loopback, la máquina misma: no sale ni a la red de la casa.
3. 3Fácil

   Corres docker run -p 8080:8000 mi-api. Adentro, uvicorn arranca sin --host y en su puerto por omisión. Desde tu laptop, curl localhost:8080 falla. ¿Por qué, y qué cambias?

   Ver la solución paso a paso

   • El -p lleva el 8080 de tu laptop al 8000 del contenedor: el puerto coincide con el de uvicorn, eso está bien.
   • El problema es la dirección: sin --host, uvicorn escucha en 127.0.0.1, el localhost del contenedor. Lo que llega por -p entra por la interfaz de red del contenedor, donde nadie escucha.
   • Arreglo: uvicorn app:app --host 0.0.0.0 --port 8000.
4. 4Fácil

   Un juego promete un RTT de 40 ms. Si todo fuera fibra en línea recta, ¿a cuántos km puede estar el servidor, como máximo?

   Ver la solución paso a paso

   • 40 ms de ida y vuelta son 20 ms de ida.
   • A 200 km por milisegundo: 20 × 200 = 4,000 km, como máximo. En la práctica, menos, porque la ruta no es recta y cada router suma.
5. 5Medio

   Un programa hace 3 requests seguidas, cada una esperando a la anterior, a un servidor con 45 ms de RTT y TLS. ¿Cuánto tarda la red si abre una conexión nueva para cada una? ¿Y si abre una y la reusa?

   Ver la solución paso a paso

   • Conexión nueva para cada una: 3 RTT por request (TCP, TLS y la request) × 3 requests = 9 RTT = 9 × 45 = 405 ms.
   • Una sola conexión: 2 RTT para abrirla (TCP y TLS) + 3 RTT de las requests = 5 RTT = 225 ms.
   • Reusar ahorra 180 ms. Si la conexión ya estaba abierta de antes, quedan 3 × 45 = 135 ms.
6. 6Medio

   El nombre de un servicio tiene un TTL de 86,400 s. El lunes a las 10:00 cambias su IP y apagas la máquina vieja. ¿Hasta cuándo puede haber clientes llamando a la vieja? ¿Cómo lo harías mejor?

   Ver la solución paso a paso

   • 86,400 s ÷ 3,600 = 24 horas. Un cliente que guardó la respuesta el lunes a las 9:59 la usa hasta el martes a las 9:59: casi un día de errores para él.
   • Mejor: el viernes anterior, bajar el TTL a 60 s. Esperar al menos 24 horas, para que venza todo lo guardado con el TTL viejo. El lunes, cambiar la IP; a los pocos minutos, casi todos usan la nueva. Dejar la vieja encendida hasta que deje de recibir tráfico y luego subir el TTL otra vez.
7. 7Medio

   Escribe 10.0.3.15 en binario, byte por byte. ¿Está en la red 10.0.0.0/8? ¿Y en 10.0.2.0/24?

   Ver la solución paso a paso

   • 10 = 0000 1010; 0 = 0000 0000; 3 = 0000 0011; 15 = 0000 1111. Juntos: 00001010.00000000.00000011.00001111.
   • /8 deja fijos los primeros 8 bits, que en 10.0.0.0 son 00001010. Coinciden: sí está.
   • /24 deja fijos los primeros 3 bytes: 10, 0 y 2. El tercer byte de la dirección es 3, no 2: no está. Estaría en 10.0.3.0/24.
8. 8Medio

   Por una conexión TCP nueva hay que mandar 1 MB, con 50 ms de RTT y 10 Mb/s de ancho de banda. ¿Cuántas vueltas pide el arranque lento, con ventana inicial de 10? ¿Qué limita más, el RTT o el ancho de banda?

   Ver la solución paso a paso

   • Paquetes: 1,000,000 ÷ 1,460 → 685.
   • Vueltas: 10, 20, 40, 80, 160, 320 suman 630; falta una más: 7 vueltas, 7 × 50 = 350 ms.
   • Por ancho de banda: 1,000,000 × 8 = 8,000,000 bits ÷ 10,000,000 bits por segundo = 0.8 s.
   • Limita el ancho de banda: el envío tarda ≈ 800 ms aunque la ventana se abra en 350. Con 100 Mb/s, mandaría el RTT.
9. 9Reto

   Un job de prueba manda 2,000 requests por segundo a un Triton, desde una sola máquina, y abre y cierra una conexión por request. A los pocos segundos empieza a fallar con «cannot assign requested address». ¿Por qué, y en cuántos segundos? ¿Qué cambias?

   Ver la solución paso a paso

   • Cada conexión cerrada deja su puerto efímero en TIME_WAIT 60 s. Para sostener 2,000 por segundo harían falta 2,000 × 60 = 120,000 puertos apartados a la vez, y Linux trae 28,232.
   • Se acaban en 28,232 ÷ 2,000 ≈ 14 segundos. Desde ahí, el kernel no tiene puerto que prestarle a la siguiente conexión.
   • El techo con conexiones nuevas es ≈ 470 por segundo hacia ese destino. Arreglo: un pool de conexiones con keep-alive. Con 20 conexiones reusadas, cada una lleva 100 requests por segundo, sin handshakes ni TIME_WAIT.
10. 10Reto

    Ana, en la Ciudad de México, sube por 4G a Virginia el original de su foto, de 3 MB, como si la app no la achicara. Supón un RTT de 80 ms (45 de la ruta más 35 del tramo de radio), 10 Mb/s de subida, el nombre ya guardado en caché y una conexión nueva con TLS. Estima lo que tarda la red hasta que la foto llega completa. ¿Por qué el SLO de C01 no mide esto?

    Ver la solución paso a paso

    • DNS: en caché, 0 ms.
    • Handshake de TCP y saludo de TLS: 2 RTT = 160 ms.
    • La foto: el arranque lento pediría 8 vueltas × 80 = 640 ms, pero el ancho de banda pide 3,000,000 × 8 ÷ 10,000,000 = 2.4 s. Manda el ancho de banda.
    • Total: ≈ 160 + 2,400 ≈ 2.6 s, más lo que tarde en volver la respuesta.
    • El SLO de C01 (p99 ≤ 200 ms) se mide del lado del servidor, desde que la request completa llega. Estos 2.6 s dependen de la señal de Ana y de su compañía de celular, que nadie en C01 controla. Por eso, además, la app achica la foto antes de subirla: con ≈ 200 KB son 137 paquetes, 4 vueltas de arranque lento × 80 = 320 ms (el ancho de banda pediría solo 160), y con el handshake, ≈ 480 ms en vez de 2.6 s.

En la Ronda:

• M02 · Patrones de inferencia, para decidir si el modelo corre en la nube o junto a las cámaras, pregunta si cabe una ida y vuelta por una red que no controlas y cuántos Mb/s tiene el sitio: RTT y ancho de banda.
• M06 · Orquestación y escalado usa los Services de Kubernetes como «un nombre DNS estable delante de los pods sanos», pone triton.classifier.svc.cluster.local:8000 en la configuración del gateway, advierte que el Service balancea por conexión (L4) y manda el tráfico a la misma zona con PreferSameZone.
• M13 · Nube recorre cada byte: IP públicas que se cobran, subredes privadas, el NAT de la salida a internet y lo que cuesta cruzar de zona o de región.
• También: M07 usa los puertos de Triton (8000 HTTP, 8001 gRPC, 8002 métricas) y el caso del pod nuevo que no recibe tráfico por las conexiones persistentes.

En el Dojo: la estación 7, «Empaquetado (Docker)», ya está abierta: ahí publicas puertos con -p y te topas con el «escuchar en 0.0.0.0». La estación 9, «Kubernetes», todavía no abre; cuando abra, el gateway encontrará a Triton por el nombre de su Service.

En Sensei: la siguiente lección, «HTTP: requests, respuestas y códigos», abre lo que viaja dentro de la conexión TCP: el método, la URL, los encabezados, los códigos como 200 o 503, el keep-alive y el pool de conexiones. Después vienen las APIs, los balanceadores (capa 4 contra capa 7), los timeouts y reintentos, y la latencia de punta a punta. En la fase 8, «Redes en la nube» arma la VPC, el NAT y la salida a internet de C01, y otra lección explica el cifrado con TLS.

Estos son los conceptos que presentó esta lección. Cada uno tiene su tarjeta con la definición completa.

Intenta responder en tu cabeza antes de abrir cada respuesta.

1. 1¿Qué decide la IP y qué decide el puerto?Ver respuesta

   La IP, a qué máquina va el paquete; el puerto, a qué programa de esa máquina. El gateway de C01 escucha en el 8080 de la IP de su pod.

2. 2¿Por qué el original de la foto de Ana, de 3 MB, viajaría en ≈ 2,055 paquetes y no de una pieza?Ver respuesta

   Un paquete lleva como máximo 1,500 bytes, 1,460 de datos. En pedazos, el cable se comparte y lo dañado se reenvía solo.

3. 3¿Por qué un servidor que escucha en 127.0.0.1 dentro de un contenedor no recibe nada de afuera?Ver respuesta

   Porque 127.0.0.1 es el localhost del propio contenedor. Lo de afuera llega por otra interfaz, y ahí nadie escucha. Hay que escuchar en 0.0.0.0, todas las interfaces.

4. 4¿Cuántas idas y vueltas paga una request por una conexión nueva con TLS, y por una ya abierta?Ver respuesta

   Tres: el handshake de TCP, el saludo de TLS y la request con su respuesta. Por una ya abierta, una. A 60 ms de RTT, 180 ms contra 60.

5. 5¿Cuándo conviene UDP en vez de TCP?Ver respuesta

   Cuando llegar tarde es peor que no llegar (voz, video en vivo, juegos) o cuando el mensaje cabe en un paquete y se puede volver a preguntar (DNS). QUIC usa UDP y hace él mismo lo que hacía TCP.

6. 6¿Para qué sirve el TTL de una respuesta de DNS, y qué pasa si es muy largo?Ver respuesta

   Dice cuántos segundos se puede guardar la respuesta. Si el nombre cambia de IP, quien la guardó sigue usando la vieja hasta que venza: con un TTL de un día, hasta 24 horas.

7. 7Un balanceador de capa 4 y uno de capa 7, ¿qué ve cada uno?Ver respuesta

   El de capa 4 ve IPs y puertos: reparte conexiones. El de capa 7 abre HTTP y ve cada request, con su ruta y sus encabezados. El Service de Kubernetes reparte en capa 4.