有一篇比較詳細(xì)的文章
https://zrj.me/archives/tag/%E4%BB%8E%E7%82%B9%E5%87%BB%E5%88%B0%E5%91%88%E7%8E%B0
這是一個(gè)經(jīng)典的互聯(lián)網(wǎng)問題，涉及面非常廣泛。為了整理思路，在此記錄拙見。
1.瀏覽器接收URL
URL包含的信息：協(xié)議、網(wǎng)絡(luò)地址:端口號(hào)、資源路徑、查詢字符串？、片段標(biāo)識(shí)符#
2.將URL與緩存進(jìn)行比對(duì)如果請(qǐng)求的頁(yè)面在緩存中且未過期，則直接進(jìn)行第8步
緩存分為徹底緩存和緩存協(xié)商，這里的確認(rèn)是否過期是指徹底緩存（緩存失效之前不再需要跟服務(wù)器交互）。
2.1 徹底緩存的機(jī)制（http首部字段）：cache-control，Expires
--Expires是一個(gè)絕對(duì)時(shí)間，即服務(wù)器時(shí)間。瀏覽器檢查當(dāng)前時(shí)間，如果還沒到失效時(shí)間就直接使用緩存文件。但是該方法存在一個(gè)問題：服務(wù)器時(shí)間與客戶端時(shí)間可能不一致。因此該字段已經(jīng)很少使用，現(xiàn)在基本用cache-control進(jìn)行判斷。
--cache-control中的max-age保存一個(gè)相對(duì)時(shí)間。例如Cache-Control: max-age = 484200，表示瀏覽器收到文件后，緩存在484200s內(nèi)均有效。 如果同時(shí)存在cache-control和Expires，瀏覽器總是優(yōu)先使用cache-control。
cache-control還有其他指令：
（請(qǐng)求/響應(yīng)指令）
no-cache,使用緩存前必須和服務(wù)器進(jìn)行確認(rèn)，也就是需要發(fā)起請(qǐng)求。
no-store,不緩存；
（響應(yīng)指令）
public，緩存文件保存在緩存服務(wù)器上，且其他用戶也可以訪問；
private，只有特定用戶才能訪問該緩存資源。
2.2 當(dāng)緩存過期時(shí)，瀏覽器會(huì)向服務(wù)器發(fā)起請(qǐng)求詢問資源是否真正過期，這就是緩存協(xié)商。對(duì)應(yīng)http首部字段：last-modified，Etag
--last-modified是第一次請(qǐng)求資源時(shí)，服務(wù)器返回的字段，表示最后一次更新的時(shí)間。下一次瀏覽器請(qǐng)求資源時(shí)就發(fā)送if-modified-since字段。服務(wù)器用本地Last-modified時(shí)間與if-modified-since時(shí)間比較，如果不一致則認(rèn)為緩存已過期并返回新資源給瀏覽器；如果時(shí)間一致則發(fā)送304狀態(tài)碼，讓瀏覽器繼續(xù)使用緩存。當(dāng)然，用該方法也存在問題，比如修改時(shí)間有變化但實(shí)際內(nèi)容沒有變化，而服務(wù)器卻再次將資源發(fā)送給瀏覽器。所以，使用Etag進(jìn)行判斷更好。
--Etag：資源的實(shí)體標(biāo)識(shí)（哈希字符串），當(dāng)資源內(nèi)容更新時(shí)，Etag會(huì)改變。服務(wù)器會(huì)判斷Etag是否發(fā)生變化，如果變化則返回新資源，否則返回304。
緩存協(xié)商的過程需要發(fā)起一起HTTP請(qǐng)求，如果返回304則繼續(xù)使用緩存。對(duì)于移動(dòng)端一次請(qǐng)求還是有代價(jià)的，所以我們需要避免304。
對(duì)于很少進(jìn)行更改的靜態(tài)文件，可以在文件名中加入版本號(hào)，如get.v1.js，并且把Cache-Control的max-age設(shè)置成一年半載，這樣就不會(huì)發(fā)送請(qǐng)求。
需要注意的是，當(dāng)這些文件更新的時(shí)候，我們需要更新其版本號(hào)，這樣瀏覽器才會(huì)到服務(wù)器下載新資源。
2.3 貼一個(gè)緩存機(jī)制的圖（來自淺談Web緩存）
[圖片上傳失敗...(image-ae111e-1516714845686)]
2.4 除了http首部設(shè)置緩存，HTML5的manifest文件也可以設(shè)置緩存。但現(xiàn)在已經(jīng)被標(biāo)準(zhǔn)舍棄，也就沒有討論的必要。
3.如果網(wǎng)絡(luò)地址不是一個(gè) IP 地址，通過DNS解析域名返回一個(gè)IP地址
3.1 DNS協(xié)議：
DNS數(shù)據(jù)庫(kù)是域名和IP地址相互映射的一個(gè)分布式數(shù)據(jù)庫(kù)，DNS協(xié)議用來將域名轉(zhuǎn)換為IP地址，它運(yùn)行在UDP協(xié)議之上。為什么選擇UDP而非TCP？原因如下：UDP無需連接，時(shí)效性更好，進(jìn)行一次查詢只需要兩個(gè)DNS包。而TCP需要先用3個(gè)包建立連接，再用2個(gè)DNS包進(jìn)行查詢，最后用4個(gè)包斷開連接，連接成本遠(yuǎn)大于查詢本身，容易讓DNS服務(wù)器不堪重負(fù)。
3.2 DNS查詢：
操作系統(tǒng)會(huì)先檢查本地hosts文件是否有這個(gè)網(wǎng)址映射關(guān)系，如果有就調(diào)用這個(gè)IP地址映射，完成域名解析。
否則，查找本地DNS解析器緩存，如果查找到則返回。
否則，查找本地DNS服務(wù)器，如果查找到則返回。
否則，1）未用轉(zhuǎn)發(fā)模式，按根域服務(wù)器 ->頂級(jí)域,.com->第二層域，example.com ->子域，www.example.com的順序找到IP地址。2）用轉(zhuǎn)發(fā)模式，按上一級(jí)DNS服務(wù)器->上上級(jí)->....逐級(jí)向上查詢找到IP地址。
4.瀏覽器與服務(wù)器通過三次握手(SYN,SYN/ACK,ACK)建立TCP 連接
[圖片上傳失敗...(image-13123e-1516714845686)]
為什么需要進(jìn)行三次握手，而不是兩次握手？
原因是兩次握手不可靠。比如，瀏覽器發(fā)送一個(gè)連接請(qǐng)求包A，但包A在半路上堵車了，瀏覽器就認(rèn)為包A丟失了，所以重新發(fā)生一個(gè)請(qǐng)求包B給服務(wù)器。服務(wù)器收到請(qǐng)求，建立連接。兩端進(jìn)行通信，結(jié)束后關(guān)閉連接。但是這時(shí)候，包A到達(dá)了服務(wù)器，服務(wù)器不知道這是一個(gè)無效的包，所以進(jìn)行響應(yīng)。這時(shí)兩次握手已經(jīng)完成，兩端就建立起一個(gè)無效的連接。但瀏覽器認(rèn)為自己沒發(fā)出請(qǐng)求，所以不會(huì)回應(yīng)，這樣就讓服務(wù)器白白等待回應(yīng)，浪費(fèi)了服務(wù)器資源。而三次握手的機(jī)制下，瀏覽器知道自己并沒有請(qǐng)求連接，會(huì)發(fā)送拒絕包給服務(wù)器，服務(wù)器收到回應(yīng)后也會(huì)結(jié)束這次無效的連接。
5.瀏覽器向服務(wù)器發(fā)送HTTP請(qǐng)求。
數(shù)據(jù)經(jīng)過應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、物理層逐層封裝，傳輸?shù)较乱粋€(gè)目的地。
其中，每一層的作用如下。
應(yīng)用層：為應(yīng)用進(jìn)程提供服務(wù)，加應(yīng)用層首部封裝為協(xié)議數(shù)據(jù)單元。
傳輸層：實(shí)現(xiàn)端到端通信，加TCP首部封裝為數(shù)據(jù)包，TCP控制了數(shù)據(jù)包的發(fā)送序列的產(chǎn)生，不斷的調(diào)整發(fā)送序列，實(shí)現(xiàn)流控和數(shù)據(jù)完整。
網(wǎng)絡(luò)層：轉(zhuǎn)發(fā)分組并選擇路由；加IP首部封裝為IP分組。
數(shù)據(jù)鏈路層：相鄰的節(jié)點(diǎn)間的數(shù)據(jù)傳輸；加首部[mac地址]和尾部封裝為幀。
物理層：具體物理媒介中的數(shù)據(jù)傳送，數(shù)據(jù)轉(zhuǎn)換為比特流。
下一個(gè)目的地接受到數(shù)據(jù)后，從物理層得到數(shù)據(jù)然后經(jīng)過逐層的解包 到 鏈路層 到 網(wǎng)絡(luò)層，然后開始上述的處理，在經(jīng)網(wǎng)絡(luò)層 鏈路層 物理層將數(shù)據(jù)封裝好繼續(xù)傳往下一個(gè)地址。
到達(dá)最終目的地，再經(jīng)過5層結(jié)構(gòu)，逐層剝離，最終將數(shù)據(jù)送到目的主機(jī)的目的端口。
6.服務(wù)器收到請(qǐng)求，從它的文檔空間中查找資源并返回HTTP響應(yīng)。
7.瀏覽器接受 HTTP 響應(yīng)，檢查 HTTP header 里的狀態(tài)碼，并做出不同的處理方式。
比如404顯示錯(cuò)誤頁(yè)面，304使用緩存，200下一步解碼和渲染， 204頁(yè)面不會(huì)發(fā)生更新。
常見狀態(tài)碼：200 ok, 204 no content, 206 partial content
301 moved permanently(資源已分配新的uri)，302 found(本次使用新uri訪問)，303 see other(以get定向到另一個(gè)uri)，304 not modified, 307 temporary redirect(不會(huì)從post改為get)
400 bad request，402 unauthorized，403 forbidden, 404 not found
500 internal server error，503 service unavailable
8.如果是可以緩存的，這個(gè)響應(yīng)則會(huì)被存儲(chǔ)起來。
根據(jù)首部字段判斷是否進(jìn)行緩存。例如，Cache-Control, no-cache(每次使用緩存前和服務(wù)器確認(rèn))，no-store 絕對(duì)禁止緩存
9.解碼
9.1 瀏覽器拿到index.html文件后，就開始解析其中的html代碼，遇到j(luò)s/css/image等靜態(tài)資源時(shí)，就向服務(wù)器端去請(qǐng)求下載
9.2 解析成對(duì)應(yīng)的樹形數(shù)據(jù)結(jié)構(gòu)DOM樹、CSS規(guī)則樹，Javascript腳本通過DOM API和CSSOM API來操作DOM樹、CSS規(guī)則樹。
10.渲染
10.1 計(jì)算CSS樣式（JS可動(dòng)態(tài)修改dom或css,進(jìn)一步改變渲染樹和分布）
10.2 構(gòu)建渲染樹（Repaint：屏幕的一部分要重畫，比如某個(gè)CSS的背景色變了，元素的幾何尺寸沒有變。Reflow：幾何尺寸變了，我們需要重新驗(yàn)證并計(jì)算Render Tree。）
10.3 確認(rèn)布局（定位坐標(biāo)和大小，是否換行，各種position, overflow, z-index屬性 ……）
10.4 繪制（調(diào)用操作系統(tǒng)Native GUI的API繪制，將每個(gè)節(jié)點(diǎn)轉(zhuǎn)化為實(shí)際像素繪制到視口上）
11.關(guān)閉TCP連接或繼續(xù)保持連接
通過四次揮手關(guān)閉連接(FIN ACK, ACK, FIN ACK, ACK)。
[圖片上傳失敗...(image-24f881-1516714845686)]
為什么需要進(jìn)行四次揮手？
第一次揮手是瀏覽器發(fā)完數(shù)據(jù)后，發(fā)送FIN請(qǐng)求斷開連接。第二次揮手是服務(wù)器發(fā)送ACK表示同意，如果在這一次服務(wù)器也發(fā)送FIN請(qǐng)求斷開連接似乎也沒有不妥，但考慮到服務(wù)器可能還有數(shù)據(jù)要發(fā)送，所以服務(wù)器發(fā)送FIN應(yīng)該放在第三次揮手中。這樣瀏覽器需要返回ACK表示同意，也就是第四次揮手。
簡(jiǎn)而言之，一端斷開連接需要兩次揮手（請(qǐng)求和回應(yīng)），兩端斷開連接就需要四次揮手了。
參考資料：
《圖解Http協(xié)議》
《Wireshark網(wǎng)絡(luò)分析就是這么簡(jiǎn)單》
作者：minxuan
鏈接：http://www.lxweimin.com/p/71cf7f69eca8
來源：簡(jiǎn)書
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。</pre>
幾個(gè)和應(yīng)用層傳輸層和網(wǎng)絡(luò)層的文章，講的比較通俗易懂。
https://mp.weixin.qq.com/s/V1fUjSP3BwJ1CbEM0MC6pw
