OSI七層模型工作過程&&輸入URL瀏覽器的工作過程(超詳細!!)

從以下10個方面深入理解輸入URL後整個模型以及瀏覽器的工作流程!

目錄

1.HTTP

2.DNS

3.協議棧

4.TCP

5.IP

6.MAC

7.網卡

8.交換機

9.路由器

10.服務器與客戶端

輸入URL後瀏覽器的整個流程(簡單版本):


 1.孤單小弟——HTTP

(1) 解析URL

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

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

 

 所以圖中一長串的URL本質上是請求服務器裏面的文件資源

Q:如果URL元素組成中省略了藍色部分,哪應該是請求哪個文件呢?

A:當URL中不存在路徑名時,就代表着訪問根目錄下事先設置好的默認文件,例如 /index.html 或者 /default.html 等,這樣就不會發生混亂。在瀏覽器中輸入www.baidu.com以及www.baidu.com/default.html兩者顯示是不一樣的。

(2) 生成HTTP請求信息

對URL進行解析之後,瀏覽器確定了Web服務器和文件名,接下來根據這些信息來生成 相應的HTTP 請求信息。

 一個孤單 HTTP 數據包表示:「我這麼一個小小的數據包,沒親沒友,直接發到浩瀚的網絡,誰會知道我呢?誰能載我一層呢?誰能保護我呢?我的目的地在哪呢?」。充滿各種疑問的它,沒有停滯不前,依然踏上了征途!

2.真實地址查詢——DNS

通過瀏覽器解析 URL 並生成 HTTP 請求消息後,需要委託操作系統將消息發送給 Web 服務器。但在發送之前,還有一項工作需要完成,那就是查詢服務器域名對於的 IP 地址,因為委託操作系統發 送消息時,必須提供通信對象的 IP 地址。

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

(1) 域名的層級關係

DNS 中的域名都是用句點來分隔的,比如 www.server.com ,這裡的句點代表了不同層次之間的界限。在域名中,越靠右的位置表示其層級越高。

根域名是在頂層,它的下一層就是 com 頂級域名,再下面是 server.com。所以域名的層級關係類似一個樹狀結構:

根域名 DNS 服務器

頂級域名 DNS 服務器(com)

權限域名 DNS 服務器(server.com)

根域名的 DNS 服務器信息保存在互聯網中所有的 DNS 服務器中。這樣一來,任何 DNS 服務器就都可以找到並訪問根域名 DNS 服務器了。因此,客戶端只要能夠找到任意一台 DNS 服務器,就可以通過它找到根域名 DNS 服務器,然後再一路 順藤摸瓜找到位於下層的某台目標 DNS 服務器。

(2) 域名解析的工作流程

瀏覽器緩存->系統緩存->路由器緩存->本地域名服務器->根域名服務器->頂級域名服務器->權限域名服務器->本地域名服務器把返回的結果保存到緩存

具體流程如下:

瀏覽器緩存

  當用戶通過瀏覽器訪問某域名時,瀏覽器首先會在自己的緩存中查找是否有該域名對應的IP地址(若曾經訪問過該域名且沒有清空緩存便存在);

系統緩存

  當瀏覽器緩存中無域名對應IP則會自動檢查用戶計算機系統Hosts文件DNS緩存是否有該域名對應IP;

路由器緩存

  當瀏覽器及系統緩存中均無域名對應IP則進入路由器緩存中檢查,以上三步均為客戶端的DNS緩存;

ISP(互聯網服務提供商)DNS緩存【本地域名服務器】

  當在用戶客服端查找不到域名對應IP地址,則將進入ISP DNS緩存中進行查詢。比如你用的是電信的網絡,則會進入電信的DNS緩存服務器中進行查找;如果經由以上方式都沒找到對應IP的話,則向根域名服務器查找域名對應的IP地址,根域名服務器把請求轉發到下一級,逐層查找該域名的對應數據,直到獲得最終解析結果或失敗結果。

保存結果至緩存

最後本地域名服務器把返回的結果保存到緩存,以備下一次使用,同時將該結果反饋給客戶端,客戶端通過這個IP地址與web服務器建立鏈接。


 如果在客戶端的DNS緩存中沒有找到對應的IP地址,則進入本地DNS服務器進行遞歸查詢迭代查詢

1. 客戶端首先會發出一個 DNS 請求,問 www.server.com 的 IP 是啥,並發給本地 DNS 服務器(也 就是客戶端的 TCP/IP 設置中填寫的 DNS 服務器地址)。

