Temuduga Frontend: Bagaimanakah anda akan melancarkan kenari (canary) Compression Dictionary Transport secara selamat?

Soalan dan konteks

Sebuah laman dokumentasi menjana HTML, CSS, dan JavaScript yang serupa pada setiap keluaran (release). Pasukan ingin respons terkemudian menggunakan semula respons terdahulu sebagai kamus Brotli atau Zstandard bagi mengurangkan bait yang berulang, tetapi sokongan pelayar tidak seragam dan sesetengah respons mengandungi data peribadi pengguna. Reka pelan kenari, cache, dan keselamatan menggunakan Compression Dictionary Transport.

RFC 9842 mentakrifkan aliran di mana respons mengiklankan kamus dengan Use-As-Dictionary, klien menawarkan kamus yang tersedia dengan Available-Dictionary, dan kedua-dua pihak merundingkan pengekodan kandungan kamus. Spesifikasi tersebut memerlukan konteks selamat HTTPS; MDN pada masa ini melabelkan keupayaan tersebut sebagai Ketersediaan terhad (Limited availability), jadi ia tidak boleh menjadi laluan wajib untuk setiap pelayar.

Perkara yang diuji oleh penemuduga

Bolehkah anda menerangkan pendaftaran kamus, pemadanan, perundingan cincangan (hash negotiation), pilihan pengekodan, dan sandaran mampatan biasa?
Bolehkah anda mengendalikan kesegaran (freshness), kunci cache, versi keluaran, CDN, dan ketekalan merentasi nod?
Bolehkah anda mengenal pasti risiko inferens kandungan atau saluran sisi mampatan daripada kamus yang dikongsi?
Bolehkah anda mereka bentuk peningkatan progresif (progressive enhancement) berasaskan keupayaan pelayar, HTTPS, dan kebolehbacaan respons?
Bolehkah anda membuktikan penjimatan bait tanpa meningkatkan ralat atau pendedahan privasi?

Soalan untuk dijelaskan terlebih dahulu

Adakah pelayar sasaran, WebView, proksi, dan CDN menyokong pengekodan kamus yang berkaitan? Bolehkah pelancaran dihadkan kepada Chromium sahaja?
Respons manakah yang bersifat awam, sama asal (same-origin), dan berulang, serta respons manakah yang mengandungi data pengguna, penyewa (tenant), atau kebenaran (authorization)?
Siapakah yang mencipta, menandatangani, mematangkan (expire), dan mengembalikan (rollback) kamus, dan adakah versi keluaran terikat kepada cincangan sumber?
Adakah cache diasingkan mengikut bahasa, penyewa, status kebenaran, dan pengekodan kandungan?
Adakah laman tersebut sudah menggunakan Brotli, Zstandard, ETag, Early Hints, atau caching service-worker?

Jawapan 30 saat

"Saya akan memilih sumber awam, sama asal, dan sangat berulang mengikut keupayaan pelayar serta tahap kepekaan data. Melalui HTTPS, pelayan mengiklankan kamus berversi dengan Use-As-Dictionary; selepas Available-Dictionary, ia memilih dcb, dcz, atau Brotli/gzip biasa. Versi kamus dan kandungan, cincangan, serta varian cache kekal diasingkan, dan respons sensitif tidak berkongsi kamus. Saya akan melancarkan kenari pada Chromium dan set sumber yang kecil, mengukur bait, ralat penyahkodan, hit cache, serta amaran privasi, dan kembali kepada pengekodan biasa apabila sokongan atau pengesahan gagal."

Huraian mendalam langkah demi langkah

Pilih sumber yang betul. Mulakan dengan sumber statik, awam, sama asal, dan stabil dari segi versi. Kecualikan HTML yang diperibadikan, data akaun, respons rentas penyewa, dan rahsia. Ukur tahap pengulangan dan faedah kamus sebelum menerima kerumitan tambahan ini.

