此文章轉載自：https://www.cnblogs.com/SarahLiu/p/5954832.html

這是面試中一道非常經典的問題。

當你在瀏覽器中輸入一個網址，瀏覽器的處理過程如下：

第一步 瀏覽器查詢該域名的 IP 地址

第二步 瀏覽器根據解析得到的IP地址向 web 伺服器傳送一個 HTTP 請求

第三步 伺服器收到請求並進行處理

第四步 伺服器返回一個響應

第五步 瀏覽器對該響應進行解碼，渲染顯示。

第六步 頁面顯示完成後，瀏覽器傳送非同步請求。

下面對每個環節做進一步分析：

01 瀏覽器查詢該域名的 IP 地址

DNS查詢過程為：瀏覽器快取->系統快取->路由器快取->ISP DNS快取->遞迴搜尋遞迴搜尋過程為：從根域名伺服器到頂級域名伺服器到你查詢的域名伺服器。

瀏覽器快取 首先是查詢瀏覽器快取,瀏覽器會快取DNS記錄一段時間，不同瀏覽器儲存的時常不等（2分鐘到30分鐘不等）。 

系統快取 如果在瀏覽器快取裡沒有找到需要的記錄，瀏覽器會做一個系統呼叫來查詢這個網址的對應DNS資訊。 

路由器快取 如果在系統快取裡沒有找到找到對應的IP，請求會發向路由器，它一般會有自己的DNS快取。 

ISP DNS伺服器 如果在路由器快取裡還是沒有對應的IP，請求會被髮送到ISP。 

根域名伺服器 如果還是沒有，請求將發向根域名伺服器進行搜尋。找不到就說明此域名不存在。

02 瀏覽器根據解析得到的IP地址向 web 伺服器傳送一個 HTTP 請求

可能會重定向響應

伺服器重定向的原因有很多，舉其中兩個： 

       一：跟搜尋引擎排名有關。你看，如果一個頁面有兩個地址，就像“http://www.facebook.com/” 和“http://facebook.com/”。搜尋引擎會認為它們是兩個網站，結果造成每一個的搜尋連結都減少從而降低排名。 

       二：不同的地址會造成快取友好性變差。當一個頁面有好幾個名字時，它可能會在快取裡出現好幾次。

然後瀏覽器會跟蹤重定向地址 

過程：

       通過DNS獲取到IP後，目標IP和本機IP分別與子網掩碼相與的結果相同，那麼它們在一個子網，那麼通過ARP協議可以查到目標主機的MAC地址，否則的話，需要通過閘道器轉發，也就是目標MAC是閘道器的MAC。 

       請求需要進行編碼，生成一個HTTP資料包，依次打上TCP、IP、乙太網協議的頭部。其中TCP頭部主要資訊是本機埠和目標埠號等資訊，用於標識同一個主機的不同程序，對於HTTP協議，伺服器端的預設埠號是80，本機瀏覽器的話生成一個1024到65535之間的埠號。IP頭部主要包含本地IP和目標IP等資訊。乙太網協議頭部主要是雙方的MAC地址，目標MAC可以由第一條所訴方法得到。乙太網資料包的資料部分，最大長度為1500位元組，所以如果IP包太大的話還要拆包，比如IP包5000位元組，要分為4包，每一包都包含一個IP頭部。

03 伺服器收到請求並進行處理

負載均衡

       網站可能會有負載均衡裝置來平均分配所有使用者的請求。 

       負載均衡，即對工作任務進行平衡，分攤到多個操作單元上執行，如圖片伺服器，應用伺服器。可分為鏈路負載均衡，叢集負載均衡，作業系統負載均衡 

       叢集負載均衡又分為硬體負載均衡和軟體負載均衡。

CDN

       請求的資料可能儲存在分散式快取、靜態檔案或者資料庫中。如果請求的資料是靜態檔案，如果在CDN上，那麼CDN伺服器又會處理這個使用者的請求。如果在資料庫中需要向資料庫發起查詢請求。

04 伺服器返回一個響應

過程：

       伺服器返回一個 HTTP 響應，如果返回狀態碼304，瀏覽器可以直接使用之前快取的資源。對於內容響應，瀏覽器需要進行響應解碼，渲染顯示。

05 瀏覽器對該響應進行解碼，渲染顯示。

過程：

       在瀏覽器沒有完整接受全部HTML文件時，它就已經開始顯示這個頁面了，如果是個靜態的頁面，拿到此就基本結束了。如果是是動態的，那麼在瀏覽器顯示HTML時，會獲取嵌入在HTML中的物件，瀏覽器會發送獲取請求來重新獲得這些檔案。這些請求都要經歷一個和HTML讀取類似的過程。 

       對於靜態的頁面內容，瀏覽器通常會進行快取，而對於動態的內容，瀏覽器通常不會進行快取。

06 頁面顯示完成後，瀏覽器傳送非同步請求。

過程：

       頁面顯示完成後客戶端仍與伺服器端保持著聯絡。 

它會持續與伺服器保持聯絡來及時更新一些頁面資訊。在瀏覽器中執行的 JavaScript程式碼會給伺服器傳送非同步請求。這個非同步請求傳送給特定的地址，它是一個按照程式構造的獲取或傳送請求。