2. 本地域名服務器收到客戶端的請求後,如果緩存里的表格能找到 www.server.com,則它直接返回 IP 地址。如果沒有,本地 DNS 會去問它的根域名服務器:「老大, 能告訴我 www.server.com 的 IP 地址嗎?」 根域名服務器是高層次的,它不直接用於域名解析,但能指明一條道路。

3. 根域名 DNS服務器收到來自本地 DNS 的請求後,發現後置是 .com,說:「www.server.com 這個域名歸 .com 區域管理」,我給你 .com 頂級域名服務器地址給你,你去問問它吧。」

4. 本地 DNS 收到頂級域名服務器的地址後,發起請求問「老二, 你能告訴我 www.server.com 的 IP 地址嗎?」

5. 頂級域名服務器說:「我給你負責 www.server.com 區域的權威 DNS 服務器的地址,你去問它應該 能問到」。

6. 本地 DNS 於是轉向問權威 DNS 服務器:「老三,www.server.com對應的IP是啥呀?」 server.com 的權威 DNS 服務器,它是域名解析結果的原出處。為啥叫權威呢?就是我的域名我做主。

7. 權威 DNS 服務器查詢後將對應的 IP 地址 X.X.X.X 告訴本地 DNS。

8. 本地 DNS 再將 IP 地址返回客戶端,客戶端和目標建立連接。

DNS 域名解析的過程就和我們日常生活中找人問路的過程類似,只指路不帶路

數據包表示:「DNS 老大哥厲害呀,找到了目的地了!我還是很迷茫呀,我要發出去,接下來我需要誰的幫 助呢?」

3.指南好幫手——協議棧

通過 DNS 獲取到 IP 後,就可以把 HTTP 的傳輸工作交給操作系統中的協議棧。協議棧的內部分為幾個部分,分別承擔不同的工作。上下關係是有一定的規則的,上面的部分會向下面 的部分委託工作,下面的部分收到委託的工作並執行。

(1) 應用程序(瀏覽器)通過調用 Socket 庫,來委託協議棧工作。協議棧的上半部分有兩塊,分別是負責 收發數據的 TCP 和 UDP 協議,它們兩會接受應用層的委託執行收發數據的操作。

(2) 協議棧的下面一半是用 IP 協議控制網絡包收發操作,在互聯網上傳數據時,數據劊被切分成一塊塊的 網絡包,而將網絡包發送給對方的操作就是由 IP 負責的。此外 IP 中還包括 ICMP 協議和 ARP 協議。

  • ICMP 用於告知網絡包傳送過程中產生的錯誤以及各種控制信息。
  • ARP 用於根據 IP 地址查詢相應的以太網 MAC 地址。

(3) IP 下面的網卡驅動程序負責控制網卡硬件,而下面的網卡則負責完成實際的收發操作,也就是對網線中的信號執行發送和接收操作。

有關網卡的介紹://blog.csdn.net/tao546377318/article/details/51602298

有關網卡驅動程序的介紹://baike.baidu.com/item/%E9%A9%B1%E5%8A%A8%E7%A8%8B%E5%BA%8F

數據包看了這份指南表示:「原來我需要那麼多大佬的協助啊,那我先去找找 TCP 大佬!」

4.可靠傳輸——TCP

HTTP 是基於 TCP 協議傳輸的,所以在這我們先了解下 TCP 協議。

(1) TCP報文頭部的格式

首先,源端口號目標端口號是不可少的,如果沒有這兩個端口號,數據就不知道應該發給哪個應用。

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

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

接下來還有一些狀態位。例如 SYN 是發起一個連接, ACK 是回復, RST 是重新連接, FIN 是 結束連接等。TCP 是面向連接的,因而雙方要維護連接的狀態,這些帶狀態位的包的發送,會引起雙方 的狀態變更。

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

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

有關TCP三次握手、四次揮手的知識點請看 備戰研發崗-計算機通信網絡

(2) TCP數據分割

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

 兩個概念:

  • MTU :一個網絡包的大長度,以太網中一般為 1500 位元組。
  • MSS :除去 IP(20Bytes) 和 TCP 頭部(20Bytes) 之後,一個網絡包所能容納的 TCP 數據的大長度。通常情況下mss的值=1500-20-20=1460Bytes

數據會被以 MSS 的長度為單位進行拆分,拆分出來的每一塊數據都會被放進單獨的網絡包中。也就 是在每個被拆分的數據加上 TCP 頭信息,然後交給 IP 模塊來發送數據。

(3) TCP報文生成

在雙方建立連接之後,TCP 報文中的數據部分為存放 HTTP 頭部 + 數據,組裝好 TCP 報文之後,就需交給下面的網絡層處理。TCP報文如下圖所示:

此時,遇上了 TCP 的 數據包激動表示:「太好了,碰到了可靠傳輸的 TCP 傳輸,它給我加上 TCP 頭部,我 不在孤單了,安全感十足啊!有大佬可以保護我的可靠送達!但我應該往哪走呢?」

5.遠程定位——IP

TCP 模塊在執行連接、收發、斷開等各階段操作時,都需要委託 IP 模塊將數據封裝成網絡包發送給通信對象。

(1) IP報文頭部格式

在 IP 協議裏面需要有源地址 IP 和 目標地址 IP

  • 源地址IP,即是客戶端輸出的 IP 地址;

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

因為 HTTP 是經過 TCP 傳輸的,所以在 IP 包頭的協議號,要填寫為 06(十六進制),表示協議為 TCP。從圖中可以看出IP包頭的基本大小為20Bytes,一個Byte等於8bit(8位)。

(2) IP報文

 此時,加上了 IP 頭部的數據包表示 :「有 IP 大佬給我指路了,感謝 IP 層給我加上了 IP 包頭,讓我有了遠程定位的能力!不會害怕在浩瀚的互聯網迷茫了!可是目的地好遠啊,我下一站應該去哪呢?」

6.兩點傳輸——MAC

生成了 IP 頭部之後,接下來網絡包還需要在 IP 頭部的前面加上 MAC 頭部

(1)  MAC報頭格式

在 MAC 包頭裡需要發送方 MAC 地址接收方目標 MAC 地址,用於兩點之間的傳輸

一般在 TCP/IP 通信里,MAC 包頭的協議類型只使用:

  • 0800 :IP 協議

  • 0806 :ARP 協議

(2) MAC發送方與接收方地址的確認

發送方的 MAC 地址獲取就比較簡單了,MAC 地址是在網卡生產時寫入到 ROM 里的,只要將這個值讀取出來寫入到 MAC 頭部就可以了。

接收方的 MAC 地址就有點複雜了,只要告訴以太網對方的 MAC 的地址,以太網就會幫我們把包發送過去,那麼很顯然這裡應該填寫對方的 MAC 地址。

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

Q:路由表是如何獲取到下一跳的地址?

A:通常採用靜態路由或者動態路由的方式進行獲取。https://blog.csdn.net/laoniu_c/article/details/39268387

(3) 獲取對方的MAC地址

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

ARP 協議會在以太網中以廣播的形式,對以太網所有的設備喊出:「這個 IP 地址是誰的?請把你的 MAC 地址告訴我」。然後就會有人回答:「這個 IP 地址是我的,我的 MAC 地址是 XXXX」。

如果對方和自己處於同一個子網中,那麼通過上面的操作就可以得到對方的 MAC 地址。然後,我們將這個 MAC 地址寫入 MAC 頭部,MAC 頭部就完成了。

Q:好像每次都要廣播獲取,這不是很麻煩嗎?

A:在後續操作系統會把本次查詢結果放到一塊叫做 ARP 緩存的內存空間留着以後用,不過緩存的時間就幾分鐘。也就是說,在發包時:

  • 先查詢 ARP 緩存,如果其中已經保存了對方的 MAC 地址,就不需要發送 ARP 查詢,直接使用 ARP 緩存中的地址。

  • 而當 ARP 緩存中不存在對方 MAC 地址時,則發送 ARP 廣播查詢。

在 Linux 系統中,我們可以使用 arp -a 命令來查看 ARP 緩存的內容。

(4) MAC報文生成

此時,加上了 MAC 頭部的數據包萬分感謝,說道 :「感謝 MAC 大佬,我知道我下一步要去了哪了!我現在 有很多頭部兄弟,相信我可以到達終的目的地!」。 帶着眾多頭部兄弟的數據包,終於準備要出門了。

7.出口——網卡

IP 生成的網絡包只是存放在內存中的一串二進制數字信息,沒有辦法直接發送給對方。因此,我們需要將數字信息轉換為電信號,才能在網線上傳輸,也就是說,這才是真正的數據發送過程。

負責執行這一操作的是網卡,要控制網卡還需要靠網卡驅動程序

網卡驅動從 IP 模塊獲取到包之後,會將其複製到網卡內的緩存區中,接着會其開頭加上報頭和起始幀分界符,在末尾加上用於檢測錯誤的幀校驗序列

 

  • 起始幀分界符是一個用來表示包起始位置的標記

  • 末尾的 FCS(幀校驗序列)用來檢查包傳輸過程是否有損壞

最後網卡會將包轉為電信號,通過網線發送出去。

唉,真是不容易,發一個包,真是歷經歷經千辛萬苦。致此,一個帶有許多頭部的數據終於踏上尋找目的地的征途了!