Bina aliran perundingan. Sesuatu respons menggunakan Use-As-Dictionary untuk mengisytiharkan pemadanan, jenis, pengecam, dan kesegaran. Klien yang mempunyai padanan akan menghantar cincangan Available-Dictionary dan mengiklankan pengekodan kamus dalam Accept-Encoding. Pelayan mengembalikan dcb atau dcz hanya apabila kedua-dua pihak menyokongnya dan kamus masih segar; jika tidak, ia menggunakan pengekodan biasa.

http

HTTP/2 200
Content-Type: text/javascript
Cache-Control: public, max-age=3600
Use-As-Dictionary: match="/assets/*", id="docs-v42", type="dictionary"

HTTP/2 200
Content-Encoding: dcb
Vary: Accept-Encoding, Available-Dictionary

Tetapkan sempadan ketekalan. ID kamus, versi sumber, dan cincangan kandungan berada dalam satu artifak keluaran yang sama. Setiap nod CDN mesti memperoleh kamus yang sama; separuh nod tidak boleh mengembalikan kamus lama manakala selebihnya menggunakan pengekodan baharu. Vary dan kunci cache mesti meliputi pengepala permintaan yang mengubah perwakilan, bagi mengelakkan respons kamus daripada sampai kepada klien yang tidak menyokongnya.

Kendalikan kesegaran dan pengembalian semula (rollback). Apabila kamus tamat tempoh, dibatalkan, atau tidak lagi sepadan dengan versi kandungan, hentikan pengiklanannya dan kembali kepada mampatan biasa. Simpan kamus lama untuk tetingkap pertindihan terkawal dengan masa persaraan yang tegas. Pengembalian semula harus mengalih keluar iklan kamus, membersihkan varian CDN, dan memulihkan Brotli/gzip; ia tidak seharusnya bergantung pada tindakan klien mengosongkan cache.

Asingkan risiko privasi. Lindungi kandungan kamus seperti sumber awam sama asal. Jika penyerang mengawal sebahagian daripada input dan dapat memerhati saiz termampat, subrentetan yang berulang mungkin mendedahkan kandungan kamus atau respons. Jauhkan rahsia daripada konteks mampatan yang sama dengan teks kawalan penyerang, dan nyahdayakan mampatan kamus apabila perlu. HTTPS melindungi pengangkutan tetapi tidak menghapuskan saluran sisi mampatan.

Gunakan peningkatan progresif. Kegagalan keupayaan atau perundingan akan diteruskan dengan Brotli, gzip, atau respons yang tidak dimampatkan. Mulakan dengan kohort sumber statik dan pelayar yang kecil. Bandingkan taburan Content-Encoding, bait yang dipindahkan, TTFB, ralat penyahkodan, hit cache, dan kadar sandaran; tarik balik ciri tersebut jika faedah yang diperoleh tidak stabil.

Jawapan model

Saya akan mengehadkan pelancaran pertama kepada sumber statik awam, sama asal, dan berversi dengan tahap pengulangan yang tinggi, sambil mengecualikan HTML yang diperibadikan, data penyewa, dan rahsia. Melalui HTTPS, pelayan mengiklankan kamus dengan ID, skop pemadanan, dan masa tamat tempoh melalui Use-As-Dictionary. Hanya selepas klien menghantar Available-Dictionary dan merundingkan Accept-Encoding, pelayan akan mengembalikan dcb atau dcz; klien yang tidak menyokong, kamus lapuk, dan ketidakpadanan cincangan akan menggunakan Brotli/gzip biasa.

Artifak keluaran akan merangkumi kamus, cincangan sumber, dan varian cache CDN supaya setiap nod kekal tekal. Vary mengasingkan pengekodan dan pengepala permintaan kamus. Saya tidak akan sekali-kali meletakkan input kawalan penyerang dan rahsia dalam konteks mampatan yang sama; HTTPS tidak menghapuskan saluran sisi berasaskan saiz. Pelancaran kenari bermula dengan Chromium dan set statik yang kecil, mengukur penjimatan bait, hit cache, ralat penyahkodan, sandaran, dan amaran privasi. Tindakan pengembalian semula akan mengalih keluar iklan kamus dan memulihkan pengekodan biasa.

