Perintah dan cakupan
Klien seluler dapat menjangkau HTTPS dengan andal, tetapi suara, game, dan probe real-time bergantung pada UDP. Desain proksi yang memungkinkan klien membuat terowongan (tunnel) HTTP ke host UDP target, mencakup siklus hidup, penerusan (forwarding), otorisasi, batas laju (rate limits), DNS, failover, dan fallback.
RFC 9298 mendefinisikan CONNECT-UDP dan templat proksi. RFC 9297 mendefinisikan HTTP Datagrams dan Capsule Protocol masing-masing untuk data yang tidak andal (unreliable) dan informasi kontrol yang andal (reliable). Jawaban yang kuat memisahkan semantik protokol, sumber daya proksi, dan kebijakan keamanan; TLS saja tidak mencegah penyalahgunaan.
Hal yang dievaluasi pewawancara
- Membedakan pembuatan terowongan, penerusan, dan penutupan untuk CONNECT-UDP.
- Menjelaskan batasan antara HTTP/3 Datagrams dan Capsules, termasuk fallback.
- Mendesain allowlist target, kebijakan port, otorisasi pengguna, dan kuota penyewa (tenant).
- Menangani DNS, batas waktu (timeouts), percobaan ulang (retries), sesi setengah terbuka (half-open sessions), dan failover.
- Menentukan metrik bandwidth, konkurensi, kehilangan paket (loss), latensi, penyalahgunaan, dan biaya.
- Menyatakan bahwa proksi tidak dapat menambahkan semantik keandalan UDP, pengurutan, atau enkripsi end-to-end.
Pertanyaan klarifikasi
- Apakah klien dan proksi sama-sama mendukung HTTP/3 Datagrams, atau apakah HTTP/2 juga harus berfungsi?
- Apakah targetnya adalah jaringan perusahaan, media real-time, atau Internet terbuka? Model risikonya berbeda.
- Apakah klien menyediakan nama host, dan apakah proksi menyelesaikan DNS? Apa persyaratan privasi dan masa pakainya?
- Berapa banyak terowongan, bita, dan aliran UDP konkuren yang boleh digunakan oleh satu penyewa? Apakah perutean regional diperlukan?
- Berapa periode idle maksimum, ukuran paket, dan durasi sesi?
Jawaban 30 detik
Saya akan membatasi proksi hanya untuk penyewa terotentikasi dan kumpulan target yang eksplisit, lalu membuat sesi dengan CONNECT-UDP. Capsules membawa kontrol yang andal; HTTP/3 Datagrams membawa data UDP jika didukung. Jika tidak, proksi akan beralih ke enkapsulasi yang andal atau menolak permintaan, tanpa mengklaim latensi yang setara. Bidang data (data plane) menerapkan token bucket penyewa, batas konkurensi, dan batas waktu idle, sementara resolver yang terkontrol mengikat hasil DNS ke sesi tersebut. Failover hanya membangun kembali status yang dapat diputar ulang (replayable). Saya akan memvalidasi latensi p99, kehilangan paket, keberhasilan penyiapan, penggunaan sumber daya, tingkat penolakan, dan peringatan penyalahgunaan.
Desain langkah demi langkah
1. Sesi dan mesin status (state machine)
Klien mengirimkan CONNECT-UDP untuk host dan port target. Proksi mengotentikasi identitas, kebijakan, dan kuota, menyelesaikan target, serta membuat sesi. Status harus mencakup otorisasi tertunda (pending authorization), terhubung (connected), pengosongan (draining), dan ditutup (closed), masing-masing dengan batas waktu dan kode alasan sehingga sesi setengah terbuka tidak menahan sumber daya tanpa batas.
CONNECT / .well-known/masque/udp/example.test/443 HTTP/3
Host: proxy.exampleImplementasi harus mengikuti templat permintaan dan aturan pengkodean RFC 9298; cuplikan kode hanya menyampaikan maksudnya.
2. Memisahkan bidang kontrol dan data
Capsule Protocol cocok untuk kontrol sesi yang andal, kesalahan, dan pemberitahuan penutupan. HTTP/3 Datagrams cocok untuk data UDP yang tidak memerlukan transmisi ulang. Petakan setiap Datagram ke soket UDP yang sesuai dan batasi ukuran paket, kedalaman antrean, dan lonjakan (burst). Jika jalur tidak memiliki dukungan Datagram, pilih secara eksplisit enkapsulasi yang andal atau kembalikan pesan tidak didukung daripada menyembunyikan latensi dan biaya CPU.
3. Otorisasi dan kebijakan target
Validasi kredensial berumur pendek, status penyewa, dan pengikatan perangkat sebelum menerapkan allowlist berdasarkan nama host, rentang IP, port, dan tujuan. Blokir tujuan loopback, privat, metadata, dan berisiko tinggi. Selesaikan DNS dengan resolver terkontrol, catat versi resolusi dan TTL, serta cegah resolusi ulang melintasi batas penyewa secara diam-diam.
4. Batasan, kuota, dan biaya
Batasi terowongan, paket per detik, laju bita, durasi sesi, dan waktu idle per penyewa. Gunakan token bucket pada ingress maupun egress, dengan ambang batas keselamatan node global. Lacak CPU proksi, soket kernel, antrean, bandwidth egress, dan biaya per sesi; hanya membatasi jumlah permintaan HTTP tidak akan membatasi aliran UDP yang berumur panjang.
5. Kegagalan dan fallback
Catat alasan berbeda untuk kegagalan penyiapan, target yang tidak dapat dijangkau, batas waktu DNS, dan kelebihan beban. Sesi baru dapat mencoba lagi pada node yang sehat. Data UDP yang sudah dikirim umumnya tidak aman untuk diputar ulang (replay), sehingga failover harus memulihkan status kontrol atau membiarkan protokol tingkat atas membuat sesi baru. Jika Datagram tidak didukung, pilih enkapsulasi yang andal atau kegagalan eksplisit dan ukur jalur-jalur tersebut secara terpisah.
6. Observabilitas dan operasi keamanan
Untuk setiap sesi, catat penyewa, node proksi, versi kebijakan, alasan penyiapan dan penutupan, bita, paket, estimasi kehilangan data, latensi p50/p95/p99, dan peristiwa throttling. Jangan pernah mencatat kredensial lengkap atau muatan (payload) sensitif. Deteksi pemindaian port, konsentrasi target, lonjakan amplifikasi, dan perebutan sumber daya antar-penyewa, dengan pencabutan cepat berdasarkan penyewa, target, atau wilayah.
7. Peluncuran dan penerimaan
Lakukan uji coba canary pada wilayah tetap dan target dalam allowlist, bandingkan jalur langsung, Datagram, dan fallback. Uji ketahanan terhadap kehilangan data, pengurutan ulang (reordering), restart proksi, perubahan DNS, sesi setengah terbuka, dan lalu lintas berlebih. Gerbang rilis harus mencakup keberhasilan penyiapan, p99 real-time, kehilangan data, sumber daya per sesi, penolakan palsu, dan latensi peringatan penyalahgunaan. Perketat kebijakan atau nonaktifkan jalur saat ambang batas keamanan atau sumber daya terlampaui.
Contoh jawaban yang kuat
Saya akan membangun proksi terotentikasi yang dibatasi untuk kumpulan target yang eksplisit. Setelah CONNECT-UDP, proksi memvalidasi kredensial, target, dan kuota, menyelesaikan DNS melalui resolver terkontrol, dan membuat sesi. Capsules membawa kontrol; HTTP/3 Datagrams membawa data UDP yang tidak dapat diputar ulang jika tersedia. Setiap sesi memiliki batas ukuran paket, antrean, laju, idle, dan masa pakai.
Kebijakan egress memblokir port privat, loopback, metadata, dan berisiko tinggi, sementara token bucket melindungi kedua arah. Sesi baru dapat melakukan failover; data UDP yang dikirim tidak diputar ulang secara otomatis. Saya akan mengamati keberhasilan penyiapan, latensi p99, kehilangan data, sumber daya, biaya, pemindaian, dan amplifikasi. Pengujian canary membandingkan jalur Datagram, fallback, dan langsung, dengan gerbang keamanan dan sumber daya yang mampu menonaktifkan fitur tersebut.
Kesalahan umum
- Mengatakan "menaruh UDP di dalam HTTPS" tanpa semantik terowongan → pisahkan CONNECT-UDP, Capsules, dan Datagrams.
- Memperlakukan proksi sebagai transport yang andal → keandalan dan pengurutan tetap menjadi tanggung jawab lapisan atas.
- Mengizinkan tujuan arbitrer → gunakan allowlist host dan port serta blokir rentang khusus.
- Hanya membatasi permintaan HTTP → batasi juga terowongan, paket, bita, masa pakai, dan waktu idle.
- Memutar ulang semua data UDP setelah kegagalan → pulihkan hanya status kontrol yang dapat diputar ulang dan biarkan lapisan atas terhubung kembali.
- Hanya mengukur latensi rata-rata → sertakan metrik p99, kehilangan data, penolakan, sumber daya, dan penyalahgunaan.
Pertanyaan lanjutan dan tanggapan
Bagaimana jika HTTP/2 tidak dapat membawa HTTP/3 Datagrams?
Pilih enkapsulasi yang andal, transport bergaya polling, atau penolakan eksplisit sesuai dengan beban kerja. Ukur latensi, CPU, dan bandwidth secara terpisah; jangan mengklaim kesetaraan dengan Datagram yang tidak andal.
Bagaimana Anda mencegah SSRF?
Periksa IP yang diselesaikan setelah DNS dan sebelum terhubung, blokir rentang loopback, link-local, privat, metadata, dan di luar kebijakan, serta tangani DNS rebinding. Ikat versi kebijakan ke sesi dan buat agar dapat dicabut.
Siapa yang mencoba mengirim ulang paket UDP yang hilang?
Proksi melaporkan observasi transport tetapi tidak memutar ulang paket aplikasi. Protokol tingkat atas dengan semantik idempoten dan urutan yang memutuskan percobaan ulang; media real-time dapat membuang atau memperbaiki data sebagai gantinya.
Bagaimana restart proksi memulihkan sesi?
Lebih baik lakukan otentikasi ulang dan sesi baru. Jika status kontrol harus tetap ada, pulihkan hanya status berumur pendek yang dapat diverifikasi tanpa data yang tidak dapat diputar ulang, dan segera kosongkan soket lama.
Bagaimana Anda menunjukkan bahwa batasan tidak menyebabkan penolakan palsu?
Bandingkan penolakan dan keberhasilan berdasarkan penyewa, wilayah, target, dan versi klien. Tetapkan anggaran kesalahan penolakan (error-rejection budget) dan putar ulang lonjakan beban, sesi panjang, dan kegagalan node untuk memverifikasi perilaku kuota.