Uruchamiamy wersję próbną RTCQuicTransport w pobliżu (Chrome 73)

Co?

RTCQuicTransport to nowa platforma internetowa API, która umożliwia wymianę dowolnych danych ze zdalnymi połączeniami równorzędnymi za pomocą protokołu QUIC. Służy on do obsługi przypadków użycia peer-to-peer, dlatego jest używany z samodzielnym interfejsem API RTCIceTransport do nawiązywania połączenia peer-to-peer przez ICE. Dane są przesyłane w niezawodny i porządku (szczegóły poniżej znajdziesz w sekcji poniżej). Ponieważ jest to ogólny, dwukierunkowy transport danych, można go używać do gier, przesyłania plików, przesyłania multimediów, przesyłania wiadomości itp.

Dlaczego?

Zaawansowany interfejs API transportu danych niskiego poziomu może umożliwiać aplikacjom (na przykład komunikację w czasie rzeczywistym) z korzystaniem z nowych funkcji w sieci. Możesz tworzyć własne rozwiązania, wykorzystując interfejsy API, przenosząc granice możliwości połączeń peer-to-peer, na przykład odblokowując gałki alokacji niestandardowych szybkości transmisji bitów. W przyszłości spójna obsługa kodowanych multimediów może umożliwić utworzenie własnej aplikacji do komunikacji wideo z niskopoziomowymi elementami sterującymi. Celem NV WebRTC jest przejście na interfejsy API niższego poziomu i wczesne przetestowanie tego rozwiązania jest cenne.

Dlaczego QUIC?

Protokół QUIC jest dobrym rozwiązaniem w przypadku komunikacji w czasie rzeczywistym. Działa na podstawie protokołu UDP, ma wbudowane szyfrowanie, kontrolę nadmiaru i multipleksowanie bez blokowania linii. Interfejs RTCQuicTransport ma bardzo podobne możliwości co interfejs RTCDataChannel API, ale jego protokół transportowy używa QUIC, a nie SCTP. RTCQuicTransport jest samodzielnym interfejsem API, dlatego nie ma narzutu interfejsu API RTCPeerConnection, który obejmuje stos multimediów w czasie rzeczywistym.

Jak to zrobić?

Ogólne omówienie interfejsu API

Interfejs API ma 3 główne abstrakcje: RTCIceTransport, RTCQuicTransport i RTCQuicStream.

Diagram RTCQuicTransport przedstawiający architekturę interfejsu API

RTCIceTransport

ICE to protokół służący do nawiązywania połączeń peer-to-peer przez internet. Obecnie jest używany w WebRTC. Ten obiekt udostępnia samodzielny interfejs API, który umożliwia nawiązanie połączenia ICE. Jest używany jako transport pakietów na potrzeby połączenia QUIC, a RTCQuicTransport pobiera go w swoim konstruktorze.

RTCQuicTransport

Reprezentuje połączenie QUIC. Służy do nawiązywania połączenia QUIC i tworzenia strumieni QUIC. Udostępnia też istotne statystyki na poziomie połączenia QUIC.

RTCQuicStream

Służy do odczytywania i zapisywania danych ze strony zdalnej. Strumienie przesyłają dane w niezawodny i kolejny sposób. Z jednego elementu RTCQuicTransport można utworzyć wiele strumieni. Po zapisaniu danych w strumieniu wywoływane jest zdarzenie „onquicstream” w transporcie zdalnym. Strumienie umożliwiają rozróżnianie różnych danych w ramach tego samego połączenia QUIC. Typowym przykładem może być wysyłanie osobnych plików w oddzielnych strumieniach, małych porcji danych w różnych strumieniach lub różnych typów multimediów w oddzielnych strumieniach. RTCQuicStream są niewielkie, są multipleksowane przez połączenie QUIC i nie powodują blokowania bloków czołowych w innych strumieniach RTCQuicStream.

Konfiguracja połączenia

Poniżej znajdziesz przykład konfigurowania połączenia QUIC peer-to-peer. Podobnie jak RTCPeerConnection, interfejs API RTCQuicTransport wymaga użycia bezpiecznego kanału sygnałów do negocjowania parametrów połączenia, w tym jego parametrów zabezpieczeń. RTCIceTransport negocjuje parametry ICE (ufrag i hasło) oraz RTCIceCandidate.

Diagram RTCQuicTransport przedstawiający architekturę interfejsu API

Perspektywa klienta:

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

Perspektywa serwera:

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

Przenoszenie danych

Dane można przenieść za pomocą interfejsów API RTCQuicStream do odczytywania i zapisywania:

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

Buforuję

