1 正向**與方向**
正向**： **客戶端請求，如 請求goggle被拒絕，可以搭建乙個**伺服器，再轉向 谷歌
反向**： **服務端，如ngix，指向**伺服器後，**到其他的伺服器
2 快取
快取網路資源，當請求的資源被快取後，可以攔截請求，返回資源的拷貝，用來緩解伺服器壓力，提公升效能。
大致分為私有與共享快取
快取驗證確認
cache-control: must-revalidate 意味著快取在考慮使用乙個陳舊的資源時，必須驗證她的狀態，已過期的快取將不被使用
快取驅逐
快取只有有限的空間儲存資源副本，所以快取會定期的將一些副本刪除，這個過程叫快取驅逐，當伺服器上的資源進行了更新，那麼快取的資源也應該被更新，
但是不可能直接通知客戶端進行更新快取，所以雙方必須為該資源約定乙個過期時間，在該時間之前資源就是新鮮的，過了時間之後資源就是陳舊的，
驅逐演算法用於將陳舊的資源變成新鮮的資源，乙個陳舊的資源是不會直接被清除或忽略的，當客戶端發起請求後，快取檢索到已有乙個對應的陳舊資源，則
快取會先將此請求附加乙個if-none-match，然後發給目標伺服器，一次來檢查該資源副本是否還是新鮮的，若伺服器返回304（not-modified）（該響應
不會帶有試題資訊），則表示該資源副本是新鮮的，這樣一來，可以節省一些寬頻，若服務端通過if-none-match或if-modified-since判斷後發現已過期，
那麼會帶有實體內容返回。
對於含有特定資訊的請求，會計算快取壽命，比如cache-control: max-age=n,相應的快取的壽命就是n，通常情況下，對於不含這個屬性的則會去檢視
是否包含expires屬性，通過比較expires和頭裡面的date屬性的值判斷是否快取有效，如果max-age和expires屬性都沒有，找找頭裡面的last-modified
如果有嗎，快取的壽命就是頭裡面date的值減去last-modified的值除以10，
快取驗證
使用者點選重新整理按鈕是會觸發驗證，如果換快取的響應頭資訊含有cache-control：must-revalidate，那麼在瀏覽的過程中也會觸發快取驗證，
當快取的文件過期後，需要進行快取驗證或者重新獲取資源，只有伺服器返回強校驗或者弱校驗時候才會驗證
etags
作為快取的一種強強校驗器，如果資源請求的響應頭含有etag，客戶端就可以在後續的請求頭中帶上if-none-match頭來驗證快取。
last-modified響應頭可以作為一種弱校驗器，說他弱是因為他只能精確到一秒。如果響應頭里包含這個資訊，客戶端可以再後續的請求上
帶上if-modified-since來驗證快取
當服務端發起快取校驗請求時，服務端返回200或者304 表示瀏覽器可以使用本地快取，304的響應頭可以同時更新快取檔案的過期時間
待vary頭的響應
當快取伺服器收到乙個請求，只有當前的請求和原始快取的請求頭跟快取的響應頭裡面的vary都匹配的時候，才能使用快取的響應
如vary：user-agent 因為移動端與桌面的客戶端請求頭ua不一樣，快取伺服器不會錯誤的把移動端的內容輸入到桌面端到使用者
這篇文章推薦一下
App PHP快取抓取http快取
解決方案方案分為兩部分 業務線中讀取php快取，寫入redis 在指令碼中，取出redis快取 寫入log檔案 如下。var繼承的子類如有構造方法 記得呼叫父類方法 驗證登入 public function construct 記錄日誌 public function destruct page層使...
前端快取之HTTP快取
說真的，當自己還很小白的時候，明明修改了js的內容了，但是就是沒有載入成功，那時候感覺好神奇，好沒道理。後來知道了這是因為快取的原因。說實話，現在基於各種框架的開發，基本上沒有在業務 過程中關注快取的事情了，當然，不包括使用localstorage和cookie。今天自己學習了一些關於前端快取的東西...
前端快取總結 HTTP快取
在前端面試中，可能或多或少都會被提及快取問題，而這個問題大多數都是作為業務中不得不考慮的乙個效能優化點，如果平時沒有怎麼關注或是特意去了解這塊的童鞋們，可能就是不太了解其中的原由，那麼今天我們就這個快取問題來細細分析，幫助一些還不是太明白的或是剛入門的前端童鞋們梳理梳理，理解理解，那就話不多說，開始...