RTCQuicTransport se lanzará una versión de prueba de origen cerca de ti (Chrome 73)

¿Qué?

RTCQuicTransport es una nueva API de la plataforma web que permite intercambiar datos arbitrarios con pares remotos mediante el protocolo QUIC. Está diseñado para casos de uso de pares y, por lo tanto, se usa con una API independiente de RTCIceTransport para establecer una conexión entre pares a través de ICE. Los datos se transportan de forma confiable y ordenada (consulta la sección a continuación para obtener detalles sobre la entrega desordenada y poco confiable). Como es un transporte de datos genérico y bidireccional, se puede usar para juegos, transferencias de archivos, transporte de contenido multimedia, mensajería, etcétera.

¿Por qué?

Una API de transporte de datos de bajo nivel potente puede permitir que las aplicaciones (como las comunicaciones en tiempo real) realicen tareas nuevas en la Web. Puedes compilar sobre la API, crear tus propias soluciones y superar los límites de lo que se puede hacer con las conexiones de par a par, por ejemplo, desbloquear los controles de asignación de tasa de bits personalizados. En el futuro, una mayor compatibilidad con el contenido multimedia codificado podría permitir compilar tu propia aplicación de comunicación por video con controles de bajo nivel. El esfuerzo de NV de WebRTC es avanzar hacia las APIs de nivel inferior, y experimentar con esto con anticipación es valioso.

¿Por qué QUIC?

El protocolo QUIC es conveniente para las comunicaciones en tiempo real. Se compila en UDP, tiene encriptación integrada, control de congestión y se multiplexa sin bloqueo de línea. RTCQuicTransport ofrece capacidades muy similares a las de la API de RTCDataChannel, pero usa QUIC en lugar de SCTP como protocolo de transporte. Debido a que RTCQuicTransport es una API independiente, no tiene la sobrecarga de la API de RTCPeerConnection, que incluye la pila de medios en tiempo real.

¿Cómo?

Descripción general de la API

La API tiene 3 abstracciones principales: RTCIceTransport, RTCQuicTransport y RTCQuicStream.

Diagrama de RTCQuicTransport que muestra la arquitectura de la API

RTCIceTransport

ICE es un protocolo para establecer conexiones de igual a igual a través de Internet y se usa en WebRTC en la actualidad. Este objeto proporciona una API independiente para establecer una conexión ICE. Se usa como transporte de paquetes para la conexión QUIC, y RTCQuicTransport lo toma en su constructor.

RTCQuicTransport

Representa una conexión QUIC. Se usa para establecer una conexión QUIC y crear transmisiones QUIC. También expone estadísticas relevantes para el nivel de conexión de QUIC.

RTCQuicStream

Se usa para leer y escribir datos desde o hacia el extremo remoto. Las transmisiones transportan datos de forma confiable y ordenada. Se pueden crear varias transmisiones desde el mismo RTCQuicTransport y, una vez que se escriben datos en una transmisión, se activa un evento "onquicstream" en el transporte remoto. Las transmisiones ofrecen una forma de distinguir diferentes datos en la misma conexión QUIC. Algunos ejemplos comunes pueden ser el envío de archivos separados en transmisiones independientes, pequeños fragmentos de datos en transmisiones diferentes o diferentes tipos de contenido multimedia en transmisiones independientes. Los RTCQuicStream son ligeros, se multiplexan a través de una conexión QUIC y no causan bloqueos de cabeza de línea en otros RTCQuicStream.

Configuración de la conexión

El siguiente es un ejemplo para configurar una conexión QUIC entre pares. Al igual que RTCPeerConnection, la API de RTCQuicTransport requiere el uso de un canal de señalización seguro para negociar los parámetros de la conexión, incluidos sus parámetros de seguridad. RTCIceTransport negocia sus parámetros de ICE (ufrag y contraseña), así como los RTCIceCandidate.

Diagrama de RTCQuicTransport que muestra la arquitectura de la API

Perspectiva del cliente:

const iceTransport = new RTCIceTransport();
const quicTransport = new RTCQuicTransport(iceTransport);
// Signal parameters, key and candidates.
signalingChannel.send({
  iceParams: iceTransport.getLocalParameters(),
  quicKey: quicTransport.getKey(),
});
iceTransport.onicecandidate = e => {
  if (e.candidate) {
    signalingChannel.send({candidate: e.candidate});
  }
};

// When remote parameters are signaled, start connection.
signalingChannel.onMessage = async ({iceParams, candidate}) => {
  if (iceParams) {
    iceTransport.start(iceParams);
    quicTransport.connect();
  } else if (candidate) {
    iceTransport.addRemoteCandidate(candidate);
  }
};

Perspectiva del servidor:

const iceTransport = new RTCIceTransport();
const quicTransport = new RTCQuicTransport(iceTransport);
// Signal parameters, key and candidates.
signalingChannel.send({
  iceParams: iceTransport.getLocalParameters(),
});
iceTransport.onicecandidate = e => {
  if (e.candidate) {
    signalingChannel.send({candidate: e.candidate});
  }
};

