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
.
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
.
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
atauRTCDataChannel
WebRTC)? Bagaimana cara meningkatkannya? - Performa
- Ergonomi API
Mendaftar ke uji coba origin
- Minta token untuk origin Anda.
- 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
- Tambahkan tag
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
- Dokumentasi lebih lanjut
- Penjelasan publik
- Bug pelacakan
- Meminta token uji coba origin
- Cara menggunakan token uji coba origin
- Pembahasan tentang masalah untuk RTCQuicTransport
- Diskusi tentang masalah untuk RTCIceTransport