又一個老生常談的問題，但的確能引申出很多內容，從這個問題入手能復習或者學到很多知識點，開始分析~（提前說明，默認URL使用HTTPS/HTTP協議）
對于這一個程序應該有一個大概的骨架，然后再是回憶里面的具體細節
總體流程如下，每一部分細節后面補充~：
-
查找瀏覽器快取：如果查找到快取中有我們URL對應的檔案，則判斷是否命中強快取，如果命中直接讀取使用即可，如果強快取沒有命中，判斷協商快取是否命中，但協商快取不論是否命中都會發送請求，所以都會走下面的步驟
-
DNS域名決議：將輸入的URL決議成對應的IP地址
-
生成HTTP請求報文：請求報文包括起始行，首部，主體
-
TCP連接：客戶端與服務端進行TCP三次握手，建立連接
-
發送HTTP請求：握手成功后，客戶端向服務端發送http請求，請求資料
-
服務器收到請求并回傳資料：客戶端根據回傳的結果進行渲染展示，同時判斷是否需要將檔案存入快取
-
TCP斷開連接：客戶端與服務端進行TCP四次揮手，斷開連接
一.查找瀏覽器快取：
如果是第一次請求肯定在快取找不到檔案啦（先在memory cache也就是記憶體中找，再在disk cache也就是磁盤中找），那之后的請求為什么能找到呢
因為第一次請求時如果服務器端在對應的請求介面中設定了回應頭里的Cache-Control:max-age或者Expires,Last-Modified（最后修改時間） 或者etag（其實就是一個比檔案最后修改時間判斷是否修改更精確的一個標識，通常會用檔案的md5值），瀏覽器第一次請求到之后就會將檔案及這些資訊快取下來，再次請求的時候就會先判斷max-age有沒有過期（沒有max-age就找Expires，兩者同時存在前者優先級更高），如果沒有過期，則強快取命中，回傳200（from disk cache或者from memory cache）;如果已經過期，則會發起一個請求，請求頭中帶上If-None-Match（值就是上一次服務器回傳的etag）或者If-Modified-Since（值就是上一次服務器回傳的Last-Modified ），去比對服務器中要請求的檔案的etag或者last-modified（注意如果兩者同時存在，前者的優先級會更高），判斷檔案到底有沒有修改，如果沒有修改，則使用本地快取的就好了，回傳304（from disk cache或者from memory cache），如果修改過了，再從服務器中重新請求，并修改etag或者last-modified，回傳200
看兩張圖，走一遍流程~
第一次請求某個URL資源檔案
注意這里的Expires是http1.0的屬性，已經被http1.1的max-age所替代了，只有沒有設定max-age的時候才回去找Expires
再次請求
為了加深理解，我在本地自己的一個專案演示了一下，
現在我這個服務器介面回傳的回應頭設定了Cache-Control:max-age是一年的時間
重啟服務器再運行我的專案，點開瀏覽器除錯，
在Network中可以看到第一次請求這個介面的資源的時候，回傳的是200 OK，
當我第二次去請求的時候，
可以看到狀態碼就變成了 200 （from disk cache），也就是從磁盤中讀取的快取檔案 這樣就是命中強快取啦
接著來試一下協商快取
現在我把Cache-control中的max-age設成了0，也就是每次請求的時候強快取都會失敗，我又接著設定了Last-modified屬性，etag就先不寫了，道理也是一樣的
那我們再接著去瀏覽器中看一下現在的請求結果~
可以看到這個時候回應頭中就帶上了Last-Modified
再次請求試一下~
驗證成功~現在的請求頭已經帶上了If-Modified-Since，瀏覽器會判斷是否和Last-Modified是否相等，現在判斷是相等的也就是命中了協商快取，回傳304，從本地讀取快取，
補充一點：上文說了快取會存在兩個地方，memory cache或者disk cache，一般來說需要經常讀取的檔案，比如圖片，JS會存在memory cache，不會經常讀取的比如css檔案會存在disk cache中
二.DNS域名決議
查找主機中的瀏覽器中DNS快取，快取中維護了一張域名和IP地址的對應表
查找主機中的作業系統中的DNS快取，就存在C:\Windows\System32\drivers\etc目錄下的hosts檔案
查詢本地域名服務器，注意主機和本地域名服務器為遞回查詢，也就是主機需要的Ip地址一定要從本地域名服務器查詢獲得，不論他是自身查到的還是繼續向上從哪一級獲取的
如果本地域名服務器沒有查詢到，向根域名服務器發起迭代查詢，根域名服務器會回傳他一個權限域名服務器的地址，然后再去向權限域名服務器迭代查詢，得到最終的IP地址
本地域名服務器得到IP地址后回傳給主機的作業系統，作業系統快取后，交給瀏覽器，瀏覽器同時也存在維護域名-IP地址的表中
哎(′ο｀*))) 這篇文章內容好像有點多了…TCP三次握手和四次揮手內容就放到之后的文章專門說吧，先放兩個圖￣□￣｜｜
三.TCP三次握手
四.TCP四次揮手
感謝閱讀！歡迎指正~ 覺得寫得還不錯可以關注我的公眾號：西元前的小鐵匠
參考：
瀏覽器快取機制
博客園 吳秦（Tyler）
臥槽！牛皮了，頭一次見有大佬把TCP/IP三次握手四次揮手解釋的這么明白
知乎 愛前端不愛戀愛
超詳細 DNS 協議決議
掘金 飛天小牛肉
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/292824.html
標籤：其他
上一篇：VirtualKD + VMWare雙機除錯（失敗）
下一篇：Orange網關