web頁面的請求過程

關鍵路徑：開啟瀏覽器，輸入url，連線伺服器，渲染伺服器返回的結果。

那在這個過程中首先我們需要建立連線，也就是tcp三次握手，先開始第一次握手，也就是主機向伺服器傳送請求報文段，這就需要知道源ip，目的ip。

1、dhcp discover：客戶端以廣播形式傳送dhcp discover報文，該區域網內的所有dhcp伺服器都可以收到此報文。

2、dhcp offer：dhcp伺服器收到客戶端傳送的dhcp discover報文後，會從配置的位址池中選擇乙個ip位址預分配給客戶端，該ip位址封裝在dhcp offer報文內以廣播形式傳送給客戶端。

3、dhcp request：客戶端會在收到的dhcp offer報文中選擇乙個ip,一般為第乙個收到的dhcp offer報文，但此時客戶端並不能使用該ip，需要以廣播形式傳送dhcp request報文給dhcp伺服器。

4、dhcp ack：dhcp伺服器收到後會檢視客戶端選擇的是否為自己分配的ip位址，如果不是，則將ip位址放回位址池，等待下一次的客戶端的申請。如果選擇的是自己分配的ip位址，則廣播傳送dhcp ack報文給客戶端，並在服務端將客戶端的mac位址和ip位址進行繫結。

5、客戶端收到該報文後不會立即使用，而是利用arp進行探測該位址是否被其他客戶端所使用，如果在超時時間內沒有得到回應，則客戶端使用該ip位址，如果得到arp回應，則傳送dhcp decline包給dhcp伺服器，然後重複上述流程，向dhcp伺服器申請ip位址。

6、dhcp客戶端重新啟動後不需要再傳送dhcp discover報文進行位址申請，它進行和續約類似的操作。

網路層新增頭部封裝成ip資料報，主要包含

資料鏈路層新增頭部封裝成乙太網幀，主要包含

乙太網幀被傳送到交換機，交換機修改**表記錄我的mac

與交換機相連的預設閘道器路由器接收到了這個廣播幀，進行解析，提取出ip資料報，發現目的ip是廣播ip，就交給傳輸層，傳輸層又提取出 dhcp 請求交給應用層， dhcp 伺服器就收到了該 dhcp 請求。

dhcp 伺服器為此生成乙個 dhcp ack 報文，主要包含：

這個報文再被傳輸層、網路層、資料鏈路層一路封裝成幀，該幀的目的 mac 是我的mac，源mac是接收 dhcp 請求幀的路由器埠的 mac

dhcp ack乙太網幀由預設閘道器路由器傳送給交換機，交換機根據**表**回給我的主機

主機收到該幀之後再從鏈路層到應用層，層層提取，最後得到自己的ip、dns伺服器ip、預設閘道器路由器ip，進行配置

獲得到ip

查詢目的網域名稱的ip：dns網域名稱系統

層層封裝成乙太網幀，幀的目的 mac 是預設閘道器路由器的 mac

預設閘道器路由器接收到該幀之後，提取出ip資料報，並根據路由表進行**，因為路由器具有內部閘道器協議*（rip路由資訊協議、ospf開放最短路徑優先協議）和外部閘道器協議（bgp邊界閘道器協議）*，因此路由表中已經配置了可以從路由器到達 dns 伺服器的路由表項

rip：同一自治系統(a.s.)中的路由器每 30秒會與相鄰的路由器交換子訊息，以動態的建立路由表。rip 允許最大的hop數(跳數）為15 多於15跳不可達。

ospf：dijkstra最短路演算法

目的伺服器收到主機的確認後，連線就建立了。

為什麼要進行第三次握手呢？

第三次握手是為了防止失效的連線請求到達伺服器，讓伺服器錯誤開啟連線。

客戶端傳送的連線請求如果在網路中滯留，那麼就會隔很長一段時間才能收到伺服器端發回的連線確認。客戶端等待乙個超時重傳時間之後，就會重新請求連線。但是這個滯留的連線請求最後還是會到達伺服器，如果不進行三次握手，那麼伺服器就會開啟兩個連線。如果有第三次握手，客戶端會忽略伺服器之後傳送的對滯留連線請求的連線確認，不進行第三次握手，因此就不會再次開啟連線。

瀏覽器收到 http 響應報文後，抽取出 web 頁面內容，之後進行渲染，顯示 web 頁面。

web頁面的請求過程

web頁面的請求過程

頁面的請求過程

Web 頁面請求過程

相關推薦