Obietnice zwracane przez metody waitFor* umożliwiają buforowanie danych, gdy JavaScript jest zajęty. Obciążenie wsteczne jest stosowane po stronie wysyłania, gdy bufor odczytu jest pełny po stronie odbierania. Po stronie wysyłania znajduje się bufor zapisu, który może zostać uzupełniony po zastosowaniu wstecznego obciążenia. Dlatego też strona zapisu zawiera metodę waitForWriteBufferedAmountBelow, która umożliwia też oczekiwanie na zapis w buforze. Więcej informacji o pisaniu i odczytywaniu danych znajdziesz w dalszej dokumentacji dla programistów.

Niezamówienie lub niepewna dostawa

Protokół RTCQuicStream obsługuje tylko wysyłanie danych w niezawodny i kolejny sposób, natomiast w inny sposób można zapewnić niezawodne lub nieuporządkowane przesyłanie danych. W przypadku przesyłania nieuporządkowanego można wysyłać niewielkie fragmenty danych w osobnych strumieniach, ponieważ nie są one uporządkowane między strumieniami. W przypadku niestabilnego dostarczania możesz wysłać niewielkie fragmenty danych z ustawieniem końca ustawionym na prawda, a potem po upływie czasu oczekiwania wywołać reset() w strumieniu. Limit czasu powinien być uzależniony od liczby ponownych transmisji do przesłania przed usunięciem danych.

Kiedy?

Testowanie origin rozpocznie się w Chrome 73 i będzie dostępne aż do wersji M75. Po tym czasie test origin się zakończy. Na podstawie opinii i zainteresowań wprowadzimy odpowiednie zmiany i wysłamy interfejs API, będziemy kontynuować testy w nowym miejscu docelowym lub wycofamy interfejs API.

Gdzie?

Przeglądarka Chrome na wszystkich platformach oprócz iOS.

Co jeszcze?

Prześlij opinię

Jednym z głównych celów testowania origin jest zebranie opinii od deweloperów. Interesuje nas:

  • Co daje Ci ten interfejs API?
  • W jaki sposób ten interfejs API działa w porównaniu z innymi interfejsami API do transportu danych (WebSocket lub RTCDataChannel WebRTC)? Jak można go ulepszyć?
  • Występy
  • Ergonomia interfejsu API

Zarejestruj się, aby korzystać z testowania origin

  1. Poproś o token dla Twojego źródła.
  2. Dodaj token do swoich stron. Dostępne są 2 sposoby udostępniania go na dowolnych stronach w pierwotnym miejscu:
    • Dodaj tag origin-trial <meta> w nagłówku dowolnej strony. Może to wyglądać np. tak: <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • Jeśli masz możliwość skonfigurowania serwera, możesz też udostępnić token na stronach z wykorzystaniem nagłówka HTTP Origin-Trial. Nagłówek odpowiedzi powinien wyglądać mniej więcej tak: Origin-Trial: TOKEN_GOES_HERE

Specyfikacja sieciowa

W testach origin specyfikacja w wersji roboczej wyprzedziła interfejs API, w tym:

  • Strumienie jednokierunkowe ściślej dopasowane do strumieni WhatWG
  • Wyłączanie ponownego przesyłania
  • Datagramy (już wkrótce)

Chcemy wdrożyć pełną specyfikację i inne funkcje (w tym obsługę strumienia COWG), ale najpierw chcielibyśmy poznać Twoją opinię.

Bezpieczeństwo

Zabezpieczenia w trakcie uzgadniania połączenia QUIC są wymuszane przez użycie wstępnie udostępnionego klucza do nawiązania zaszyfrowanego połączenia P2P QUIC. Ten klucz musi być sygnalizowany przez bezpieczny pozapasmowy kanał z gwarancją poufności i integralności. Pamiętaj, że klucz będzie dostępny dla JavaScriptu.

Aktywny atak

W przeciwieństwie do standardu DTLS-SRTP, który wymaga integralności do sygnalizowania odcisku palca certyfikatu, sygnał, że wstępnie udostępniony klucz jest dostępny, wymaga zachowania integralności i poufności. Jeśli klucz PSK zostanie przejęty (np. przez serwer w kanale sygnału), aktywny atakujący może przeprowadzić atak typu „man in the middle” zamiast uzgadniania połączenia QUIC.

Obecny stan,

Step Stan
1. Utwórz wyjaśnienie Zakończono
**2a. Specyfikacja RTCQuicTransport ** **W toku**
**2b. Specyfikacja transportu RTCIce ** **W toku**
**3. Zbieraj opinie i ponownie ulepszaj projekt** **W toku**
4. Testowanie origin Uruchamia się w Chrome od wersji 73.
5. Uruchom Nie rozpoczęto

Przydatne linki