8.送別者——交換機

下面來看一下包是如何通過交換機的。交換機的設計是將網絡包原樣轉發到目的地。交換機工作在 MAC 層,也稱為二層網絡設備。

(1) 交換機數據包操作

首先,電信號到達網線接口,交換機里的模塊進行接收,接下來交換機里的模塊將電信號轉換為數字信號。

然後通過包末尾的 FCS 校驗錯誤,如果沒問題則放到緩衝區。這部分操作基本和計算機的網卡相同,但交換機的工作方式和網卡不同。

計算機的網卡本身具有 MAC 地址,並通過核對收到的包的接收方 MAC 地址判斷是不是發給自己的,如果不是發給自己的則丟棄;相對地,交換機的端口不核對接收方 MAC 地址,而是直接接收所有的包並存放到緩衝區中。因此,和網卡不同,交換機的端口不具有 MAC 地址

將包存入緩衝區後,接下來需要查詢一下這個包的接收方 MAC 地址是否已經在 MAC 地址表中有記錄了。

交換機的 MAC 地址表主要包含兩個信息:

  • 一個是設備的 MAC 地址,

  • 另一個是該設備連接在交換機的哪個端口上。

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

所以,交換機根據 MAC 地址表查找 MAC 地址,然後將信號發送到相應的端口

Q:當 MAC 地址表找不到指定的 MAC 地址會怎麼樣?

地址表中找不到指定的 MAC 地址。這可能是因為具有該地址的設備還沒有向交換機發送過包,或者這 個設備一段時間沒有工作導致地址被從地址表中刪除了。這種情況下,交換機無法判斷應該把包轉發到哪個端口,只能將包轉發到除了源端口之外的所有端口 上,無論該設備連接在哪個端口上都能收到這個包。

這樣做不會產生什麼問題,因為以太網的設計本來就是將包發送到整個網絡的,然後只有相應的接收者 才接收包,而其他設備則會忽略這個包。

數據包通過交換機轉發抵達了路由器,準備要離開土生土長的子網了。此時,數據包和交換機離別時說道:「感謝交換機兄弟,幫我轉發到出境的大門,我要出遠門啦!」

9.出境大門——路由器

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

網絡包經過交換機之後,現在到達了路由器,並在此被轉發到下一個路由器或目標設備。

這一步轉發的工作原理和交換機類似,也是通過查表判斷包轉發的目標。

不過在具體的操作過程上,路由器和交換機是有區別的。

  • 因為路由器是基於 IP 設計的,俗稱三層網絡設備,路由器的各個端口都具有 MAC 地址和 IP 地址;

  • 交換機是基於以太網設計的,俗稱二層網絡設備,交換機的端口不具有 MAC 地址。

(2) 路由器基本原理

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

當轉發包時,首先路由器端口會接收發給自己的以太網包,然後路由表查詢轉發目標,再由相應的端口作為發送方將以太網包發送出去。

(3)路由器的包接收操作

首先,電信號到達網線接口部分,路由器中的模塊會將電信號轉成數字信號,然後通過包末尾的 FCS 進行錯誤校驗。

如果沒問題則檢查 MAC 頭部中的接收方 MAC 地址,看看是不是發給自己的包,如果是就放到接收緩衝區中,否則就丟棄這個包。

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

(4) 查詢路由表確定輸出端口

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

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

接下來,路由器會根據 MAC 頭部後方的 IP 頭部中的內容進行包的轉發操作。

轉發操作分為幾個階段,首先是查詢路由表判斷轉發目標。

具體的工作流程根據上圖,舉個例子。

假設地址為 10.10.1.101 的計算機要向地址為 192.168.1.100 的服務器發送一個包,這個包先到達圖中的路由器。

判斷轉發目標的第一步,就是根據包的接收方 IP 地址查詢路由表中的目標地址欄,以找到相匹配的記錄。

路由匹配和前面講的一樣,每個條目的子網掩碼和 192.168.1.100 IP 做 & 與運算後,得到的結果與對應條目的目標地址進行匹配,如果匹配就會作為候選轉發目標,如果不匹配就繼續與下個條目進行路由匹配。

如第二條目的子網掩碼 255.255.255.0 與 192.168.1.100 IP 做 & 與運算後,得到結果是 192.168.1.0 ,這與第二條目的目標地址 192.168.1.0 匹配,該第二條目記錄就會被作為轉發目標。

實在找不到匹配路由時,就會選擇默認路由,路由表中子網掩碼為 0.0.0.0 的記錄表示「默認路由」。

(5) 路由器的發送操作

接下來就會進入包的發送操作

