在瀏覽器的地址欄輸入一個 URL 后回車,背后到底發(fā)生了什么才能使得一個界面完美的展現(xiàn)在我們眼前?
今天講解的這道題目,由于其涉及大量網(wǎng)絡(luò)協(xié)議,可以非常直觀的看出諸位小伙伴對計算機網(wǎng)絡(luò)體系的整體把握程度,所以自然成為了各大公司的面試常客。
在瀏覽中輸入 URL 并且獲取響應(yīng)的過程,其實就是瀏覽器和該 URL 對應(yīng)的服務(wù)器的網(wǎng)絡(luò)通信過程。比如我們輸入 www.baidu.com
,那么會返回一個百度搜索的界面,這其實就是瀏覽器和百度服務(wù)器之間的網(wǎng)絡(luò)通信過程。瀏覽器就是客戶端,用于發(fā)出請求,而百度的服務(wù)器就是服務(wù)端,用于接收并響應(yīng)請求。
下面我們就來詳細(xì)講解這個龐大的網(wǎng)絡(luò)通信過程。
不知道有沒有同學(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 請求報文的例子:
解釋一下封裝,這是一個貫穿整個計算機網(wǎng)絡(luò)的概念。就是說發(fā)送端在層與層之間傳輸數(shù)據(jù)時,每經(jīng)過一層必定會被打上一個該層所屬的首部信息。反之,接收端在層與層之間傳輸數(shù)據(jù)時,每經(jīng)過一層就會把該層對應(yīng)的首部信息消去。
封裝好 HTTP 請求報文后,在正式還有一項準(zhǔn)備工作沒有做,那就是獲取目標(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é)議做的事情,如下:
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ā)送能力。
三次握手過程如下圖:
TCP 三次握手完成后,瀏覽器與目標(biāo)服務(wù)器之間就建立了一個可靠的虛擬通道,于是瀏覽器就可以發(fā)送自己的 HTTP 請求了。
需要注意的是,HTTP 請求報文或者響應(yīng)報文在 TCP 連接通道上進行傳輸?shù)臅r候,由于這些報文比較大,為了更容易和準(zhǔn)確可靠的傳輸,TCP 會將 HTTP 報文按序號分割成若干報文段并加上 TCP 首部,分別進行傳輸。接收方在收到這些報文段后,按照序號以原來的順序重組 HTTP 報文。
實際上,TCP 在三次握手建立連接、四次握手?jǐn)嚅_連接、以及連接建立過程中的收發(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ù)報要通過怎樣的路徑(傳輸路線)才能到達(dá)對方計算機,并傳送給對方。不理解這句話的詳細(xì)解釋馬上就來,繼續(xù)往下讀。
上面說了,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ò)層告知了 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 請求報文一樣的過程。
看下方這個圖回顧一下(圖片來源《圖解 HTTP》):
瀏覽器和服務(wù)器都不再需要發(fā)送數(shù)據(jù)后,四次揮手?jǐn)嚅_ TCP 連接
瀏覽器接收到服務(wù)器返回的數(shù)據(jù)包,根據(jù)瀏覽器的渲染機制對相應(yīng)的數(shù)據(jù)進行渲染
屏蔽掉底層細(xì)節(jié),籠統(tǒng)的總結(jié)一下上述過程:
應(yīng)用層:
傳輸層:
網(wǎng)絡(luò)層:
服務(wù)端在鏈路層收到數(shù)據(jù),按序往上層發(fā)送,一直到應(yīng)用層接收到瀏覽器發(fā)送來的 HTTP 請求報文,然后處理該請求并返回 HTTP 響應(yīng)報文,瀏覽器接收到響應(yīng)報文之后解析渲染界面。最后 TCP 斷開連接。
以上就是解析在瀏覽器地址欄輸入一個URL后發(fā)生了什么的詳細(xì)內(nèi)容,更多關(guān)于在瀏覽器地址欄輸入一個URL的資料請關(guān)注腳本之家其它相關(guān)文章!
標(biāo)簽:錫林郭勒盟 丹東 遵義 雙鴨山 襄陽 鄂爾多斯 哈爾濱 莆田
巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《解析在瀏覽器地址欄輸入一個URL后發(fā)生了什么》,本文關(guān)鍵詞 解析,在,瀏覽器,地址,欄,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。