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 pembanding jarak jauh menggunakan protokol QUIC. Layanan ini ditujukan untuk kasus penggunaan peer-to-peer sehingga digunakan dengan RTCIceTransport API mandiri untuk membuat koneksi peer-to-peer melalui ICE. Data dipindahkan dengan andal dan berurutan (lihat bagian di bawah untuk mengetahui detail tentang pengiriman yang tidak berurutan & tidak dapat diandalkan). Karena merupakan transport data dua arah yang generik, ini dapat digunakan untuk game, transfer file, transportasi media, pengiriman pesan, dll.

Mengapa?

API transportasi data tingkat rendah yang canggih dapat memungkinkan aplikasi (seperti komunikasi real-time) melakukan hal-hal baru di web. Anda dapat melakukan pengembangan di atas API, membuat solusi Anda sendiri, mendorong batas kemampuan yang dapat dilakukan dengan koneksi peer-to-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 untuk beralih ke API dengan level yang lebih rendah, dan bereksperimen lebih awal dengan hal ini sangat berharga.

Mengapa QUIC?

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

Bagaimana caranya?

Ringkasan API umum

API ini memiliki 3 abstraksi utama, 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. Library ini digunakan sebagai transportasi paket untuk koneksi QUIC, dan RTCQuicTransport membawanya dalam konstruktornya.

RTCQuicTransport

Menampilkan koneksi QUIC. Atribut ini digunakan untuk membuat koneksi QUIC dan membuat streaming QUIC. Laporan ini juga menampilkan statistik yang relevan untuk tingkat koneksi QUIC.

RTCQuicStream

Digunakan untuk membaca dan menulis data ke/dari sisi jarak jauh. Aliran data membawa data secara andal dan berurutan. Beberapa streaming dapat dibuat dari RTCQuicTransport yang sama dan setelah data ditulis ke streaming, peristiwa tersebut akan mengaktifkan peristiwa "onquicstream" pada transportasi jarak jauh. Aliran menawarkan cara untuk membedakan data yang berbeda pada koneksi QUIC yang sama. Contoh umumnya adalah mengirim file terpisah di stream terpisah, potongan data kecil di streaming yang berbeda, atau berbagai jenis media di streaming yang terpisah. RTCQuicStream bersifat ringan, di-multiplex 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 (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 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 sibuk. Tekanan balik diterapkan ke sisi kirim saat buffer baca penuh di sisi penerima. Sisi kirim memiliki buffering tulis yang dapat mengisi saat tekanan kembali diterapkan sehingga sisi tulis memiliki metode waitForWriteBufferedAmountBelow juga untuk memungkinkan ruang tunggu di buffer untuk menulis. Informasi selengkapnya tentang menulis/membaca data dapat ditemukan di dokumentasi developer lebih lanjut.

Pengiriman yang Tidak Sesuai Urutan/Tidak Dapat Diandalkan

Meskipun RTCQuicStream hanya mendukung pengiriman data dengan andal dan berurutan, pengiriman yang tidak dapat diandalkan/tidak berurutan dapat dilakukan melalui cara lain. Untuk pengiriman yang tidak berurutan, seseorang dapat mengirim potongan data kecil di aliran yang terpisah karena data tidak diurutkan di antara aliran. Untuk pengiriman yang tidak stabil, seseorang dapat mengirim potongan data kecil dengan penyelesaian ditetapkan ke true, diikuti dengan memanggil reset() pada aliran data setelah waktu tunggu. Waktu tunggu harus bergantung pada jumlah transmisi ulang yang diinginkan sebelum data dibuang.

Kapan?

Uji coba origin akan dimulai di versi Chrome 73, dan akan tersedia hingga dan termasuk versi M75. Setelah ini, uji coba origin akan berakhir. Berdasarkan masukan dan minat, kami akan membuat perubahan yang sesuai dan mengirimkan API, melanjutkan dengan 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 untuk mendapatkan masukan dari Anda, para developer. Kami tertarik pada:

  • Apa yang dapat diberikan API ini untuk Anda?
  • Bagaimana cara API ini meningkatkan API transmisi data lainnya (WebSocket atau RTCDataChannel WebRTC)? Bagaimana cara meningkatkannya?
  • Performa
  • Ergonomi API

Mendaftar ke uji coba origin

  1. Minta token untuk origin Anda.
  2. Tambahkan token ke halaman Anda. Ada dua cara untuk memberikan token ini pada halaman mana pun di origin Anda:
    • Tambahkan tag origin-trial <meta> ke bagian head halaman mana pun. Misalnya, tampilannya mungkin seperti berikut: <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • Jika dapat mengonfigurasi server, Anda juga dapat menyediakan token di halaman menggunakan header HTTP Origin-Trial. Header respons yang dihasilkan akan terlihat seperti ini: Origin-Trial: TOKEN_GOES_HERE

Spesifikasi Web

Spesifikasi draf telah melampaui API dalam uji coba origin, termasuk:

  • Aliran searah yang lebih sesuai dengan aliran GETWG
  • Menonaktifkan transmisi ulang
  • (Segera hadir) datagram

Kami tertarik untuk menerapkan spesifikasi lengkap dan seterusnya (termasuk dukungan 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 P2P QUIC terenkripsi. Kunci ini perlu diberi sinyal melalui saluran keluar yang aman dari band dengan jaminan kerahasiaan dan integritas. Perhatikan bahwa kunci tersebut akan diekspos ke JavaScript.

Serangan Aktif

Tidak seperti DTLS-SRTP, yang hanya memerlukan integritas untuk memberi sinyal sidik jari sertifikat, sinyal ke kunci yang telah dibagikan 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. Buat penjelasan Selesai
**2a. Spesifikasi RTCQuicTransport ** **Dalam Proses**
**2b. Spesifikasi RTCIceTransport ** **Dalam Proses**
**3. Kumpulkan masukan & iterasi desain** **Dalam Proses**
4. Uji coba origin Dimulai di Chrome 73
5. Luncurkan Not started

Link Bermanfaat