一、前言

在瀏覽器的地址欄輸入一個 URL 后回車，背后到底發生了什么才能使得一個界面完美的展現在我們眼前？

今天講解的這道題目，由于其涉及大量網絡協議，可以非常直觀的看出諸位小伙伴對計算機網絡體系的整體把握程度，所以自然成為了各大公司的面試常客。

在瀏覽中輸入 URL 并且獲取響應的過程，其實就是瀏覽器和該 URL 對應的服務器的網絡通信過程。比如我們輸入 www.baidu.com，那么會返回一個百度搜索的界面，這其實就是瀏覽器和百度服務器之間的網絡通信過程。瀏覽器就是客戶端，用于發出請求，而百度的服務器就是服務端，用于接收并響應請求。

下面我們就來詳細講解這個龐大的網絡通信過程。

二、解析 URL

不知道有沒有同學會混淆域名和 URL 的概念，可以這樣理解，URL 就是我們輸入的網址，而網址里面含有域名。舉個例子：www.baidu.com/veal98 是一個網址，而 www.baidu.com 就是服務器的域名。

URL 各元素的組成如下（當然，下述請求文件的路徑名可以省略）：

這個 URL 請求的目標服務器上的文件路徑就是：

那么首先，瀏覽器做的第一步就是解析 URL 得到里面的參數，將域名和需要請求的資源分離開來，從而了解需要請求的是哪個服務器，請求的是服務器上什么資源等等。

三、瀏覽器封裝 HTTP 請求報文

對 URL 進行解析之后，瀏覽器確定了目標服務器和文件名，接下來就需要根據這些消息封裝成一個 HTTP 請求報文發送出去。舉個 HTTP 請求報文的例子：

解釋一下封裝，這是一個貫穿整個計算機網絡的概念。就是說發送端在層與層之間傳輸數據時，每經過一層必定會被打上一個該層所屬的首部信息。反之，接收端在層與層之間傳輸數據時，每經過一層就會把該層對應的首部信息消去。

四、DNS 域名解析獲取 IP 地址

封裝好 HTTP 請求報文后，在正式還有一項準備工作沒有做，那就是獲取目標服務器的 IP 地址。

雖然解析得到了域名，理論瀏覽器已經知道目標服務器是誰了。但是實際上，域名并不是目標服務器真正意義上的地址，互聯網上每一臺計算機都被全世界唯一 IP 地址標識著，但是 IP 地址并不方便記憶，所以才設計出了域名。

那么就需要解析域名獲取目標服務器的 IP 地址。不然空有一個方便記憶的域名咋知道這個請求到底發送到哪里去呢。由域名轉換得到 IP 地址就是 DNS 協議做的事情，如下：

1）首先搜索瀏覽器的 DNS 緩存，緩存中維護著一張域名與 IP 地址的對應表；

2）若沒有命中，則繼續搜索操作系統的 DNS 緩存；

3）若仍然沒有命中，則操作系統將域名發送至本地域名服務器，本地域名服務器查詢自己的 DNS 緩存，查找成功則返回結果（注意：主機和本地域名服務器之間的查詢方式是遞歸查詢）；

4）若本地域名服務器的 DNS 緩存沒有命中，則本地域名服務器向上級域名服務器進行查詢，通過以下方式進行迭代查詢（注意：本地域名服務器和其他域名服務器之間的查詢方式是迭代查詢，防止根域名服務器壓力過大）：

• 首先本地域名服務器向根域名服務器發起請求，根域名服務器是最高層次的，它并不會直接指明這個域名對應的 IP 地址，而是返回頂級域名服務器的地址，也就是說給本地域名服務器指明一條道路，讓他去這里尋找答案
• 本地域名服務器拿到這個頂級域名服務器的地址后，就向其發起請求，獲取權限域名服務器的地址
• 本地域名服務器根據權限域名服務器的地址向其發起請求，最終得到該域名對應的 IP 地址

4）本地域名服務器將得到的 IP 地址返回給操作系統，同時自己將 IP 地址緩存起來

5）操作系統將 IP 地址返回給瀏覽器，同時自己也將 IP 地址緩存起來

