Temuduga Backend: Bagaimanakah Anda Menjalankan WebSocket melalui HTTP/2 Extended CONNECT?

Prompt dan konteks

Get laluan dan klien menyokong HTTP/2, dan perkhidmatan masa nyata mahu strim WebSocket dimultiplekskan pada satu sambungan. Reka bentuk migrasi RFC 8441: jabat tangan (handshake), rundingan keupayaan, keserasian proksi, penutupan strim berbanding penutupan sambungan, fallback, dan metrik penerimaan. Ini ialah soalan backend tentang semantik extended-connect HTTP/2.

Perkara yang dinilai oleh penemu duga

1. Membezakan Extended CONNECT daripada HTTP/1.1 Upgrade.
2. Menggunakan :protocol dan SETTINGS_ENABLE_CONNECT_PROTOCOL dengan betul.
3. Memisahkan penutupan strim HTTP/2 daripada penutupan sambungan.
4. Mereka bentuk fallback untuk proksi dan klien yang tidak disokong.
5. Mengukur jabat tangan, ralat strim, guna semula (reuse), dan kependaman (latency).

Soalan penjelasan untuk ditanya

• Adakah klien, proksi pinggir, pengimbang beban, get laluan, dan asal (origin) menyokong RFC 8441?
• Bolehkah permintaan biasa dan strim WebSocket berkongsi satu sambungan HTTP/2?
• Adakah pengimbang beban mengekalkan HTTP/2 hujung ke hujung atau menamatkannya dan membinanya semula?
• Bolehkah klien lama terus menggunakan HTTP/1.1 Upgrade?
• Adakah klien itu sebuah pelayar, SDK natif, atau pelaksanaan RPC dalaman?

Jawapan 30 saat

“Saya akan mengesahkan SETTINGS_ENABLE_CONNECT_PROTOCOL pada setiap lompatan (hop). Klien yang berkemampuan menghantar Extended CONNECT dengan :protocol = websocket; selepas berjaya, strim HTTP/2 tersebut membawa bingkai WebSocket. Lompatan yang tidak disokong akan beralih (fallback) kepada HTTP/1.1 Upgrade. Membatalkan satu strim tidak boleh menutup keseluruhan sambungan. Semasa pelancaran kenari (canary), saya akan menjejaki kejayaan jabat tangan, fallback, RST_STREAM, GOAWAY, guna semula, dan kependaman mesej pertama.”

Jawapan mendalam

Langkah 1: Runding sokongan lanjutan

Titik akhir mengiklankan Extended CONNECT melalui HTTP/2 SETTINGS. Klien menghantar pengepala pseudo :protocol hanya selepas menerima sokongan; proksi yang membuang tetapan tersebut mesti mencetuskan fallback dan bukannya menghantar permintaan yang tidak sah.

SETTINGS_ENABLE_CONNECT_PROTOCOL = 1
:method = CONNECT
:protocol = websocket
:authority = chat.example

Keratan ini menunjukkan medan jabat tangan; susunan bingkai masih mengikut HTTP/2 dan RFC 8441.

Langkah 2: Kendalikan jabat tangan dan data strim

Extended CONNECT yang berjaya mencipta strim HTTP/2 yang membawa semantik bingkai WebSocket. Ia tidak menggunakan Connection, Upgrade, Sec-WebSocket-Key HTTP/1.1, atau laluan 101. Pelayan masih melakukan pengesahan, menyemak asal, dan merundingkan subprotokol serta lanjutan.

Langkah 3: Asingkan kitaran hayat

RST_STREAM atau penutupan strim biasa hanya menjejaskan satu WebSocket, bukan permintaan lain pada sambungan tersebut. GOAWAY menghalang strim baharu; strim sedia ada memerlukan dasar penyiapan, migrasi, atau sambung semula. Logik sambung semula mesti mengelakkan penghantaran semula mesej yang telah pun diperakui (acknowledged).

Langkah 4: Reka bentuk fallback proksi

Bina matriks keupayaan untuk klien, CDN, pengimbang beban, dan get laluan. Jika mana-mana lompatan tiada sokongan, gunakan HTTP/1.1 Upgrade atau kembalikan ralat tidak disokong yang jelas; jangan majukan :protocol sebagai pengepala biasa. Kekalkan pengesahan, semakan asal, subprotokol, dan tingkah laku denyutan jantung (heartbeat) dalam kedua-dua laluan.

