Temu duga backend: Bagaimanakah anda akan mereka bentuk titik akhir penyerapan WebRTC WHIP yang selamat?

Gesaan dan konteks

Anda memerlukan titik akhir WHIP (WebRTC-HTTP Ingestion Protocol) untuk pengekod atau pengeluar media. Klien menghantar tawaran application/sdp dengan HTTP POST; pelayan merundingkan ICE dan DTLS serta mengembalikan jawapan SDP. Terangkan API, kitaran hayat sesi, pengesahan, perlindungan sumber, dan kebolehcerapan. Andaikan penyerapan media satu hala; rakaman dan pengekodan trans (transcoding) adalah di luar skop.

Perkara yang dinilai oleh penemu duga

• Sama ada sumber pengisyaratan HTTP dan sumber media WebRTC dimodelkan secara berasingan.
• Sama ada satu POST membawa kepada urutan konkrit untuk pengesahan, had, had masa tamat (timeout), dan pembersihan.
• Sama ada calon memahami sempadan antara HTTPS, ICE, DTLS-SRTP, dan API pelayar dan bukannya menganggap WHIP sebagai pengangkutan media semata-mata.
• Sama ada percubaan semula, penciptaan pendua, sesi separa terbuka (half-open), dan SDP berniat jahat diliputi.

Soalan penjelasan

• Adakah penerbit merupakan pengekod terkawal atau pengguna terbuka? Bolehkah kelayakan bersifat jangka pendek dan untuk aliran tunggal?
• Adakah titik akhir ini bersifat serantau atau pelbagai rantau? Bolehkah keadaan sesi berpindah antara rantau?
• Adakah kependaman rendah merupakan keutamaan, atau kelengkapan rakaman dan kebolehmain semula mesti dijamin?
• Adakah trickle ICE atau sambungan WHIP lain akan disokong, dan siapakah yang memiliki perundingan serta kebenarannya?

Jawapan 30 saat

Saya akan membahagikan titik akhir kepada get laluan pengesahan, satah kawalan sesi, dan nod media WebRTC. Get laluan mengesahkan kelayakan jangka pendek, had permintaan, dan kuota penyewa (tenant) sebelum menghantar tawaran SDP kepada perkhidmatan sesi. Perkhidmatan memperuntukkan sumber yang terhad, melengkapkan ICE/DTLS, dan mengembalikan 201 Created, jawapan SDP, dan Location sesi. Setiap perundingan yang tidak lengkap mesti melepaskan sumber; DELETE adalah idempoten, dan had dikenakan bagi setiap penyewa dan sumber. Saya akan mengukur pengisyaratan HTTP, keadaan ICE/DTLS, dan kependaman paket media pertama secara berasingan dan bukannya menggunakan kejayaan POST sebagai metrik ketersediaan.

Penyelesaian langkah demi langkah

1. Tetapkan sempadan protokol. WHIP melakukan satu pertukaran tawaran/jawapan HTTP; WebRTC membawa media selepas itu. W3C mendedahkan kawalan pelayar, manakala pelayan masih mengendalikan ICE, DTLS, dan penerimaan media.
2. Lakukan pemeriksaan kos rendah dahulu. Sebelum memperuntukkan ICE atau nod media, periksa HTTPS, pengesahan, status penyewa, Content-Type: application/sdp, saiz permintaan, kebenaran saluran, dan kuota kadar. Penolakan tidak boleh mencetuskan penghuraian SDP yang mahal atau peruntukan sambungan.
3. Modelkan sumber sesi. Gunakan URL sesi rawak yang tidak boleh disenaraikan (non-enumerable) dengan pending → connected → closing → closed. Penciptaan mengembalikan 201 Created, Location, dan jawapan SDP; ralat harus dapat didiagnosis tanpa mendedahkan topologi dalaman.
4. Batasi kerja separa terbuka. Tetapkan tarikh akhir yang berasingan untuk penghuraian SDP, pembentukan ICE/DTLS, dan paket media pertama. RFC 9725 memberi amaran tentang banjir POST: penyerang dengan kelayakan boleh memaksa peruntukan dan menunggu timeout ICE/DTLS. Kuat kuasakan had kadar pinggir, kuota keserentakan sesi, dan penambakan semula timeout.
5. Kendalikan percubaan semula dan pemadaman. Percubaan semula rangkaian boleh menghantar tawaran yang sama lebih daripada sekali. Ikatkan kelayakan kepada saluran atau kunci keidempotanan; jika kesamaan tidak dapat dibuktikan, cipta sesi baharu hanya di bawah had keserentakan. Jadikan DELETE /session idempoten dan kembalikan keadaan terminal yang sama pada panggilan berulang.
6. Lindungi pengangkutan dan kelayakan. RFC 9725 memerlukan HTTPS untuk mengekalkan model keselamatan WebRTC. Jauhkan kelayakan daripada rentetan pertanyaan (query strings) dan log hanya pengecam sesi yang di-hash. Nod media harus menerima kebenaran jangka pendek daripada perkhidmatan sesi dan bukannya kunci saluran yang disalin secara meluas.
7. Rundingkan sambungan secara eksplisit. Jika trickle ICE atau peristiwa pelayan disokong, iklankan keupayaan tersebut melalui mekanisme seperti Link; klien tidak boleh menganggap setiap pelayan WHIP menyokongnya. Jika sambungan gagal, kembali kepada pertukaran asas atau tamatkan secara eksplisit.
8. Uji sempadan kesediaan sebenar. Jejaki penerimaan POST peringkat penyewa, kegagalan penghuraian SDP, kejayaan ICE, masa persediaan DTLS, kependaman media pertama, penambakan semula timeout, dan kependaman DELETE. Suntik POST pendua, SDP bersaiz lebih, ICE yang tidak dapat dihubungi, permulaan semula nod, dan pembatalan kelayakan.

