RTCQuicTransport Akan Segera Hadir untuk Uji Coba Origin di Dekat Anda (Chrome 73)

Apa?

RTCQuicTransport adalah platform web baru API yang memungkinkan pertukaran data arbitrer dengan peer jarak jauh menggunakan QUIC dan berperforma tinggi karena merupakan protokol biner. Dimaksudkan untuk kasus penggunaan peer-to-peer, dan karenanya digunakan dengan RTCIceTransport mandiri untuk membuat koneksi peer-to-peer melalui ICE. Data dipindahkan dengan andal dan berurutan (lihat bagian di bawah untuk detail tentang item yang pengiriman yang tidak dapat diandalkan). Karena ini generik, dua arah, dapat digunakan untuk permainan, transfer file, transportasi media, pesan, dll.

Mengapa?

API transpor data tingkat rendah yang andal dapat mengaktifkan aplikasi (seperti komunikasi) untuk melakukan hal-hal baru di web. Anda dapat membangun di atas API, membuat solusi Anda sendiri, mendorong batas apa yang bisa dilakukan dengan rekan ke koneksi peer, misalnya, membuka tombol alokasi kecepatan bit kustom. Di beberapa di masa depan, dukungan lebih lanjut untuk media yang dienkode bahkan memungkinkan pembuatan aplikasi komunikasi video dengan kontrol tingkat rendah. Upaya NV WebRTC adalah beralih ke API dengan level yang lebih rendah, dan bereksperimen lebih awal dengan hal ini berguna untuk Anda.

Mengapa QUIC?

Protokol QUIC diinginkan untuk komunikasi real time. AI generatif dibuat di atas UDP, memiliki enkripsi bawaan, kontrol kemacetan, dan {i>multiplexed<i} tanpa {i>head of line blocking<i}. RTCQuicTransport memberikan kemampuan yang sangat mirip dengan RTCDataChannel API, tetapi menggunakan QUIC, bukan SCTP sebagai transpornya dan berperforma tinggi karena merupakan protokol biner. Karena RTCQuicTransport adalah API mandiri, API ini tidak memiliki overhead API RTCPeerConnection, yang mencakup informasi media {i>stack<i}.

Bagaimana caranya?

Ringkasan umum API

API ini memiliki 3 abstraksi utama, yaitu RTCIceTransport dan RTCQuicTransport dan RTCQuicStream.

Diagram RTCQuicTransport yang menampilkan arsitektur API

RTCIceTransport

ICE adalah protokol untuk membuat koneksi {i>peer-to-peer<i} melalui internet dan digunakan di WebRTC saat ini. Objek ini menyediakan API mandiri untuk menetapkan koneksi ICE. Ini digunakan sebagai transportasi paket untuk koneksi QUIC, dan RTCQuicTransport akan mengambilnya dalam konstruktornya.

RTCQuicTransport

Menunjukkan koneksi QUIC. Alat ini digunakan untuk menyambung koneksi QUIC dan membuat aliran QUIC. Alat ini juga menampilkan statistik yang relevan untuk koneksi QUIC level organisasi.

RTCQuicStream

Digunakan untuk membaca dan menulis data ke/dari sisi jarak jauh. Transportasi feed data secara andal dan berurutan. Beberapa streaming dapat dibuat dari RTCQuicTransport, dan setelah data ditulis ke stream, data diaktifkan {i>onquicstream<i} pada transportasi jarak jauh. {i>Stream<i} menawarkan cara untuk membedakan data yang berbeda pada koneksi QUIC yang sama. Contoh umum dapat mengirim file terpisah melalui aliran data yang terpisah, potongan kecil data melalui aliran yang berbeda, atau jenis media yang berbeda di aliran terpisah. RTCQuicStream bersifat ringan, di-multiplex melalui koneksi QUIC, dan tidak menyebabkan pemblokiran head of line ke RTCQuicStream lain.

Penyiapan Koneksi

Berikut adalah contoh untuk menyiapkan koneksi QUIC peer-to-peer. Seperti RTCPeerConnection, RTCQuicTransport API memerlukan penggunaan saluran pensinyalan aman untuk menegosiasikan parameter koneksi, termasuk parameter keamanannya. RTCIceTransport menegosiasikan ICE-nya parameter (ufrag dan sandi), serta RTCIceCandidate.

Diagram RTCQuicTransport yang menampilkan arsitektur API

Perspektif klien:

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

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

Transfer Data

Transfer data dapat dilakukan menggunakan API RTCQuicStream untuk membaca dan menulis:

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

Buffering

