在瀏覽器中輸入一個網址後，發生了什麼？

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

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

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

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

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

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

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

第六步 頁面顯示完成後，瀏覽器發送異步請求。

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

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

瀏覽器緩存 首先是查找瀏覽器緩存,瀏覽器會緩存DNS記錄一段時間，不一樣瀏覽器保存的時常不等（2分鐘到30分鐘不等）。 

系統緩存 若是在瀏覽器緩存裏沒有找到須要的記錄，瀏覽器會作一個系統調用來查找這個網址的對應DNS信息。 

路由器緩存 若是在系統緩存裏沒有找到找到對應的IP，請求會發向路由器，它通常會有本身的DNS緩存。 

ISP DNS服務器 若是在路由器緩存裏仍是沒有對應的IP，請求會被髮送到ISP。 

根域名服務器 若是仍是沒有，請求將發向根域名服務器進行搜索。找不到就說明此域名不存在。

02 瀏覽器根據解析獲得的IP地址向 web 服務器發送一個 HTTP 請求

可能會重定向響應

       例如「http://facebook.com/」，服務器會給瀏覽器響應一個301永久重定向響應，這樣瀏覽器就會訪問「http://www.facebook.com/」 而非「http://facebook.com/」。

服務器重定向的緣由有不少，舉其中兩個： 

       一：跟搜索引擎排名有關。你看，若是一個頁面有兩個地址，就像「http://www.facebook.com/」 和「http://facebook.com/」。搜索引擎會認爲它們是兩個網站，結果形成每個的搜索連接都減小從而下降排名。 

       二：不一樣的地址會形成緩存友好性變差。當一個頁面有好幾個名字時，它可能會在緩存裏出現好幾回。

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

       瀏覽器會發送另外一個獲取請求到」http://www.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代碼會給服務器發送異步請求。這個異步請求發送給特定的地址，它是一個按照程式構造的獲取或發送請求。

相關擴展：

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只能用於具備廣播能力的網絡。