Kesilapan lazim

Gejala: Mendayakan kamus kongsi untuk setiap respons → Sebab ia gagal: Data yang diperibadikan atau sensitif memasuki konteks mampatan yang boleh diinferens → Penyelesaian: Gunakan sumber statik awam sahaja dan mampatan biasa untuk respons sensitif.
Gejala: Hanya memeriksa Accept-Encoding dan mengabaikan cincangan serta kesegaran kamus → Sebab ia gagal: Klien mungkin menggunakan kamus yang salah atau gagal menyahkod → Penyelesaian: Ikatkan ID, cincangan, versi, dan masa tamat tempoh.
Gejala: Caching mengikut URL sahaja pada CDN → Sebab ia gagal: Respons kamus mungkin sampai kepada klien yang tidak menyokongnya → Penyelesaian: Asingkan pengekodan, pengepala kamus, dan versi sumber dengan Vary dan kunci cache.
Gejala: Menganggap HTTPS sebagai jaminan keselamatan sepenuhnya → Sebab ia gagal: Saluran sisi mampatan masih boleh mendedahkan subrentetan berulang → Penyelesaian: Asingkan input kawalan penyerang daripada data rahsia dan nyahdayakan mampatan kamus jika perlu.

Soalan susulan dan jawapan

Apakah yang berlaku apabila pelayar tidak menyokongnya?

Pelayan mengembalikan dcb atau dcz hanya selepas perundingan kamus berjaya. Permintaan lain diteruskan dengan Brotli, gzip, atau tanpa mampatan; pantau kadar sandaran dan jangan sekali-kali mewajibkan peningkatan versi untuk mengakses halaman.

Berapa lamakah kamus patut disimpan?

Tetapkan jangka hayat berdasarkan kekerapan keluaran, faedah pengulangan, dan kelajuan pembatalan, serta kodkan pilihan tersebut dalam dasar keluaran. Gunakan tempoh pertindihan yang singkat semasa pertukaran versi statik, kemudian persarakan kamus lama dan bersihkan varian CDN dan bukannya menyimpannya selama-lamanya.

Bagaimanakah anda menguji penyahkodan dan ketepatan cache?

Uji pelayar yang menyokong dan tidak menyokong, HTTP/1.1, HTTP/2, nod CDN yang berbeza, serta cache sejuk dan panas. Sahkan Vary, cincangan kandungan, bait yang dinyahkod, respons 304, pengambilan asal (origin fetch), dan sandaran pengekodan biasa, bukan sekadar nisbah mampatan.

Isyarat apakah yang menyebabkan anda menyahdayakannya serta-merta?

Percampuran kandungan rentas pengguna, ketidakpadanan cincangan kamus, ralat penyahkodan, keracunan cache (cache poisoning), saiz termampat yang tidak normal, atau amaran imbasan privasi harus mendorong pengalihan keluar Use-As-Dictionary serta-merta. Pulihkan pengekodan biasa dan simpan metrik insiden tersebut.

Rujukan

Compression Dictionary Transport (RFC 9842)
MDN Compression Dictionary Transport
Chrome for Developers: Menambah Baik Carian Google dengan Kamus Mampatan
Dokumentasi Chromium Compression Dictionary Transport

Senarai semak temuduga

Mulakan dengan pemilihan sumber statik awam dan pengepala perundingan. Kemudian bincangkan versi kamus, kunci cache, HTTPS, saluran sisi, peningkatan progresif, dan pengembalian semula. Sahkan faedah dengan metrik bait, cache, dan ralat.

Rumusan satu ayat

Kamus yang dikongsi hanya mengurangkan bait berulang apabila pengasingan sumber, cincangan versi, sandaran pelayar, dan perlindungan privasi semuanya dilaksanakan dengan betul.