強快取與協商快取的區別
強快取：瀏覽器不與服務端協商直接取瀏覽器快取
協商快取：瀏覽器會先向伺服器確認資源的有效性後才決定是從快取中取資源還是重新獲取資源
協商快取運作原理
現在有乙個這樣的業務情景：後端的靜態資源會不定時地發生更新，而因為瀏覽器預設使用強快取，會預設從瀏覽器快取中取到過時的資源。
現在我們希望瀏覽器每次獲取資源的時候都向後端確認資源是否更新，就要設定瀏覽器使用協商快取
那麼後端如何判斷資源是否更新了呢？這時就要用到etag和last-modified兩項響應頭。
每次收到乙個靜態資源的請求時，後端都將資源的最後修改時間（last-modified）、根據資源內容計算出來的etag放在響應頭給前端。
前端收到響應後將這兩項快取起來，然後在下次請求同樣資源的時候，將這兩項的內容放到if-modified-since和if-none-match這兩項請求頭中。
服務端收到這兩項後，會與資源當前生成的etag和last-modified做比較，如果兩者都一致，說明資源沒有更新，服務端會返回304空響應；否則，說明資源有更新，服務端會將完整的資源內容返回
實現
那麼如何實現這樣乙個複雜的過程呢？其實很簡單，只要使用nginx作為靜態資源的伺服器，再在響應頭加上cache-control:no-cache就可以了。
下面來分步驟實現一下
1. 使用nginx作為靜態資源的伺服器
在nginx的配置中，將對靜態資源的請求對映到資源的磁碟路徑上
nginx -s reload3. 此時，請求靜態資源的時候nginx會自動在response頭中加上etag和last-modified兩項
4. 但是這時發現，如果不配置
cache-contrl: no-cache，瀏覽器在下次請求這個資源的時候不會將請求發向後端，而是直接從快取中獲取資源
5. 在nginx中配置
location /picture/6. 清除瀏覽器快取後第一次發起請求，會得到乙個正常的200 response，而且響應頭里已經有了cache-control: no-cache，表示使用協商快取
7.
再次發起請求後，會發現請求頭已經帶上了if-modified-since和if-none-match兩項
8. 服務端（nginx）收到這兩項後，會與資源當前生成的etag和last-modified做比較，如果兩者都一致，說明資源沒有更新，服務端會返回304空響應；否則，說明資源有更新，服務端會將完整的資源內容返回
另外，伺服器驗證if-modified-since的方式只是簡單的字串比較，即使資源的last-modified比if-modified-since要早，服務端仍認為資源有更新
9. 瀏覽器在收到304響應後，會從瀏覽器快取中取資源。因此速度非常塊
no-cache與no-store的區別
no-cache表示不快取過期資源，快取會向伺服器進行有效處理確認之後處理資源
而no-store才是真正的不進行快取。
nginx作為靜態web服務 設定瀏覽器快取
瀏覽器是支援快取機制的，不是每次請求都需要去服務端獲取資料的，避免對服務端造成資源消耗，而且響應比較高效。校驗第一步 校驗本地快取是否過期 部分客戶端每次都會走第二步校驗 expires 基於http1.0，預設了多久以後快取就過期了。cache control 基於http1.1版本，預設了多久以...
Nginx設定瀏覽器快取
在location或if段裡,來寫.格式 expires 30s expires 30m expires 2h expires 30d 注意 伺服器的日期要準確,如果伺服器的日期落後於實際日期,可能導致快取失效 另 304 也是一種很好的快取手段 原理是 伺服器響應檔案內容是,同時響應etag標籤 ...
python selenium清除瀏覽器快取
最近在做自動化測試的時候，由於重複進入登入頁面多次，並且此頁面在第一次進入的時候才會出現輸入使用者名稱和密碼，之後進入時候由於登入過了就不會出現使用者名稱和密碼框了，所以沒登入一次就清除一次瀏覽器的快取，下面是清除瀏覽器快取的 from selenium import webdriver from ...