Sanyanggae LogoSanyanggae

💻 Web dan pembangunan frontend

Perbezaan no-cache dan no-store dalam cache HTTP: semak kemas kini dengan ETag dan 304

Bezakan penyimpanan daripada pengesahan semula, tafsir Cache-Control, ETag dan respons 304 melalui contoh waktu operasi rekaan, kemudian kesan punca paparan yang masih lama.

사냥개 (Sanyanggae)Diterbitkan Dikemas kini 16 minit

Ini ialah terjemahan teks asal bahasa Korea. Teks asal bahasa Korea · Semakan terjemahan: Disemak oleh AI

Rajah penerangan tentang penyimpanan dan penggunaan semula cache HTTP, pengesahan semula ETag serta respons 200 dan 304.
Rajah penerangan oleh Sanyanggae: penyimpanan dan penggunaan semula, pengesahan semula ETag serta respons 200 dan 304.

Bayangkan waktu operasi hari ini pada laman perpustakaan sudah dikemas kini, namun pelayar masih memaparkan waktu lama. Mungkin kandungan pada pelayan asal belum berubah, pelayar menggunakan salinan yang disimpan, atau cache perantara membekalkan salinan lama. Menekan butang muat semula berulang kali sahaja belum dapat membezakan punca-punca ini.

Cache HTTP menyimpan respons dan menggunakannya semula apabila syarat tertentu dipenuhi. Artikel ini menggunakan contoh waktu operasi yang dipaparkan kepada umum untuk menghubungkan Cache-Control, ETag dan 304. Pertukaran mesej dipermudah dan nilainya direka untuk penerangan, bukannya hasil pengukuran perkhidmatan sebenar. Matlamatnya ialah menjelaskan syarat yang membenarkan penggunaan semula, supaya penyiasatan tidak sekadar berakhir dengan memadam semua cache.

1. Asingkan penyimpanan, pengesahan dan perkongsian salinan

Semasa membaca dasar cache, tanyakan tiga perkara: adakah respons boleh disimpan, adakah salinan tersimpan boleh terus digunakan, dan adakah salinan itu boleh dikongsi dengan pengguna lain? Kebenaran menyimpan tidak bermakna penggunaan semula sentiasa dibenarkan, manakala semakan kemas kini tidak dengan sendirinya memberi kebenaran berkongsi. RFC 9111 membezakan peranan arahan ini. Huraian di bawah merujuk arahan respons tanpa argumen nama medan.

SoalanArahan responsPerbezaan yang perlu difahami
Bolehkah respons disimpan untuk digunakan kemudian?no-storeMelarang penyimpanan bagi penggunaan semula pada masa hadapan.
Bolehkah salinan tersimpan digunakan tanpa semakan?no-cacheBoleh disimpan, tetapi pengesahan mesti berjaya sebelum digunakan semula.
Bolehkah respons disimpan dalam cache kongsi?privateMelarang penyimpanan dalam cache kongsi, tetapi tidak melarang penyimpanan dalam cache persendirian.

Bagi waktu operasi awam yang kerap berubah pada URL yang sama, semakan sebelum penggunaan semula mungkin sesuai. Halaman yang mengandungi maklumat khusus seseorang pengguna mempunyai pertimbangan perkongsian yang berlainan. private bukan mekanisme log masuk atau semakan hak capaian. Jika tujuan ini dicampuradukkan, respons boleh sampai kepada penerima yang salah.

Apabila menyediakan jadual dasar, tulis juga sebabnya: adakah waktu operasi perlu diperiksa untuk kemas kini, adakah logo kekal sama, dan adakah URL yang sama memberikan kandungan khusus kepada setiap pengguna? Ini ialah langkah awal pengelasan, bukan tetapan lengkap yang sesuai untuk semua laman. Bezakan juga penyimpanan dalam pelayar daripada penyimpanan pada CDN atau cache kongsi lain.

2. Nama no-cache dan no-store sahaja tidak cukup untuk memahaminya

Nama no-cache mudah disalahertikan sebagai larangan menyimpan. Namun, no-cache pada respons membenarkan penyimpanan dan mewajibkan pengesahan sebelum salinan digunakan semula. Jika pelayan mengesahkan bahawa kandungan belum berubah, badan respons yang sudah disimpan boleh digunakan. Sebaliknya, no-store meminta agar respons ini tidak disimpan untuk kegunaan semula. Apa yang disimpan dan apa yang perlu diperiksa pada permintaan berikutnya ialah dua perkara berbeza, jadi kedua-dua tetapan tidak boleh dijangka bertindak sama.

