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

¿Qué?

RTCQuicTransport es una nueva plataforma web API que permite el intercambio de datos arbitrarios con pares remotos mediante QUIC protocolo. Se diseñó para casos de uso entre pares y, por lo tanto, se usa con un RTCIceTransport independiente. para establecer una conexión entre pares mediante ICE: Los datos se transportan de manera confiable y en orden (consulta la sección más abajo). para obtener detalles sobre las transacciones una entrega poco confiable). Como es un formato genérico, transporte de datos bidireccional, se puede usar para videojuegos, transferencia de archivos, transporte de medios, mensajería, etc.

¿Por qué?

Una API de transporte de datos potente y de bajo nivel puede habilitar aplicaciones (como datos en tiempo real comunicaciones) para hacer cosas nuevas en la Web. Puedes compilar sobre la API, crear tus propias soluciones, desafiando los límites de lo que se puede hacer con pares a conexiones de intercambio de tráfico, como desbloquear controles personalizados de asignación de tasa de bits. En en el futuro, una mayor compatibilidad con medios codificados podría incluso permitirte crear su propia aplicación de comunicación por video con controles de bajo nivel. Esfuerzo de NV de WebRTC es avanzar hacia APIs de niveles inferiores, y experimentar anticipadamente con esto es valioso.

¿Por qué usar QUIC?

El protocolo QUIC es ideal para comunicaciones en tiempo real. Se basa en de UDP, tiene encriptación integrada, control de congestión y es multiplexado sin el bloqueo de cabeza de línea. RTCQuicTransport brinda capacidades muy similares a las que la API de RTCDataChannel, pero usa QUIC en lugar de SCTP como su protocolo. Como RTCQuicTransport es una API independiente, no tiene la sobrecarga de la API de RTCPeerConnection, que incluye los archivos multimedia en tiempo real en una pila.

¿Cómo?

Descripción general de la API

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

Diagrama de RTCQuicTransport que muestra la arquitectura de la API

RTCIceTransport

ICE es un protocolo para establecer conexiones entre pares por Internet y se usa en WebRTC actualmente. 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 la 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 la conexión QUIC. a nivel de organización.

RTCQuicStream

Se utiliza para leer y escribir datos desde y hacia el lado remoto. Transporte de transmisiones de forma confiable y en orden. Se pueden crear varias transmisiones a partir de la misma RTCQuicTransport y, una vez que se escriben los datos en una transmisión, se activa “onquicstream” en el transporte remoto. Las transmisiones ofrecen una forma de distinguir datos diferentes en la misma conexión QUIC. Algunos ejemplos comunes pueden envían archivos separados a través de transmisiones separadas, pequeños fragmentos de datos en diferentes transmisiones o distintos tipos de contenido multimedia en transmisiones separadas. Los elementos RTCQuicStream son ligeros, se multiplexan a través de una conexión QUIC y No provocan un bloqueo de encabezado de línea para otros objetos RTCQuicStream.

Configuración de la conexión

El siguiente es un ejemplo de la configuración de una conexión QUIC entre pares. Al igual que RTCPeerConnection, la API de RTCQuicTransport requiere el uso de un un canal de señalización seguro para negociar los parámetros de la conexión incluidos sus parámetros de seguridad. RTCIceTransport negocia su ICE parámetros (ufrag y password), así como 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 puede lograrse con las APIs de RTCQuicStream para la lectura y escribiendo:

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

Almacenando en búfer

Las promesas que devuelven los métodos waitFor* permiten almacenar datos en búfer cuando JavaScript está ocupado. Se aplica contrapresión al lado de envío cuando el de lectura se llena en el lado receptor. El lado de envío tiene una función 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 permiten esperar a que haya espacio en el búfer para escribir. Más información sobre la escritura/lectura de datos se puede encontrar en la parte del desarrollador documentación.

Entrega desordenada o poco confiable

Si bien un RTCQuicStream solo admite el envío de datos de forma confiable y en orden, una entrega poco fiable o desordenada se puede lograr por otros medios. Para entrega sin ordenar, se pueden enviar pequeños fragmentos de datos en transmisiones separadas porque los datos no están ordenados entre transmisiones. Para una entrega poco confiable, una puedes enviar pequeños fragmentos de datos con Finish configurado como true, seguido de la llamada reset() en la transmisión después de que se agote el tiempo de espera. El tiempo de espera depende de cuántas retransmisiones se desean antes de descartar los datos.

¿Cuándo?

La prueba de origen comenzará en la versión de Chrome 73 y estará disponible incluida la versión M75. Después de esto, la prueba de origen final. En función de los comentarios y el interés, realizaremos los cambios adecuados enviar la API, continuar con una prueba de origen nueva de la API descontinuar la API.

¿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 tus comentarios. los desarrolladores. Nos interesa lo siguiente:

  • ¿Qué te permite esta API?
  • Cómo mejora esta API con respecto a otras APIs de transporte de datos (¿WebSocket o RTCDataChannel de WebRTC)? ¿Cómo podría mejorar?
  • Rendimiento
  • Ergonomía de las APIs

Regístrate en 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 en tu origen:
    • Agrega una etiqueta origin-trial <meta> al encabezado de cualquier página. Por ejemplo: es posible que se vea algo así: <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 debe verse así: Origin-Trial: TOKEN_GOES_HERE

Especificación web

La especificación de borrador se trasladó por delante de la API en la prueba de origen como:

  • 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 allá (incluida la compatibilidad con la transmisión 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 P2P QUIC encriptada. Se debe indicar esta clave en un canal seguro y fuera de banda con garantías de confidencialidad y de integridad. Ten en cuenta que la clave se expondrá a JavaScript.

Ataque activo

A diferencia de DTLS-SRTP, que solo requiere integridad para indicar el certificado huella digital, se indica la clave precompartida requiere integridad y la confidencialidad. Si la PSK está comprometida (por ejemplo, por el servidor de la canal), un atacante activo podría activar un ataque de intermediario contra el protocolo de enlace QUIC.

Estado actual

Paso Estado
1. Crear explicación Completo
**2a. Especificación de RTCQuicTransport ** **En curso**
**2b. Especificación de RTCIceTransport ** **En curso**
**3. Recopila comentarios y iterar en el diseño** **En curso**
4. Prueba de origen Se inicia en Chrome 73
5. Lanzamiento Sin iniciar

Vínculos útiles