Wawancara umum: Bagaimana Alt-Svc memfasilitasi migrasi HTTP/3 yang aman?

Prompt dan cakupan

Sebuah origin HTTPS ingin mengaktifkan HTTP/3 secara bertahap. Server dapat menawarkan layanan yang setara di endpoint lain, tetapi beberapa jaringan memblokir UDP dan klien dapat menyimpan data layanan alternatif yang usang. Jelaskan Alt-Svc dan rancang pemeriksaan sertifikat, caching, fallback, pembatalan (invalidation), dan observabilitas.

Alt-Svc mengiklankan layanan yang setara untuk origin yang sama; ini bukan pengalihan (redirect) dan tidak mengubah URL yang terlihat oleh pengguna. Ini menguji migrasi protokol, bukan asumsi bahwa setiap klien langsung menggunakan HTTP/3.

Hal yang diuji oleh pewawancara

Apakah Anda membedakan Alt-Svc, pengalihan HTTP, dan pengikatan layanan DNS (DNS service binding).
Apakah Anda menjelaskan otoritas origin dan validasi sertifikat TLS untuk endpoint alternatif.
Apakah Anda menangani masa pakai Alt-Svc, pembatalan clear, UDP yang tidak dapat dijangkau, dan fallback.
Apakah Anda mengukur peluncuran (rollout), keberhasilan handshake, versi protokol, dan peristiwa keamanan.

Pertanyaan klarifikasi

Siapa yang mengontrol endpoint alternatif, dan nama host apa saja yang dicakup oleh sertifikatnya?
Apakah klien, CDN, proksi, dan firewall mendukung HTTP/3 dan UDP/443?
Apakah iklan lintas port atau lintas host diperlukan, dan di mana batas origin-nya?
Bagaimana iklan yang buruk akan dicabut dan dihapus dari cache klien?
Apakah metrik keberhasilan berupa tingkat keberhasilan handshake, time to first byte, latensi ekor (tail latency), atau kesalahan?

Jawaban 30 detik

“Alt-Svc memungkinkan origin mengiklankan endpoint alternatif yang setara yang dapat dicoba oleh klien pada koneksi berikutnya; ini bukan pengalihan 3xx dan tidak mengubah URL. Untuk HTTP/3, saya akan memvalidasi sertifikat TLS dan otoritas origin dari endpoint alternatif, memulai dengan ma yang singkat selama pengujian canary, melakukan fallback ke HTTP/2 atau HTTP/1.1 saat UDP gagal, dan mempertahankan jalur pencabutan clear. Saya akan melakukan segmentasi handshake dan tail latency berdasarkan klien, jaringan, dan protokol sebelum memperpanjang masa pakai cache.”

Desain langkah demi langkah

1. Jelaskan peran Alt-Svc

RFC 7838 mendefinisikan header respons Alt-Svc agar klien dapat menemukan layanan alternatif untuk origin yang sama. Klien dapat terus menggunakan URL asli sambil mengubah endpoint transport jika mampu; semantik origin aplikasi dan otorisasi tidak boleh dilewati.

2. Validasi otoritas dan TLS

Nama host atau port alternatif tidak dipercaya hanya karena muncul di header respons. Klien memvalidasi layanan berdasarkan aturan origin dan sertifikat yang dijelaskan oleh RFC 7838. Sertifikat harus mencakup nama yang terhubung, dan operator harus mencegah percampuran lalu lintas antar-penyewa (cross-tenant). Iklan lintas origin memerlukan peninjauan risiko yang lebih tinggi.

3. Iklankan secara bertahap

Kirim Alt-Svc terlebih dahulu ke kohort klien atau regional yang kecil, menggunakan ma (usia maksimum) yang singkat sambil mengukur keberhasilan. Endpoint HTTP/3 dapat menggunakan pengidentifikasi h3; klien lama dapat mengabaikan header dan melanjutkan dengan protokol yang ada. Satu iklan bukanlah jaminan bahwa klien akan meningkatkan versi.

http

HTTP/2 200 OK
Alt-Svc: h3=":443"; ma=300
Cache-Control: private, no-store