Status fresh bermaksud dasar membenarkan penggunaan semula tanpa pengesahan tambahan. Ia bukan jaminan bahawa kandungan pada pelayan asal masih sama. Dengan max-age, salinan yang belum tamat tempohnya boleh terus disampaikan walaupun kandungan asal sudah diubah. Tentukan dahulu kelewatan kemas kini yang boleh diterima, kemudian pilih pengepala; tempoh hayat yang panjang bukan jawapan untuk setiap halaman.

Seperti diterangkan dalam panduan cache MDN, menambah no-store pada respons baharu tidak memadam respons lama yang sudah tersimpan bagi URL yang sama secara automatik. Jika salinan lama masih fresh, permintaan mungkin belum sampai kepada respons dan pengepala baharu. no-store bukan arahan mengosongkan cache atau penyelesaian privasi yang lengkap. Periksa juga tempoh hayat terdahulu dan cara mengemas kini cache yang anda urus.

3. Jejaki ETag dan 304 ketika kunjungan semula

Andaikan URL rekaan /hours.json menyatakan perpustakaan tutup pada pukul 18:00. Contoh HTTP/1.1 berikut diringkaskan dan tidak menyenaraikan semua pengepala yang mungkin diperlukan. hours-v1 ialah pengecam perwakilan yang ditetapkan oleh pelayan, bukannya rumus masa atau nilai cincangan fail sebenar.

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache
ETag: "hours-v1"

{"closes":"18:00"}

Selepas menyimpan respons itu, pelayar boleh menghantar ETag melalui If-None-Match semasa pengesahan semula. Jika pengecam tersebut sepadan dengan perwakilan yang dipilih oleh pelayan pada ketika itu dan tiada perubahan, pelayan boleh membalas dengan 304. Blok berikut menunjukkan permintaan diikuti respons secara ringkas. Tiada JSON baharu dihantar selepas respons 304.

GET /hours.json HTTP/1.1
Host: library.example
If-None-Match: "hours-v1"

HTTP/1.1 304 Not Modified
Cache-Control: no-cache
ETag: "hours-v1"

Menurut penerangan ETag oleh MDN, klien kemudian boleh menggunakan badan respons yang tersimpan. Respons 304 tidak mempunyai badan, namun permintaan dan pengesahan masih melibatkan komunikasi rangkaian. Jika waktu tutup berubah kepada 19:00 dan perwakilannya turut berubah, respons yang dijangkakan ialah 200 dengan badan serta teg baharu. no-cache tidak bermaksud setiap respons mesti 304 atau pangkalan data tidak akan ditanya sama sekali.

Oleh itu, semak hubungan kandungan dengan teg, bukan kod status sahaja. Kandungan yang berubah tetapi masih menggunakan teg lama boleh menghasilkan keputusan pengesahan yang salah. Jika kandungan sama tetapi teg sentiasa berubah, penghantaran semula badan mungkin meningkat. Teliti cara pelayan menghasilkan perwakilan dan pengecamnya; kewujudan ETag semata-mata belum membuktikan pelaksanaannya betul.

4. Bezakan dokumen yang berubah daripada aset dengan nama baharu

Dokumen waktu operasi yang dikemas kini pada URL sama berbeza daripada logo atau skrip yang mendapat nama fail baharu semasa dikemas kini. Jika logo.a1.png digantikan dengan logo.b2.png, dokumen baharu mesti merujuk URL baharu itu. Menulis ganti kandungan lama walaupun nama fail mengandungi pengecam akan merosakkan persetujuan antara alamat dengan kandungannya.

Memuat naik fail baharu tidak menyebabkan pelayar memintanya secara automatik. Jika HTML lama masih merujuk logo lama, aset lama mungkin terus digunakan semula. Maka semak pembaruan dokumen serta pengepala aset bersama-sama. Kelewatan yang boleh diterima bagi setiap jenis kandungan tidak semestinya sama, jadi tempoh hayatnya juga tidak perlu diseragamkan.

Semasa pelancaran versi, dokumen lama dan baharu boleh wujud serentak. Dokumen baharu mungkin gagal jika diterbitkan sebelum asetnya tersedia, manakala dokumen lama boleh rosak jika aset lama dipadam terlalu awal. Pastikan aset baharu sudah wujud dan aset lama masih boleh dicapai. Corak penamaan fail tidak menyelesaikan pelancaran atau pengembalian versi dengan sendirinya.

