老生常談-從輸入url到頁面展示到底發生了什麼

來自：鹹魚老弟 - 博客園

已獲轉載授權

閱讀目錄

1、輸入地址

2、瀏覽器查找域名的 IP 地址

3、瀏覽器向 web 伺服器發送一個 HTTP 請求

4、伺服器的永久重定向響應

5、瀏覽器跟蹤重定向地址

6、伺服器處理請求

7、伺服器返回一個 HTTP 響應

8、瀏覽器顯示 HTML

9、瀏覽器發送請求獲取嵌入在 HTML 中的資源（如圖片、音頻、視頻、CSS、JS等等）

剛開始寫這篇文章還是挺糾結的，因為網上搜索「從輸入url到頁面展示到底發生了什麼」，你可以搜到一大堆的資料。而且面試這道題基本是必考題，二月份面試的時候，雖然知道這個過程發生了什麼，不過當面試官一步步追問下去的，很多細節就不太清楚了。

最近剛好也在看http協議相關的東西，所以想對這個話題來個深入的總結，本文的目的是通過輸入url之後發生的事情來做知識的總結和擴展。所以文章可能會很雜。

總的過程大概如下:

1、輸入地址

當我們開始在瀏覽器中輸入網址的時候，瀏覽器其實就已經在智能的匹配可能得 url 了，他會從歷史記錄，書籤等地方，找到已經輸入的字元串可能對應的 url，然後給出智能提示，讓你可以補全url地址。對於 google的chrome 的瀏覽器，他甚至會直接從緩存中把網頁展示出來，就是說，你還沒有按下 enter，頁面就出來了。

2、瀏覽器查找域名的 IP 地址

1、請求一旦發起，瀏覽器首先要做的事情就是解析這個域名，一般來說，瀏覽器會首先查看本地硬碟的 hosts 文件，看看其中有沒有和這個域名對應的規則，如果有的話就直接使用 hosts 文件裡面的 ip 地址。

2、如果在本地的 hosts 文件沒有能夠找到對應的 ip 地址，瀏覽器會發出一個 DNS請求到本地DNS伺服器 。本地DNS伺服器一般都是你的網路接入伺服器商提供，比如中國電信，中國移動。

3、查詢你輸入的網址的DNS請求到達本地DNS伺服器之後，本地DNS伺服器會首先查詢它的緩存記錄，如果緩存中有此條記錄，就可以直接返回結果，此過程是遞歸的方式進行查詢。如果沒有，本地DNS伺服器還要向DNS根伺服器進行查詢。

4、根DNS伺服器沒有記錄具體的域名和IP地址的對應關係，而是告訴本地DNS伺服器，你可以到域伺服器上去繼續查詢，並給出域伺服器的地址。這種過程是迭代的過程。

5、本地DNS伺服器繼續向域伺服器發出請求，在這個例子中，請求的對象是.com域伺服器。.com域伺服器收到請求之後，也不會直接返回域名和IP地址的對應關係，而是告訴本地DNS伺服器，你的域名的解析伺服器的地址。

6、最後，本地DNS伺服器向域名的解析伺服器發出請求，這時就能收到一個域名和IP地址對應關係，本地DNS伺服器不僅要把IP地址返回給用戶電腦，還要把這個對應關係保存在緩存中，以備下次別的用戶查詢時，可以直接返回結果，加快網路訪問。

下面這張圖很完美的解釋了這一過程：

知識擴展：1)什麼是DNS？

DNS（Domain Name System，域名系統），網際網路上作為域名和IP地址相互映射的一個分布式資料庫，能夠使用戶更方便的訪問互聯網，而不用去記住能夠被機器直接讀取的IP數串。通過主機名，最終得到該主機名對應的IP地址的過程叫做域名解析（或主機名解析）。

2)DNS查詢的兩種方式：遞歸查詢和迭代查詢

1、遞歸解析

當局部DNS伺服器自己不能回答客戶機的DNS查詢時，它就需要向其他DNS伺服器進行查詢。此時有兩種方式，如圖所示的是遞歸方式。局部DNS伺服器自己負責向其他DNS伺服器進行查詢，一般是先向該域名的根域伺服器查詢，再由根域名伺服器一級級向下查詢。最後得到的查詢結果返回給局部DNS伺服器，再由局部DNS伺服器返回給客戶端。

2、迭代解析

3)DNS域名稱空間的組織方式