// When remote parameters are signaled, start connection.
signalingChannel.onMessage = async ({iceParams, quicKey, candidate}) => {
  if (iceParams && quicKey) {
    iceTransport.start(iceParams);
    quicTransport.listen(quicKey);
  } else if (candidate) {
    iceTransport.addRemoteCandidate(candidate);
  }
};

Transferencia de datos

La transferencia de datos se puede lograr con las APIs de RTCQuicStream para leer y escribir:

RTCQuicStreamReadResult readInto(Uint8Array data);
void write(RTCQuicStreamWriteParameters data);
Promise<void> waitForWriteBufferedAmountBelow(unsigned long amount);
Promise<void> waitForReadable(unsigned long amount);

Almacenamiento en búfer

Las promesas que muestran los métodos waitFor* permiten almacenar datos en búfer cuando JavaScript está ocupado. La contrapresión se aplica al lado de envío cuando el búfer de lectura se llena en el lado de recepción. El lado de envío tiene un búfer de escritura que se puede llenar cuando se aplica la contrapresión y, por lo tanto, el lado de escritura también tiene un método waitForWriteBufferedAmountBelow para permitir que se espere espacio en el búfer para escribir. Puedes encontrar más información para escribir o leer datos en la documentación para desarrolladores.

Entrega no solicitada o poco confiable

Si bien un RTCQuicStream solo admite el envío de datos de forma confiable y ordenada, la entrega no confiable o no ordenada se puede lograr por otros medios. Para la entrega desordenada, se pueden enviar pequeños fragmentos de datos en flujos separados, ya que los datos no están ordenados entre los flujos. Para una entrega poco confiable, se pueden enviar fragmentos pequeños de datos con finish establecido en verdadero, seguido de una llamada a reset() en la transmisión después de un tiempo de espera. El tiempo de espera debe depender de la cantidad de retransmisiones que se deseen antes de descartar los datos.

¿Cuándo?

La prueba de origen comenzará en la versión 73 de Chrome y estará disponible hasta la versión M75 inclusive. Después de esto, finalizará la prueba de origen. En función de los comentarios y el interés, realizaremos los cambios adecuados y, luego, enviaremos la API, continuaremos con una nueva prueba de origen de esta API o la descontinuaremos.

¿Dónde?

Navegador Chrome en todas las plataformas, excepto iOS

¿Qué más?

Comentarios

Uno de los objetivos principales de la prueba de origen es recibir comentarios de los desarrolladores. Nos interesa lo siguiente:

  • ¿Qué te permite esta API?
  • ¿En qué se diferencia esta API de otras APIs de transporte de datos (WebSocket o RTCDataChannel de WebRTC)? ¿Cómo podría mejorar?
  • Rendimiento
  • Ergonomía de la API

Regístrate para la prueba de origen

  1. Solicita un token para tu origen.
  2. Agrega el token a tus páginas. Existen dos maneras de proporcionar este token en cualquier página de tu origen:
    • Agrega una etiqueta <meta> origin-trial al encabezado de cualquier página. Por ejemplo, puede verse de la siguiente manera: <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • Si puedes configurar tu servidor, también puedes proporcionar el token en las páginas con un encabezado HTTP Origin-Trial. El encabezado de respuesta resultante debería ser similar al siguiente: Origin-Trial: TOKEN_GOES_HERE

Especificación web

El borrador de especificaciones avanzó a la API en la prueba de origen, lo que incluye lo siguiente:

  • Transmisiones unidireccionales que están más alineadas con las transmisiones de WHATWG
  • Inhabilita las retransmisiones
  • Datagramas (próximamente)

Nos interesa implementar la especificación completa y más (incluida la compatibilidad con transmisiones de WHATWG), pero primero queremos escuchar tus comentarios.

Seguridad

La seguridad en el protocolo de enlace QUIC se aplica mediante el uso de una clave precompartida para establecer una conexión QUIC P2P encriptada. Esta clave debe indicarse a través de un canal fuera de banda seguro con garantías de confidencialidad e integridad. Ten en cuenta que la clave se expondrá a JavaScript.

Ataque activo

A diferencia de DTLS-SRTP, que solo requiere integridad para indicar la huella dactilar del certificado, la señalización de la clave precompartida requiere integridad y confidencialidad. Si el PSK se ve comprometido (por ejemplo, por el servidor en el canal de señalización), un atacante activo podría realizar un ataque de intermediario contra el protocolo de enlace QUIC.

Estado actual

Paso Estado
1. Crea una explicación Completar
**2a. Especificación de RTCQuicTransport ** **En curso**
**2b. Especificación de RTCIceTransport ** **En curso**
**3. Recopilar comentarios y iterar en el diseño** **En curso**
4. Prueba de origen Comienza en Chrome 73.
5. Lanzamiento No se inició

Vínculos útiles