web中網(wǎng)址到網(wǎng)頁顯示其間發(fā)生了什么

本篇內(nèi)容介紹了“web中網(wǎng)址到網(wǎng)頁顯示其間發(fā)生了什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

正文

接下來以下圖較簡單的網(wǎng)絡拓撲模型作為例子，探究探究其間發(fā)生了什么？

簡單的網(wǎng)絡模型

01 孤單小弟 —— HTTP

瀏覽器做的第一步工作是解析 URL

首先瀏覽器做的第一步工作就是要對 URL 進行解析，從而生發(fā)送給 Web 服務器的請求信息。

讓我們看看一條長長的 URL 里的各個元素的代表什么，見下圖：

HTTP 的消息格式

一個孤單 HTTP 數(shù)據(jù)包表示：“我這么一個小小的數(shù)據(jù)包，沒親沒友，直接發(fā)到浩瀚的網(wǎng)絡，誰會知道我呢？誰能載我一層呢？誰能保護我呢？我的目的地在哪呢？”。充滿各種疑問的它，沒有停滯不前，依然踏上了征途！

02 真實地址查詢 —— DNS

通過瀏覽器解析 URL 并生成 HTTP 消息后，需要委托操作系統(tǒng)將消息發(fā)送給 Web  服務器。

但在發(fā)送之前，還有一項工作需要完成，那就是查詢服務器域名對于的 IP 地址，因為委托操作系統(tǒng)發(fā)送消息時，必須提供通信對象的 IP 地址。

比如我們打電話的時候，必須要知道對方的電話號碼，但由于電話號碼難以記憶，所以通常我們會將對方電話號 + 姓名保存在通訊錄里。

所以，有一種服務器就專門保存了 Web 服務器域名與 IP 的對應關系，它就是 DNS 服務器。

域名的層級關系

DNS 中的域名都是用句點來分隔的，比如 www.server.com，這里的句點代表了不同層次之間的界限。

在域名中，越靠右的位置表示其層級越高。

畢竟域名是外國人發(fā)明，所以思維和中國人相反，比如說一個城市地點的時候，外國喜歡從小到大的方式順序說起（如 XX 街道 XX 區(qū) XX 市 XX ?。?，而中國則喜歡從大到小的順序（如 XX 省 XX 市 XX 區(qū) XX 街道）。

根域是在最頂層，它的下一層就是 com 頂級域，再下面是 server.com。

所以域名的層級關系類似一個樹狀結(jié)構(gòu)：

• 根 DNS 服務器

• 頂級域 DNS 服務器（com）

• 權威 DNS 服務器（server.com）

域名解析的工作流程

DNS 域名解析的過程蠻有意思的，整個過程就和我們?nèi)粘Ｉ钪姓胰藛柭返倪^程類似，只指路不帶路。

數(shù)據(jù)包表示：“DNS 老大哥厲害呀，找到了目的地了！我還是很迷茫呀，我要發(fā)出去，接下來我需要誰的幫助呢?”

03 指南好幫手 —— 協(xié)議棧

通過 DNS 獲取到 IP 后，就可以把 HTTP 的傳輸工作交給操作系統(tǒng)中的協(xié)議棧。

協(xié)議棧的內(nèi)部分為幾個部分，分別承擔不同的工作。上下關系是有一定的規(guī)則的，上面的部分會向下面的部分委托工作，下面的部分收到委托的工作并執(zhí)行。

TCP 包頭格式

首先，源端口號和目標端口號是不可少的，如果沒有這兩個端口號，數(shù)據(jù)就不知道應該發(fā)給哪個應用。

接下來有包的序號，這個是為了解決包亂序的問題。

還有應該有的是確認號，目的是確認發(fā)出去對方是否有收到。如果沒有收到就應該重新發(fā)送，直到送達，這個是為了解決不丟包的問題。

接下來還有一些狀態(tài)位。例如 SYN 是發(fā)起一個連接，ACK 是回復，RST 是重新連接，F(xiàn)IN 是結(jié)束連接等。TCP 是面向連接的，因而雙方要維護連接的狀態(tài)，這些帶狀態(tài)位的包的發(fā)送，會引起雙方的狀態(tài)變更。

還有一個重要的就是窗口大小。TCP 要做流量控制，通信雙方各聲明一個窗口（緩存大?。?，標識自己當前能夠的處理能力，別發(fā)送的太快，撐死我，也別發(fā)的太慢，餓死我。