Langkah 5: Kawalan aliran dan tekanan balik (backpressure)

Tetingkap kawalan aliran HTTP/2 dan giliran aplikasi kedua-duanya terpakai. Hadkan penimbal per-strim dan per-sambungan, pantau kekangan tetingkap (window stalls), dan pastikan satu strim perlahan tidak dapat menyekat permintaan biasa yang berkongsi sambungan.

Langkah 6: Pemeriksaan kenari dan keselamatan

Mulakan dengan klien dalaman dan satu rantau. Bandingkan Extended CONNECT dengan HTTP/1.1 Upgrade untuk kejayaan jabat tangan, kependaman mesej pertama, sambung semula, RST_STREAM, GOAWAY, dan ralat proksi. Had TLS, asal, pengesahan, subprotokol, dan saiz mesej kekal tidak berubah.

Langkah 7: Tentukan pengunduran (rollback) dan penerimaan

Sediakan suis peringkat klien atau peringkat rantau untuk melumpuhkan WebSocket HTTP/2. Uji ketiadaan SETTINGS, protokol yang ditolak, pembatalan strim, GOAWAY, perubahan rangkaian, dan sambung semula yang pendua. Bandingkan susunan mesej, kependaman p95, kiraan sambungan, dan nisbah fallback sebelum memperluaskannya.

Jawapan model

“Saya akan mewujudkan matriks keupayaan hujung ke hujung dan memerlukan SETTINGS_ENABLE_CONNECT_PROTOCOL pada setiap lompatan. Klien yang disokong menghantar Extended CONNECT dengan :protocol = websocket; strim HTTP/2 yang berjaya membawa bingkai WebSocket, manakala laluan yang tidak disokong menggunakan HTTP/1.1 Upgrade. Pengesahan, asal, subprotokol, denyutan jantung, dan had saiz kekal sama.

RST_STREAM hanya menjejaskan satu WebSocket; GOAWAY menjejaskan strim baharu dan memerlukan dasar penyiapan atau sambung semula. Ujian kenari mengukur jabat tangan, fallback, sambung semula, p95 mesej pertama, guna semula, dan ralat proksi, dengan suntikan ujian ketiadaan SETTINGS, protokol ditolak, strim perlahan, dan perubahan rangkaian.”

Kesilapan lazim

• Menganggap Extended CONNECT sebagai pengepala biasa → proksi mungkin menolak atau salah menghalakannya → sahkan SETTINGS dan pengepala pseudo.
• Menghantar pengepala Upgrade HTTP/1.1 → HTTP/2 tidak menggunakan jabat tangan tersebut → ikuti RFC 8441.
• Menutup sambungan apabila RST_STREAM berlaku → permintaan lain yang tidak berkaitan akan gagal → asingkan keadaan strim dan sambungan.
• Mengabaikan GOAWAY → penyambungan semula dan penyiapan menjadi kabur → tentukan dasar kitaran hayat.
• Hanya menguji sambungan terus → perbezaan CDN dan pengimbang beban merosakkan persekitaran pengeluaran → uji setiap lompatan.
• Menggugurkan pengesahan semasa migrasi → lanjutan ini tidak mengubah keperluan keselamatan WebSocket → guna semula dasar sedia ada.

Soalan susulan dan respons

Soalan susulan 1: Mengapa tidak terus menggunakan WebSocket HTTP/3?

RFC 9220 mentakrifkan laluan HTTP/3. RFC 8441 ialah langkah praktikal apabila laluan hujung ke hujung sedia ada ialah HTTP/2; sokongan dan kos migrasi menjadi penentu.

Soalan susulan 2: Bolehkah klien mencuba Extended CONNECT tanpa tetapan tersebut?

Tidak. Tunggu isyarat keupayaan, kemudian lakukan fallback atau laporkan tidak disokong daripada menghantar permintaan yang tidak sah mengikut protokol.

Soalan susulan 3: Bagaimanakah anda mengelakkan mesej pendua selepas GOAWAY?

Gunakan nombor jujukan klien atau kunci keidempotensian (idempotency keys), simpan ofset yang telah diperakui, dan sambung semula dari titik yang ditetapkan selepas menyambung semula.

Soalan susulan 4: Bagaimanakah anda mengesan proksi yang tidak serasi?

Rakam SETTINGS, respons CONNECT, dan kod ralat lompatan demi lompatan, dibahagikan mengikut proksi, rantau, dan versi klien.