4. Tangani kegagalan UDP dan fallback

Firewall perusahaan, jaringan seluler, atau NAT dapat memblokir UDP. Setelah upaya koneksi gagal atau kehabisan waktu (timeout), klien harus kembali ke HTTP/2 atau HTTP/1.1. Permintaan aplikasi tidak boleh diulang hanya karena transport alternatif telah dicoba. Catat upaya protokol dan alasan fallback agar pemblokiran jaringan tidak salah didiagnosis sebagai kegagalan aplikasi.

5. Cabut dan batalkan cache

Jika masalah sertifikat, rute, atau keamanan muncul, kirim Alt-Svc: clear dan hentikan pengiklanan layanan lama. Berakhirnya ma juga membuat klien melakukan penilaian ulang. Jaga agar masa pakai tetap singkat selama pengujian canary dan perpanjang hanya setelah stabil; membersihkan CDN saja tidak menghapus status layanan alternatif di sisi klien.

6. Koordinasikan rekaman DNS HTTPS

Rekaman SVCB/HTTPS RFC 9460 juga dapat memublikasikan parameter pengikatan layanan. Kedua mekanisme ini dapat membantu menemukan HTTP/3, tetapi memiliki propagasi, caching, dan kepemilikan operasional yang berbeda. Tentukan prioritas (precedence), rollback, dan pemantauan konflik agar DNS tidak beralih ke endpoint baru sementara respons HTTP masih mengiklankan endpoint lama.

Contoh jawaban berkualitas tinggi

“Saya akan memperlakukan Alt-Svc sebagai penemuan layanan alternatif untuk origin yang sama, bukan pengalihan. Pertama, validasi sertifikat TLS endpoint, otoritas, dan isolasi penyewa, lalu kirim h3 dengan ma yang singkat ke kohort kecil. Pada kegagalan handshake UDP atau HTTP/3, lakukan fallback ke HTTP/2/1.1 tanpa mengulangi operasi penulisan (write). Untuk masalah konfigurasi atau keamanan, kirim Alt-Svc: clear dan hentikan iklan lama. Ukur handshake, fallback, dan tail latency berdasarkan jaringan, klien, dan protokol; jika rekaman DNS HTTPS juga digunakan, tentukan prioritas konflik dan satu prosedur rollback.”

Kesalahan umum

Memperlakukan Alt-Svc sebagai 301/308 → semantik URL dan cache berubah → jelaskan ini sebagai penemuan layanan.
Melewatkan validasi sertifikat → lalu lintas dapat mencapai layanan yang tidak tepercaya → terapkan pemeriksaan origin dan TLS.
Menggunakan ma yang panjang selama canary → konfigurasi yang buruk akan bertahan lama → mulai dengan durasi singkat dan perpanjang nanti.
Menggagalkan permintaan saat UDP diblokir → kondisi jaringan menyebabkan pemadaman yang seharusnya dapat dihindari → lakukan fallback ke HTTP/2 atau HTTP/1.1.
Hanya membersihkan CDN → klien tetap menyimpan alternatif yang usang → kirim clear dan biarkan masa pakai klien berakhir.

Pertanyaan lanjutan dan tanggapan

Apakah Alt-Svc mengubah URL di bilah alamat browser?

Tidak. Ini mendeskripsikan layanan alternatif untuk origin yang sama sementara aplikasi mempertahankan URL aslinya. Itu adalah perbedaan utama dari pengalihan HTTP.

Mengapa tidak langsung mencoba ulang operasi penulisan setelah HTTP/3 gagal?

Kegagalan upaya transport tidak membuktikan bahwa operasi aplikasi tidak pernah sampai. Gunakan kunci idempoten (idempotency key) atau semantik permintaan eksplisit, dan lakukan fallback dalam konteks operasi yang sama alih-alih membuat ulang sumber daya secara membabi buta.

Apa arti ma=300?

Ini menetapkan usia cache maksimum 300 detik untuk informasi layanan alternatif. Ini bukan durasi koneksi HTTP/3 yang diharuskan dan tidak menjamin bahwa klien akan menggunakan atau mencoba alternatif tersebut selama periode tersebut.