DTLS y SCTP: el canal de datos sobre una pila de medios

Cuando el procedimiento de conectividad encuentra por fin una pareja de direcciones que responde, lo que se tiene es un camino por el que pasan datagramas sueltos, sin orden, sin garantía de llegada y sin protección alguna. Falta todo lo que convierte eso en algo utilizable por una aplicación. WebRTC resuelve esa parte apilando dos protocolos que no se diseñaron para esto ni el uno para el otro: una adaptación del cifrado de la web a un transporte sin conexión, y encima de ella un protocolo de transporte nacido para llevar señalización telefónica sobre red de datos. El resultado tiene una virtud enorme y muy infravalorada, que es poder elegir por canal si los mensajes llegan en orden y si se reintentan, y arrastra un lastre igual de real: tres saludos encadenados antes del primer byte útil, un límite de tamaño de mensaje que hay que gestionar a mano y una implementación considerable de código heredado dentro del proceso del navegador. Esta lección examina las dos caras con el mismo detalle.

Cifrado obligatorio y tres saludos encadenados

Lo primero que ocurre sobre el camino recién abierto es un saludo criptográfico. WebRTC no permite transmitir en claro, no hay opción de configuración que lo desactive, y eso es una decisión excelente que conviene aplaudir sin matices: elimina de raíz una categoría entera de errores de despliegue y garantiza que ningún intermediario de la ruta lea los datos. La adaptación empleada es la del cifrado de la web llevada a un transporte sin conexión, lo que obliga a añadir por su cuenta numeración y reintentos porque los mensajes del saludo pueden perderse o llegar desordenados.

Los certificados son autofirmados y se generan en el propio navegador, sin autoridad que los avale. Como vimos en la segunda lección, la única comprobación posible es contrastar la huella presentada con la que llegó por señalización, de modo que la solidez del cifrado depende por completo de la integridad de aquel canal. Aquí interesa la otra cara: el coste temporal. El saludo requiere sus propias idas y vueltas, y ocurre después de que las comprobaciones de conectividad hayan terminado, no en paralelo.

// Los tres saludos son secuenciales y sus latencias se suman
// 1. conectividad: probar parejas hasta que una responde   -> variable, cola larga
// 2. cifrado: saludo sobre datagramas con reintentos       -> una o dos idas y vueltas
// 3. transporte: apertura del canal fiable por encima      -> otra ida y vuelta

// Y solo despues de los tres se puede enviar el primer byte util.
pc.addEventListener("connectionstatechange", () => {
  console.log(pc.connectionState); // connecting -> connected
});

Ese apilamiento explica por qué una conexión entre pares tarda en estar lista bastante más de lo que la intuición sugiere, incluso cuando la red es buena y la pareja de direcciones se encuentra al primer intento. No es un problema de implementación: es la suma aritmética de tres protocolos que negocian por separado porque se escribieron por separado y en épocas distintas.

Un transporte de señalización telefónica dentro de un datagrama

Encima del cifrado va el transporte que de verdad reparte los mensajes, y su procedencia es la parte más sorprendente de toda la pila. Se diseñó para llevar señalización de telefonía sobre red de datos, un caso de uso con requisitos muy peculiares: mensajes discretos en lugar de un flujo continuo de bytes, muchas conversaciones independientes dentro de una misma asociación, tolerancia a caminos que se caen y una hostilidad explícita hacia los ataques de apertura masiva de conexiones.

De ese origen vienen tres propiedades que sí resultan útiles aquí y una que no se usa. La primera útil es que es orientado a mensajes: lo que envías es lo que el otro recibe, con sus fronteras intactas, sin necesidad de inventarse un marco de longitud como haría falta sobre un flujo de bytes. La segunda es el multiplexado en flujos independientes dentro de una sola asociación, que permite que un mensaje grande atascado en un flujo no bloquee a los demás. La tercera es la fiabilidad parcial, y es la joya de la corona. La que no se usa es la capacidad de mantener varios caminos simultáneos, porque de eso ya se encarga el procedimiento de conectividad de la lección anterior.

// Tres canales sobre la misma asociacion, con politicas deliberadamente distintas
const ops = pc.createDataChannel("ops", {
  negotiated: true, id: 1, ordered: true          // fiable y ordenado: operaciones
});

const presencia = pc.createDataChannel("presencia", {
  negotiated: true, id: 2,
  ordered: false, maxPacketLifeTime: 500          // caduca: cursores y estado efimero
});

const bloques = pc.createDataChannel("bloques", {
  negotiated: true, id: 3,
  ordered: false                                   // fiable pero sin orden: trozos
});