我們在前面有說到根DNS伺服器，域DNS伺服器，這些都是DNS域名稱空間的組織方式。按其功能命名空間中用來描述 DNS 域名稱的五個類別的介紹詳見下表中，以及與每個名稱類型的示例

（盜圖）

4)DNS負載均衡

當一個網站有足夠多的用戶的時候，假如每次請求的資源都位於同一台機器上面，那麼這台機器隨時可能會蹦掉。處理辦法就是用DNS負載均衡技術，它的原理是在DNS伺服器中為同一個主機名配置多個IP地址,在應答DNS查詢時,DNS伺服器對每個查詢將以DNS文件中主機記錄的IP地址按順序返回不同的解析結果,將客戶端的訪問引導到不同的機器上去,使得不同的客戶端訪問不同的伺服器,從而達到負載均衡的目的?例如可以根據每台機器的負載量，該機器離用戶地理位置的距離等等。

3、瀏覽器向 web 伺服器發送一個 HTTP 請求

拿到域名對應的IP地址之後，瀏覽器會以一個隨機埠（1024

TCP連接如圖所示:

建立了TCP連接之後，發起一個http請求。一個典型的 http request header 一般需要包括請求的方法，例如 GET 或者 POST 等，不常用的還有 PUT 和 DELETE 、HEAD、OPTION以及 TRACE 方法，一般的瀏覽器只能發起 GET 或者 POST 請求。

客戶端向伺服器發起http請求的時候，會有一些請求信息，請求信息包含三個部分：

| 請求方法URI協議/版本

| 請求頭(Request Header)

| 請求正文：

下面是一個完整的HTTP請求例子：

注意：最後一個請求頭之後是一個空行，發送回車符和換行符，通知伺服器以下不再有請求頭。

（1）請求的第一行是「方法URL議/版本」：GET/sample.jsp HTTP/1.1

（2）請求頭(Request Header)

請求頭包含許多有關的客戶端環境和請求正文的有用信息。例如，請求頭可以聲明瀏覽器所用的語言，請求正文的長度等。

（3）請求正文

請求頭和請求正文之間是一個空行，這個行非常重要，它表示請求頭已經結束，接下來的是請求正文。請求正文中可以包含客戶提交的查詢字元串信息：

知識擴展：

1）TCP三次握手

第一次握手：客戶端A將標誌位SYN置為1,隨機產生一個值為seq=J（J的取值範圍為=1234567）的數據包到伺服器，客戶端A進入SYN_SENT狀態，等待服務端B確認；

第二次握手：服務端B收到數據包後由標誌位SYN=1知道客戶端A請求建立連接，服務端B將標誌位SYN和ACK都置為1，ack=J+1，隨機產生一個值seq=K，並將該數據包發送給客戶端A以確認連接請求，服務端B進入SYN_RCVD狀態。

第三次握手：客戶端A收到確認後，檢查ack是否為J+1，ACK是否為1，如果正確則將標誌位ACK置為1，ack=K+1，並將該數據包發送給服務端B，服務端B檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，客戶端A和服務端B進入ESTABLISHED狀態，完成三次握手，隨後客戶端A與服務端B之間可以開始傳輸數據了。

如圖所示：

2）為什需要三次握手？《計算機網路》第四版中講「三次握手」的目的是「為了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤」

書中的例子是這樣的，「已失效的連接請求報文段」的產生在這樣一種情況下：client發出的第一個連接請求報文段並沒有丟失，而是在某個網路結點長時間的滯留了，以致延誤到連接釋放以後的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段後，就誤認為是client再次發出的一個新的連接請求。於是就向client發出確認報文段，同意建立連接

假設不採用「三次握手」，那麼只要server發出確認，新的連接就建立了。由於現在client並沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送數據。但server卻以為新的運輸連接已經建立，並一直等待client發來數據。這樣，server的很多資源就白白浪費掉了。採用「三次握手」的辦法可以防止上述現象發生。例如剛才那種情況，client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立連接。」。主要目的防止server端一直等待，浪費資源。

3）TCP四次揮手

第一次揮手：Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。

第二次揮手：Server收到FIN後，發送一個ACK給Client，確認序號為收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。

第三次揮手：Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。

第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接著發送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態，完成四次揮手。

4）為什麼建立連接是三次握手，而關閉連接卻是四次揮手呢？

