此文章轉(zhuǎn)載自：https://www.cnblogs.com/SarahLiu/p/5954832.html
這是面試中一道非常經(jīng)典的問題。
當(dāng)你在瀏覽器中輸入一個網(wǎng)址，瀏覽器的處理過程如下：
下面對每個環(huán)節(jié)做進一步分析：
01 瀏覽器查找該域名的 IP 地址
DNS查找過程為：瀏覽器緩存->系統(tǒng)緩存->路由器緩存->ISP DNS緩存->遞歸搜索遞歸搜索過程為：從根域名服務(wù)器到頂級域名服務(wù)器到你查詢的域名服務(wù)器。
瀏覽器緩存 首先是查找瀏覽器緩存,瀏覽器會緩存DNS記錄一段時間，不同瀏覽器保存的時常不等（2分鐘到30分鐘不等）。
系統(tǒng)緩存 如果在瀏覽器緩存里沒有找到需要的記錄，瀏覽器會做一個系統(tǒng)調(diào)用來查找這個網(wǎng)址的對應(yīng)DNS信息。
路由器緩存 如果在系統(tǒng)緩存里沒有找到找到對應(yīng)的IP，請求會發(fā)向路由器，它一般會有自己的DNS緩存。
ISP DNS服務(wù)器 如果在路由器緩存里還是沒有對應(yīng)的IP，請求會被發(fā)送到ISP。
根域名服務(wù)器 如果還是沒有，請求將發(fā)向根域名服務(wù)器進行搜索。找不到就說明此域名不存在。
02 瀏覽器根據(jù)解析得到的IP地址向 web 服務(wù)器發(fā)送一個 HTTP 請求
可能會重定向響應(yīng)
例如“http://facebook.com/”，服務(wù)器會給瀏覽器響應(yīng)一個301永久重定向響應(yīng)，這樣瀏覽器就會訪問“http://www.facebook.com/” 而非“http://facebook.com/”。
服務(wù)器重定向的原因有很多，舉其中兩個：
一：跟搜索引擎排名有關(guān)。你看，如果一個頁面有兩個地址，就像“http://www.facebook.com/” 和“http://facebook.com/”。搜索引擎會認為它們是兩個網(wǎng)站，結(jié)果造成每一個的搜索鏈接都減少從而降低排名。
二：不同的地址會造成緩存友好性變差。當(dāng)一個頁面有好幾個名字時，它可能會在緩存里出現(xiàn)好幾次。
然后瀏覽器會跟蹤重定向地址
瀏覽器會發(fā)送另一個獲取請求到”http://www.facebook.com/”。
過程：
通過DNS獲取到IP后，目標IP和本機IP分別與子網(wǎng)掩碼相與的結(jié)果相同，那么它們在一個子網(wǎng)，那么通過ARP協(xié)議可以查到目標主機的MAC地址，否則的話，需要通過網(wǎng)關(guān)轉(zhuǎn)發(fā)，也就是目標MAC是網(wǎng)關(guān)的MAC。
請求需要進行編碼，生成一個HTTP數(shù)據(jù)包，依次打上TCP、IP、以太網(wǎng)協(xié)議的頭部。其中TCP頭部主要信息是本機端口和目標端口號等信息，用于標識同一個主機的不同進程，對于HTTP協(xié)議，服務(wù)器端的默認端口號是80，本機瀏覽器的話生成一個1024到65535之間的端口號。IP頭部主要包含本地IP和目標IP等信息。以太網(wǎng)協(xié)議頭部主要是雙方的MAC地址，目標MAC可以由第一條所訴方法得到。以太網(wǎng)數(shù)據(jù)包的數(shù)據(jù)部分，最大長度為1500字節(jié)，所以如果IP包太大的話還要拆包，比如IP包5000字節(jié)，要分為4包，每一包都包含一個IP頭部。
03 服務(wù)器收到請求并進行處理
負載均衡
網(wǎng)站可能會有負載均衡設(shè)備來平均分配所有用戶的請求。
負載均衡，即對工作任務(wù)進行平衡，分攤到多個操作單元上執(zhí)行，如圖片服務(wù)器，應(yīng)用服務(wù)器。可分為鏈路負載均衡，集群負載均衡，操作系統(tǒng)負載均衡
集群負載均衡又分為硬件負載均衡和軟件負載均衡。
CDN
請求的數(shù)據(jù)可能存儲在分布式緩存、靜態(tài)文件或者數(shù)據(jù)庫中。如果請求的數(shù)據(jù)是靜態(tài)文件，如果在CDN上，那么CDN服務(wù)器又會處理這個用戶的請求。如果在數(shù)據(jù)庫中需要向數(shù)據(jù)庫發(fā)起查詢請求。
04 服務(wù)器返回一個響應(yīng)
過程：
服務(wù)器返回一個 HTTP 響應(yīng)，如果返回狀態(tài)碼304，瀏覽器可以直接使用之前緩存的資源。對于內(nèi)容響應(yīng)，瀏覽器需要進行響應(yīng)解碼，渲染顯示。
05 瀏覽器對該響應(yīng)進行解碼，渲染顯示。
過程：
在瀏覽器沒有完整接受全部HTML文檔時，它就已經(jīng)開始顯示這個頁面了，如果是個靜態(tài)的頁面，拿到此就基本結(jié)束了。如果是是動態(tài)的，那么在瀏覽器顯示HTML時，會獲取嵌入在HTML中的對象，瀏覽器會發(fā)送獲取請求來重新獲得這些文件。這些請求都要經(jīng)歷一個和HTML讀取類似的過程。
對于靜態(tài)的頁面內(nèi)容，瀏覽器通常會進行緩存，而對于動態(tài)的內(nèi)容，瀏覽器通常不會進行緩存。
06 頁面顯示完成后，瀏覽器發(fā)送異步請求。
過程：
頁面顯示完成后客戶端仍與服務(wù)器端保持著聯(lián)系。
它會持續(xù)與服務(wù)器保持聯(lián)系來及時更新一些頁面信息。在瀏覽器中執(zhí)行的 JavaScript代碼會給服務(wù)器發(fā)送異步請求。這個異步請求發(fā)送給特定的地址，它是一個按照程式構(gòu)造的獲取或發(fā)送請求。
07 整個過程結(jié)束之后，瀏覽器關(guān)閉TCP連接。
相關(guān)擴展：
ARP原理
01 每個主機都會在自己的ARP緩沖區(qū)中建立一個ARP列表，以表示IP地址和MAC地址之間的對應(yīng)關(guān)系。
02 當(dāng)源主機要發(fā)送數(shù)據(jù)時，首先檢查ARP列表中是否有對應(yīng)IP地址的目的主機的MAC地址，如果有，則直接發(fā)送數(shù)據(jù)，如果沒有，就向本網(wǎng)段的所有主機發(fā)送ARP數(shù)據(jù)包，該數(shù)據(jù)包包括的內(nèi)容有：源主機 IP地址，源主機MAC地址，目的主機的IP 地址。
03 當(dāng)本網(wǎng)絡(luò)的所有主機收到該ARP數(shù)據(jù)包時，首先檢查數(shù)據(jù)包中的IP地址是否是自己的IP地址，如果不是，則忽略該數(shù)據(jù)包，如果是，則首先從數(shù)據(jù)包中取出源主機的IP和MAC地址寫入到ARP列表中，如果已經(jīng)存在，則覆蓋，然后將自己的MAC地址寫入ARP響應(yīng)包中，告訴源主機自己是它想要找的MAC地址。
04 源主機收到ARP響應(yīng)包后。將目的主機的IP和MAC地址寫入ARP列表，并利用此信息發(fā)送數(shù)據(jù)。如果源主機一直沒有收到ARP響應(yīng)數(shù)據(jù)包，表示ARP查詢失敗。
RARP原理
RARP是逆地址解析協(xié)議，作用是完成硬件地址到IP地址的映射，主要用于無盤工作站，因為給無盤工作站配置的IP地址不能保存。
工作流程：在網(wǎng)絡(luò)中配置一臺RARP服務(wù)器，里面保存著IP地址和MAC地址的映射關(guān)系，當(dāng)無盤工作站啟動后，就封裝一個RARP數(shù)據(jù)包，里面有其MAC地址，然后廣播到網(wǎng)絡(luò)上去，當(dāng)服務(wù)器收到請求包后，就查找對應(yīng)的MAC地址的IP地址裝入響應(yīng)報文中發(fā)回給請求者。因為需要廣播請求報文，因此RARP只能用于具有廣播能力的網(wǎng)絡(luò)。
TCP三次握手和四次揮手
TCP三次握手：
所謂的三次握手，是指建立一個TCP連接時，需要客戶端和服務(wù)器端總共發(fā)送三個包，三次握手的目的是連接服務(wù)器的指定端口，建立TCP連接，并同步連接雙方的序列號和確認號并交換TCP窗口大小信息，在SOCKET編程中，客戶端執(zhí)行connect()時，將會觸發(fā)三次握手
解釋：
ACK：TCP協(xié)議規(guī)定，只有ACK=1時有效，也規(guī)定連接建立后所有發(fā)送的報文的ACK必須為1
SYN：在連接建立時用來同步序號，當(dāng)SYN=1而ACK=0時，表明這是一個連接請求報文，對方若同意建立連接，則應(yīng)在響應(yīng)報文中使SYN=1和ACK=1，因此，SYN置1就表示這是一個連接請求或連接接受報文
FIN：即終結(jié)的意思，用來釋放一個連接，當(dāng)FIN=1時，表明此報文段的發(fā)送方的數(shù)據(jù)已經(jīng)發(fā)送完畢，并要求釋放連接
為什么要進行三次握手（兩次確認）？
主要是為了防止客戶端發(fā)出的已失效的連接請求報文段突然又傳送到了服務(wù)器端，因而產(chǎn)生錯誤，考慮一種正常情況，A發(fā)出連接請求，但因連接請求報文丟失而未收到確認，于是A再重傳一次連接請求，后來收到了確認，建立了連接，數(shù)據(jù)傳輸完畢后，就釋放了連接，A共發(fā)送了兩個連接請求報文段，其中第一個丟失，第二個到達了B，正常，再考慮一種異常情況，即A發(fā)出的第一個連接請求報文段并沒有丟失，而是在某個網(wǎng)絡(luò)節(jié)點長時間滯留了，以致延誤到連接釋放以后的某個時間才到達B，本來這是一個早已失效的報文段，但B收到此失效的連接請求報文段后，會誤以為是A又發(fā)出一次新的連接請求，于是就向A發(fā)出確認報文段，同意建立連接，假定不采用第三次握手，那么只要B發(fā)出確認，新的連接就建立了，一直等待A發(fā)送數(shù)據(jù)過來，使得B的許多資源就浪費了，所以采用三次握手的方法可以防止上述現(xiàn)象的發(fā)生，在剛才的情況下，A不會向B發(fā)出第二次確認，B由于收不到確認，就知道A并沒有要求建立連接
TCP四次揮手：
TCP連接的拆除需要發(fā)送四個包，客戶端或者服務(wù)器端均可主動發(fā)起揮手動作，在SOCKET編程中，任何一方執(zhí)行close()即可產(chǎn)生揮手操作
解釋：當(dāng)A沒有數(shù)據(jù)要發(fā)送時，就要釋放A這邊的連接，A會發(fā)送一個報文（沒有數(shù)據(jù)），B收到后會給應(yīng)用程序一個信，這時候A那邊的連接已經(jīng)關(guān)閉，即A不再發(fā)送信息（但仍可接收信息），A收到B的確認后進入等待狀態(tài)，等待B請求釋放連接，B數(shù)據(jù)發(fā)送完成后就向A請求連接釋放，A收到后回復(fù)一個確認信息，并等待2MSL時間
為什么要等待呢？
考慮到這種情況，B向A發(fā)送釋放連接請求，但這個報文丟失了，A沒有接收到不會發(fā)送確認信息，B超時會重傳，這時A在等待時間內(nèi)還能夠接收到這個請求，再回復(fù)一個確認就行了
另外服務(wù)器B存在一個?；顮顟B(tài)，如果A突然死機了，?；顣r間到了后，B會發(fā)送探測信息，以決定是否釋放連接
常見的狀態(tài)代碼、狀態(tài)描述：
200 客戶端請求成功
400 客戶端請求有語法錯誤，不能被服務(wù)器理解
401 請求未經(jīng)授權(quán)
403 服務(wù)器收到請求，但是拒絕提供服務(wù)
404 請求資源不存在
500 服務(wù)器發(fā)生了不可預(yù)期的錯誤
503 服務(wù)器當(dāng)前不能處理客戶端請求，一段時間后可能恢復(fù)正常
聯(lián)系客服
