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

Co?

RTCQuicTransport to nowa platforma internetowa Interfejs API, który umożliwia wymianę dowolnych danych ze zdalnymi połączeniami równorzędnymi za pomocą QUIC protokołu. Jest przeznaczona do zastosowań peer-to-peer i dlatego jest używana samodzielny, RTCIceTransport API do nawiązywania połączenia peer-to-peer ICE dane są przenoszone niezawodnie i w określonej kolejności (patrz sekcja poniżej); . niestabilna dostawa). Jest to termin ogólny, dwukierunkowego transportu danych, może służyć do grania, przesyłania plików transport medialny, przekaz itp.

Dlaczego?

Zaawansowany interfejs API transportu danych niskiego poziomu umożliwia korzystanie z aplikacji (takich jak czas rzeczywisty) komunikacji), aby tworzyć nowe rzeczy w sieci. Możesz wykorzystać interfejs API, tworzenia własnych rozwiązań i przesuwania granic możliwości, jakie dają podobne rozwiązania. połączeń równorzędnych, na przykład dzięki odblokowanie pokrętła alokacji niestandardowej szybkości transmisji bitów. W dalsza obsługa kodowanych multimediów umożliwi nawet tworzenie do komunikacji wideo z elementami sterującymi niskiego poziomu. Wysiłek NV WebRTC jest przejście na interfejsy API niższego poziomu. cennych informacji.

Dlaczego QUIC?

Protokół QUIC jest potrzebny do komunikacji w czasie rzeczywistym. Platforma opiera się na ma wbudowane szyfrowanie, kontrolę przeciążenia i jest multipleksowany bez blokowanie wiersza. RTCQuicTransport daje bardzo podobne umiejętności: interfejs API RTCDataChannel, ale jego transportem używa QUIC, a nie SCTP protokołu. RTCQuicTransport jest samodzielnym interfejsem API, dlatego nie ma z narzutem na interfejs API RTCPeerConnection, który obejmuje media w czasie rzeczywistym. stosów.

Jak to zrobić?

Ogólne omówienie interfejsu API

Interfejs API zawiera 3 główne abstrakcje: RTCIceTransport oraz RTCQuicTransport i RTCQuicStream.

Diagram RTCQuicTransport przedstawiający architekturę interfejsu API

RTCIceTransport

ICE to protokół do nawiązywania połączeń peer-to-peer przez internet oraz jest używany w WebRTC. Ten obiekt udostępnia samodzielny interfejs API do ustanowienia połączenia ICE. Służy on jako transport pakietów podczas połączenia QUIC, a RTCQuicTransport wykorzystuje go w swoim konstruktorze.

RTCQuicTransport

Reprezentuje połączenie QUIC. Służy do nawiązywania połączenia QUIC tworzyć strumienie QUIC. Udostępnia też istotne statystyki połączenia QUIC na poziomie 300%.

RTCQuicStream

Umożliwia odczyt i zapis danych na zdalnym urządzeniu. Transport strumieniowy aby zawsze i w odpowiedniej kolejności. W ramach jednego kanału można utworzyć wiele strumieni RTCQuicTransport. Zapisując dane w strumieniu, uruchamia się „onquicstream” na zdalnym transporcie. Dzięki transmisjom strumieniowym możesz: rozróżnianie różnych danych w tym samym połączeniu QUIC. Typowe przykłady to wysyłać osobne pliki w osobnych strumieniach, małymi porcjami danych różne strumienie lub różne typy multimediów w osobnych strumieniach. Obiekty RTCQuicStream mają małą wagę, są multipleksowane za pomocą połączenia QUIC nie powodują blokowania nagłówka wiersza dla innych elementów RTCQuicStream.

Konfiguracja połączenia