Contoh jawapan

Saya pada mulanya akan merangka ini sebagai titik akhir satah kawalan: HTTP POST menyerahkan tawaran SDP kepada perkhidmatan sesi, manakala WebRTC membawa media selepas itu. Get laluan mengesahkan HTTPS, kelayakan jangka pendek, kebenaran saluran, jenis kandungan, saiz, dan keserentakan penyewa sebelum menghuraikan SDP; setiap penolakan berlaku sebelum sumber media diperuntukkan. Permintaan yang berjaya akan mencipta sesi non-enumerable, mengembalikan 201 Created, Location, dan jawapan, serta memasuki keadaan menunggu (pending) bertempoh. Jika ICE atau DTLS tidak pernah selesai, perkhidmatan menambak semula calon dan nod supaya sesi separa terbuka tidak menghabiskan kapasiti. DELETE adalah idempoten, dan kelayakan jangka pendek berserta kunci keidempotanan mengehadkan percubaan semula. Saya akan memisahkan metrik HTTP, ICE/DTLS, dan media pertama, kemudian melakukan ujian beban terhadap banjir POST, SDP berniat jahat, permulaan semula, dan pembatalan kelayakan untuk membuktikan keselamatan dan pemulihan.

Kesilapan biasa

• Menganggap WHIP sebagai saluran media → Keadaan ICE, DTLS, dan nod hilang daripada reka bentuk → pisahkan satah kawalan dan satah media.
• Memperuntukkan nod penuh pada setiap POST → Permintaan berniat jahat mengumpulkan kerja separa terbuka → lakukan pemeriksaan murah dan kuota berperingkat terlebih dahulu.
• Hanya menggunakan had kadar global → Satu penyewa atau saluran memberi kesan kepada semua orang → hadkan mengikut penyewa, kelayakan, saluran, dan sumber.
• Mencatat log SDP mentah → Alamat dan topologi mungkin bocor → rekodkan ringkasan (digest), kelas ralat, dan ID korelasi.
• Menjadikan DELETE tidak idempoten → Percubaan semula mencipta perlumbaan pembersihan dan ralat 404 yang bising → tentukan keadaan terminal dan respons yang boleh diulang.
• Mengembalikan HTTP 200 untuk setiap hasil → Klien tidak dapat membezakan antara penciptaan, penolakan, dan percubaan semula → gunakan status semantik dan badan ralat yang selamat.

Soalan susulan dan jawapan

Penyerang mempunyai kelayakan yang sah dan terus menghantar POST. Bagaimanakah anda melindungi perkhidmatan?

Ikatkan kelayakan kepada penyewa, saluran, dan tempoh luput; gunakan baldi token (token bucket) dan had siling keserentakan di bahagian pinggir, kemudian hadkan sesi menunggu dan jumlah masa menunggu dalam satah kawalan. Batalkan kelayakan yang berulang kali melepasi ambang dan simpan bukti audit.

ICE berjaya tetapi DTLS tidak pernah berjaya. Adakah anda mencuba semula atau melaporkan kejayaan?

Kejayaan ICE bukan bermakna kesediaan media. Kekalkan sesi dalam keadaan menunggu sehingga DTLS dan syarat media pertama dipenuhi; apabila timeout, tutup sesi, kembalikan kelas kegagalan yang boleh dicuba semula, dan lepaskan calon serta nod.

Klien menghantar tawaran SDP yang sama sebanyak dua kali. Bagaimanakah anda mengelakkan penyerapan pendua?

Wajibkan kunci keidempotanan jangka pendek dan ikatkannya kepada kelayakan, saluran, dan ringkasan tawaran. Kembalikan sesi asal untuk pendua yang terbukti. Jika kesetaraan tidak dapat dibuktikan, cipta sesi baharu hanya dalam kuota keserentakan.

Bolehkah sesi WHIP berpindah ke rantau lain semasa gangguan perkhidmatan berlaku?

Sesi ICE/DTLS yang telah terbentuk secara amnya tidak boleh dipindahkan secara telus. Titik akhir baharu harus mengeluarkan URL sesi baharu, klien harus menghantar POST sekali lagi, dan sesi lama harus dilepaskan melalui timeout atau DELETE yang eksplisit. Keadaan kelayakan yang direplikasi tidak boleh meluaskan skop pendedahan.