5. Gunakan panel Network untuk menguji andaian

Mula-mula perhatikan keadaan asas apabila cache dibenarkan. Catat URL penuh termasuk parameter pertanyaan, versi waktu operasi yang terpapar, kod status, If-None-Match pada permintaan, serta Cache-Control dan ETag pada respons. Pengepala permintaan dan respons menyatakan syarat daripada pihak berbeza; walaupun namanya sama, rekodkan pada bahagian mana ia muncul. Dokumentasi panel Network Chrome menerangkan cara memeriksanya melalui tab Headers.

Keadaan ujianPerkara yang perlu dicatatKesimpulan yang perlu dielakkan
Mengunjungi semula waktu operasi yang belum diubahPermintaan bersyarat, kod status dan waktu yang dipaparkanMenganggap 304 bermaksud tiada komunikasi rangkaian.
Mengubah waktu operasi pada pelayan asalBadan baharu, teg dan URL yang benar-benar dimintaMenganggap simpanan berjaya bermakna semua pengguna sudah mendapat kemas kini.
Mematikan cache pelayarPerbezaan muat turun pertama dengan kunjungan semula biasaMenganggap hasilnya mewakili kelajuan kunjungan semula biasa.
Kembali ke halaman terdahuluSama ada permintaan baharu berlaku dan paparan yang dipulihkanMenganggap paparan yang muncul membuktikan pengesahan HTTP telah berlaku.

Ujian dengan cache dimatikan ialah keadaan yang berasingan. Pilihan Disable cache dalam Chrome berfungsi ketika DevTools terbuka, jadi catat sama ada alat itu terbuka dan pilihan tersebut diaktifkan. Ujian muat turun pertama tidak sama dengan penggunaan semula biasa. Jika pilihan itu terlupa, muat turun baharu yang berulang boleh disalah anggap sebagai cache yang rosak. Simpan butiran keadaan untuk dibandingkan selepas cache dihidupkan semula.

Ubah satu perkara pada satu masa. Perhatikan kunjungan semula tanpa perubahan terlebih dahulu, kemudian ubah satu medan waktu operasi. Jika URL, tetapan pelayan dan nama fail diubah serentak, puncanya sukar dipisahkan. Apabila 200 atau 304 tidak seperti yang dijangka, baca pertukaran sebenar sebelum menambah tetapan lain.

6. Semak storan lain dan syarat kerja dianggap selesai

Mematikan cache HTTP pelayar tidak bermaksud cache CDN atau semua storan aplikasi turut dimatikan. Service worker, pemilihan salinan oleh perantara dan data yang dikekalkan aplikasi perlu disemak secara berasingan. URL yang sama tidak bererti semua salinan datang daripada lapisan yang sama.

Tindakan kembali ke halaman terdahulu juga perlu dibezakan daripada permintaan HTTP baharu. Paparan sesi sebelumnya mungkin dipulihkan tanpa pengesahan semula yang dijangka, walaupun no-cache digunakan. Itu belum membuktikan pelayan mengabaikan pengepala. Catat permintaan yang benar-benar berlaku ketika navigasi baharu, muat semula dan kembali ke halaman terdahulu.

Kejayaan tidak memadai dinilai melalui nisbah hit cache sahaja. Pastikan kandungan yang belum berubah digunakan semula dengan betul, perubahan tiba dalam masa yang dibenarkan, dan salinan dikongsi dengan penerima yang tepat. Rekodkan waktu perubahan, waktu pemerhatian, keadaan ujian dan badan respons sebenar supaya masalah boleh dihasilkan semula. Laman yang lebih pantas tetapi terus memaparkan waktu operasi salah terlalu lama masih belum memenuhi keperluan.

Bagi perkhidmatan sebenar, tentukan dasar untuk setiap respons berserta aliran kemas kini dan pengembalian versi. Jangan terus menyalin dasar kandungan awam kepada respons peribadi, dan jangan samakan pengesahan cache dengan pemberian hak capaian. Pengepala menetapkan aturan penyimpanan dan penggunaan semula. Menjelaskan apa yang disimpan, apa yang disahkan dan salinan mana yang sedang dipaparkan akan menjadikan diagnosis lebih terarah.

Sumber dan bacaan lanjut

Artikel ini menerangkan maklumat daripada sumber awam. Petikan sumber tidak bermakna organisasi berkenaan menyemak atau mengesahkannya.

Penerbit dan hubungan

Artikel lain tentang topik ini