除了做流量控制以外，TCP還會做擁塞控制，對于真正的通路堵車不堵車，它無能為力，唯一能做的就是控制自己，也即控制發(fā)送的速度。不能改變世界，就改變自己嘛。

TCP 傳輸數(shù)據(jù)之前，要先三次握手建立連接

在 HTTP 傳輸數(shù)據(jù)之前，首先需要 TCP 建立連接，TCP 連接的建立，通常稱為三次握手。

這個所謂的「連接」，只是雙方計算機里維護一個狀態(tài)機，在連接建立的過程中，雙方的狀態(tài)變化時序圖就像這樣。

TCP 分割數(shù)據(jù)

如果 HTTP 請求消息比較長，超過了 MSS 的長度，這時 TCP 就需要把 HTTP 的數(shù)據(jù)拆解一塊塊的數(shù)據(jù)發(fā)送，而不是一次性發(fā)送所有數(shù)據(jù)。

數(shù)據(jù)包分割

TCP 報文生成

TCP 協(xié)議里面會有兩個端口，一個是瀏覽器監(jiān)聽的端口（通常是隨機生成的），一個是 Web 服務器監(jiān)聽的端口（HTTP 默認端口號是 80， HTTPS 默認端口號是 443）。

在雙方建立了連接后，TCP 報文中的數(shù)據(jù)部分就是存放 HTTP 頭部 + 數(shù)據(jù)，組裝好 TCP 報文之后，就需交給下面的網(wǎng)絡層處理。

至此，網(wǎng)絡包的報文如下圖。

IP 包頭格式

在 IP 協(xié)議里面需要有源地址 IP 和 目標地址 IP：

• 源地址IP，即是客戶端輸出的 IP 地址；

• 目標地址，即通過 DNS 域名解析得到的 Web 服務器 IP。

因為 HTTP 是經(jīng)過 TCP 傳輸?shù)?，所以?IP 包頭的協(xié)議號，要填寫為 06（十六進制），表示協(xié)議為 TCP。

假設客戶端有多個網(wǎng)卡，就會有多個 IP 地址，那 IP 頭部的源地址應該選擇哪個 IP 呢？

當存在多個網(wǎng)卡時，在填寫源地址 IP 時，就需要判斷到底應該填寫哪個地址。這個判斷相當于在多塊網(wǎng)卡中判斷應該使用哪個一塊網(wǎng)卡來發(fā)送包。

這個時候就需要根據(jù)路由表規(guī)則，來判斷哪一個網(wǎng)卡作為源地址 IP。

在 Linux 操作系統(tǒng)，我們可以使用 route -n 命令查看當前系統(tǒng)的路由表。

路由規(guī)則判斷

1. 首先先和第一條條目的子網(wǎng)掩碼（Genmask）進行 與運算，得到結(jié)果為 192.168.10.0，但是第一個條目的 Destination 是 192.168.3.0，兩者不一致所以匹配失敗。

2. 再與第二條目的子網(wǎng)掩碼進行 與運算，得到的結(jié)果為 192.168.10.0，與第二條目的 Destination 192.168.10.0 匹配成功，所以將使用 eth2 網(wǎng)卡的 IP 地址作為 IP 包頭的源地址。

那么假設 Web 服務器的目標地址是 10.100.20.100，那么依然依照上面的路由表規(guī)則判斷，判斷后的結(jié)果是和第三條目匹配。

第三條目比較特殊，它目標地址和子網(wǎng)掩碼都是 0.0.0.0，這表示默認網(wǎng)關，如果其他所有條目都無法匹配，就會自動匹配這一行。并且后續(xù)就把包發(fā)給路由器，Gateway 即是路由器的 IP 地址。

IP 報文生成

至此，網(wǎng)絡包的報文如下圖。

MAC 包頭格式

在 MAC 包頭里需要發(fā)送方 MAC 地址和接收方目標 MAC 地址，用于兩點之間的傳輸。

一般在 TCP/IP 通信里，MAC 包頭的協(xié)議類型只使用：

• 0800 ：IP 協(xié)議

• 0806 ：ARP 協(xié)議

MAC 發(fā)送方和接收方如何確認?

發(fā)送方的 MAC 地址獲取就比較簡單了，MAC 地址是在網(wǎng)卡生產(chǎn)時寫入到 ROM 里的，只要將這個值讀取出來寫入到 MAC 頭部就可以了。

