為了能讓Jerry更能清楚的跟開發同仁討論快取的設定方式，於是開始幫Jerry上課什麼是網頁快取。

快取的好處

當使用者第一次瀏覽網站時，瀏覽器會下載所有網頁內容，並將部分資源（如圖片、HTML、CSS、JavaScript）存儲在本地硬碟的快取區域。

當使用者再次訪問該網站時，瀏覽器會先檢查本地的快取，如果找到了相應的資源且未過期，就會直接從快取中載入，而不是重新從伺服器下載。

當導入CDN架構後，需要被快取的物件會放置於CDN主機上，使用者端改跟CDN取得內容時，有以下優點:

1. 加速載入速度：依據CDN的特性，會引導使用者存取離他地理位置較近的主機，並將快取的資源提供給使用者，這同時也增加了使用者的體驗，對公司服務產生好感。

2. 減少網路流量： 由於許多靜態資源可以直接從CDN快取讀取，減少了從源站伺服器下載的資料量，有效降低網路流量消耗。

3. 減輕伺服器負載： 當使用者請求資源，源站主機會需要進行運算，並透過磁碟I/O去讀取或寫入相關物件。藉由CDN的架構可減少伺服器需要處理的請求，降低伺服器負載，自然就提升網站的整體性能。

Jerry問到，當網站的內容需要更新的時候，CDN跟瀏覽器怎麼知道要再去源站重新抓呢?

快取控制Cache-Control

網站物件的內容更新利用了一種時間效期的機制，這個期限可以讓瀏覽器或是提供快取的主機，重新去確認是否要更新，這樣的機制稱之為Cache-Control。

這個機制利用TTL(Time To Live 存活時間) 來設定資源保存在快取中的時間長度，當TTL 設定的秒數過後，快取的資源就會過期，瀏覽器或CDN就要重新獲取新的內容。

透過HTTP標頭 Cache-Control欄位屬性的調整，透過設定不同屬性值來進行控制，常見的有:

-Cache-Control: max-age=86400 ; cache可停留的秒數為86400秒

-Cache-Control: no-store ; 每次使用者請求此資料時，都必須向原始伺服器傳送請求以獲取新複本。此指令通常保留用於包含極其敏感資料（如銀行帳戶資訊）的資源。

-Cache-Control: no-cahce ; 每一次都要跟源站確認，如果源站回傳 304 Not Modified 就不用更新

-Cache-Control: private ; 只能由用戶端快取，而不能由中繼代理程式（如 CDN 或代理）快取。這些通常是包含私人資料的資源，例如顯示使用者個人資訊的網站。

-Cache-Control: public ; 可以被儲存在任何地方例如瀏覽器或CDN。

也請參考下圖完整的Cache-Control 流程圖，有說明到完整的判斷流程:

圖片來源：[使用 HTTP 快取，避免不必要的網路要求] (https://web.dev/articles/http-cache?hl=zh-tw)

Jerry聽到這邊感到頭痛!! 這些平常不用理會的知識，現在卻都要能理解跟應用!! 但為了能跟開發同仁相處，也只能認命學習了。

什麼是304 Not Modified

「304 Not Modified」狀態代碼是 HTTP 回應狀態碼的一部分。當網頁瀏覽器向伺服器請求資源（如網頁或圖像）時，伺服器可以使用304 狀態代碼進行回應，以表示自瀏覽器上次請求以來，所請求的資源尚未被修改。

從流程上來說當瀏覽器發出請求時，源站會回應這個物件何時被修改的，在Http 標頭中會有個Last-Modified的欄位，例如Last-Modified : Mon, 29 Mar 2021 09:50:16 GMT 。

而當物件時效過期時，就會去問源站從這個時間點以後，這個物件有沒更改過。有就更新，沒有就回 304 的 Status code通知繼續使用。

但這邊延伸了一個問題，檔案時間跟內容有無異動不一定有直接關係。因此又利用了 Etag & If-None-Match來解決了這個問題。

Etag有點是針對物件的內容計算出一個 Etag 值，即使加了一個空白也會讓eatg值改變。

當物件效期施失效後，瀏覽器就會在 request header 中帶入 If-None-Match :Etag 值 ，源站會去檢驗瀏覽器帶過來的 Etag 與最新的檔案是否相符，若不相符就更新物件。

快取策略

後續上線的時候，一定會遇到快取設定的問題，所以必須要有個策略，例如

1. 那些可以物件或檔案以及路徑，可以被快取?例如，圖檔、js、css等物件，這些物件副檔名有哪些?

2. 可以被快取的物件，存活時間要設定多久(秒 / 分 / 時 / 天)?
   -時間長:比較適合於很少更動的檔案，例如logo或是字形檔。

   -時間短:因應業務需求，更新較為頻繁的檔案例如廣告用圖檔。

   -不快取:業務單位每次更新都要立即看最新的，或是與個人機敏資料與金融交易相關的 。

3. 絕對不能被快取的物件或檔案以及路徑有哪些?例如，例如，圖形驗證、依據使用者身分經過運算產生的檔案、交易相關的結果等。

4. 參考目前源站的快取策略，只要源站的的回應說要快取的CDN就保存，這是許多客戶上線時會先採用的選項，反正就是跟現在一樣的快取設定。

5. 全站不快取，這也是初次導入CDN時會用的策略，先以不影響服務及內容的更新，後續再逐步優化。

不過別擔心，導入後可以透過平台的報表跟Dashboard來確認快取的命中率，再逐步優化就好。

明天我們就來討論，外取命中率以及平台設定原則，還有要如何清快取吧。

Jerry苦笑的回顧問，我也只是個網管，這個專案只是為了DDoS的目的導入，感覺有好多是要別的部門共同來決定的事情耶!!

此時，顧問語重心長的說道，這專案對你來說是個利用CDN進行DDoS防護的專案。

但參與這個專案的其他同仁，是基於業務面考量進行配合。有時要避免導入專案防護服務的同時，影響目前維運同仁運作的方式，當服務衍生出問題時產生更多磨擦

試想，當使用者體驗被影響時，站在第一線的客服或其他同仁被罵，你能體會嗎?

尤其貴司的電商相關的網站服務，快取的設定攸關商品圖檔或是網站最新消息的即時更新，都會對營運有直接的影響，那誰要背鍋呢?

所以理解這些東西不僅是專案上的技術與品質要求更好，更能協調各部門得出一個較佳的方案。未來進行任何的異動調整，你就能站在別的部門立場來思考，思考的面向越廣不管是工作績效還是人緣，都會越來越好啦

大家一起加油吧!!