這是因為服務端在LISTEN狀態下，收到建立連接請求的SYN報文後，把ACK和SYN放在一個報文里發送給客戶端。而關閉連接時，當收到對方的FIN報文時，僅僅表示對方不再發送數據了但是還能接收數據，己方也未必全部數據都發送給對方了，所以己方可以立即close，也可以發送一些數據給對方後，再發送FIN報文給對方來表示同意現在關閉連接，因此，己方ACK和FIN一般都會分開發送。

4、伺服器的永久重定向響應

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

為什麼伺服器一定要重定向而不是直接發送用戶想看的網頁內容呢？其中一個原因跟搜索引擎排名有關。如果一個頁面有兩個地址，就像http://www.yy.com/和http://yy.com/，搜索引擎會認為它們是兩個網站，結果造成每個搜索鏈接都減少從而降低排名。而搜索引擎知道301永久重定向是什麼意思，這樣就會把訪問帶www的和不帶www的地址歸到同一個網站排名下。還有就是用不同的地址會造成緩存友好性變差，當一個頁面有好幾個名字時，它可能會在緩存里出現好幾次。

擴展知識1）301和302的區別。

301和302狀態碼都表示重定向，就是說瀏覽器在拿到伺服器返回的這個狀態碼後會自動跳轉到一個新的URL地址，這個地址可以從響應的Location首部中獲取（用戶看到的效果就是他輸入的地址A瞬間變成了另一個地址B）——這是它們的共同點。

他們的不同在於。301表示舊地址A的資源已經被永久地移除了（這個資源不可訪問了），搜索引擎在抓取新內容的同時也將舊的網址交換為重定向之後的網址；

302表示舊地址A的資源還在（仍然可以訪問），這個重定向只是臨時地從舊地址A跳轉到地址B，搜索引擎會抓取新的內容而保存舊的網址。 SEO302好於301

2）重定向原因：

（1）網站調整（如改變網頁目錄結構）；

（2）網頁被移到一個新地址；

（3）網頁擴展名改變(如應用需要把.php改成.Html或.shtml)。

這種情況下，如果不做重定向，則用戶收藏夾或搜索引擎資料庫中舊地址只能讓訪問客戶得到一個404頁面錯誤信息，訪問流量白白喪失；再者某些註冊了多個域名的網站，也需要通過重定向讓訪問這些域名的用戶自動跳轉到主站點等。

3）什麼時候進行301或者302跳轉呢？

當一個網站或者網頁24—48小時內臨時移動到一個新的位置，這時候就要進行302跳轉，而使用301跳轉的場景就是之前的網站因為某種原因需要移除掉，然後要到新的地址訪問，是永久性的。

清晰明確而言：使用301跳轉的大概場景如下：

1、域名到期不想續費（或者發現了更適合網站的域名），想換個域名。

2、在搜索引擎的搜索結果中出現了不帶www的域名，而帶www的域名卻沒有收錄，這個時候可以用301重定向來告訴搜索引擎我們目標的域名是哪一個。

3、空間伺服器不穩定，換空間的時候。

5、瀏覽器跟蹤重定向地址

6、伺服器處理請求

經過前面的重重步驟，我們終於將我們的http請求發送到了伺服器這裡，其實前面的重定向已經是到達伺服器了，那麼，伺服器是如何處理我們的請求的呢？

後端從在固定的埠接收到TCP報文開始，它會對TCP連接進行處理，對HTTP協議進行解析，並按照報文格式進一步封裝成HTTP Request對象，供上層使用。

一些大一點的網站會將你的請求到反向代理伺服器中，因為當網站訪問量非常大，網站越來越慢，一台伺服器已經不夠用了。於是將同一個應用部署在多台伺服器上，將大量用戶的請求分配給多台機器處理。此時，客戶端不是直接通過HTTP協議訪問某網站應用伺服器，而是先請求到Nginx，Nginx再請求應用伺服器，然後將結果返回給客戶端，這裡Nginx的作用是反向代理伺服器。同時也帶來了一個好處，其中一台伺服器萬一掛了，只要還有其他伺服器正常運行，就不會影響用戶使用。

如圖所示：

通過Nginx的反向代理，我們到達了web伺服器，服務端腳本處理我們的請求，訪問我們的資料庫，獲取需要獲取的內容等等，當然，這個過程涉及很多後端腳本的複雜操作。由於對這一塊不熟，所以這一塊只能介紹這麼多了。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！