Wawancara umum: Bagaimana Anda mengelola prioritas yang dimultipleks dengan send group WebTransport?

Perintah dan konteks

Satu sesi WebTransport harus mengirimkan pratinjau langsung, pesan kontrol, dan berkas berukuran besar. Pratinjau membutuhkan latensi rendah, pesan kontrol harus tiba tepat waktu, dan berkas dapat mengalah dalam penggunaan bandwidth. Gunakan WebTransportSendGroup, sendOrder, dan getStats() untuk merancang kebijakan pengiriman, termasuk batasan prioritas, kongesti, penyambungan ulang, peramban yang tidak didukung, dan penanganan kesalahan.

MDN menjelaskan send group sebagai kumpulan stream dan datagram yang prioritas pengiriman relatifnya ditentukan oleh sendOrder; alokasi bandwidth di berbagai grup yang berbeda ditentukan oleh implementasi (implementation-defined). Antarmuka ini masih bersifat eksperimental. Artikel ini merangkum materi publik dan tidak mengklaim sebagai pertanyaan wawancara khusus perusahaan tertentu.

Apa yang sedang diuji oleh pewawancara

Pewawancara ingin melihat apakah Anda dapat membedakan urutan relatif di dalam grup dari keadilan antar grup, memetakan prioritas bisnis ke antrean yang dapat diobservasi, dan menjelaskan perbedaan antara datagram yang tidak andal (unreliable) dan stream berurutan yang andal (reliable). Jawaban yang kuat menyebutkan createSendGroup(), meneruskan sendGroup saat membuat stream, sendOrder, getStats() tingkat grup, kontrol kongesti, dan deteksi kapabilitas; jawaban yang lemah hanya mengatakan "memberi bobot pada pesan-pesan penting".

Pertanyaan untuk diklarifikasi terlebih dahulu

• Data mana yang boleh di-drop (dibuang), dan mana yang harus andal, berurutan, serta tahan lama (durable)?
• Berapa target latensi, target throughput berkas, dan usia antrean maksimum?
• Apakah prioritas bersifat tetap untuk sesi tersebut atau diubah oleh tindakan pengguna?
• Apakah peramban target mendukung send group, dan apakah fallback dapat mengekspresikan semantik bisnis yang sama?

Jawaban 30 detik

"Saya akan memisahkan pesan kontrol yang andal, pratinjau real-time yang toleran terhadap kehilangan data (lossy), dan transfer berkas latar belakang ke dalam anggota-anggota eksplisit. Anggota yang membutuhkan pengurutan relatif berbagi send group yang sama, dengan sendOrder menempatkan kontrol dan pratinjau mendahului berkas; ini bukan jaminan bandwidth lintas grup. Pengirim membatasi antrean dan ukuran item, mengamati antrean dan penyelesaian melalui getStats(), membuang pratinjau yang sudah usang, dan menjeda berkas saat terjadi kongesti. Jika tidak didukung, pengirim beralih ke koneksi terpisah atau penjadwal aplikasi sambil tetap menjaga keandalan pesan kontrol."

Solusi langkah demi langkah

Mulailah dengan batasan keandalan. Gunakan stream yang andal untuk kontrol, otorisasi, dan konfirmasi akhir; datagram dapat membawa pratinjau langsung yang dapat dibuang; stream yang andal dapat membawa berkas dengan prioritas rendah. Send group menyelesaikan urutan pengiriman relatif di antara para anggotanya. Send group tidak mengubah berbagai grup yang berbeda menjadi antrean berbobot yang dapat diprediksi atau melakukan percobaan ulang (retry) tingkat bisnis.

Setelah membuat grup, kaitkan stream pengiriman atau stream datagram yang dapat ditulis dengannya dan atur sendOrder pada anggota. Dokumentasikan hubungan numerik dalam protokol sehingga implementasi tidak berselisih mengenai apakah nilai yang lebih besar atau lebih kecil yang menang. Hanya anggota yang berpartisipasi dalam pengurutan ketat dalam grup yang sama yang dibandingkan; urutan yang tidak disetel ditentukan oleh implementasi.

const group = transport.createSendGroup();
const control = await transport.createUnidirectionalStream({
  sendGroup: group,
  sendOrder: 30,
});
const preview = transport.datagrams.createWritable({
  sendGroup: group,
  sendOrder: 20,
});
const archive = await transport.createUnidirectionalStream({
  sendGroup: group,
  sendOrder: 1,
});

Aplikasi tetap membutuhkan anggaran (budget): batasi ukuran dan usia datagram pratinjau, serta gabungkan (coalesce) status terbaru untuk setiap objek; potongan berkas membutuhkan pembatalan, percobaan ulang, dan catatan titik pemeriksaan (checkpoint). Ketika antrean mendekati batasnya, buang pratinjau usang terlebih dahulu dan jeda berkas, tetapi pertahankan pesan kontrol. Gunakan konfirmasi tanda terima (acknowledgement) dan kunci idempoten untuk pesan-pesan penting; urutan kirim yang tinggi tidak menjamin pengiriman pasti sampai.

Kontrol kongesti adalah preferensi transport, bukan SLA bisnis yang ketat. congestionControl dapat mengekspresikan preferensi latensi rendah atau throughput tinggi, tetapi hasilnya bergantung pada implementasi dan kondisi jaringan. Pilih preferensi saat membuat koneksi, lalu gunakan metrik aplikasi untuk mengurangi frekuensi pratinjau atau menjeda pekerjaan latar belakang; jangan mengklaim jaminan latensi hanya dari satu opsi.