接收方的 MAC 地址就有點復雜了，只要告訴以太網(wǎng)對方的 MAC 的地址，以太網(wǎng)就會幫我們把包發(fā)送過去，那么很顯然這里應該填寫對方的 MAC 地址。

所以先得搞清楚應該把包發(fā)給誰，這個只要查一下路由表就知道了。在路由表中找到相匹配的條目，然后把包發(fā)給 Gateway 列中的 IP 地址就可以了。

既然知道要發(fā)給誰，按如何獲取對方的 MAC 地址呢？

不知道對方 MAC 地址？不知道就喊唄。

此時就需要 ARP 協(xié)議幫我們找到路由器的 MAC 地址。

MAC 層報文

此時，加上了 MAC 頭部的數(shù)據(jù)包萬分感謝，說道 ：“感謝 MAC 大佬，我知道我下一步要去了哪了！我現(xiàn)在有很多頭部兄弟，相信我可以到達最終的目的地！”。帶著眾多頭部兄弟的數(shù)據(jù)包，終于準備要出門了。

07 出口 —— 網(wǎng)卡

IP 生成的網(wǎng)絡包只是存放在內(nèi)存中的一串二進制數(shù)字信息，沒有辦法直接發(fā)送給對方。因此，我們需要將數(shù)字信息轉(zhuǎn)換為電信號，才能在網(wǎng)線上傳輸，也就是說，這才是真正的數(shù)據(jù)發(fā)送過程。

負責執(zhí)行這一操作的是網(wǎng)卡，要控制網(wǎng)卡還需要靠網(wǎng)卡驅(qū)動程序。

網(wǎng)卡驅(qū)動從 IP 模塊獲取到包之后，會將其復制到網(wǎng)卡內(nèi)的緩存區(qū)中，接著會其開頭加上報頭和起始幀分界符，在末尾加上用于檢測錯誤的幀校驗序列。

交換機的 MAC 地址表

舉個例子，如果收到的包的接收方 MAC 地址為 00-02-B3-1C-9C-F9，則與圖中表中的第 3 行匹配，根據(jù)端口列的信息，可知這個地址位于 3 號端口上，然后就可以通過交換電路將包發(fā)送到相應的端口了。

所以，交換機根據(jù) MAC 地址表查找 MAC 地址，然后將信號發(fā)送到相應的端口。

當 MAC 地址表找不到指定的 MAC 地址會怎么樣？

地址表中找不到指定的 MAC 地址。這可能是因為具有該地址的設備還沒有向交換機發(fā)送過包，或者這個設備一段時間沒有工作導致地址被從地址表中刪除了。

這種情況下，交換機無法判斷應該把包轉(zhuǎn)發(fā)到哪個端口，只能將包轉(zhuǎn)發(fā)到除了源端口之外的所有端口上，無論該設備連接在哪個端口上都能收到這個包。

這樣做不會產(chǎn)生什么問題，因為以太網(wǎng)的設計本來就是將包發(fā)送到整個網(wǎng)絡的，然后只有相應的接收者才接收包，而其他設備則會忽略這個包。

有人會說：“這樣做會發(fā)送多余的包，會不會造成網(wǎng)絡擁塞呢？”

其實完全不用過于擔心，因為發(fā)送了包之后目標設備會作出響應，只要返回了響應包，交換機就可以將它的地址寫入 MAC 地址表，下次也就不需要把包發(fā)到所有端口了。

局域網(wǎng)中每秒可以傳輸上千個包，多出一兩個包并無大礙。

此外，如果接收方 MAC 地址是一個廣播地址，那么交換機會將包發(fā)送到除源端口之外的所有端口。

以下兩個屬于廣播地址：

• MAC 地址中的 FF:FF:FF:FF:FF:FF

• IP 地址中的 255.255.255.255

數(shù)據(jù)包通過交換機轉(zhuǎn)發(fā)抵達了路由器，準備要離開土生土長的子網(wǎng)了。此時，數(shù)據(jù)包和交換機離別時說道：“感謝交換機兄弟，幫我轉(zhuǎn)發(fā)到出境的大門，我要出遠門啦！”

09 出境大門 —— 路由器

路由器與交換機的區(qū)別

網(wǎng)絡包經(jīng)過交換機之后，現(xiàn)在到達了路由器，并在此被轉(zhuǎn)發(fā)到下一個路由器或目標設備。

這一步轉(zhuǎn)發(fā)的工作原理和交換機類似，也是通過查表判斷包轉(zhuǎn)發(fā)的目標。