07 整個過程結束之後，瀏覽器關閉TCP連線。

相關擴充套件：

ARP原理

01 每個主機都會在自己的ARP緩衝區中建立一個ARP列表，以表示IP地址和MAC地址之間的對應關係。 

02 當源主機要傳送資料時，首先檢查ARP列表中是否有對應IP地址的目的主機的MAC地址，如果有，則直接傳送資料，如果沒有，就向本網段的所有主機發送ARP資料包，該資料包包括的內容有：源主機 IP地址，源主機MAC地址，目的主機的IP 地址。 

03 當本網路的所有主機收到該ARP資料包時，首先檢查資料包中的IP地址是否是自己的IP地址，如果不是，則忽略該資料包，如果是，則首先從資料包中取出源主機的IP和MAC地址寫入到ARP列表中，如果已經存在，則覆蓋，然後將自己的MAC地址寫入ARP響應包中，告訴源主機自己是它想要找的MAC地址。 

04 源主機收到ARP響應包後。將目的主機的IP和MAC地址寫入ARP列表，並利用此資訊傳送資料。如果源主機一直沒有收到ARP響應資料包，表示ARP查詢失敗。

RARP原理

       RARP是逆地址解析協議，作用是完成硬體地址到IP地址的對映，主要用於無盤工作站，因為給無盤工作站配置的IP地址不能儲存。 

       工作流程：在網路中配置一臺RARP伺服器，裡面儲存著IP地址和MAC地址的對映關係，當無盤工作站啟動後，就封裝一個RARP資料包，裡面有其MAC地址，然後廣播到網路上去，當伺服器收到請求包後，就查詢對應的MAC地址的IP地址裝入響應報文中發回給請求者。因為需要廣播請求報文，因此RARP只能用於具有廣播能力的網路。

TCP三次握手和四次揮手

TCP三次握手：

所謂的三次握手，是指建立一個TCP連線時，需要客戶端和伺服器端總共傳送三個包，三次握手的目的是連線伺服器的指定埠，建立TCP連線，並同步連線雙方的序列號和確認號並交換TCP視窗大小資訊，在SOCKET程式設計中，客戶端執行connect()時，將會觸發三次握手

解釋：

ACK：TCP協議規定，只有ACK=1時有效，也規定連線建立後所有傳送的報文的ACK必須為1

SYN：在連線建立時用來同步序號，當SYN=1而ACK=0時，表明這是一個連線請求報文，對方若同意建立連線，則應在響應報文中使SYN=1和ACK=1，因此，SYN置1就表示這是一個連線請求或連線接受報文

FIN：即終結的意思，用來釋放一個連線，當FIN=1時，表明此報文段的傳送方的資料已經發送完畢，並要求釋放連線

為什麼要進行三次握手（兩次確認）？

主要是為了防止客戶端發出的已失效的連線請求報文段突然又傳送到了伺服器端，因而產生錯誤，考慮一種正常情況，A發出連線請求，但因連線請求報文丟失而未收到確認，於是A再重傳一次連線請求，後來收到了確認，建立了連線，資料傳輸完畢後，就釋放了連線，A共傳送了兩個連線請求報文段，其中第一個丟失，第二個到達了B，正常，再考慮一種異常情況，即A發出的第一個連線請求報文段並沒有丟失，而是在某個網路節點長時間滯留了，以致延誤到連線釋放以後的某個時間才到達B，本來這是一個早已失效的報文段，但B收到此失效的連線請求報文段後，會誤以為是A又發出一次新的連線請求，於是就向A發出確認報文段，同意建立連線，假定不採用第三次握手，那麼只要B發出確認，新的連線就建立了，一直等待A傳送資料過來，使得B的許多資源就浪費了，所以採用三次握手的方法可以防止上述現象的發生，在剛才的情況下，A不會向B發出第二次確認，B由於收不到確認，就知道A並沒有要求建立連線

TCP四次揮手：

TCP連線的拆除需要傳送四個包，客戶端或者伺服器端均可主動發起揮手動作，在SOCKET程式設計中，任何一方執行close()即可產生揮手操作

解釋：當A沒有資料要傳送時，就要釋放A這邊的連線，A會發送一個報文（沒有資料），B收到後會給應用程式一個信，這時候A那邊的連線已經關閉，即A不再發送資訊（但仍可接收資訊），A收到B的確認後進入等待狀態，等待B請求釋放連線，B資料傳送完成後就向A請求連線釋放，A收到後回覆一個確認資訊，並等待2MSL時間

為什麼要等待呢？

考慮到這種情況，B向A傳送釋放連線請求，但這個報文丟失了，A沒有接收到不會發送確認資訊，B超時會重傳，這時A在等待時間內還能夠接收到這個請求，再回復一個確認就行了

另外伺服器B存在一個保活狀態，如果A突然宕機了，保活時間到了後，B會發送探測資訊，以決定是否釋放連線

常見的狀態程式碼、狀態描述：

200 客戶端請求成功

400 客戶端請求有語法錯誤，不能被伺服器理解

401 請求未經授權

403 伺服器收到請求，但是拒絕提供服務

404 請求資源不存在

500 伺服器發生了不可預期的錯誤

503 伺服器當前不能處理客戶端請求，一段時間後可能恢復正常