Merece la pena detenerse en el tercer canal porque es el que más gente configura mal. Un trozo de fichero identificado por su posición no necesita llegar en orden: necesita llegar. Pedir orden cuando no hace falta activa el bloqueo por cabecera de línea, en el que un solo mensaje perdido detiene la entrega de todos los que ya habían llegado detrás mientras se espera su reintento. En una red con pérdidas, esa diferencia de configuración cambia el rendimiento de forma drástica y no cuesta nada.

Elegir la política de entrega dato por dato

Las dos palancas son independientes y dan cuatro combinaciones, de las cuales la mayoría de las aplicaciones usa solo una. Conviene tener la tabla mental completa porque es la capacidad más valiosa que ofrece este transporte y la que no tiene equivalente en un canal ordinario contra un servidor.

Las dos últimas combinaciones son mutuamente excluyentes y son también la razón principal por la que este transporte tiene sentido para una aplicación colaborativa. Un cursor de otra persona que llegó con dos segundos de retraso no es información útil, es información equivocada: la persona ya está en otro sitio. Reintentar su entrega consume ancho de banda para empeorar lo que se ve. Un canal ordinario contra un servidor no puede expresar eso, porque su contrato es entregarlo todo aunque sea tarde, y por eso las aplicaciones que lo usan acaban implementando a mano un descarte que el transporte de debajo sigue empeñado en evitar.

La contrapresión, en cambio, no es opcional y es donde se rompen las implementaciones descuidadas. Enviar sin comprobar cuánto queda pendiente hace crecer un buffer interno sin límite hasta que el canal se cierra o el proceso se queda sin memoria, y ocurre con facilidad al volcar un historial entero al conectar.

const LIMITE = 1 << 20;                 // un megabyte pendiente como techo
canal.bufferedAmountLowThreshold = 256 * 1024;

async function enviarConControl(canal, mensajes) {
  for (const m of mensajes) {
    if (canal.bufferedAmount > LIMITE) {
      await new Promise((r) =>
        canal.addEventListener("bufferedamountlow", r, { once: true }));
    }
    canal.send(m);
  }
}

Al mismo problema pertenece el tamaño máximo de mensaje. Aunque las implementaciones actuales admiten mensajes bastante grandes y anuncian su límite, lo prudente en una aplicación real es trocear por tu cuenta en fragmentos pequeños y reensamblar arriba, tanto por compatibilidad como porque un mensaje enorme monopoliza su flujo durante todo el envío y estropea la latencia de lo demás.

Lo que arrastras y no ibas a usar

Puesto el balance sobre la mesa, hay que nombrar el pasivo con la misma franqueza. El primer apunte es la latencia acumulada de tres negociaciones encadenadas, que ya hemos visto y que no se puede recortar salvo con canales pre-acordados. El segundo es la superficie de código: la implementación del transporte es una biblioteca considerable escrita hace años para otro propósito, que vive dentro del navegador y ha tenido su historial de vulnerabilidades como cualquier código de red de ese tamaño. No es un argumento decisivo, pero conviene saber que aceptar conexiones de pares desconocidos expone esa superficie a datos que envía cualquiera.

El tercer apunte es de redundancia conceptual, y es el más interesante. El control de congestión, los reintentos, la numeración y el reensamblado están implementados aquí, en el espacio de la aplicación, sobre una capa de cifrado que también lleva su propia numeración y sus propios reintentos para su saludo, sobre un transporte sin conexión que no lleva nada. Tres capas que se escribieron sin conocerse, cada una resolviendo una parte del mismo problema con su propio vocabulario.

flowchart TD
subgraph pila de WebRTC
  A1[mensajes de la aplicacion] --> A2[transporte con flujos y fiabilidad parcial]
  A2 --> A3[cifrado adaptado a datagramas]
  A3 --> A4[datagramas sin conexion]
end
subgraph transporte integrado moderno
  B1[mensajes de la aplicacion] --> B2[flujos y cifrado en una sola capa]
  B2 --> B4[datagramas sin conexion]
end
style A2 fill:#f9e2af,color:#11111b
style A3 fill:#f9e2af,color:#11111b
style B2 fill:#a6e3a1,color:#11111b

El transporte integrado que hoy sostiene la tercera versión del protocolo de la web hace exactamente el mismo trabajo con una sola negociación, porque se diseñó desde el principio con el cifrado y el multiplexado dentro en lugar de apilados encima. Esa comparación no invalida a WebRTC, que sigue siendo lo único disponible en el navegador para hablar directamente con otro cliente, pero sí explica por qué las pilas de la generación siguiente, que veremos en el nivel próximo, no se parecen a esta.