Gunakan getStats() grup dan metrik tingkat anggota untuk mengamati antrean, pengiriman, drop, percobaan ulang, dan latensi penyelesaian. Catat dimensi untuk grup, jenis pesan, jaringan, dan versi sesi, membedakan antara "belum terkirim", "datagram hilang", dan "penerima lambat". Saat menyambung ulang, buat grup baru, pulihkan status stream yang andal, dan bangun kembali pratinjau yang dapat dibuang dari snapshot otoritatif alih-alih menggunakan kembali objek stream yang sudah usang.

Deteksi kapabilitas sebelum membuka sesi. Jika send group tidak tersedia, stream kontrol inti harus tetap berfungsi; gunakan koneksi andal yang terpisah atau antrean aplikasi. Jangan memblokir login, otorisasi, atau pengiriman formulir hanya demi mempertahankan pratinjau visual. Sebelum meluncurkan antarmuka eksperimental ke produksi, sediakan kohort peramban, sakelar peluncuran (rollout switch), dan jalur pemutus darurat (kill path).

Contoh jawaban yang kuat

Saya akan memisahkan pesan kontrol, pratinjau langsung, dan transfer berkas ke dalam anggota pengiriman yang terpisah, memilih stream atau datagram sesuai dengan kebutuhan keandalan. Anggota yang membutuhkan urutan relatif berbagi satu send group: kontrol mendapatkan sendOrder tertinggi, pratinjau berikutnya, dan berkas terendah; anggota tanpa urutan berada di luar perbandingan ketat. Urutan grup bersifat relatif, dan keadilan antar grup ditentukan oleh implementasi, jadi saya tidak akan menyajikannya sebagai kuota bandwidth.

Aplikasi mengontrol anggaran, pembatalan, idempotensi, dan kedaluwarsa: saat kongesti terjadi, aplikasi menggabungkan atau membuang pratinjau lama dan menjeda berkas, sementara pesan kontrol tetap mempertahankan konfirmasi tanda terima yang andal. congestionControl mengekspresikan preferensi, dan getStats() mengukur antrean dan latensi penyelesaian. Penyambungan ulang membangun kembali grup dan memulihkan data dari snapshot. Peramban yang tidak didukung tetap mempertahankan jalur kontrol yang andal dan menurunkan kualitas atau menonaktifkan pratinjau. Saya akan memantau drop, latensi, dan keberhasilan tugas berdasarkan grup dan jenis pesan.

Kesalahan umum

• Gejala → Memperlakukan sendOrder sebagai bobot bandwidth lintas grup; mengapa gagal → API mendefinisikan urutan pengiriman relatif di dalam grup; perbaikan → Jadwalkan lintas grup di dalam aplikasi dan ukur hasilnya.
• Gejala → Mengganti konfirmasi tanda terima yang andal dengan prioritas tinggi; mengapa gagal → Urutan pengiriman tidak menjamin penerimaan; perbaikan → Gunakan stream yang andal, konfirmasi tanda terima, dan idempotensi untuk pesan penting.
• Gejala → Terus mengantrekan setiap pratinjau dan berkas selama kongesti; mengapa gagal → Latensi dan memori menjadi tidak terbatas; perbaikan → Tetapkan anggaran, gabungkan status terbaru, dan jeda transfer latar belakang.
• Gejala → Menggunakan kembali objek stream lama setelah tersambung ulang; mengapa gagal → Objek tersebut milik sesi yang telah kedaluwarsa; perbaikan → Bangun kembali grup, pulihkan status otoritatif, dan berlangganan kembali.
• Gejala → Menjadikan API eksperimental sebagai satu-satunya saluran; mengapa gagal → Perbedaan peramban memblokir tindakan inti; perbaikan → Deteksi kapabilitas, luncurkan secara bertahap, dan pertahankan fallback yang andal.

Pertanyaan lanjutan dan jawaban

Apa perbedaan antara prioritas grup dan prioritas lintas grup?

Di dalam satu send group, stream atau datagram yang berpartisipasi dibandingkan berdasarkan sendOrder; grup yang berbeda diharapkan menerima perlakuan yang adil, tetapi pembagian pastinya ditentukan oleh implementasi. Untuk pembobotan lintas grup, jadwalkan antrean atau koneksi terpisah di dalam aplikasi dan validasi dengan metrik.

Mengapa urutan pengiriman yang tinggi tidak cukup untuk melindungi pratinjau?

Prioritas mengubah urutan antrean; itu tidak mengubah sifat datagram yang tidak andal atau menjamin pemrosesan oleh penerima. Pratinjau tetap membutuhkan aturan kedaluwarsa, penggabungan, dan pembuangan (drop). Fakta-fakta kontrol memerlukan transport yang andal, konfirmasi tanda terima, dan durabilitas.

Bagaimana Anda tahu bahwa menjeda berkas membantu?

Lacak panjang antrean berkas, latensi pratinjau, latensi penyelesaian kontrol, dan keberhasilan tugas. Lanjutkan jika latensi kontrol membaik sementara pratinjau memenuhi targetnya; lanjutkan pengiriman berkas dalam batas anggaran saat kondisi jaringan atau prioritas bisnis berubah, guna menghindari kelaparan sumber daya (starvation) yang tidak terbatas.

Apa fallback ketika send group tidak didukung?

Pertahankan stream kontrol yang andal dan navigasi inti terlebih dahulu. Rute pratinjau melalui jalur data terpisah, stream yang andal, atau tanpa pratinjau sama sekali. Pertahankan protokol pesan dan aturan pembatalan yang sama sehingga otorisasi, pengiriman data, dan semantik kesalahan tetap utuh.