Temu duga reka bentuk sistem: Bagaimanakah anda mereka bentuk proksi MASQUE CONNECT-UDP?

Maklum balas dan skop

Klien mudah alih boleh mencapai HTTPS dengan andal, tetapi suara, permainan dan prob masa nyata bergantung pada UDP. Reka bentuk proksi yang membolehkan klien mewujudkan terowong HTTP ke hos UDP sasaran, merangkumi kitaran hayat, pemajuan, pengesahan, had kadar, DNS, failover dan sandaran (fallback).

RFC 9298 mentakrifkan CONNECT-UDP dan templat proksi. RFC 9297 mentakrifkan HTTP Datagrams dan Capsule Protocol masing-masing untuk data tidak andal dan maklumat kawalan andal. Jawapan yang kukuh memisahkan semantik protokol, sumber proksi dan dasar keselamatan; TLS sahaja tidak menghalang penyalahgunaan.

Perkara yang dinilai oleh penemu duga

• Membezakan pembentukan terowong, pemajuan dan penutupan untuk CONNECT-UDP.
• Menerangkan sempadan antara HTTP/3 Datagrams dan Capsules, termasuk sandaran.
• Mereka bentuk senarai dibenarkan sasaran, dasar port, kebenaran pengguna dan kuota penyewa (tenant).
• Mengendalikan DNS, tamat masa (timeouts), percubaan semula, sesi separuh terbuka dan failover.
• Menakrifkan metrik lebar jalur, keserentakan, kehilangan, pendam (latency), penyalahgunaan dan kos.
• Menyatakan bahawa proksi tidak boleh menambah semantik keandalan UDP, penyusunan atau penyulitan hujung ke hujung.

Soalan penjelasan

1. Adakah kedua-dua klien dan proksi menyokong HTTP/3 Datagrams, atau adakah HTTP/2 juga mesti berfungsi?
2. Adakah sasaran tersebut rangkaian perusahaan, media masa nyata atau Internet terbuka? Model risikonya berbeza.
3. Adakah klien menyediakan nama hos, dan adakah proksi menyelesaikan DNS? Apakah keperluan privasi dan jangka hayat?
4. Berapa banyak terowong, bait dan aliran UDP serentak yang boleh digunakan oleh satu penyewa? Adakah penghalaan wilayah diperlukan?
5. Apakah tempoh melahu maksimum, saiz paket dan tempoh sesi?

Jawapan 30 saat

Saya akan mengehadkan proksi kepada penyewa yang disahkan dan set sasaran yang jelas, kemudian mewujudkan sesi dengan CONNECT-UDP. Capsules membawa kawalan yang andal; HTTP/3 Datagrams membawa data UDP apabila disokong. Jika tidak, proksi akan beralih kepada enkapsulasi andal atau menolak permintaan, tanpa mendakwa latensi yang setara. Satah data mengenakan baldi token penyewa, had keserentakan dan tamat masa melahu, manakala penyelesai terkawal mengikat hasil DNS pada sesi tersebut. Failover hanya membina semula keadaan yang boleh dimainkan semula. Saya akan mengesahkan latensi p99, kehilangan, kejayaan persediaan, penggunaan sumber, kadar penolakan dan amaran penyalahgunaan.

Reka bentuk langkah demi langkah

1. Sesi dan mesin keadaan

Klien menghantar CONNECT-UDP untuk hos dan port sasaran. Proksi mengesahkan identiti, dasar dan kuota, menyelesaikan sasaran dan mencipta sesi. Keadaan harus merangkumi kebenaran belum selesai (pending authorization), disambungkan (connected), penyaliran (draining) dan ditutup (closed), setiap satu dengan tamat masa dan kod sebab supaya sesi separuh terbuka tidak memegang sumber selama-lamanya.

CONNECT / .well-known/masque/udp/example.test/443 HTTP/3
Host: proxy.example

Pelaksanaan mesti mengikut templat permintaan dan peraturan pengekodan RFC 9298; coretan ini hanya menyampaikan niat.

2. Mengasingkan satah kawalan dan data

Capsule Protocol sesuai untuk kawalan sesi andal, ralat dan pemberitahuan penutupan. HTTP/3 Datagrams sesuai untuk data UDP yang tidak memerlukan penghantaran semula. Petakan setiap Datagram ke soket UDP yang sepadan dan hadkan saiz paket, kedalaman giliran dan lonjakan (burst). Jika laluan tidak mempunyai sokongan Datagram, pilih enkapsulasi andal secara eksplisit atau kembalikan mesej tidak disokong daripada menyembunyikan kos latensi dan CPU.

3. Kebenaran dan dasar sasaran

Sahkan kelayakan jangka pendek, keadaan penyewa dan pengikatan peranti sebelum menggunakan senarai dibenarkan mengikut nama hos, julat IP, port dan tujuan. Sekat destinasi loopback, peribadi, metadata dan berisiko tinggi. Selesaikan DNS dengan penyelesai terkawal, rekod versi penyelesaian dan TTL, serta elakkan penyelesaian semula daripada melintasi sempadan penyewa secara senyap.

4. Had, kuota dan kos

Hadkan terowong, paket sesaat, kadar bait, tempoh sesi dan masa melahu bagi setiap penyewa. Gunakan baldi token pada kedua-dua masukan (ingress) dan keluaran (egress), dengan ambang keselamatan nod global. Jejaki CPU proksi, soket kernel, giliran, lebar jalur keluaran dan kos bagi setiap sesi; mengehadkan kiraan permintaan HTTP sahaja tidak mengekang aliran UDP yang berpanjangan.

