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

Apa?

RTCQuicTransport adalah API platform web baru yang memungkinkan pertukaran data arbitrer dengan peer jarak jauh menggunakan protokol QUIC. API ini ditujukan untuk kasus penggunaan peer to peer, sehingga digunakan dengan API RTCIceTransport mandiri untuk membuat koneksi peer-to-peer melalui ICE. Data ditransmisikan dengan andal dan berurutan (lihat bagian di bawah untuk mengetahui detail tentang pengiriman yang tidak berurutan & tidak andal). Karena merupakan transpor data dua arah generik, teknologi ini dapat digunakan untuk game, transfer file, transpor media, pesan, dll.

Mengapa?

API transpor data tingkat rendah yang canggih dapat memungkinkan aplikasi (seperti komunikasi real time) melakukan hal-hal baru di web. Anda dapat mem-build di atas API, membuat solusi Anda sendiri, mendorong batas apa yang dapat dilakukan dengan koneksi peer ke peer, misalnya, membuka tombol alokasi kecepatan bit kustom. Di masa mendatang, dukungan lebih lanjut untuk media yang dienkode bahkan dapat memungkinkan pembuatan aplikasi komunikasi video Anda sendiri dengan kontrol tingkat rendah. Upaya NV WebRTC adalah beralih ke API level yang lebih rendah, dan bereksperimen dengan hal ini sejak awal sangatlah berharga.

Mengapa QUIC?

Protokol QUIC diinginkan untuk komunikasi real time. Protokol ini dibuat di atas UDP, memiliki enkripsi bawaan, kontrol kemacetan, dan dimultiplekskan tanpa pemblokiran head of line. RTCQuicTransport memberikan kemampuan yang sangat mirip dengan RTCDataChannel API, tetapi menggunakan QUIC, bukan SCTP, sebagai protokol transpornya. Karena RTCQuicTransport adalah API mandiri, API ini tidak memiliki overhead API RTCPeerConnection, yang mencakup stack media real time.

Bagaimana caranya?

Ringkasan API umum

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

Diagram RTCQuicTransport yang menampilkan arsitektur API

RTCIceTransport

ICE adalah protokol untuk membuat koneksi peer-to-peer melalui internet dan digunakan di WebRTC saat ini. Objek ini menyediakan API mandiri untuk membuat koneksi ICE. Ini digunakan sebagai transpor paket untuk koneksi QUIC, dan RTCQuicTransport mengambilnya dalam konstruktornya.

RTCQuicTransport

Mewakili koneksi QUIC. Ini digunakan untuk membuat koneksi QUIC dan membuat streaming QUIC. Fungsi ini juga mengekspos statistik yang relevan untuk level koneksi QUIC.

RTCQuicStream

Digunakan untuk membaca dan menulis data ke/dari sisi jarak jauh. Streaming mentransmisikan data dengan andal dan teratur. Beberapa aliran data dapat dibuat dari RTCQuicTransport yang sama dan setelah data ditulis ke aliran data, data akan memicu peristiwa “onquicstream” pada transpor jarak jauh. Streaming menawarkan cara untuk membedakan data yang berbeda pada koneksi QUIC yang sama. Contoh umum dapat mengirim file terpisah di seluruh aliran terpisah, potongan kecil data di aliran yang berbeda, atau jenis media yang berbeda di seluruh aliran terpisah. RTCQuicStream bersifat ringan, dimultiplekskan melalui koneksi QUIC, dan tidak menyebabkan pemblokiran head of line ke RTCQuicStream lainnya.

Penyiapan Koneksi

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

Diagram RTCQuicTransport yang menampilkan arsitektur API

Sudut pandang 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 RTCQuicStream API 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 buffering data saat JavaScript sedang sibuk. Tekanan balik diterapkan ke sisi pengiriman saat buffer baca menjadi penuh di sisi penerima. Sisi pengiriman memiliki buffering tulis yang dapat terisi saat tekanan balik telah diterapkan, sehingga sisi tulis juga memiliki metode waitForWriteBufferedAmountBelow untuk memungkinkan menunggu ruang dalam buffering untuk ditulis. Informasi selengkapnya tentang menulis/membaca data dapat ditemukan di dokumentasi developer selanjutnya.

Pengiriman Tidak Terurut/Tidak Andal

Meskipun RTCQuicStream hanya mendukung pengiriman data secara andal dan berurutan, pengiriman yang tidak andal/tidak berurutan dapat dilakukan melalui cara lain. Untuk pengiriman tanpa urutan, Anda dapat mengirim potongan data kecil di aliran terpisah karena data tidak diurutkan di antara aliran. Untuk pengiriman yang tidak dapat diandalkan, seseorang dapat mengirim potongan data kecil dengan finish disetel ke true, diikuti dengan memanggil reset() di streaming setelah waktu tunggu habis. Waktu tunggu harus bergantung pada jumlah pengiriman ulang yang diinginkan sebelum menghapus data.

Kapan?

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

Di mana?

Browser Chrome di semua platform kecuali iOS.

Apa lagi?

Masukan

Salah satu tujuan utama uji coba origin adalah mendapatkan masukan dari Anda, developer. Kami tertarik dengan:

  • Apa yang diaktifkan API ini untuk Anda?
  • Bagaimana API ini meningkatkan API transpor data lainnya (WebSocket atau RTCDataChannel WebRTC)? Bagaimana API ini dapat ditingkatkan?
  • Performa
  • Ergonomi API

Mendaftar 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 mana pun di origin Anda:
    • Tambahkan tag origin-trial <meta> ke header halaman mana pun. Misalnya, tampilannya mungkin terlihat seperti: <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • Jika dapat mengonfigurasi server, Anda juga dapat memberikan token di halaman menggunakan header HTTP Origin-Trial. Header respons yang dihasilkan akan terlihat seperti: Origin-Trial: TOKEN_GOES_HERE

Spesifikasi Web

Draf spesifikasi telah diluncurkan sebelum API dalam uji coba origin, termasuk:

  • Streaming searah yang lebih selaras dengan streaming WHATWG
  • Menonaktifkan transmisi ulang
  • Datagram (Segera hadir)

Kami tertarik untuk menerapkan spesifikasi lengkap dan lebih lanjut (termasuk dukungan streaming WHATWG), tetapi ingin mendengar masukan Anda terlebih dahulu.

Keamanan

Keamanan dalam handshake QUIC diterapkan melalui penggunaan pre-shared key untuk membangun koneksi QUIC P2P terenkripsi. Kunci ini harus diberi sinyal melalui saluran out of band yang aman dengan jaminan kerahasiaan dan integritas. Perhatikan bahwa kunci akan diekspos ke JavaScript.

Serangan Aktif

Tidak seperti DTLS-SRTP, yang hanya memerlukan integritas untuk memberikan sinyal sidik jari sertifikat, memberikan sinyal kunci bersama sebelumnya memerlukan integritas dan kerahasiaan. Jika PSK disusupi (misalnya oleh server di saluran sinyal), penyerang aktif berpotensi melakukan serangan man-in-the-middle terhadap handshake QUIC.

Status saat ini

Langkah Status
1. Membuat penjelasan Selesai
**2a. Spesifikasi RTCQuicTransport ** **Sedang Berlangsung**
**2b. Spesifikasi RTCIceTransport ** **Sedang Berlangsung**
**3. Mengumpulkan masukan & melakukan iterasi pada desain** **Sedang Berlangsung**
4. Uji coba origin Dimulai di Chrome 73.
5. Luncurkan Belum dimulai

Tautan Bermanfaat