Wawancara frontend: Bagaimana cara Anda melakukan canary Compression Dictionary Transport secara aman?

Pertanyaan dan konteks

Sebuah situs dokumentasi menghasilkan HTML, CSS, dan JavaScript yang serupa pada setiap rilis. Tim ingin respons-respons berikutnya menggunakan kembali respons sebelumnya sebagai kamus Brotli atau Zstandard untuk mengurangi byte yang berulang, tetapi dukungan browser belum merata dan beberapa respons berisi data pengguna pribadi. Rancang rencana canary, cache, dan keamanan menggunakan Compression Dictionary Transport.

RFC 9842 mendefinisikan alur di mana respons mengiklankan kamus dengan Use-As-Dictionary, klien menawarkan kamus yang tersedia dengan Available-Dictionary, dan kedua belah pihak menegosiasikan enkoding konten kamus. Spesifikasi ini mewajibkan konteks aman HTTPS; MDN saat ini melabeli kapabilitas tersebut dengan ketersediaan terbatas (Limited availability), sehingga ini tidak dapat menjadi jalur wajib bagi setiap browser.

Hal yang diuji oleh pewawancara

Dapatkah Anda menjelaskan pendaftaran kamus, pencocokan, negosiasi hash, pemilihan enkoding, dan fallback kompresi biasa?
Dapatkah Anda menangani kesegaran (freshness), cache key, versi rilis, CDN, dan konsistensi di seluruh node?
Dapatkah Anda mengenali risiko inferensi konten atau compression side-channel dari kamus bersama?
Dapatkah Anda merancang progressive enhancement seputar kapabilitas browser, HTTPS, dan keterbacaan respons?
Dapatkah Anda membuktikan penghematan byte tanpa meningkatkan kesalahan atau paparan privasi?

Pertanyaan klarifikasi awal

Apakah browser target, WebView, proksi, dan CDN mendukung enkoding kamus yang relevan? Bisakah peluncuran dibatasi hanya untuk Chromium?
Respons mana yang bersifat publik, same-origin, dan repetitif, serta respons mana yang berisi data pengguna, penyewa (tenant), atau otorisasi?
Siapa yang membuat, menandatangani, mengakhiri masa berlaku, dan melakukan rollback kamus, serta apakah versi rilis terikat dengan hash sumber daya?
Apakah cache dipisahkan berdasarkan bahasa, tenant, status otorisasi, dan enkoding konten?
Apakah situs sudah menggunakan Brotli, Zstandard, ETag, Early Hints, atau caching service-worker?

Jawaban 30 detik

"Saya akan memilih sumber daya publik, same-origin, dan sangat berulang berdasarkan kapabilitas browser dan tingkat sensitivitas data. Melalui HTTPS, server mengiklankan kamus berversi dengan Use-As-Dictionary; setelah menerima Available-Dictionary, server memilih dcb, dcz, atau Brotli/gzip biasa. Versi kamus dan konten, hash, serta varian cache tetap terisolasi, dan respons sensitif tidak berbagi kamus. Saya akan menerapkan canary pada Chromium dan sekumpulan kecil sumber daya, mengukur byte, kesalahan decode, cache hit, serta peringatan privasi, dan beralih kembali ke enkoding biasa setiap kali dukungan atau validasi gagal."

Pembahasan mendalam langkah demi langkah

Pilih sumber daya yang tepat. Mulailah dengan sumber daya statis, publik, same-origin, dan versi yang stabil. Kecualikan HTML yang dipersonalisasi, data akun, respons lintas-tenant, dan rahasia. Ukur pengulangan dan manfaat kamus sebelum menerima kompleksitas tambahan.

Bangun alur negosiasi. Respons menggunakan Use-As-Dictionary untuk mendeklarasikan kecocokan, tipe, pengidentifikasi, dan kesegaran. Klien yang memiliki kecocokan mengirimkan hash Available-Dictionary dan mengiklankan enkoding kamus dalam Accept-Encoding. Server mengembalikan dcb atau dcz hanya jika kedua belah pihak mendukungnya dan kamus masih segar; jika tidak, server menggunakan enkoding 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 batas konsistensi. ID kamus, versi sumber daya, dan hash konten berada dalam satu artefak rilis. Setiap node CDN harus memperoleh kamus yang sama; jangan sampai separuh node mengembalikan kamus lama sementara sisanya menggunakan enkoding baru. Vary dan cache key harus mencakup header permintaan yang mengubah representasi, mencegah respons kamus sampai ke klien yang tidak mendukung.

Tangani kesegaran dan rollback. Saat kamus kedaluwarsa, dicabut, atau tidak lagi cocok dengan versi konten, hentikan pengiklanannya dan beralihlah ke kompresi biasa. Simpan kamus lama untuk jendela tumpang tindih (overlap window) yang terkontrol dengan batas waktu pensiun yang pasti. Rollback harus menghapus iklan kamus, membersihkan (purge) varian CDN, dan memulihkan Brotli/gzip; rollback tidak boleh bergantung pada tindakan klien yang menghapus cache mereka.

Isolasi risiko privasi. Lindungi konten kamus seperti sumber daya publik same-origin. Jika penyerang mengontrol sebagian dari input dan dapat mengamati ukuran terkompresi, substring yang berulang dapat mengungkap konten kamus atau respons. Jauhkan data rahasia dari konteks kompresi yang sama dengan teks yang dikontrol penyerang, dan nonaktifkan kompresi kamus jika diperlukan. HTTPS melindungi transportasi tetapi tidak menghilangkan compression side channel.

