Wawancara backend: Bagaimana Anda merancang endpoint ingest WebRTC WHIP yang aman?

Petunjuk dan konteks

Anda memerlukan endpoint WHIP (WebRTC-HTTP Ingestion Protocol) untuk encoder atau produser media. Klien mengirimkan offer application/sdp dengan HTTP POST; server menegosiasikan ICE dan DTLS lalu mengembalikan answer SDP. Jelaskan API, siklus hidup sesi, autentikasi, perlindungan resource, dan observabilitas. Asumsikan ingest media satu arah; perekaman dan transcoding berada di luar cakupan.

Hal yang dievaluasi pewawancara

• Apakah resource pensinyalan HTTP dan resource media WebRTC dimodelkan secara terpisah.
• Apakah satu POST mengarah pada urutan konkret untuk autentikasi, batasan, batas waktu (timeout), dan pembersihan.
• Apakah kandidat memahami batas antara HTTPS, ICE, DTLS-SRTP, dan API browser daripada memperlakukan WHIP sebagai transport media.
• Apakah percobaan ulang (retry), pembuatan duplikat, sesi setengah terbuka (half-open), dan SDP berbahaya tercakup.

Pertanyaan klarifikasi

• Apakah publisher merupakan encoder terkontrol atau pengguna terbuka? Bisakah kredensial berumur pendek dan bersifat single-stream?
• Apakah endpoint bersifat regional atau multi-wilayah? Bisakah status sesi berpindah antar-wilayah?
• Apakah latensi rendah merupakan prioritas, atau kelengkapan rekaman dan kemampuan pemutaran ulang (replayability) harus dijamin?
• Apakah trickle ICE atau ekstensi WHIP lainnya akan didukung, dan siapa yang mengelola negosiasi serta otorisasi ekstensi tersebut?

Jawaban 30 detik

Saya akan membagi endpoint menjadi gateway autentikasi, control plane sesi, dan node media WebRTC. Gateway memverifikasi kredensial berumur pendek, batas permintaan, dan kuota tenant sebelum meneruskan offer SDP ke layanan sesi. Layanan ini mengalokasikan resource terbatas, menyelesaikan ICE/DTLS, dan mengembalikan 201 Created, answer SDP, serta Location sesi. Setiap negosiasi yang tidak lengkap harus melepaskan resource; DELETE bersifat idempoten, dan batasan berlaku per tenant serta sumber. Saya akan mengukur pensinyalan HTTP, status ICE/DTLS, dan latensi paket media pertama secara terpisah alih-alih menggunakan keberhasilan POST sebagai metrik ketersediaan.

Solusi langkah demi langkah

1. Tetapkan batasan protokol. WHIP melakukan satu pertukaran offer/answer HTTP; WebRTC membawa media setelahnya. W3C mengekspos kontrol browser, sementara server tetap menangani ICE, DTLS, dan penerimaan media.
2. Lakukan pemeriksaan ringan terlebih dahulu. Sebelum mengalokasikan ICE atau node media, periksa HTTPS, autentikasi, status tenant, Content-Type: application/sdp, ukuran permintaan, otorisasi saluran, dan kuota laju (rate quota). Penolakan tidak boleh memicu parsing SDP yang mahal atau alokasi koneksi.
3. Modelkan resource sesi. Gunakan URL sesi acak yang tidak dapat dihitung (non-enumerable) dengan pending → connected → closing → closed. Pembuatan mengembalikan 201 Created, Location, dan answer SDP; kesalahan harus dapat didiagnosis tanpa mengekspos topologi internal.
4. Batasi pekerjaan setengah terbuka. Tetapkan tenggat waktu terpisah untuk parsing SDP, pembentukan ICE/DTLS, dan paket media pertama. RFC 9725 menyoroti POST flooding: penyerang dengan kredensial dapat memaksa alokasi dan menunggu timeout ICE/DTLS. Terapkan batas laju edge, kuota konkurensi sesi, dan reklamasi timeout.
5. Tangani percobaan ulang dan penghapusan. Percobaan ulang jaringan dapat mengirim offer yang sama lebih dari sekali. Ikat kredensial ke saluran atau kunci idempotensi; jika kesamaan tidak dapat dibuktikan, buat sesi baru hanya di bawah batas konkurensi. Buat DELETE /session menjadi idempoten dan kembalikan status terminal yang sama pada pemanggilan berulang.
6. Lindungi transport dan kredensial. RFC 9725 mewajibkan HTTPS untuk menjaga model keamanan WebRTC. Jauhkan kredensial dari query string dan catat hanya pengidentifikasi sesi yang telah di-hash. Node media harus menerima otorisasi berumur pendek dari layanan sesi daripada kunci saluran yang disalin secara luas.
7. Negosiasikan ekstensi secara eksplisit. Jika trickle ICE atau server event didukung, iklankan kemampuan tersebut melalui mekanisme seperti Link; klien tidak boleh berasumsi bahwa setiap server WHIP mendukungnya. Pada kegagalan ekstensi, lakukan fallback ke pertukaran dasar atau hentikan secara eksplisit.
8. Uji batas kesiapan yang sebenarnya. Lacak penerimaan POST tingkat tenant, kegagalan parsing SDP, keberhasilan ICE, waktu penyiapan DTLS, latensi media pertama, reklamasi timeout, dan latensi DELETE. Uji dengan menginjeksi POST duplikat, SDP berukuran terlalu besar, ICE yang tidak dapat dijangkau, restart node, dan pencabutan kredensial.

