前端關於網路協議的入門，接觸得最多最主要的就是http協議。瀏覽器與伺服器之間的通訊協議，從瀏覽器發出請求，由伺服器響應請求。**如下：
http報文是瀏覽器與伺服器之間通訊的載體（資料塊），由報文首部（附加資訊，如cookie、快取資訊等）和報文主體（傳輸的資料內容）構成。
請求報文：`瀏覽器 => 伺服器`；報文首部構成：請求行（http方法、uri、http版本）、請求首部字段、其他；
響應報文：`伺服器 => 瀏覽器`；報文首部構成：狀態行（http版本、狀態碼）、響應首部字段、其他；
資源快取在瀏覽器記憶體中，記憶體大小受限，後開啟的 tab 會釋放前 tab 的記憶體；僅作用於當前 tab，關閉即刻釋放；優先順序高於 disk cache；記憶體快取的控制權在瀏覽器，前後端都不能干涉。
快取在硬碟（實際的檔案系統）當中，持久快取；受上限影響會清除；因為涉及檔案的 io 操作，會比 memory cache 慢；嚴格遵守http響應頭字段來判斷哪些資源是否要被快取，哪些資源是否已經過期；硬碟快取的控制權在後端。
本質是作為伺服器與客戶端之間的**伺服器，伴隨著pwa出現。service worker 真正意義上將快取控制權交給了前端，相比於localstorage、sessionstorage，後兩者只是單純的介面資料快取，例如使用者資訊（乙個物件）、列表資訊（乙個陣列），而前者可以快取靜態資源，甚至攔截網路請求，根據網路狀況作出不同的快取策略。
在快取資料未失效時，直接使用快取資料，不向伺服器傳送請求。強快取分為兩種：expires & cache-control。
伺服器告訴瀏覽器快取資料的過期時間（gmt，格林尼治時間）。當瀏覽器判斷時間沒有超過expires設定的過期時間時，則繼續使用當前的快取資料。衍生出來的問題就是，當瀏覽器時間和伺服器時間不同步的時候，快取機制失效。由於expires是http1.0的東西，而現在的瀏覽器預設的http版本為1.1，所以它的作用基本被忽略了。
伺服器告訴瀏覽器乙個過期的相對時間 `max-age=$`，瀏覽器通過接收響應的時間和這個相對時間進行計算，來判斷是否讀取本地的快取資料。這樣就解決了expires中的時間不同步問題，優先順序高於expires的絕對時間。
cache-control 的主要屬性，可組合使用：
強快取的問題在於它的強制性，時間未到，就不會向伺服器傳送請求。這樣一刀切的方式會導致資料更新不及時的問題和資料無變化導致的網路資源浪費。
因此通過協商快取來規避這樣的問題，節省伺服器資源。**如下：
協商快取通過兩組報文首部字段結合使用：
問題：為了解決時間不精確的問題，瀏覽器和伺服器再次協商，而這次著重於唯一識別符號etag。請求過程：
當既沒有設定 max-age 相對時間，也沒有設定 exprires 絕對時間的時候，瀏覽器依然會請求快取的內容，而不是請求伺服器走。
啟發式快取策略，它的計算方式為根據響應頭中2個時間字段 date 和 last-modified 之間的時間差值，取其值的10%作為快取時間週期。
1、開啟新視窗：如果命中了強快取，則請求 disk cache；否則請求伺服器；
2、重新整理：如果存在快取，優先命中 memory cache，其次是 disk cache；否則請求伺服器；
3、強制重新整理：請求伺服器獲取最新資源；
前端快取 瀏覽器快取機制
瀏覽器第一次向伺服器發起該請求後拿到請求結果後,將請求結果和快取標識存入瀏覽器快取,瀏覽器對於快取的處理是根據第一次請求資源時返回的響應頭來確定的。瀏覽器中的快取作用分為兩種情況，一種是需要傳送http請求，一種是不需要傳送。expires 即過期時間 expires max age 請求時間 存在...
瀏覽器快取機制
最近在準備優化日誌請求時遇到了一些令人疑惑的問題，比如為什麼響應頭里出現了兩個 cache control 為什麼明明設定了 no cache 卻還是發請求，為什麼多次訪問時有時請求裡帶了 etag，有時又沒有帶？等等。後來查了一些資料以及同事親自驗證，總算對這些問題有了個清晰的理解，現在整理出來以...
瀏覽器快取機制
當我們瀏覽乙個頁面發現有異常時，通常考慮的就是書不是瀏覽器做了快取呢，按ctrl f5重新請求一次就能請求到沒有快取的頁面，這個是為什麼呢。首先，ctrl f5組合鍵重新整理頁面，那麼瀏覽器會直接向目標url傳送請求，而不再使用瀏覽器快取的資料。其次，當請求到達伺服器端依然有可能出現使用伺服器端的資...