不過在具體的操作過程上，路由器和交換機是有區(qū)別的。

• 因為路由器是基于 IP 設計的，俗稱三層網(wǎng)絡設備，路由器的各個端口都具有 MAC 地址和 IP 地址；

• 而交換機是基于以太網(wǎng)設計的，俗稱二層網(wǎng)絡設備，交換機的端口不具有 MAC 地址。

路由器基本原理

路由器的端口具有 MAC 地址，因此它就能夠成為以太網(wǎng)的發(fā)送方和接收方；同時還具有 IP 地址，從這個意義上來說，它和計算機的網(wǎng)卡是一樣的。

當轉(zhuǎn)發(fā)包時，首先路由器端口會接收發(fā)給自己的以太網(wǎng)包，然后路由表查詢轉(zhuǎn)發(fā)目標，再由相應的端口作為發(fā)送方將以太網(wǎng)包發(fā)送出去。

路由器的包接收操作

首先，電信號到達網(wǎng)線接口部分，路由器中的模塊會將電信號轉(zhuǎn)成數(shù)字信號，然后通過包末尾的 FCS 進行錯誤校驗。

如果沒問題則檢查 MAC 頭部中的接收方 MAC 地址，看看是不是發(fā)給自己的包，如果是就放到接收緩沖區(qū)中，否則就丟棄這個包。

總的來說，路由器的端口都具有 MAC 地址，只接收與自身地址匹配的包，遇到不匹配的包則直接丟棄。

查詢路由表確定輸出端口

完成包接收操作之后，路由器就會去掉包開頭的 MAC 頭部。

MAC 頭部的作用就是將包送達路由器，其中的接收方 MAC 地址就是路由器端口的 MAC 地址。因此，當包到達路由器之后，MAC 頭部的任務就完成了，于是 MAC 頭部就會被丟棄。

接下來，路由器會根據(jù) MAC 頭部后方的 IP 頭部中的內(nèi)容進行包的轉(zhuǎn)發(fā)操作。

轉(zhuǎn)發(fā)操作分為幾個階段，首先是查詢路由表判斷轉(zhuǎn)發(fā)目標。

扒皮模型 

數(shù)據(jù)包抵達服務器后，服務器會先扒開數(shù)據(jù)包的 MAC 頭部，查看是否和服務器自己的 MAC 地址符合，符合就將包收起來。

接著繼續(xù)扒開數(shù)據(jù)包的 IP 頭，發(fā)現(xiàn) IP 地址符合，根據(jù) IP 頭中協(xié)議項，知道自己上層是 TCP 協(xié)議。

于是，扒開 TCP 的頭，里面有序列號，需要看一看這個序列包是不是我想要的，如果是就放入緩存中然后返回一個 ACK，如果不是就丟棄。TCP頭部里面還有端口號， HTTP 的服務器正在監(jiān)聽這個端口號。

于是，服務器自然就知道是 HTTP 進程想要這個包，于是就將包發(fā)給 HTTP 進程。

服務器的 HTTP 進程看到，原來這個請求是要訪問一個頁面，于是就把這個網(wǎng)頁封裝在 

HTTP 響應報文里。

HTTP 響應報文也需要穿上 TCP、IP、MAC 頭部，不過這次是源地址是服務器 IP 地址，目的地址是客戶端 IP 地址。

穿好頭部衣服后，從網(wǎng)卡出去，交由交換機轉(zhuǎn)發(fā)到出城的路由器，路由器就把響應數(shù)據(jù)包發(fā)到了下一個路由器，就這樣跳啊跳。

最后跳到了客戶端的城門把手的路由器，路由器扒開 IP 頭部發(fā)現(xiàn)是要找城內(nèi)的人，于是把包發(fā)給了城內(nèi)的交換機，再由交換機轉(zhuǎn)發(fā)到客戶端。

客戶端收到了服務器的響應數(shù)據(jù)包后，同樣也非常的高興，客戶能拆快遞了！

于是，客戶端開始扒皮，把收到的數(shù)據(jù)包的皮扒剩 HTTP 響應報文后，交給瀏覽器去渲染頁面，一份特別的數(shù)據(jù)包快遞，就這樣顯示出來了！

最后，客戶端要離開了，向服務器發(fā)起了 TCP 四次揮手，至此雙方的連接就斷開了。

“web中網(wǎng)址到網(wǎng)頁顯示其間發(fā)生了什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！