6）至此，瀏覽器就得到了域名對應的 IP 地址，并將 IP 地址緩存起來

配合下圖直觀理解：

需要注意的是，DNS 使用的是 UDP 協議，也就是說上面各種請求的轉發，都是基于 UDP 這個無連接協議的。

五、建立 TCP 連接

獲取到了目標服務器的 IP 地址之后，瀏覽器就知道我等下請求要發給誰了，這個時候就可以開始發送封裝好了的 HTTP 請求報文了，那么既然需要發送請求，必然就需要 TCP 通過三次握手為瀏覽器和服務器之間建立可靠的連接，保證雙方都具有可靠的接收和發送能力。

三次握手過程如下圖：

六、瀏覽器發送請求

TCP 三次握手完成后，瀏覽器與目標服務器之間就建立了一個可靠的虛擬通道，于是瀏覽器就可以發送自己的 HTTP 請求了。

需要注意的是，HTTP 請求報文或者響應報文在 TCP 連接通道上進行傳輸的時候，由于這些報文比較大，為了更容易和準確可靠的傳輸，TCP 會將 HTTP 報文按序號分割成若干報文段并加上 TCP 首部，分別進行傳輸。接收方在收到這些報文段后，按照序號以原來的順序重組 HTTP 報文。

七、負責傳輸的 IP 協議

實際上，TCP 在三次握手建立連接、四次握手斷開連接、以及連接建立過程中的收發數據（TCP 報文段）等各階段操作時，都是通過 IP 協議進行傳輸的，IP 協議將這些階段的數據添加 IP 首部封裝成 IP 數據報再進行傳輸。

IP 數據報的首部存有源 IP 地址和 目標 IP 地址。所謂源 IP 地址 就是發送方的 IP 地址；目標 IP 地址就是通過 DNS 域名解析得到的目標服務器的 IP 地址。

事實上，IP 協議身處的網絡層規定的是：數據報要通過怎樣的路徑（傳輸路線）才能到達對方計算機，并傳送給對方。不理解這句話的詳細解釋馬上就來，繼續往下讀。

八、使用 ARP 協議憑借 MAC 地址通信

上面說了，IP 協議的作用是把各種數據包傳送給對方，而要保證確實傳送到對方那里，則需要滿足各類條件，其中必要的兩個就是 IP 地址 和 MAC 地址。

MAC 地址也是用來唯一標識一個接入互聯網的設備的，可能不禁有小伙伴要問，既然網絡層已經有了唯一標識的 IP 地址，為啥還需要 MAC 地址？

看下面這幅圖，在網絡上，通信的雙方在同一局域網內的情況是很少見的，通常是需要多臺計算機和網絡設備的中轉才能連接到對方。而在進行中轉時，就需要利用下一站中轉設備的 MAC 地址來搜索下一個中轉目標。

• 網絡層指定了從哪個主機（「源 IP 地址」）發送到哪個主機（「目的 IP 地址」）。源 IP 地址和目標 IP 地址在傳輸過程中是不會變化的
• 而數據鏈路層則是根據 MAC 地址在一個接一個的區間中進行傳輸的，每個區間內的出發地址即「源 MAC 地址」，每個區間內的目的地址即「目的 MAC 地址」。顯然，隨著數據的傳輸，源 MAC 地址和目的 MAC 地址會不斷的發生變化

比如上圖，網絡層告知了 1-2-3 路線，也就是說指明了這幾個路由器的 IP 地址。那么數據鏈路層就會根據這幾個 IP 地址對應的 MAC 地址依次找到 1、2、3，并在他們之間傳輸數據。

這么說吧，舉個形象點的例子：我們把數據鏈路層當成乘坐高鐵從蘇州到南京，再在南京轉乘到北京，再在北京轉乘到西藏的旅客，那么網絡層就相當于每個車站的工作人員，在數據鏈路層每次轉乘時，網絡層為其購買了一張標有下一個 MAC 地址的車票。因此，即使旅客（數據鏈路層）不知道其最終目的地也沒有關系，工作人員（網絡層）會給你做出指引。

