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

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

創(chuàng)新互聯(lián)建站于2013年創(chuàng)立，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目成都做網(wǎng)站、成都網(wǎng)站建設(shè)網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢想脫穎而出為使命，1280元漢中做網(wǎng)站,已為上家服務(wù),為漢中各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:028-86922220

正文

接下來以下圖較簡單的網(wǎng)絡(luò)拓?fù)淠Ｐ妥鳛槔?，探究探究其間發(fā)生了什么？

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

01 孤單小弟 —— HTTP

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

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

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

HTTP 的消息格式

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

02 真實(shí)地址查詢 —— DNS

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

但在發(fā)送之前，還有一項(xiàng)工作需要完成，那就是查詢服務(wù)器域名對于的 IP 地址，因?yàn)槲胁僮飨到y(tǒng)發(fā)送消息時(shí)，必須提供通信對象的 IP 地址。

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

所以，有一種服務(wù)器就專門保存了 Web 服務(wù)器域名與 IP 的對應(yīng)關(guān)系，它就是 DNS 服務(wù)器。

域名的層級關(guān)系

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

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

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

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

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

• 根 DNS 服務(wù)器

• 頂級域 DNS 服務(wù)器（com）

• 權(quán)威 DNS 服務(wù)器（server.com）

域名解析的工作流程

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

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

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

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

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

TCP 包頭格式

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

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

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

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

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

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

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

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

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

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

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

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

TCP 報(bào)文生成

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

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

至此，網(wǎng)絡(luò)包的報(bào)文如下圖。

IP 包頭格式

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

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

• 目標(biāo)地址，即通過 DNS 域名解析得到的 Web 服務(wù)器 IP。

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

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

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

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

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

路由規(guī)則判斷

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

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

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

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

IP 報(bào)文生成

至此，網(wǎng)絡(luò)包的報(bào)文如下圖。

MAC 包頭格式

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

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

• 0800 ：IP 協(xié)議

• 0806 ：ARP 協(xié)議

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

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

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

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

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

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

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

MAC 層報(bào)文

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

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

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

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

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

交換機(jī)的 MAC 地址表

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

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

當(dāng) MAC 地址表找不到指定的 MAC 地址會怎么樣？

地址表中找不到指定的 MAC 地址。這可能是因?yàn)榫哂性摰刂返脑O(shè)備還沒有向交換機(jī)發(fā)送過包，或者這個(gè)設(shè)備一段時(shí)間沒有工作導(dǎo)致地址被從地址表中刪除了。

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

這樣做不會產(chǎn)生什么問題，因?yàn)橐蕴W(wǎng)的設(shè)計(jì)本來就是將包發(fā)送到整個(gè)網(wǎng)絡(luò)的，然后只有相應(yīng)的接收者才接收包，而其他設(shè)備則會忽略這個(gè)包。

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

其實(shí)完全不用過于擔(dān)心，因?yàn)榘l(fā)送了包之后目標(biāo)設(shè)備會作出響應(yīng)，只要返回了響應(yīng)包，交換機(jī)就可以將它的地址寫入 MAC 地址表，下次也就不需要把包發(fā)到所有端口了。

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

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

以下兩個(gè)屬于廣播地址：

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

• IP 地址中的 255.255.255.255

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

09 出境大門 —— 路由器

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

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

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

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

• 因?yàn)槁酚善魇腔?IP 設(shè)計(jì)的，俗稱三層網(wǎng)絡(luò)設(shè)備，路由器的各個(gè)端口都具有 MAC 地址和 IP 地址；

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

路由器基本原理

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

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

路由器的包接收操作

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

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

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

查詢路由表確定輸出端口

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

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

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

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

扒皮模型 

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

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

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

于是，服務(wù)器自然就知道是 HTTP 進(jìn)程想要這個(gè)包，于是就將包發(fā)給 HTTP 進(jìn)程。

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

HTTP 響應(yīng)報(bào)文里。

HTTP 響應(yīng)報(bào)文也需要穿上 TCP、IP、MAC 頭部，不過這次是源地址是服務(wù)器 IP 地址，目的地址是客戶端 IP 地址。

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

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

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

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

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

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

當(dāng)前標(biāo)題：web中網(wǎng)址到網(wǎng)頁顯示其間發(fā)生了什么
鏈接URL：http://bm7419.com/article0/jjshio.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供服務(wù)器托管、品牌網(wǎng)站建設(shè)、App設(shè)計(jì)、外貿(mào)網(wǎng)站建設(shè)、品牌網(wǎng)站設(shè)計(jì)、域名注冊

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)