http 快取分為強快取和協商快取.
// 當前頁面不快取, 每次訪問都去伺服器拉取. 只有部分瀏覽器支援.由於具體時間沒有轉換到正確的時區有可能造成錯誤. 所以傾向於使用 cache-control: max-age如果強快取沒有命中的話, 則進入協商快取
判斷的字段: last-modified 或 etag
last-modified/if-modified-since
瀏覽器第一次請求資料之後,服務端在 response headers 會帶上 last-modified (服務端資源最後修改時間).
再次請求時, 請求頭會帶上 if-modified-since 去跟伺服器資源的最後修改時間對比. 如果修改, 返回 200 , 否則返回 304 .
第一次請求資料的時候, response headers 帶上 etag . (etag 由服務端生成一段 hash 字段)
之後的請求帶上 if-none-match: 原etag 的值.
last-modified 和 etag 區別
last-modified 和 etag 優先順序
先判斷 etag, 再判斷 last-modified. 但是結果會由伺服器決策.
一張圖總結流程:我們可以在 chrome 的開發者工具中，network -> size 一列看到乙個請求最終的處理方式：如果是大小 (多少 k， 多少 m 等) 就表示是網路請求，否則會列出 from memory cache, from disk cache 和 from serviceworker。乙個請求在查詢資源的過程中經過的快取順序
http cache/disk cache (硬碟上的快取)
push cache
一般資源會存入記憶體. 如果記憶體不夠, 會釋放一些.首次請求走網路請求
再次請求 (f5)
三個請求都來自 memory cache。因為我們沒有關閉 tab，所以瀏覽器把快取的應用加到了 memory cache。(耗時 0ms，也就是 1ms 以內)
關閉 tab，開啟新 tab 並再次請求
永久快取: 帶 hash 值的靜態 js, css資源永久快取. cache-control : max-age=3153600 一年過期時間
對 index.html 使用 cache-control: no-cache
幸運的是，關於協商快取你無需管理，無需配置， nginx 或者一些 oss 都會自動配置協商快取，而對於協商快取，也有它們自己的演算法。協商快取背後是基於 last-modified/etag。瀏覽器每次請求資源時，會攜帶上次伺服器響應的 etag/last-modified 作為標誌，與服務端此時的 etag/last-modified 作比較，來判斷內容更改。
關注「前端加加」, 第一時間獲取優質文章.建立新使用者
新增新使用者 允許本地 ip 訪問 localhost,127.0.0.1 create user test localhost identified by 123456 允許外網 ip 訪問 create user test identified by 123456 為新使用者分配許可權 授予使用...
新使用者註冊
第一步 新增新好友，實驗步驟5 伺服器端處理新增好友的訊息。if mess.getmessagetype equals message.message addfriend elseelse sendmessage s,mess 傳送到客戶端 第二部 第一張卡片，建立物件 myfriendpanel ...
VSTS 強制TFS更新使用者組許可權
無論你是使用工作組模式還是域的模式部署你的tfs服務，你都會碰到這樣的情況。一般我們會建立乙個專門的使用者組，作為某個專案團隊，比如 projectteam1，然後把使用者加入這個組，再在tfs中將這個組加入某個許可權組，這樣我們可以最大限度的減少在tfs中配置許可權的工作量，但是你會發現當你建立了...
