Permintaan dan konteks
Sebuah gateway dan klien mendukung HTTP/2, dan layanan real-time ingin memultipleks stream WebSocket pada satu koneksi. Rancang migrasi RFC 8441: handshake, negosiasi kapabilitas, kompatibilitas proksi, penutupan stream versus penutupan koneksi, fallback, dan metrik penerimaan. Ini adalah pertanyaan backend tentang semantik extended-connect HTTP/2.
Hal yang dievaluasi pewawancara
- Membedakan Extended CONNECT dari HTTP/1.1 Upgrade.
- Menggunakan
:protocoldanSETTINGS_ENABLE_CONNECT_PROTOCOLdengan benar. - Memisahkan penutupan stream HTTP/2 dari penutupan koneksi.
- Merancang fallback untuk proksi dan klien yang tidak mendukung.
- Mengukur handshake, galat stream, penggunaan ulang (reuse), dan latensi.
Pertanyaan klarifikasi untuk diajukan
- Apakah klien, edge proxy, load balancer, gateway, dan origin mendukung RFC 8441?
- Bisakah permintaan biasa dan stream WebSocket berbagi satu koneksi HTTP/2?
- Apakah load balancer mempertahankan HTTP/2 end-to-end atau menghentikan (terminate) lalu membangunnya kembali?
- Bisakah klien lama terus menggunakan HTTP/1.1 Upgrade?
- Apakah klien berupa peramban (browser), SDK native, atau implementasi RPC internal?
Jawaban 30 detik
“Saya akan memverifikasi SETTINGS_ENABLE_CONNECT_PROTOCOL di setiap hop. Klien yang mampu akan mengirimkan Extended CONNECT dengan :protocol = websocket; setelah berhasil, stream HTTP/2 tersebut membawa frame-frame WebSocket. Hop yang tidak mendukung akan melakukan fallback ke HTTP/1.1 Upgrade. Membatalkan satu stream tidak boleh menutup seluruh koneksi. Selama canary rollout, saya akan melacak keberhasilan handshake, fallback, RST_STREAM, GOAWAY, reuse, dan latensi pesan pertama.”
Jawaban mendalam
Langkah 1: Negosiasikan dukungan ekstensi
Titik akhir (endpoint) mengiklankan Extended CONNECT melalui HTTP/2 SETTINGS. Klien mengirim pseudo-header :protocol hanya setelah menerima konfirmasi dukungan; proksi yang menghapus setelan tersebut harus memicu fallback alih-alih mengirim permintaan yang tidak valid.
SETTINGS_ENABLE_CONNECT_PROTOCOL = 1
:method = CONNECT
:protocol = websocket
:authority = chat.exampleCuplikan ini menunjukkan bidang-bidang handshake; urutan frame tetap mengikuti HTTP/2 dan RFC 8441.
Langkah 2: Tangani handshake dan data stream
Extended CONNECT yang berhasil akan membuat stream HTTP/2 yang membawa semantik frame WebSocket. Ini tidak menggunakan Connection, Upgrade, Sec-WebSocket-Key HTTP/1.1, atau jalur 101. Server tetap melakukan autentikasi, memeriksa origin, serta menegosiasikan subprotokol dan ekstensi.
Langkah 3: Pisahkan siklus hidup
RST_STREAM atau penutupan stream normal hanya memengaruhi satu WebSocket, bukan permintaan lain pada koneksi tersebut. GOAWAY mencegah stream baru; stream yang ada memerlukan kebijakan penyelesaian, migrasi, atau penyambungan ulang (reconnect). Logika reconnect harus menghindari pengiriman ulang pesan yang telah diakui (acknowledged).
Langkah 4: Rancang fallback proksi
Bangun matriks kapabilitas untuk klien, CDN, load balancer, dan gateway. Jika ada hop yang tidak mendukung, gunakan HTTP/1.1 Upgrade atau kembalikan pesan galat tidak didukung yang jelas; jangan meneruskan :protocol sebagai header biasa. Pertahankan autentikasi, pemeriksaan origin, subprotokol, dan perilaku heartbeat di kedua jalur.
Langkah 5: Kontrol aliran dan backpressure
Jendela kontrol aliran (flow-control window) HTTP/2 dan antrean aplikasi keduanya berlaku. Batasi buffer per-stream dan per-koneksi, amati stall pada jendela, dan pastikan satu stream yang lambat tidak dapat memblokir permintaan biasa yang berbagi koneksi tersebut.
Langkah 6: Pemeriksaan canary dan keamanan
Mulai dengan klien internal dan satu wilayah. Bandingkan Extended CONNECT dengan HTTP/1.1 Upgrade untuk keberhasilan handshake, latensi pesan pertama, reconnect, RST_STREAM, GOAWAY, dan galat proksi. Batasan TLS, origin, autentikasi, subprotokol, dan ukuran pesan tetap tidak berubah.
Langkah 7: Tentukan rollback dan penerimaan
Sediakan sakelar tingkat klien atau tingkat wilayah untuk menonaktifkan HTTP/2 WebSocket. Uji ketiadaan SETTINGS, protokol yang ditolak, pembatalan stream, GOAWAY, perubahan jaringan, dan reconnect duplikat. Bandingkan urutan pesan, latensi p95, jumlah koneksi, dan rasio fallback sebelum memperluas peluncuran.
Contoh jawaban model
“Saya akan menetapkan matriks kapabilitas end-to-end dan mewajibkan SETTINGS_ENABLE_CONNECT_PROTOCOL di setiap hop. Klien yang mendukung akan mengirimkan Extended CONNECT dengan :protocol = websocket; stream HTTP/2 yang berhasil akan membawa frame WebSocket, sedangkan jalur yang tidak mendukung menggunakan HTTP/1.1 Upgrade. Batasan autentikasi, origin, subprotokol, heartbeat, dan ukuran tetap sama.
RST_STREAM hanya memengaruhi satu WebSocket; GOAWAY memengaruhi stream baru dan memerlukan kebijakan penyelesaian atau reconnect. Canary mengukur handshake, fallback, reconnect, p95 pesan pertama, reuse, dan galat proksi, dengan menginjeksikan kasus SETTINGS yang hilang, protokol yang ditolak, stream yang lambat, dan perubahan jaringan.”
Kesalahan umum
- Memperlakukan Extended CONNECT sebagai header biasa → proksi dapat menolak atau salah merutekannya → validasi SETTINGS dan pseudo-header.
- Mengirim header Upgrade HTTP/1.1 → HTTP/2 tidak menggunakan handshake tersebut → ikuti RFC 8441.
- Menutup koneksi saat RST_STREAM → permintaan lain yang tidak terkait akan gagal → pisahkan status stream dan koneksi.
- Mengabaikan GOAWAY → reconnect dan penyelesaian menjadi ambigu → definisikan kebijakan siklus hidup.
- Hanya menguji koneksi langsung → perbedaan perilaku CDN dan load balancer merusak sistem di produksi → uji setiap hop.
- Menghilangkan autentikasi saat migrasi → ekstensi tidak mengubah persyaratan keamanan WebSocket → gunakan kembali kebijakan yang ada.
Pertanyaan lanjutan dan tanggapan
Pertanyaan lanjutan 1: Mengapa tidak langsung menggunakan WebSocket HTTP/3?
RFC 9220 mendefinisikan jalur HTTP/3. RFC 8441 adalah langkah praktis ketika jalur end-to-end yang ada saat ini adalah HTTP/2; ketersediaan dukungan dan biaya migrasi yang menjadi penentunya.
Pertanyaan lanjutan 2: Bisakah klien mencoba Extended CONNECT tanpa setelan tersebut?
Tidak. Tunggu sinyal kapabilitas, lalu lakukan fallback atau laporkan bahwa itu tidak didukung daripada mengirimkan permintaan yang melanggar protokol.
Pertanyaan lanjutan 3: Bagaimana Anda menghindari pesan duplikat setelah GOAWAY?
Gunakan nomor urut klien atau kunci idempotensi, pertahankan offset yang diakui, dan lanjutkan dari titik yang telah ditentukan setelah reconnect.
Pertanyaan lanjutan 4: Bagaimana cara menemukan proksi yang tidak kompatibel?
Tangkap SETTINGS, respons CONNECT, dan kode galat hop demi hop, lalu pisahkan berdasarkan proksi, wilayah, dan versi klien.