Gunakan progressive enhancement. Kegagalan kapabilitas atau negosiasi akan berlanjut dengan Brotli, gzip, atau respons tanpa kompresi. Mulailah dengan kelompok kecil sumber daya statis dan browser. Bandingkan distribusi Content-Encoding, byte yang ditransfer, TTFB, kesalahan decode, cache hit, dan tingkat fallback; tarik fitur tersebut jika keuntungannya tidak stabil.

Contoh jawaban

Saya akan membatasi peluncuran awal pada sumber daya statis publik, same-origin, dan berversi dengan tingkat pengulangan yang tinggi, mengecualikan HTML yang dipersonalisasi, data tenant, dan rahasia. Melalui HTTPS, server mengiklankan kamus dengan ID, cakupan pencocokan, dan masa kedaluwarsa melalui Use-As-Dictionary. Hanya setelah klien mengirimkan Available-Dictionary dan menegosiasikan Accept-Encoding, server akan mengembalikan dcb atau dcz; klien yang tidak mendukung, kamus usang, dan ketidakcocokan hash akan menggunakan Brotli/gzip biasa.

Artefak rilis akan mencakup kamus, hash sumber daya, dan varian cache CDN sehingga setiap node tetap konsisten. Vary mengisolasi header permintaan enkoding dan kamus. Saya tidak akan pernah menempatkan input yang dikontrol penyerang dan rahasia dalam konteks kompresi yang sama; HTTPS tidak menghilangkan side-channel berbasis ukuran. Canary dimulai dengan Chromium dan sekumpulan kecil data statis, mengukur byte yang dihemat, cache hit, kesalahan decode, fallback, dan peringatan privasi. Rollback dilakukan dengan menghapus iklan kamus dan memulihkan enkoding biasa.

Kesalahan umum

Gejala: Mengaktifkan kamus bersama untuk setiap respons → Penyebab kegagalan: Data yang dipersonalisasi atau sensitif masuk ke dalam konteks kompresi yang dapat disimpulkan → Solusi: Gunakan hanya sumber daya statis publik dan kompresi biasa untuk respons sensitif.
Gejala: Hanya memeriksa Accept-Encoding dan mengabaikan hash serta kesegaran kamus → Penyebab kegagalan: Klien mungkin menggunakan kamus yang salah atau gagal melakukan decode → Solusi: Ikat ID, hash, versi, dan masa kedaluwarsa secara bersamaan.
Gejala: Hanya melakukan caching berdasarkan URL di CDN → Penyebab kegagalan: Respons kamus dapat sampai ke klien yang tidak mendukung → Solusi: Pisahkan enkoding, header kamus, dan versi sumber daya dengan Vary dan cache key.
Gejala: Menganggap HTTPS sebagai jaminan keamanan yang lengkap → Penyebab kegagalan: Compression side channel masih dapat mengungkap substring yang berulang → Solusi: Isolasi input yang dikontrol penyerang dari rahasia dan nonaktifkan kompresi kamus bila diperlukan.

Pertanyaan lanjutan dan jawaban

Apa yang terjadi jika browser tidak mendukungnya?

Server mengembalikan dcb atau dcz hanya setelah negosiasi kamus berhasil. Permintaan lainnya berlanjut dengan Brotli, gzip, atau tanpa kompresi; pantau fallback dan jangan pernah mewajibkan peningkatan versi untuk mengakses halaman.

Berapa lama kamus harus bertahan?

Tetapkan masa pakai berdasarkan ritme rilis, manfaat pengulangan, dan kecepatan pencabutan, serta tuangkan pilihan tersebut dalam kebijakan rilis. Gunakan masa tumpang tindih yang singkat selama perubahan versi statis, kemudian pensiunkan kamus lama dan bersihkan varian CDN alih-alih menyimpannya tanpa batas waktu.

Bagaimana cara Anda menguji proses decode dan kebenaran cache?

Uji browser yang mendukung dan yang tidak mendukung, HTTP/1.1, HTTP/2, node CDN yang berbeda, serta cache dingin (cold) dan hangat (warm). Verifikasi Vary, hash konten, byte yang didecode, respons 304, pengambilan ke server asal (origin fetch), dan fallback enkoding biasa, bukan hanya rasio kompresi.

Sinyal apa yang membuat Anda segera menonaktifkannya?

Pencampuran konten lintas pengguna, ketidakcocokan hash kamus, kesalahan decode, cache poisoning, anomali ukuran terkompresi, atau peringatan pemindaian privasi harus segera menghapus Use-As-Dictionary. Pulihkan enkoding biasa dan simpan metrik insiden tersebut.

Referensi

Compression Dictionary Transport (RFC 9842)
MDN Compression Dictionary Transport
Chrome for Developers: Meningkatkan Google Search dengan Compression Dictionaries
Dokumentasi Chromium Compression Dictionary Transport

Daftar periksa wawancara

Mulailah dengan pemilihan sumber daya statis publik dan header negosiasi. Kemudian bahas versi kamus, cache key, HTTPS, side channel, progressive enhancement, dan rollback. Validasi manfaat dengan metrik byte, cache, dan kesalahan.

Kesimpulan satu kalimat

Kamus bersama mengurangi byte yang berulang hanya jika isolasi sumber daya, hash versi, fallback browser, dan pagar pembatas privasi semuanya diterapkan dengan benar.