RTCQuicTransport sta per iniziare una prova dell'origine vicino a te (Chrome 73)

Cosa?

RTCQuicTransport è una nuova piattaforma web API che consente lo scambio di dati arbitrari con peer remoti utilizzando QUIC protocollo. È destinata a casi d'uso peer-to-peer e, pertanto, viene utilizzata un RTCIceTransport indipendente API per stabilire una connessione peer-to-peer ICE. I dati vengono trasferiti in modo affidabile e in ordine (consulta la sezione di seguito per i dettagli su ordini e una distribuzione inaffidabile). Poiché si tratta di un argomento generico, bidirezionale dei dati, può essere usato per giocare, trasferire i file trasporto multimediale, messaggistica ecc.

Perché?

Una potente API di trasporto dati di basso livello può abilitare le applicazioni (come in tempo reale comunicazioni) per fare nuove cose sul web. Puoi basarti sull'API, creando le tue soluzioni, superando i limiti di ciò che si può fare con a connessioni peer, ad esempio sbloccando manopole di allocazione della velocità in bit personalizzate. Nella in futuro, un ulteriore supporto per i contenuti multimediali codificati potrebbe persino consentirti di sviluppare il tuo una propria applicazione di comunicazione video con controlli di basso livello. L'impegno NV di WebRTC è di passare alle API di livello inferiore e sperimentare questo approccio sono preziose.

Perché QUIC?

Il protocollo QUIC è preferibile per le comunicazioni in tempo reale. Si basa su UDP, è integrata con crittografia, controllo della congestione ed è multiplexata senza il blocco "head of line". Il RTCQuicTransport offre funzionalità molto simili a quelle l'API RTCDataChannel, ma utilizza QUIC anziché SCTP come trasporto protocollo. Poiché RTCQuicTransport è un'API autonoma, non dispone l'overhead dell'API RTCPeerConnection, che include i media in tempo reale stack.

Come?

Panoramica generale dell'API

L'API ha 3 astrazioni principali: RTCIceTransport, RTCQuicTransport e RTCQuicStream.

Diagramma RTCQuicTransport che mostra l'architettura dell'API

RTCIceTransport

ICE è un protocollo per stabilire connessioni peer-to-peer su internet e attualmente viene utilizzato in WebRTC. Questo oggetto fornisce un'API autonoma per stabilire una connessione ICE. È utilizzato come trasporto dei pacchetti per la connessione QUIC, e RTCQuicTransport lo prende nel suo costruttore.

RTCQuicTransport

Rappresenta una connessione QUIC. È utilizzato per stabilire una connessione QUIC e creano stream QUIC. Mostra inoltre le statistiche pertinenti per la connessione QUIC. livello.

RTCQuicStream

Utilizzato per leggere e scrivere dati da/verso il lato remoto. Trasporto stream i dati in modo affidabile e in ordine. È possibile creare più stream dallo stesso RTCQuicTransport e, una volta che i dati vengono scritti in un flusso, viene attivato un evento "onquicstream" sul trasporto remoto. Gli stream offrono un modo per distinguere dati diversi sulla stessa connessione QUIC. Gli esempi comuni possono inviare file separati su flussi separati, piccoli blocchi di dati stream diversi o tipi di contenuti multimediali su stream separati. I RTCQuicStream sono leggeri, vengono multiplexati tramite una connessione QUIC e non causano il blocco "head of line" di altri RTCQuicStream.

Configurazione connessione

Di seguito è riportato un esempio per la configurazione di una connessione QUIC peer-to-peer. Come nel caso di RTCPeerConnection, l'API RTCQuicTransport richiede l'utilizzo di una proprietà un canale di segnalazione sicuro per negoziare i parametri della connessione inclusi i parametri di sicurezza. RTCIceTransport negozia l'ICE (ufrag e password), nonché RTCIceCandidate.

Diagramma RTCQuicTransport che mostra l'architettura dell'API

Punto di vista 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);
  }
};

Punto di vista server:

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);
  }
};

Data Transfer

Il trasferimento dei dati può essere eseguito utilizzando le API RTCQuicStream per la lettura e scrivendo:

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

Buffering

