本篇內(nèi)容介紹了“在瀏覽器地址欄輸入一個 URL后回車的過程分析”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！
創(chuàng)新互聯(lián)公司致力于互聯(lián)網(wǎng)品牌建設(shè)與網(wǎng)絡(luò)營銷，包括網(wǎng)站設(shè)計制作、成都網(wǎng)站設(shè)計、SEO優(yōu)化、網(wǎng)絡(luò)推廣、整站優(yōu)化營銷策劃推廣、電子商務(wù)、移動互聯(lián)網(wǎng)營銷等。創(chuàng)新互聯(lián)公司為不同類型的客戶提供良好的互聯(lián)網(wǎng)應(yīng)用定制及解決方案，創(chuàng)新互聯(lián)公司核心團隊十載專注互聯(lián)網(wǎng)開發(fā)，積累了豐富的網(wǎng)站經(jīng)驗，為廣大企業(yè)客戶提供一站式企業(yè)網(wǎng)站建設(shè)服務(wù)，在網(wǎng)站建設(shè)行業(yè)內(nèi)樹立了良好口碑。
不知道有沒有同學(xué)會混淆域名和 URL 的概念，可以這樣理解，URL 就是我們輸入的網(wǎng)址，而網(wǎng)址里面含有域名。舉個例子：www.baidu.com/veal98 是一個網(wǎng)址，而 www.baidu.com 就是服務(wù)器的域名。
URL 各元素的組成如下（當(dāng)然，下述請求文件的路徑名可以省略）：
這個 URL 請求的目標(biāo)服務(wù)器上的文件路徑就是：
那么首先，瀏覽器做的第一步就是解析 URL 得到里面的參數(shù)，將域名和需要請求的資源分離開來，從而了解需要請求的是哪個服務(wù)器，請求的是服務(wù)器上什么資源等等。
對 URL 進行解析之后，瀏覽器確定了目標(biāo)服務(wù)器和文件名，接下來就需要根據(jù)這些消息「封裝」成一個 HTTP 請求報文發(fā)送出去。舉個 HTTP 請求報文的例子：
?關(guān)于 HTTP 協(xié)議詳細可見 HTTP 協(xié)議的前世今生 這篇文章，這里不再贅述
?
解釋一下「封裝」，這是一個貫穿整個計算機網(wǎng)絡(luò)的概念。就是說發(fā)送端在層與層之間傳輸數(shù)據(jù)時，每經(jīng)過一層必定會被打上一個該層所屬的首部信息。反之，接收端在層與層之間傳輸數(shù)據(jù)時，每經(jīng)過一層就會把該層對應(yīng)的首部信息消去。
封裝好 HTTP 請求報文后，在正式還有一項準備工作沒有做，那就是獲取目標(biāo)服務(wù)器的 IP 地址。
雖然解析得到了域名，理論瀏覽器已經(jīng)知道目標(biāo)服務(wù)器是誰了。但是實際上，域名并不是目標(biāo)服務(wù)器真正意義上的地址，互聯(lián)網(wǎng)上每一臺計算機都被全世界唯一 IP 地址標(biāo)識著，但是 IP 地址并不方便記憶，所以才設(shè)計出了域名。
那么就需要解析域名獲取目標(biāo)服務(wù)器的 IP 地址。不然空有一個方便記憶的域名咋知道這個請求到底發(fā)送到哪里去呢。由域名轉(zhuǎn)換得到 IP 地址就是 DNS 協(xié)議做的事情，如下：
?關(guān)于 DNS 詳細的內(nèi)容各位可以回顧 超詳細 DNS 協(xié)議解析 這篇文章，比如什么是域名，域名服務(wù)器，遞歸查詢和迭代查詢等等，寫的已經(jīng)足夠詳細，此處只列出 DNS 的解析過程。
?
1）首先搜索「瀏覽器的 DNS 緩存」，緩存中維護著一張域名與 IP 地址的對應(yīng)表；
2）若沒有命中，則繼續(xù)搜索「操作系統(tǒng)的 DNS 緩存」；
3）若仍然沒有命中，則操作系統(tǒng)將域名發(fā)送至「本地域名服務(wù)器」，本地域名服務(wù)器查詢自己的 DNS 緩存，查找成功則返回結(jié)果（注意：主機和本地域名服務(wù)器之間的查詢方式是「遞歸查詢」）；
4）若本地域名服務(wù)器的 DNS 緩存沒有命中，則本地域名服務(wù)器向上級域名服務(wù)器進行查詢，通過以下方式進行「迭代查詢」（注意：本地域名服務(wù)器和其他域名服務(wù)器之間的查詢方式是迭代查詢，防止根域名服務(wù)器壓力過大）：
4）本地域名服務(wù)器將得到的 IP 地址返回給操作系統(tǒng)，同時自己將 IP 地址緩存起來
5）操作系統(tǒng)將 IP 地址返回給瀏覽器，同時自己也將 IP 地址緩存起來
6）至此，瀏覽器就得到了域名對應(yīng)的 IP 地址，并將 IP 地址緩存起來
配合下圖直觀理解：
需要注意的是，DNS 使用的是 UDP 協(xié)議，也就是說上面各種請求的轉(zhuǎn)發(fā)，都是基于 UDP 這個無連接協(xié)議的。
獲取到了目標(biāo)服務(wù)器的 IP 地址之后，瀏覽器就知道我等下請求要發(fā)給誰了，這個時候就可以開始發(fā)送封裝好了的 HTTP 請求報文了，那么既然需要發(fā)送請求，必然就需要 TCP 通過三次握手為瀏覽器和服務(wù)器之間建立可靠的連接，「保證雙方都具有可靠的接收和發(fā)送能力」。
?這里又是一道經(jīng)典的面試題：TCP 三次握手和四次揮手，詳細可見 關(guān)于 TCP 三次握手和四次揮手，滿分回答在此 這篇文章。
?
三次握手過程如下圖：
TCP 三次握手完成后，瀏覽器與目標(biāo)服務(wù)器之間就建立了一個可靠的虛擬通道，于是瀏覽器就可以發(fā)送自己的 HTTP 請求了。
需要注意的是，HTTP 請求報文或者響應(yīng)報文在 TCP 連接通道上進行傳輸?shù)臅r候，由于這些報文比較大，為了更容易和準確可靠的傳輸，「TCP 會將 HTTP 報文按序號分割成若干報文段并加上 TCP 首部，分別進行傳輸。接收方在收到這些報文段后，按照序號以原來的順序重組 HTTP 報文」。
實際上，TCP 在三次握手建立連接、四次握手斷開連接、以及連接建立過程中的收發(fā)數(shù)據(jù)（TCP 報文段）等各階段操作時，都是通過 IP 協(xié)議進行傳輸?shù)?，IP 協(xié)議將這些階段的數(shù)據(jù)添加 IP 首部封裝成 IP 數(shù)據(jù)報再進行傳輸。
IP 數(shù)據(jù)報的首部存有「源 IP 地址」和 「目標(biāo) IP 地址」。所謂源 IP 地址 就是發(fā)送方的 IP 地址；目標(biāo) IP 地址就是通過 DNS 域名解析得到的目標(biāo)服務(wù)器的 IP 地址。
事實上，「IP 協(xié)議身處的網(wǎng)絡(luò)層規(guī)定的是：數(shù)據(jù)報要通過怎樣的路徑（傳輸路線）才能到達對方計算機，并傳送給對方」。不理解這句話的詳細解釋馬上就來，繼續(xù)往下讀。
?關(guān)于 IP 協(xié)議、IP 地址、MAC 地址等詳細請看 別再恐懼 IP 協(xié)議（萬字長文 | 多圖預(yù)警） 這篇文章。
?
上面說了，IP 協(xié)議的作用是把各種數(shù)據(jù)包傳送給對方，而要保證確實傳送到對方那里，則需要滿足各類條件，其中必要的兩個就是 IP 地址 和 MAC 地址。
MAC 地址也是用來唯一標(biāo)識一個接入互聯(lián)網(wǎng)的設(shè)備的，可能不禁有小伙伴要問，既然網(wǎng)絡(luò)層已經(jīng)有了唯一標(biāo)識的 IP 地址，為啥還需要 MAC 地址？
看下面這幅圖，在網(wǎng)絡(luò)上，「通信的雙方在同一局域網(wǎng)內(nèi)的情況是很少見的，通常是需要多臺計算機和網(wǎng)絡(luò)設(shè)備的中轉(zhuǎn)才能連接到對方。而在進行中轉(zhuǎn)時，就需要利用下一站中轉(zhuǎn)設(shè)備的 MAC 地址來搜索下一個中轉(zhuǎn)目標(biāo)」。
網(wǎng)絡(luò)層指定了從哪個主機（「源 IP 地址」）發(fā)送到哪個主機（「目的 IP 地址」）。「源 IP 地址和目標(biāo) IP 地址在傳輸過程中是不會變化的」
而數(shù)據(jù)鏈路層則是根據(jù) MAC 地址在一個接一個的區(qū)間中進行傳輸?shù)?，每個區(qū)間內(nèi)的出發(fā)地址即「源 MAC 地址」，每個區(qū)間內(nèi)的目的地址即「目的 MAC 地址」。顯然，隨著數(shù)據(jù)的傳輸，「源 MAC 地址和目的 MAC 地址會不斷的發(fā)生變化」
比如上圖，「網(wǎng)絡(luò)層告知了 1-2-3 路線，也就是說指明了這幾個路由器的 IP 地址。那么數(shù)據(jù)鏈路層就會根據(jù)這幾個 IP 地址對應(yīng)的 MAC 地址依次找到 1、2、3，并在他們之間傳輸數(shù)據(jù)」。
???? 這么說吧，舉個形象點的例子：我們把數(shù)據(jù)鏈路層當(dāng)成乘坐高鐵從蘇州到南京，再在南京轉(zhuǎn)乘到北京，再在北京轉(zhuǎn)乘到西藏的旅客，那么網(wǎng)絡(luò)層就相當(dāng)于每個車站的工作人員，「在數(shù)據(jù)鏈路層每次轉(zhuǎn)乘時，網(wǎng)絡(luò)層為其購買了一張標(biāo)有下一個 MAC 地址的車票」。因此，即使旅客（數(shù)據(jù)鏈路層）不知道其最終目的地也沒有關(guān)系，工作人員（網(wǎng)絡(luò)層）會給你做出指引。
實際上，網(wǎng)絡(luò)層做出指引的過程，我們將其稱為「路由控制」，其中又涉及到了路由協(xié)議比如 OSPF 等
那么，「將 IP 地址轉(zhuǎn)化為 MAC 地址」，從而在數(shù)據(jù)鏈路層精確的傳輸數(shù)據(jù)的協(xié)議就是 「ARP 協(xié)議」。
ARP 是借助 「ARP 請求與 ARP 響應(yīng)」兩種類型的包確定 MAC 地址的。并且每個主機都有一個 「ARP 高速緩存」，里面有本局域網(wǎng)上的各主機和路由器的 「IP 地址到 MAC 地址的映射表」。
如下圖所示，假定主機 A 向同一鏈路上的主機 B 發(fā)送 IP 數(shù)據(jù)報，已知主機 A 和主機 B 的 IP 地址，它們互不知道對方的 MAC 地址：
1）首先，主機 A 為了獲得主機 B 的 MAC 地址，它會先去查詢自己的 ARP 高速緩存中有沒有主機 B 的相關(guān)記錄；
2）如果主機 A 的 ARP 高速緩存中沒有主機 B 的 IP 地址到 MAC 地址的映射，主機 A 就會通過「廣播」的方式發(fā)送 「ARP 請求包」（該包攜帶自己的 IP 地址 和 MAC 地址 以及 目標(biāo)主機的 IP 地址），表明自己想要獲得主機 B 的 MAC 地址；
2） 由于廣播請求可以被同一個鏈路上的所有主機或路由器接收，因此如果這條鏈路上某個主機或路由的 IP 地址與這個 ARP 請求包中包含的目標(biāo)主機的 IP 地址相同，那么這個節(jié)點就將自己的 MAC 地址塞入 「ARP 響應(yīng)包」中返回給主機 A；
?當(dāng)然，ARP 響應(yīng)包是以單播的形式進行發(fā)送的，畢竟 ARP 請求包中已經(jīng)包含了主機 A 的 IP 地址，所以主機 B 非常清楚這個響應(yīng)包應(yīng)該發(fā)送給誰。
大部分網(wǎng)絡(luò)協(xié)議在設(shè)計的時候，都是保持極度克制的，不需要的交互就砍掉，能合并的信息就合并，能不用廣播就用單播，以此讓帶寬變得更多讓網(wǎng)絡(luò)變得更快。
?
3）主機 A 在收到主機 B 發(fā)過來的 ARP 響應(yīng)包后，向其 ARP 高速緩存中寫入主機 B 的 IP 地址到 MAC 地址的映射。
當(dāng)然，緩存是有一定期限的，超過這個期限，緩存的內(nèi)容將被清空。這也使得即使 MAC 地址和 IP 地址的映射關(guān)系發(fā)生了變化，也依然能夠正確的將數(shù)據(jù)包發(fā)送給目標(biāo)地址。
瀏覽器的 HTTP 請求報文通過 TCP 三次握手建立的連接通道被切分成若干報文段分別發(fā)送給服務(wù)器，服務(wù)器在收到這些報文段后，按照序號以原來的順序重組 HTTP 請求報文。然后處理并返回一個 HTTP 響應(yīng)。當(dāng)然，HTTP 響應(yīng)報文也要經(jīng)過和 HTTP 請求報文一樣的過程。
看下方這個圖回顧一下：
瀏覽器和服務(wù)器都不再需要發(fā)送數(shù)據(jù)后，四次揮手斷開 TCP 連接，詳細可見 關(guān)于 TCP 三次握手和四次揮手，滿分回答在此 這篇文章。
瀏覽器接收到服務(wù)器返回的 HTTP 響應(yīng)報文后，根據(jù)瀏覽器的渲染機制對相應(yīng)的數(shù)據(jù)進行渲染
“在瀏覽器地址欄輸入一個 URL后回車的過程分析”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！
重慶分公司
重慶分公司