5. Kegagalan dan sandaran

Rekod sebab yang berbeza untuk kegagalan persediaan, sasaran tidak dapat dicapai, tamat masa DNS dan beban lampau. Sesi baharu boleh mencuba semula pada nod yang sihat. Data UDP yang telah dihantar secara amnya tidak selamat untuk dimainkan semula, jadi failover harus memulihkan keadaan kawalan atau membiarkan protokol peringkat atas mewujudkan sesi baharu. Jika Datagram tidak disokong, pilih enkapsulasi andal atau kegagalan eksplisit dan ukur laluan secara berasingan.

6. Kebolehcerapan dan operasi keselamatan

Bagi setiap sesi, rekod penyewa, nod proksi, versi dasar, sebab persediaan dan penutupan, bait, paket, anggaran kehilangan, latensi p50/p95/p99 dan peristiwa pendikit (throttling). Jangan sekali-kali merekod kelayakan penuh atau muatan sensitif. Kesan imbasan port, penumpuan sasaran, lonjakan penguatan (amplification bursts) dan perebutan silang penyewa, dengan pembatalan pantas mengikut penyewa, sasaran atau wilayah.

7. Pelancaran dan penerimaan

Laksanakan ujian canary pada wilayah tetap dan sasaran yang disenarai dibenarkan, membandingkan laluan langsung, Datagram dan sandaran. Uji tekanan kehilangan, penyusunan semula, permulaan semula proksi, perubahan DNS, sesi separuh terbuka dan trafik berlebihan. Pintu pelepasan harus merangkumi kejayaan persediaan, p99 masa nyata, kehilangan, sumber setiap sesi, penolakan palsu dan latensi amaran penyalahgunaan. Ketatkan dasar atau lumpuhkan laluan apabila ambang keselamatan atau sumber dilebihi.

Contoh jawapan yang kukuh

Saya akan membina proksi yang disahkan yang terhad kepada set sasaran yang jelas. Selepas CONNECT-UDP, ia mengesahkan kelayakan, sasaran dan kuota, menyelesaikan DNS melalui penyelesai terkawal dan mencipta sesi. Capsules membawa kawalan; HTTP/3 Datagrams membawa data UDP yang tidak boleh dimainkan semula apabila tersedia. Setiap sesi mempunyai had saiz paket, giliran, kadar, melahu dan jangka hayat.

Dasar keluaran menyekat port peribadi, loopback, metadata dan berisiko tinggi, manakala baldi token melindungi kedua-dua arah. Sesi baharu boleh melakukan failover; data UDP yang dihantar tidak dimainkan semula secara automatik. Saya akan mencerap kejayaan persediaan, latensi p99, kehilangan, sumber, kos, imbasan dan penguatan. Ujian canary membandingkan laluan Datagram, sandaran dan langsung, dengan pintu keselamatan dan sumber yang mampu melumpuhkan ciri tersebut.

Kesilapan biasa

• Menyatakan "letakkan UDP di dalam HTTPS" tanpa semantik terowong → pisahkan CONNECT-UDP, Capsules dan Datagrams.
• Menganggap proksi sebagai pengangkutan yang andal → keandalan dan penyusunan kekal menjadi tanggungjawab lapisan atas.
• Membenarkan destinasi sewenang-wenangnya → gunakan senarai dibenarkan hos dan port serta sekat julat khas.
• Mengehadkan permintaan HTTP sahaja → hadkan juga terowong, paket, bait, jangka hayat dan masa melahu.
• Memainkan semula semua data UDP selepas kegagalan → pulihkan hanya keadaan kawalan yang boleh dimainkan semula dan biarkan lapisan atas menyambung semula.
• Mengukur latensi purata sahaja → sertakan metrik p99, kehilangan, penolakan, sumber dan penyalahgunaan.

Soalan susulan dan respons

Bagaimana jika HTTP/2 tidak dapat membawa HTTP/3 Datagrams?

Pilih enkapsulasi andal, pengangkutan gaya pengundian (polling) atau penolakan eksplisit mengikut beban kerja. Ukur latensi, CPU dan lebar jalur secara berasingan; jangan mendakwa kesetaraan dengan Datagram yang tidak andal.

Bagaimanakah anda menghalang SSRF?

Semak IP yang diselesaikan selepas DNS dan sebelum menyambung, sekat julat loopback, link-local, peribadi, metadata dan luar dasar, serta kendalikan pengikatan semula DNS (DNS rebinding). Ikat versi dasar pada sesi dan jadikannya boleh dibatalkan.

Siapa yang mencuba semula paket UDP yang hilang?

Proksi melaporkan pemerhatian pengangkutan tetapi tidak memainkan semula paket aplikasi. Protokol peringkat atas dengan semantik idempoten dan jujukan yang menentukan percubaan semula; media masa nyata sebaliknya boleh menggugurkan atau membaiki data.

Bagaimanakah permulaan semula proksi memulihkan sesi?

Lebih utamakan pengesahan semula dan sesi baharu. Jika keadaan kawalan mesti dikekalkan, pulihkan hanya keadaan jangka pendek yang boleh disahkan tanpa data yang tidak boleh dimainkan semula, dan salirkan soket lama dengan segera.

Bagaimanakah anda menunjukkan bahawa had tidak menyebabkan penolakan palsu?

Bandingkan penolakan dan kejayaan mengikut penyewa, wilayah, sasaran dan versi klien. Tetapkan belanjawan ralat-penolakan dan mainkan semula lonjakan, sesi panjang dan kegagalan nod untuk mengesahkan tingkah laku kuota.