實際上，網絡層做出指引的過程，我們將其稱為路由控制，其中又涉及到了路由協議比如 OSPF 等

那么，將 IP 地址轉化為 MAC 地址，從而在數據鏈路層精確的傳輸數據的協議就是 ARP 協議。

ARP 是借助 ARP 請求與 ARP 響應兩種類型的包確定 MAC 地址的。并且每個主機都有一個 ARP 高速緩存，里面有本局域網上的各主機和路由器的 IP 地址到 MAC 地址的映射表。

如下圖所示，假定主機 A 向同一鏈路上的主機 B 發送 IP 數據報，已知主機 A 和主機 B 的 IP 地址，它們互不知道對方的 MAC 地址：

1）首先，主機 A 為了獲得主機 B 的 MAC 地址，它會先去查詢自己的 ARP 高速緩存中有沒有主機 B 的相關記錄；

2）如果主機 A 的 ARP 高速緩存中沒有主機 B 的 IP 地址到 MAC 地址的映射，主機 A 就會通過廣播的方式發送 ARP 請求包（該包攜帶自己的 IP 地址 和 MAC 地址 以及 目標主機的 IP 地址），表明自己想要獲得主機 B 的 MAC 地址；

2） 由于廣播請求可以被同一個鏈路上的所有主機或路由器接收，因此如果這條鏈路上某個主機或路由的 IP 地址與這個 ARP 請求包中包含的目標主機的 IP 地址相同，那么這個節點就將自己的 MAC 地址塞入 ARP 響應包中返回給主機 A；

當然，ARP 響應包是以單播的形式進行發送的，畢竟 ARP 請求包中已經包含了主機 A 的 IP 地址，所以主機 B 非常清楚這個響應包應該發送給誰。

大部分網絡協議在設計的時候，都是保持極度克制的，不需要的交互就砍掉，能合并的信息就合并，能不用廣播就用單播，以此讓帶寬變得更多讓網絡變得更快。

3）主機 A 在收到主機 B 發過來的 ARP 響應包后，向其 ARP 高速緩存中寫入主機 B 的 IP 地址到 MAC 地址的映射。

當然，緩存是有一定期限的，超過這個期限，緩存的內容將被清空。這也使得即使 MAC 地址和 IP 地址的映射關系發生了變化，也依然能夠正確的將數據包發送給目標地址。

九、服務器響應請求

瀏覽器的 HTTP 請求報文通過 TCP 三次握手建立的連接通道被切分成若干報文段分別發送給服務器，服務器在收到這些報文段后，按照序號以原來的順序重組 HTTP 請求報文。然后處理并返回一個 HTTP 響應。當然，HTTP 響應報文也要經過和 HTTP 請求報文一樣的過程。

看下方這個圖回顧一下（圖片來源《圖解 HTTP》）：

十、斷開 TCP 連接

瀏覽器和服務器都不再需要發送數據后，四次揮手斷開 TCP 連接

十一、瀏覽器顯示界面

瀏覽器接收到服務器返回的數據包，根據瀏覽器的渲染機制對相應的數據進行渲染

十二、總結

屏蔽掉底層細節，籠統的總結一下上述過程：

應用層：

• 瀏覽器封裝 HTTP 請求報文
• DNS 解析域名獲得目標服務器地址

傳輸層：

• 建立連接
• 把應用層傳過來的 HTTP 請求報文進行分割，并在各個報文上打上標記序號及端口號轉發給網絡層

網絡層：

• 利用 ARP 協議根據 IP 地址獲取作為通信目的地的 MAC 地址后轉發給鏈路層

服務端在鏈路層收到數據，按序往上層發送，一直到應用層接收到瀏覽器發送來的 HTTP 請求報文，然后處理該請求并返回 HTTP 響應報文，瀏覽器接收到響應報文之后解析渲染界面。最后 TCP 斷開連接。

以上就是解析在瀏覽器地址欄輸入一個URL后發生了什么的詳細內容，更多關于在瀏覽器地址欄輸入一個URL的資料請關注腳本之家其它相關文章！