Poniżej znajduje się przykład konfigurowania połączenia QUIC peer-to-peer. Podobnie jak RTCPeerConnection, interfejs API RTCQuicTransport wymaga użycia i bezpiecznego kanału sygnału do negocjowania parametrów połączenia. w tym jego parametrów zabezpieczeń. RTCIceTransport negocjuje warunki ICE (fragmenty kodu 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 RTCQuicStream API pisanie:

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

Buforowanie

Obietnice zwracane przez metody waitFor* umożliwiają buforowanie danych, gdy Skrypt JavaScript jest zajęty. Ciśnienie wsteczne jest stosowane po stronie wysyłającej, gdy bufor odczytu zostanie zapełniony po stronie odbierania. Strona wysyłająca ma zapis i bufor, który może się wypełnić po zastosowaniu nacisku wstecznego i dlatego strona zapisu ma też metodę waitForWriteBufferedAmountBelow do pozwalają na oczekiwanie na zapis w buforze. Więcej informacji: dotyczące zapisu/odczytu danych można znaleźć w dalszej części dokumentacja.

Niezamówiona/niewiarygodna dostawa

RTCQuicStream obsługuje tylko stabilne i właściwe wysyłanie danych, niestabilną lub niezamówioną dostawę można osiągnąć innymi sposobami. Dla: w ramach niezamówionej dostawy, można wysyłać małe porcje danych w osobnych strumieniach ponieważ dane nie są uporządkowane między strumieniami. W przypadku nierzetelnej dostawy: może wysyłać małe porcje danych z zakończeniem ustawionym na true, a następnie wywołaniem reset() w strumieniu po upływie czasu oczekiwania. Czas oczekiwania powinien być zależny od ile razy jest potrzebna liczba ponownych transmisji przed usunięciem danych.

Kiedy?

Testowanie origin rozpocznie się w Chrome 73 i będzie dostępne od wersji M75 włącznie. Po tym okresie test origin będzie na ich końcu. Na podstawie opinii i zainteresowań wprowadzimy odpowiednie zmiany i przesłać interfejs API, kontynuować testowanie origin tego interfejsu API albo wyłączyć ten 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 Was, dla programistów. Co nas interesuje:

  • Co Ci umożliwia ten interfejs API?
  • Jak ten interfejs API jest wydajniejszy w porównaniu z innymi interfejsami API do przesyłania danych (WebSocket czy RTCDataChannel WebRTC)? Jak można ją ulepszyć?
  • Wyniki
  • Ergonomia interfejsów API

Zarejestruj się, aby wziąć udział w testach origin

  1. Poproś o token dla punktu początkowego.
  2. Dodaj token do swoich stron. Token można podać na 2 sposoby dowolne strony w pierwotnym miejscu:
    • Dodaj tag origin-trial <meta> w nagłówku dowolnej strony. Przykład: 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 podać token również na stronach za pomocą nagłówka HTTP Origin-Trial. Otrzymany nagłówek odpowiedzi powinien wyglądaj na przykład: Origin-Trial: TOKEN_GOES_HERE

Specyfikacja sieciowa

W ramach testowania origin specyfikacja w wersji roboczej jest nadrzędna w stosunku do interfejsu API w tym:

  • Strumienie jednokierunkowe, które są ściślej powiązane ze strumieniami WhatWG
  • Wyłączam ponowne przesyłanie
  • Datagramy (wkrótce)

Jesteśmy zainteresowani wdrożeniem pełnej specyfikacji i nie tylko (w tym ze strumieniami WhatWG), ale najpierw chcę poznać Twoją opinię.

Bezpieczeństwo

Bezpieczeństwo podczas uzgadniania połączenia QUIC jest wymuszane przez użycie wstępnie udostępnionego klucza do nawiązać szyfrowane połączenie P2P QUIC. Ten klucz musi być sygnalizowany bezpieczny kanał pozapasmowy z gwarancją poufności i integralności Pamiętaj, że klucz będzie dostępny dla JavaScriptu.

Aktywny atak

W przeciwieństwie do protokołu DTLS-SRTP, który wymaga integralności do sygnalizowania certyfikatu odcisk palca, sygnalizowanie klucza wstępnie udostępnionego wymaga integralności poufność danych. Jeśli klucz PSK został przejęty (np. serwer w sygnalizacji kanał), aktywny atakujący może przeprowadzić atak typu „man in the middle”. podczas uzgadniania połączenia QUIC.

Obecny stan,

Krok Stan
1. Utwórz wyjaśnienie Zakończono
**2a. Specyfikacja RTCQuicTransport ** **W toku**
**2b. Specyfikacja RTCIceTransport ** **W toku**
**3. Zbieraj opinie iterację projektu** **W toku**
4. Wersja próbna origin Funkcja dostępna w Chrome 73.
5. Uruchom Nie rozpoczęto

Przydatne linki