首先,我們需要根據路由表的網關列判斷對方的地址。

  • 如果網關是一個 IP 地址,則這個IP 地址就是我們要轉發到的目標地址,還未抵達終點,還需繼續需要路由器轉發。

  • 如果網關為空,則 IP 頭部中的接收方 IP 地址就是要轉發到的目標地址,也是就終於找到 IP 包頭裡的目標地址了,說明已抵達終點

知道對方的 IP 地址之後,接下來需要通過 ARP 協議根據 IP 地址查詢 MAC 地址,並將查詢的結果作為接收方 MAC 地址。

路由器也有 ARP 緩存,因此首先會在 ARP 緩存中查詢,如果找不到則發送 ARP 查詢請求。

接下來是發送方 MAC 地址字段,這裡填寫輸出端口的 MAC 地址。還有一個以太類型字段,填寫 0080 (十六進制)表示 IP 協議。

網絡包完成後,接下來會將其轉換成電信號並通過端口發送出去。這一步的工作過程和計算機也是相同的。

發送出去的網絡包會通過交換機到達下一個路由器。由於接收方 MAC 地址就是下一個路由器的地址,所以交換機會根據這一地址將包傳輸到下一個路由器。

接下來,下一個路由器會將包轉發給再下一個路由器,經過層層轉發之後,網絡包就到達了最終的目的地。

不知你發現了沒有,在網絡包傳輸的過程中,源 IP 和目標 IP 始終是不會變的,一直變化的是 MAC 地址,因為需要 MAC 地址在以太網內進行兩個設備之間的包傳輸。

Q:什麼是網關,網關有什麼作用?

  • 網關其實是一個邏輯概念,可以理解為數據的特定出口。通常網關是具有路由功能的設備上實現的,其作用就是用來連接兩個不同網段的網絡的。而路由器是一個具體的硬件,一般特指能夠實現路由尋找和轉發的特定類產品,路由器很顯然能夠實現網關的功能。
  • 默認網關事實上不是一個產品而是一個網絡層的概念,PC本身不具備路由尋址能力,所以PC要把所有的IP包發送到一個默認的中轉地址上面進行轉發,也就是默認網關。這個網關可以在路由器上,可以在三層交換機上,可以在防火牆上,可以在服務器上,所以和物理的設備無關。
數據包通過多個路由器道友的幫助,在網絡世界途徑了很多路程,最終抵達了目的地的城門!城門值守的路由器,發現了這個小兄弟數據包原來是找城內的人,於是它就將數據包送進了城內,再經由城內的交換機幫助下,最終轉發到了目的地了。數據包感慨萬千的說道:「多謝這一路上,各路大俠的相助!」

 10.互相扒皮——服務器與客戶端

數據包抵達了服務器,服務器肯定高興呀,正所謂有朋自遠方來,不亦樂乎?

服務器高興的不得了,於是開始扒數據包的皮!就好像你收到快遞,能不興奮嗎?

數據包抵達服務器後,服務器會先扒開數據包的 MAC 頭部,查看是否和服務器自己的 MAC 地址符合,符合就將包收起來。

接着繼續扒開數據包的 IP 頭,發現 IP 地址符合,根據 IP 頭中協議項,知道自己上層是 TCP 協議。

於是,扒開 TCP 的頭,裏面有序列號,需要看一看這個序列包是不是我想要的,如果是就放入緩存中然後返回一個 ACK,如果不是就丟棄。TCP頭部裏面還有端口號, HTTP 的服務器正在監聽這個端口號。

於是,服務器自然就知道是 HTTP 進程想要這個包,於是就將包發給 HTTP 進程。

服務器的 HTTP 進程看到,原來這個請求是要訪問一個頁面,於是就把這個網頁封裝在 HTTP 響應報文里。


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

穿好頭部衣服後,從網卡出去,交由交換機轉發到出城的路由器,路由器就把響應數據包發到了下一個路由器,就這樣跳啊跳。

最後跳到了客戶端的城門把手的路由器,路由器扒開 IP 頭部發現是要找城內的人,於是把包發給了城內的交換機,再由交換機轉發到客戶端。

客戶端收到了服務器的響應數據包後,同樣也非常的高興,客戶能拆快遞了!

於是,客戶端開始扒皮,把收到的數據包的皮扒剩 HTTP 響應報文後,交給瀏覽器去渲染頁面,一份特別的數據包快遞,就這樣顯示出來了!

最後,客戶端要離開了,向服務器發起了 TCP 四次揮手,至此雙方的連接就斷開了。

 

參考://mp.weixin.qq.com/s/iSZp41SRmh5b2bXIvzemIw