Los relevos sin estado y la economía de montar una red entre pares

Toda red entre pares que aspire a funcionar fuera del laboratorio necesita un servidor en algún sitio, y quien diga lo contrario está omitiendo el arranque en frío, la localización de pares y la fracción de usuarios que nunca conseguirá una conexión directa. La pregunta interesante no es si hace falta infraestructura, sino qué se le pide a esa infraestructura, porque de ahí sale todo lo demás: cuánto cuesta, quién puede operarla, qué pasa cuando se cae y cuánto duele migrarla. La documentación de iroh formula la respuesta en una sola frase que conviene tomarse como enunciado técnico y no como eslogan: a diferencia de los servidores tradicionales, los relevos no tienen estado; no almacenan los datos de tu aplicación, se limitan a facilitar conexiones. Esta lección desarrolla las consecuencias de esa frase, que son más numerosas y más económicas que técnicas.

Qué hace exactamente un relevo, y qué no hace

La documentación de iroh asigna al relevo exactamente dos cometidos y conviene no ampliarlos mentalmente. El primero es ayudar a perforar: cuando dos extremos se encuentran por primera vez, intercambian información de red a través del relevo para intentar una conexión directa. El segundo es transportar como reserva: si la conexión directa no se puede establecer, por traducciones de direcciones estrictas, cortafuegos u otras condiciones, el tráfico circula por el relevo. Nada más. En cuanto la ruta directa queda establecida, el relevo se aparta y los datos fluyen entre pares.

Hay un tercer hecho, negativo y decisivo: los servidores de relevo no pueden leer el tráfico que manejan, porque va cifrado de extremo a extremo. Esto no es una promesa de política de privacidad, es una consecuencia mecánica de lo que vimos en la lección anterior: la identidad es la clave, el establecimiento de sesión de TLS 1.3 ocurre entre los extremos, y el relevo mueve bytes que no puede interpretar. La propia documentación observa además que el relevo no participa activamente en la coordinación: reenvía paquetes cifrados sin saber si contienen datos de aplicación o mensajes de coordinación.

Merece la pena señalar que este patrón no es exclusivo de una biblioteca. El relevo de circuito de libp2p llega a la misma idea desde otro camino cuando permite al relevo acotar los recursos que dedica a cada reserva por número de conexiones, por tiempo y por bytes. En ambos casos la observación de fondo es idéntica: el intermediario solo es sostenible si lo que se le pide es acotado y no acumulativo.

Sin estado: qué desaparece de la lista de tareas

La ausencia de estado no se nota en el diagrama de arquitectura, se nota en el calendario del equipo de operaciones. La documentación de iroh enumera cuatro consecuencias y las cuatro son partidas de trabajo que dejan de existir.

No hay sincronización de bases de datos, porque no hay nada que replicar entre instancias de relevo. No hay migración de estado: cuando un relevo cae, los clientes se reconectan a otro sin pérdida de datos, porque no había datos que perder. El escalado es simple, ya que las instancias se levantan y se apagan como cualquier servicio ligero, sin ceremonia de rebalanceo ni particionado. Y la conmutación por fallo es automática, porque un extremo puede intentar conectarse a varios relevos y basta con que uno sea alcanzable para que los pares se encuentren.

// Configurar relevos propios es la unica decision de infraestructura que queda
use iroh::{Endpoint, RelayMode, RelayMap, RelayUrl};

let relevos = RelayMap::from_iter([
    RelayUrl::from(url_europa),
    RelayUrl::from(url_america),
]);

let endpoint = Endpoint::builder()
    .relay_mode(RelayMode::Custom(relevos))
    .bind()
    .await?;

Puesto todo junto, la documentación describe el resultado como una inversión del modelo tradicional: los relevos son facilitadores de conexión desechables, mientras que los clientes poseen todo el estado y toda la lógica de la aplicación. Esa palabra, desechable, es el núcleo económico de la lección: un componente desechable puede replicarse sin coordinación, apagarse sin aviso y sustituirse sin migración.

La economía frente al servidor de retransmisión clásico

Compara ahora dos hojas de cálculo. En el modelo clásico, el servidor recibe cada mensaje, lo almacena, lo indexa, lo entrega a los destinatarios y lo conserva por si alguien vuelve. Su coste crece con el volumen acumulado de datos y con el número de usuarios activos, y arrastra tres partidas que no aparecen en la factura del proveedor de nube pero sí en la nómina: copias de seguridad, migraciones de esquema y respuesta ante incidentes con datos de por medio. Cuando ese servidor cae, hay pérdida potencial y hay que restaurar; cuando hay que actualizarlo, hay ventana de mantenimiento.

En el modelo de relevo sin estado, el coste crece con el ancho de banda de la fracción que no consigue conexión directa, y con nada más. No hay volumen acumulado porque no se acumula nada. No hay copias de seguridad de lo que no se guarda. No hay migración de esquema donde no hay esquema. Y la caída de una instancia no es un incidente con datos, es una reconexión.

flowchart TD
subgraph CLASICO
  C1[cliente] --> S[servidor con base de datos]
  C2[cliente] --> S
  S --> BK[copias de seguridad y migraciones]
  S --> ESC[escalado con reparticion y coordinacion]
end
subgraph RELEVO
  P1[par con todo el estado] --> R[relevo sin estado]
  P2[par con todo el estado] --> R
  R -.-> P1
  P1 --> DIR[ruta directa validada]
  DIR --> P2
  R --> DESE[instancia desechable sin nada que migrar]
end
style S fill:#f38ba8,color:#11111b
style R fill:#a6e3a1,color:#11111b
style DIR fill:#89b4fa,color:#11111b
style DESE fill:#f9e2af,color:#11111b

Hay un factor multiplicador que conviene calcular antes de decidir nada. Si la perforación acierta en torno a nueve de cada diez configuraciones de red, como documenta iroh, el relevo solo transporta el tráfico de la décima parte restante, y solo mientras esa conversación dure. El resto del tráfico —el noventa por ciento— no pasa por tu infraestructura en absoluto, ni consume ancho de banda que pagues, ni aparece en tu factura. Ese es el cambio de escala real: no estás optimizando un servidor, estás sacando la mayor parte del tráfico del presupuesto.

Lo que sigue costando dinero

Sería deshonesto terminar aquí. Hay partidas que no desaparecen y conviene tenerlas escritas. La primera es el ancho de banda de la minoría que no perfora, que es tráfico real, sostenido y que además tiende a concentrarse en las redes corporativas y móviles, es decir, en usuarios que a menudo son los que más importan. La segunda es la cobertura geográfica: iroh funciona con un solo relevo, pero funciona mejor con relevos en cada región donde haya usuarios, y cada región es una instancia más.

La tercera es la disponibilidad. Los relevos públicos que la biblioteca trae de serie son gratuitos, están limitados por tasa para evitar abusos, no ofrecen ninguna garantía de tiempo de actividad ni de rendimiento y están compartidos con el resto del mundo; la documentación es explícita en que sirven para desarrollo y pruebas, y en que producción pide relevos dedicados. La cuarta, fácil de olvidar al planificar: los relevos públicos se operan para la última versión mayor de la biblioteca, de modo que quedarse atrás en versiones tiene un coste de infraestructura además de uno de mantenimiento.