Promise yang ditampilkan oleh metode waitFor* memungkinkan data buffering saat JavaScript sibuk. Tekanan kembali diterapkan ke sisi kirim ketika {i>read buffer <i}menjadi penuh di sisi penerima. Sisi kirim memiliki operasi tulis {i>buffer<i} yang dapat terisi ketika tekanan balik telah diterapkan, dan karenanya sisi tulis juga memiliki metode waitForWriteBufferedAmountBelow untuk memungkinkan menunggu ruang di {i>buffer<i} untuk menulis. Informasi selengkapnya tentang menulis/membaca data dapat ditemukan di pengembang lebih lanjut dokumentasi.

Pengiriman Tidak Dipesan/Tidak Dapat Diandalkan

Meskipun RTCQuicStream hanya mendukung pengiriman data secara andal dan berurutan, pengiriman yang tidak dapat diandalkan/tidak berurutan dapat dicapai dengan cara lain. Sebagai pengiriman yang tidak berurutan, seseorang dapat mengirim potongan kecil data pada aliran terpisah karena data tidak diurutkan di antara aliran data. Untuk pengiriman yang tidak dapat diandalkan, satu dapat mengirim potongan kecil data dengan {i>finish <i}diset ke true, diikuti dengan memanggil reset() pada streaming setelah waktu tunggu. Waktu tunggu harus bergantung pada berapa banyak transmisi ulang yang diinginkan sebelum data dikurangi.

Kapan?

Uji coba origin akan dimulai pada versi Chrome 73, dan akan tersedia hingga dan termasuk versi M75. Setelah ini, uji coba origin akan berakhir. Berdasarkan masukan dan minat, kami akan melakukan perubahan yang sesuai dan mengirimkan API, melanjutkan dengan uji coba origin baru API ini, atau menghentikan API.

Di mana?

Browser Chrome di semua platform kecuali iOS.

Apa lagi?

Masukan

Salah satu sasaran utama uji coba origin adalah untuk mendapatkan masukan dari Anda, para pengembang. Untuk hal berikut:

  • Apa yang dimungkinkan oleh API ini untuk Anda?
  • Bagaimana API ini meningkatkan API transportasi data lainnya (WebSocket atau RTCDataChannel WebRTC)? Bagaimana cara memperbaikinya?
  • Performa
  • Ergonomi API

Daftar untuk uji coba origin

  1. Minta token untuk origin Anda.
  2. Tambahkan token ke halaman Anda, ada dua cara untuk memberikan token ini di halaman apa pun di origin Anda:
    • Tambahkan tag origin-trial <meta> ke bagian atas halaman mana pun. Misalnya, hal ini mungkin terlihat seperti: <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • Jika Anda dapat mengonfigurasi server, Anda juga dapat memberikan token di halaman menggunakan header HTTP Origin-Trial. {i>Header<i} respons yang dihasilkan harus terlihat seperti: Origin-Trial: TOKEN_GOES_HERE

Spesifikasi Web

Spesifikasi draf telah menggantikan API dalam uji coba origin termasuk:

  • Streaming searah yang lebih selaras dengan streaming WhatWG
  • Menonaktifkan transmisi ulang
  • (Segera hadir) datagram

Kami berminat untuk menerapkan spesifikasi lengkap dan seterusnya (termasuk mendukung streaming WhatWG), tetapi kami ingin mendengar masukan Anda terlebih dahulu!

Keamanan

Keamanan di handshake QUIC diterapkan melalui penggunaan kunci yang telah dibagikan sebelumnya untuk membuat koneksi QUIC P2P yang terenkripsi. Kunci ini perlu diberi sinyal melalui saluran {i>out-of-band<i} yang aman dengan jaminan kerahasiaan dan integritas. Perhatikan bahwa kunci tersebut akan diekspos ke JavaScript.

Serangan Aktif

Tidak seperti DTLS-SRTP, yang hanya membutuhkan integritas untuk memberi sinyal pada sertifikat sidik jari, pemberian sinyal bahwa kunci yang dibagikan sebelumnya membutuhkan integritas dan kerahasiaan. Jika PSK disusupi (misalnya oleh server dalam pensinyalan, penyerang aktif berpotensi melakukan serangan {i>man-in-the-middle<i} terhadap jabat tangan QUIC.

Status saat ini

Langkah Status
1. Buat penjelasan Selesai
**2a. Spesifikasi RTCQuicTransport ** **Dalam Proses**
**2b. Spesifikasi RTCIceTransport ** **Dalam Proses**
**3. Kumpulkan masukan & melakukan iterasi desain** **Dalam Proses**
4. Uji coba origin Dimulai di Chrome 73
5. Luncurkan Belum dimulai

Tautan Bermanfaat