Le promesse restituite dai metodi waitFor* consentono il buffering dei dati quando JavaScript è occupato. La contropressione viene applicata al lato di invio quando il buffer di lettura diventa pieno sul lato di ricezione. Il lato invio ha un'istanza di scrittura tampone che può riempire quando è stata applicata la contropressione, e quindi sul lato scrittura ha anche un metodo waitForWriteBufferedAmountBelow per consente di attendere lo spazio in scrittura nel buffer. Ulteriori informazioni su per la scrittura e la lettura dei dati sono disponibili nella documentazione.

Consegna non ordinata/inaffidabile

Mentre RTCQuicStream supporta l'invio di dati solo in modo affidabile e in ordine, la consegna non affidabile/non ordinata può essere ottenuta con altri mezzi. Per una distribuzione non ordinata, è possibile inviare piccoli blocchi di dati in flussi perché i dati non sono ordinati tra gli stream. Per una distribuzione inaffidabile, puoi inviare piccoli blocchi di dati con il completamento impostato su true, seguito dalla chiamata reset() nello stream dopo un timeout. Il timeout deve dipendere da: quante ritrasmissioni si desidera prima di eliminare i dati.

Quando?

La prova dell'origine inizierà nella versione 73 di Chrome e sarà disponibile fino alla versione M75 inclusa. Al termine, la prova dell'origine fine. In base ai feedback e agli interessi, apporteremo le modifiche necessarie e inviare l'API, continuare con una nuova prova dell'origine di questa API oppure interrompere l'API.

Dove?

Browser Chrome su tutte le piattaforme tranne iOS.

Che altro?

Feedback

Uno dei principali obiettivi della prova dell'origine è ricevere un feedback da parte tua, gli sviluppatori. Vogliamo:

  • Che cosa abilita per te questa API?
  • In che modo questa API migliora rispetto ad altre API di trasporto dati? (WebSocket o RTCDataChannel di WebRTC)? Come potrebbe migliorare?
  • Prestazioni
  • Ergonomia delle API

Registrati per la prova dell'origine

  1. Richiedi un token per la tua origine.
  2. Aggiungi il token alle tue pagine. Esistono due modi per fornirlo nelle qualsiasi pagina nella tua origine:
    • Aggiungi un tag origin-trial <meta> all'intestazione di una pagina. Ad esempio: potrebbe avere un aspetto simile a questo: <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • Se puoi configurare il tuo server, puoi anche fornire il token nelle pagine utilizzando un'intestazione HTTP Origin-Trial. L'intestazione della risposta risultante deve avrà il seguente aspetto: Origin-Trial: TOKEN_GOES_HERE

Specifica web

La bozza di specifica è stata spostata rispetto all'API nella prova dell'origine tra cui:

  • Stream unidirezionali maggiormente allineati con gli stream WHATWG
  • Disattivazione delle ritrasmissioni
  • (Disponibile a breve) datagrammi

Ci interessa implementare tutte le specifiche e non solo (incluse supporto per gli stream WHATWG), ma prima voglio ricevere il tuo feedback.

Sicurezza

La sicurezza nell'handshake QUIC viene applicata mediante l'uso di una chiave precondivisa per stabilire una connessione QUIC P2P criptata. Questa chiave deve essere segnalata un canale fuori banda sicuro con garanzie di riservatezza e integrità. Tieni presente che la chiave verrà esposta a JavaScript.

Attacco attivo

A differenza di DTLS-SRTP, che richiede solo l'integrità per segnalare il certificato l'impronta digitale, la segnalazione della chiave precondivisa richiede l'integrità e riservatezza. Se il PSK è compromesso (ad esempio dal server nella canale), un aggressore attivo potrebbe potenzialmente montare un attacco man in the middle rispetto allo handshake QUIC.

Stato attuale

Passaggio Stato
1. Crea messaggio esplicativo Completato
**2a. Specifica RTCQuicTransport ** **In corso**
**2b. Specifiche RTCIceTransport ** **In corso**
**3. Raccogli feedback e iterare il design** **In corso**
4. Prova dell'origine Inizia con Chrome 73.
5. Lancio Non avviato

Link utili