Perintah dan konteks
Sebuah gateway HTTP/3 menangani koneksi jangka panjang dan permintaan termultipleks. Selama proses rollout, gateway harus menolak pekerjaan baru, menyelesaikan permintaan yang telah diterima, dan menutup koneksi dengan aman setelah batas waktu tercapai. Rancang graceful shutdown dengan RFC 9114 GOAWAY dan jelaskan batasannya dengan penutupan koneksi QUIC serta percobaan ulang HTTP.
Hal yang diuji oleh pewawancara
Membedakan GOAWAY, yang membatasi permintaan di masa mendatang, dari CONNECTION_CLOSE, yang mengakhiri koneksi QUIC. HTTP/3 GOAWAY membawa batas ID stream permintaan; server dapat memulainya dengan nilai yang lebih luas dan menyusutkannya ke batas akhir. Cakup stream konkuren, pengetahuan klien tentang permintaan yang belum diproses, idempotensi, propagasi proksi, batas waktu (timeout), dan observabilitas.
Pertanyaan klarifikasi yang perlu diajukan terlebih dahulu
Karakteristik permintaan dan koneksi
Tanyakan tentang long polling, upload, WebTransport, POST non-idempoten, dan reverse proxy. Waktu penyelesaian dan risiko percobaan ulang berbeda menurut jenis stream.
Tujuan pengurasan dan tenggat waktu
Klarifikasi apakah ini pengurasan koneksi, pemeliharaan node, atau isolasi kegagalan. Tetapkan batas waktu pengurasan maksimum, batas waktu penutupan paksa (hard-close), dan ukuran batch rollout; jika tidak, koneksi lama dapat mengonsumsi kapasitas tanpa batas.
Kemampuan klien
Pastikan klien dan proksi memproses GOAWAY, mendukung penyambungan ulang dan migrasi, serta dapat membedakan antara “stream baru ditolak” dan “permintaan dieksekusi tetapi respons hilang.”
Kerangka jawaban 30 detik
“HTTP/3 GOAWAY mengiklankan batas ID stream permintaan; setelah menerimanya, peer tidak boleh membuat permintaan baru di atas batas tersebut. Server pertama-tama mengirimkan nilai yang luas, berhenti menetapkan pekerjaan baru, lalu mengirimkan nilai akhir yang lebih kecil sehingga klien mengetahui permintaan mana yang mungkin belum diterima. Stream yang diterima akan dikuras; setelah batas waktu, server menggunakan QUIC CONNECTION_CLOSE. Klien melakukan percobaan ulang hanya ketika dapat memastikan bahwa permintaan tidak dieksekusi dan operasinya aman untuk diulang.”
Jawaban mendalam langkah demi langkah
Langkah 1: Pisahkan GOAWAY dari CONNECTION_CLOSE
GOAWAY adalah pesan kontrol HTTP/3 yang membatasi ID stream permintaan tertinggi; pesan ini tidak langsung mengakhiri koneksi. CONNECTION_CLOSE mengakhiri QUIC dan dapat menginterupsi permintaan yang sedang aktif. Lakukan pengurasan dengan GOAWAY terlebih dahulu dan tutup hanya pada batas waktu akhir yang ketat.
Langkah 2: Gunakan batas lebar-lalu-sempit
Kirim ID besar yang mencakup permintaan konkuren yang terpantau, berhenti menerima pekerjaan baru, lalu kirim ID akhir yang lebih kecil. Klien tidak boleh mengartikan proses penyusutan ini sebagai izin untuk membuat permintaan baru. Pertahankan urutan dan status control frame agar logika penyambungan ulang bersifat deterministik.
Langkah 3: Tangani permintaan yang diterima, belum dimulai, dan tidak diketahui
Stream yang diterima di bawah batas akhir akan tetap berjalan. Permintaan di atasnya tidak diterima dan dapat dicoba ulang pada koneksi baru. Jika server tidak dapat mengetahui apakah permintaan non-idempoten telah dijalankan, sediakan kunci idempotensi atau pencarian status daripada memutar ulang secara membabi buta.
Langkah 4: Rancang perilaku proksi dan migrasi
Reverse proxy yang menerima GOAWAY dari upstream harus berhenti menetapkan permintaan baru ke koneksi tersebut dan menyebarkan status pengurasan ke downstream. Migrasi koneksi QUIC bukanlah migrasi permintaan; mengubah jalur tidak mentransfer stream HTTP yang sedang dieksekusi secara aman.
Langkah 5: Tetapkan batas waktu pengurasan dan penutupan paksa
Catat waktu GOAWAY, stream aktif terakhir, dan sisa permintaan. Pada batas waktu pengurasan, batalkan stream yang belum selesai; pada waktu penutupan paksa, kirim CONNECTION_CLOSE dan lepaskan koneksi. Batasi jumlah instans yang dikuras sekaligus agar kapasitas tidak anjlok.
Langkah 6: Lindungi percobaan ulang dan efek samping
Coba ulang hanya metode idempoten yang terkonfirmasi belum dieksekusi atau operasi penulisan yang membawa kunci idempotensi, dengan backoff eksponensial dan batas percobaan ulang. Respons yang hilang tidak membuktikan bahwa permintaan tidak dijalankan; pembayaran dan mutasi inventaris memerlukan deduplikasi di sisi server.
Langkah 7: Verifikasi rollout
Dalam deployment canary, masukkan permintaan berdurasi panjang, stream konkuren, penyambungan ulang, penyusutan nilai GOAWAY, propagasi proksi, dan penutupan paksa. Pantau stream baru yang ditolak, durasi pengurasan, stream yang belum selesai, tingkat percobaan ulang, efek samping duplikat, kesalahan koneksi, dan ruang kapasitas tersisa (headroom). Periksa latensi p99 dan tingkat kesalahan di sepanjang proses rollout.
Contoh jawaban berkualitas tinggi
Saya akan berhenti menetapkan koneksi baru, mengirim GOAWAY yang luas untuk menghentikan stream baru, dan kemudian mengirim batas akhir yang lebih kecil setelah mengamati permintaan konkuren. Stream yang diterima di bawah batas akan dikuras; hanya setelah batas waktu terlewati stream tersebut dibatalkan dan koneksi QUIC ditutup. Klien hanya mencoba ulang operasi idempoten yang terkonfirmasi belum dieksekusi, menggunakan kunci idempotensi untuk operasi tulis non-idempoten. Proksi menyebarkan status pengurasan, sementara migrasi tidak pernah dianggap sebagai transfer permintaan. Pengujian canary mencakup permintaan panjang, stream konkuren, percobaan ulang, perilaku proksi, dan efek duplikat.
Kesalahan umum
- Kesalahan: Menutup QUIC segera setelah GOAWAY. → Mengapa gagal: Permintaan aktif terinterupsi. → Solusi: Kuras terlebih dahulu dan tutup pada batas waktu akhir yang ketat.
- Kesalahan: Memperlakukan batas GOAWAY sebagai buku besar eksekusi. → Mengapa gagal: ID stream menyatakan rentang, bukan penyelesaian aplikasi. → Solusi: Konfirmasikan dengan status aplikasi dan kunci idempotensi.
- Kesalahan: Mencoba ulang setiap permintaan yang gagal. → Mengapa gagal: Respons yang hilang mungkin terjadi setelah timbulnya efek samping. → Solusi: Batasi percobaan ulang hanya untuk operasi idempoten atau yang memiliki kunci.
- Kesalahan: Mengasumsikan migrasi koneksi mentransfer permintaan yang sedang aktif. → Mengapa gagal: Perubahan jalur tidak mengubah status stream HTTP. → Solusi: Gunakan koneksi baru untuk percobaan ulang yang aman.
Pertanyaan lanjutan dan jawaban
Pertanyaan lanjutan 1: Mengapa nilai GOAWAY dapat menyusut?
Server pertama-tama dapat mencakup permintaan konkuren yang terpantau dan kemudian menetapkan batas akhir untuk stream baru. Penyusutan ini memungkinkan klien untuk konvergen tanpa harus menebak semua pekerjaan yang sedang berjalan pada sinyal pertama.
Pertanyaan lanjutan 2: Bagaimana klien mengetahui apakah suatu permintaan telah diterima?
Membandingkan ID stream dengan batas akhir mengidentifikasi rentang kemungkinan, bukan apakah kode aplikasi telah dijalankan. Gabungkan hal ini dengan respons, kesalahan koneksi, dan pencarian status idempotensi.
Pertanyaan lanjutan 3: Apakah GOAWAY otomatis merambat melalui proksi?
Jangan berasumsi demikian. Proksi adalah endpoint HTTP/3 independen dan harus menerjemahkan pengurasan upstream ke dalam kebijakan koneksi dan perutean downstream.
Pertanyaan lanjutan 4: Mengapa membatalkan stream sebelum penutupan paksa?
Pembatalan membebaskan sumber daya aplikasi dan mencatat alasan yang jelas, memungkinkan klien membedakan batas waktu pengurasan dari kegagalan jaringan. Penutupan QUIC adalah batas akhir koneksi, bukan mekanisme pembersihan aplikasi.