Petunjuk dan ruang lingkup
Papan tulis kolaboratif memuat kursor, pengeditan batch, dan potongan file. Bandingkan WebTransport dengan WebSocket dan jelaskan bagaimana jaminan pengiriman, pengurutan, kongesti, dukungan browser, dan operasional mendorong pemilihan tersebut.
WebSocket menawarkan saluran pesan dua arah (bidirectional) yang matang. WebTransport menggunakan HTTP/3 dan mengekspos stream satu arah atau dua arah yang andal (reliable) serta datagram yang dapat mengalami loss. Pertanyaan ini menguji pencocokan semantik transport dengan batasan sistem, bukan sekadar mengulang bahwa HTTP/3 lebih cepat.
Apa yang dievaluasi oleh pewawancara
Mencari pemisahan antara data yang harus sampai dan data yang boleh kedaluwarsa; pemahaman tentang pengurutan, backpressure, kongesti, dan penutupan koneksi; serta penilaian jujur terhadap server HTTP/3, sertifikat, proxy, dukungan browser, fallback, dan observabilitas.
Kerangka jawaban 30 detik
"Saya akan mengklasifikasikan datanya terlebih dahulu: pengeditan dan potongan file menggunakan stream dua arah yang andal dengan backpressure; posisi kursor dapat menggunakan datagram karena posisi yang usang tidak memiliki nilai. Jika browser target, gateway, atau server tidak mendukung WebTransport secara andal, saya akan mulai dengan WebSocket dan mempertahankan fallback yang mendeteksi kapabilitas. Kedua jalur memerlukan autentikasi, kuota, heartbeat, penyambungan ulang (reconnect), dan metrik. Saya akan memutuskan berdasarkan data end-to-end terkait loss, latensi, reconnect, dan biaya operasional."
Jawaban mendalam langkah demi langkah
Langkah 1: Tentukan kontrak pengiriman untuk setiap pesan
Pengeditan memerlukan pengiriman yang andal dan terurut, biasanya dengan ID operasi untuk deduplikasi. Potongan file memerlukan stream yang andal, checksum, dan offset yang dapat dilanjutkan (resumable). Status kursor dan pratinjau seret (drag-preview) hanya perlu mempertahankan nilai terbaru dan dapat mentoleransi loss atau ketidakteraturan urutan.
Langkah 2: Pahami batasan WebSocket
WebSocket memiliki model pesan yang sederhana dan matang untuk satu saluran dua arah yang andal. Aplikasi tetap mendefinisikan tipe pesan, backpressure, heartbeat, reconnect, siaran (broadcast), dan pembingkaian (framing) pesan besar. Pesan yang besar dapat mempersulit penjadwalan ketika setiap payload berbagi satu saluran yang sama.
Langkah 3: Pahami kapabilitas WebTransport
WebTransport menggabungkan stream satu arah atau dua arah yang andal dengan datagram yang tidak andal. Stream membawa byte yang terurut; datagram mendukung pembaruan latensi rendah yang mungkin hilang. Implementasi harus memperhatikan kesiapan stream, penutupan, dan error, alih-alih mengasumsikan datagram pasti sampai.
Langkah 4: Berikan masa kedaluwarsa dan deduplikasi pada datagram
Sertakan ID entitas, urutan (sequence), atau stempel waktu (timestamp) di setiap datagram. Penerima membuang status yang usang alih-alih memperlakukan loss sebagai kegagalan bisnis. Pertahankan hanya kursor terbaru per pengguna; kirim analitik atau konfirmasi (acknowledgement) pengeditan melalui stream yang andal.
Langkah 5: Tangani backpressure stream dan pemulihan
Tunggu kesiapan penulisan (writable readiness) dan batasi antrean per sesi. Jeda pembaruan berprioritas rendah atau isolasi klien yang bermasalah saat batas terlampaui. Lakukan checksum pada potongan file dan simpan offset; setelah reconnect, lanjutkan dari potongan terakhir yang dikonfirmasi alih-alih mengulang seluruh file.
Langkah 6: Evaluasi deployment dan kompatibilitas
WebTransport memerlukan server HTTP/3 yang kompatibel dan konfigurasi sertifikat, ditambah validasi proxy, firewall, serta load-balancer. Uji dukungan browser, kegagalan koneksi, penurunan (downgrade) HTTP/3, dan jaringan lintas wilayah sebelum peluncuran. Gunakan fallback ke WebSocket atau HTTP dengan tetap mempertahankan semantik bisnis yang sama.
Langkah 7: Rancang autentikasi dan isolasi sumber daya
Autentikasi sesi dan origin pada saat inisiasi koneksi. Terapkan batas per pengguna dan per tenant pada koneksi, stream, laju datagram, dan byte. Prioritas stream yang dideklarasikan klien bukanlah otorisasi; penulisan file tetap memerlukan izin, checksum, dan catatan audit.
Langkah 8: Putuskan dengan metrik end-to-end
Catat waktu kirim dan tiba, reconnect, error stream, estimasi kehilangan datagram, panjang antrean, CPU, dan bandwidth berdasarkan tipe pesan. Bandingkan kedua transport dan fallback di bawah jaringan nyata, peralihan seluler (mobile handoff), proxy, dan konkurensi.
Pertukaran (trade-off) dan batasan
Satu saluran versus banyak semantik
Satu saluran WebSocket yang andal lebih mudah dipelihara. WebTransport dapat memisahkan stream yang andal dari datagram berlatensi rendah, tetapi meningkatkan kompleksitas protokol, pengujian, dan operasional. Ambil biaya tersebut hanya jika produk membutuhkan kedua semantik tersebut.
Latensi versus kemampuan pemulihan
Datagram mengurangi waktu tunggu tetapi mengharuskan bisnis menerima kehilangan dan kedaluwarsa data. Status kritis harus berada pada stream yang andal dengan ID operasi, checkpoint, dan perlindungan pemutaran ulang (replay protection).
Manfaat protokol baru versus risiko deployment
Kapabilitas HTTP/3 tidak menghilangkan kegagalan yang disebabkan oleh browser atau perangkat jaringan yang tidak didukung. Validasi tingkat koneksi dan fallback dengan peluncuran kecil sebelum memperluas cakupan.
Latihan kegagalan dan evolusi
HTTP/3 tidak tersedia di jaringan perusahaan
Simulasikan pemblokiran proxy atau kegagalan handshake. Pastikan fallback ke WebSocket berlangsung cepat, tidak ada pengeditan kritis yang duplikat atau hilang, dan metrik kegagalan dapat ditindaklanjuti.
Pembaruan kursor menumpuk
Batasi laju datagram dan ciptakan kondisi jaringan lambat. Verifikasi bahwa kursor yang usang dibuang sementara operasi pengeditan tetap andal.
Stream file terputus
Lakukan reconnect setelah gangguan dan verifikasi checksum potongan file, pemulihan offset, dan otorisasi yang diperbarui. Klien tidak boleh menimpa offset sembarangan.
Kesalahan umum dan tindak lanjut
Kesalahan 1: Mengasumsikan WebTransport selalu lebih cepat
Tanyakan tentang keberhasilan koneksi, waktu handshake, dan tingkat fallback pada jaringan target.
Kesalahan 2: Mengirim pengeditan kritis sebagai datagram
Tanyakan bagaimana loss, pengurutan ulang, dan duplikasi ditangani; jawabannya harus memindahkan pengeditan ke stream yang andal dengan ID operasi.
Kesalahan 3: Hanya membahas API browser
Tanyakan bagaimana server HTTP/3, load balancer, sertifikat, proxy, dan observabilitas di-deploy.
Kesalahan 4: Mengabaikan backpressure dan kuota
Tanyakan bagaimana klien yang lambat diisolasi dan bagaimana batas stream serta byte per tenant ditegakkan.
Kesalahan 5: Membuat protokol bisnis kedua untuk fallback
Tanyakan bagaimana WebSocket dan WebTransport mempertahankan kontrak pesan dan semantik idempotensi yang sama.
Tindak lanjut tambahan dan referensi jawaban
Mengapa memisahkan lalu lintas kursor dan pengeditan?
Kursor bersifat sementara dan cepat usang, sehingga loss dapat diterima demi latensi yang lebih rendah. Pengeditan harus andal, terurut, dan dapat dipulihkan, sehingga harus berada pada stream yang andal.
Bagaimana jika WebTransport tidak tersedia?
Uji kapabilitas terlebih dahulu, lalu lakukan fallback ke WebSocket atau HTTP sambil mempertahankan autentikasi, ID pesan, reconnect, dan konfirmasi bisnis.
Bagaimana Anda membuktikan bahwa pilihan tersebut berhasil?
Bandingkan latensi, estimasi loss, reconnect, antrean, CPU, bandwidth, dan fallback pada kelompok jaringan nyata, serta verifikasi bahwa operasi kritis tidak hilang atau terduplikasi.