Contoh jawaban

Pertama-tama saya akan membingkai ini sebagai endpoint control-plane: HTTP POST menyerahkan offer SDP ke layanan sesi, sementara WebRTC membawa media setelahnya. Gateway memverifikasi HTTPS, kredensial berumur pendek, izin saluran, tipe konten, ukuran, dan konkurensi tenant sebelum mem-parsing SDP; setiap penolakan terjadi sebelum resource media dialokasikan. Permintaan yang berhasil akan membuat sesi non-enumerable, mengembalikan 201 Created, Location, dan answer, serta memasuki status pending dengan batas waktu. Jika ICE atau DTLS tidak pernah selesai, layanan mereklamasi kandidat dan node sehingga sesi setengah terbuka tidak menghabiskan kapasitas. DELETE bersifat idempoten, dan kredensial berumur pendek serta kunci idempotensi membatasi percobaan ulang. Saya akan memisahkan metrik HTTP, ICE/DTLS, dan media pertama, lalu melakukan uji beban terhadap POST flood, SDP berbahaya, restart, dan pencabutan kredensial untuk membuktikan keamanan sekaligus pemulihan.

Kesalahan umum

• Memperlakukan WHIP sebagai saluran media → Status ICE, DTLS, dan node hilang dari desain → pisahkan control plane dan media plane.
• Mengalokasikan node penuh pada setiap POST → Permintaan berbahaya mengumpulkan pekerjaan setengah terbuka → lakukan pemeriksaan ringan dan kuota bertahap terlebih dahulu.
• Hanya menggunakan batas laju global → Satu tenant atau saluran memengaruhi semua orang → batasi berdasarkan tenant, kredensial, saluran, dan sumber.
• Mencatat SDP mentah → Alamat dan topologi dapat bocor → catat digest, kelas kesalahan, dan ID korelasi.
• Membuat DELETE tidak idempoten → Percobaan ulang menyebabkan race condition pembersihan dan error 404 yang bising → tentukan status terminal dan respons yang dapat diulang.
• Mengembalikan HTTP 200 untuk setiap hasil → Klien tidak dapat membedakan antara pembuatan, penolakan, dan percobaan ulang → gunakan status semantik dan error body yang aman.

Pertanyaan lanjutan dan jawaban

Penyerang memiliki kredensial yang valid dan terus melakukan POST. Bagaimana Anda melindungi layanan?

Ikat kredensial ke tenant, saluran, dan masa kedaluwarsa; terapkan token bucket dan batas atas konkurensi di edge, lalu batasi sesi pending dan total waktu tunggu di control plane. Cabut kredensial yang berulang kali melewati ambang batas dan pertahankan bukti audit.

ICE berhasil tetapi DTLS tidak pernah berhasil. Apakah Anda mencoba lagi atau melaporkan keberhasilan?

Keberhasilan ICE bukan berarti kesiapan media. Pertahankan sesi dalam status pending hingga DTLS dan kondisi media pertama terpenuhi; saat timeout, tutup sesi, kembalikan kelas kegagalan yang dapat dicoba lagi, dan lepaskan kandidat serta node.

Klien mengirimkan offer SDP yang sama dua kali. Bagaimana Anda menghindari ingest duplikat?

Wajibkan kunci idempotensi berumur pendek dan ikat ke kredensial, saluran, dan digest offer. Kembalikan sesi asli jika terbukti duplikat. Jika kesetaraan tidak dapat dibuktikan, buat sesi baru hanya dalam kuota konkurensi.

Bisakah sesi WHIP berpindah ke wilayah lain selama pemadaman (outage)?

Sesi ICE/DTLS yang telah terbentuk umumnya tidak dapat dipindahkan secara transparan. Endpoint baru harus menerbitkan URL sesi baru, klien harus melakukan POST lagi, dan sesi lama harus dilepaskan melalui timeout atau DELETE eksplisit. Status kredensial yang direplikasi tidak boleh memperluas cakupan eksposur.