訪問一個網(wǎng)頁背后所經(jīng)歷了哪些過程

本文以訪問一個實際的 HTTP 網(wǎng)站為例，講述在訪問一個網(wǎng)頁背后所經(jīng)歷哪些過程。通過介紹各層協(xié)議是如何共同協(xié)作，最終完成網(wǎng)頁數(shù)據(jù)傳輸，使得讀者能夠?qū)υ撨^程的理解更加清晰。本文以瀏覽器訪問 URL 為例，其實在眾多 APP 客戶端工作的過程中，也是會訪問各自服務(wù)器的 URL，從原理上來說和瀏覽器端的訪問基本一致，可自行對應(yīng)。

本文分析使用到的數(shù)據(jù)報文，我已經(jīng)放在這個地方，可自行下載，對應(yīng)著后續(xù)的講述更加容易的理解整個分析過程。

本文以央視網(wǎng)這樣一個 HTTP 網(wǎng)站為例來進行講述。如果訪問像這樣一個常見的域名，由于為百度已經(jīng)采用了全站加密的技術(shù)，這樣的話會出現(xiàn)一些重定向， 同時 ssl 層還有一個建立連接的過程，對于網(wǎng)絡(luò)協(xié)議還不是那么熟悉的同學(xué)來說可能會顯得較為復(fù)雜。因此這里面使用一個沒有重定向，基于 HTTP1.1 協(xié)議傳輸?shù)木W(wǎng)站會使問題的分析變的更加容易理解，同時目前國內(nèi)的大多數(shù)網(wǎng)站還停留在 HTTP1.1 傳輸階段，分析 HTTP1.1 傳輸也能夠兼顧大多數(shù)的場景。雖然一些大的互聯(lián)網(wǎng)企業(yè)都是積極的擁抱新技術(shù)，采用了 HTTPS，但是也可以看到，政府網(wǎng)站，學(xué)校網(wǎng)站，公司網(wǎng)站依然基于 HTTP1.1 傳輸居多。

在分析 HTTP1.1 傳輸?shù)幕A(chǔ)上再去嘗試分析重定向以及 HTTPS，甚至已經(jīng)開始應(yīng)用的 HTTP2 等網(wǎng)站就變得很容易。需要說明的是本文只分析協(xié)議層次的訪問流程，也就是以對主頁 URL 的訪問為例。至于主頁上的腳本，圖片等資源的加載請求的 URL 跟主頁的請求在協(xié)議角度原理一致，不在贅述。

本文的分析主要分為三個層次：

1. 站在各個協(xié)議層次來看協(xié)議間是如何對等傳輸?shù)摹?/li>
2. 站在數(shù)據(jù)發(fā)送者角度自頂向下的分析，分析各層協(xié)議字段如何獲取。
3. 站在數(shù)據(jù)接受者的角度自底向上的分析，分析各層協(xié)議之間的聯(lián)系。

一、對等傳輸

TCP/IP 模型如圖 1：

圖 1

可以看到 TCP/IP 模型的協(xié)議棧包含四層，對等傳輸表達的就是如圖 1 虛線所示，應(yīng)用層之間互相通信，傳輸層之間互相交換數(shù)據(jù)，同理網(wǎng)絡(luò)層和物理層。這里面以 HTTP 這個常見的應(yīng)用層協(xié)議為例說明對等傳輸。

在瀏覽器中輸入 http://www.cctv.com 這樣一個網(wǎng)址，同時通過 Wireshark 工具抓取傳輸過程中的數(shù)據(jù)。使用 http.host contains "cctv" 過濾排除無用的數(shù)據(jù)包，可以看到有諸多的 http 請求和響應(yīng)。如前所述，只考慮主頁 URL 的請求，并選擇第一條進行 follow，如圖 2：

圖 2

這時候你發(fā)現(xiàn)訪問 www.cctv.com 應(yīng)用層使用了 HTTP 協(xié)議進行傳輸，為什么呢？因為瀏覽器地址欄這時候地址變成了 http://www.cctv.com/，也就是瀏覽器在訪問 www.cctv.com 時候，會添加 http:// 這樣一個協(xié)議頭，默認了其傳輸協(xié)議為 HTTP。但是訪問 gitchat 卻是 https://gitbook.cn/ 這個樣子的，前面也提到了會有 http://gitbook.cn/ 重定向到 https://gitbook.cn/ 的過程，為了問題的簡化，本文不過多的討論。如果你和服務(wù)器之間想通過 ftp 協(xié)議進行傳輸，那么在瀏覽器訪地址欄輸入的時候就要帶上具體協(xié)議了，例如 ftp://image.cctv.com 這種形式，因為 image.cctv.com 會被默認為 http://image.cctv.com，ftp 協(xié)議是沒有重定向的功能的。

從 HTTP 這個應(yīng)用層來說，通信過程是這樣的。

1. 客戶端發(fā)起一個 HTTP GET 請求。
2. 服務(wù)器給出一個 HTTP/1.1 220 OK 的響應(yīng)，同時傳輸具體的網(wǎng)頁數(shù)據(jù)。整體來看，HTTP 協(xié)議過程非常的簡單，就是請求和響應(yīng)的過程。不僅 HTTP 如此，大多數(shù)的通信協(xié)議都是請求和響應(yīng)的過程。

當然 HTTP 協(xié)議復(fù)雜程度遠不止上述請求和響應(yīng)那么簡單。例如 HTTP 所規(guī)定的方法就還包括 POST，PUT，DELETE，CONNECT，OPTIONS，HEAD，TRACE 這幾種，涵蓋了數(shù)據(jù)的增刪改查等方面。HTTP 的響應(yīng)也還包括 1xx,2xx,3xx,4xx,5xx 等多種響應(yīng)方式，分別表示不同的應(yīng)答，例如信息類應(yīng)答，成功的應(yīng)答，重定向，客戶端錯誤應(yīng)答，服務(wù)器錯誤應(yīng)答等等。

除了請求方法和響應(yīng)碼之外，還有豐富的 HTTP 頭域，例如在請求階段 Host 表示請求域名，Connection 表示長連接，User-Agent 表示客戶端名稱，Referer 表示請求來源，Aceept-Encoding 表示可接受傳輸?shù)膲嚎s編碼方式等常見的請求頭域。在響應(yīng)階段，可以看到 Expires 表示內(nèi)容過期時間，Server 表示服務(wù)器名稱，Content-Encoding 表示傳輸?shù)膲嚎s編碼方式等常見的響應(yīng)頭域。

總體上看，可以理解為 HTTP 層是基于請求和應(yīng)答（請求應(yīng)答最終是協(xié)商服務(wù)器絕對路徑，因此也可以認為是基于服務(wù)器絕對地址）所建立的虛擬鏈接。頭域字段更多的是為了協(xié)商傳輸內(nèi)容服務(wù)的。有了這樣一個虛擬連接之后，自然而然的，數(shù)據(jù)就在 HTTP 層次對等的傳輸起來。如圖 3：

圖 3

可以看到，我們忽略了所有的下層，認為 HTTP 層存在一條虛擬鏈接。同理可以認為 TCP 層是基于端口所建立的鏈接，當然關(guān)于 TCP 層的對等傳輸通常指的是 TCP 的三次握手，如圖 4：

圖 4

TCP 的三次握手具體過程是：

1. 客戶端發(fā)起 TCP 連接（SYN）
2. 服務(wù)器同意，并響應(yīng)（SYN，ACK）
3. 客戶端也準備就緒，開始發(fā)數(shù)據(jù)（ACK）。

在一條流的結(jié)束時候，有四次揮手斷開相應(yīng)的 TCP 連接，如圖 5：

圖 5

同樣的 IP 層是基于 IP 地址所建立的鏈接，MAC 是基于 MAC 地址多建立的鏈接。當然顯而易見的是，這些鏈接并不唯一。但是協(xié)議棧中各層析協(xié)議組合起來構(gòu)成的鏈接在某個時刻就是唯一的一條鏈接，因此可以看到在復(fù)雜的網(wǎng)絡(luò)中數(shù)據(jù)為什么非常有秩序的從一個終端流向另一個終端，正是這一條條唯一的鏈接所決定，不會跑偏。同時也可以看到協(xié)議中非常重要的一個要素就是地址，無論是 MAC 地址，IP 地址，端口，URL 都是一種地址，而地址就是通信的目的地?；诘刂返逆溄泳蜆?gòu)成了協(xié)議層次的對等傳輸。

二、自頂向下

這個時候你可能會有疑問，在 TCP 對等傳輸中，端口從何而來，同樣的 IP 和 MAC 地址從何而來。因為我們發(fā)現(xiàn) HTTP 下層的 TCP 端口，IP 的地址這個時候都是已知的，如圖 2 中所示。端口的獲取過程很簡單，系統(tǒng)自帶 TCP 協(xié)議棧隨機選擇了一個客戶端的端口，當然通常情況下客戶端的端口都在默認在 30000 以上。同時由于傳輸協(xié)議是 HTTP 協(xié)議，因此端口為 80。因為 1-1024 這樣一個保留端口是由 IANA 規(guī)定分配給指定的協(xié)議的，80 號端口就分配給了 HTTP 協(xié)議，后面的 53 號端口分配給了 DNS 是同樣的道理，這是一個通用的標準，大多數(shù)的使用共有協(xié)議的服務(wù)都會遵守。如果想了解關(guān)于更多的常見端口信息，可以參見我寫的文章，這里?？蛻舳说?IP 就是本機 IP，服務(wù)器的 IP 地址的獲取過程通過 DNS 來完成。

DNS 是域名解析協(xié)議，就是將域名轉(zhuǎn)換為對應(yīng)的 IP 地址，因為只有通過 IP 地址才能找到對應(yīng)的主機所在。那么為什么不直接在瀏覽器里面輸入 IP 地址的，這當然是可以的，但是由于 IP 地址沒有域名方便于記憶，通常輸入的都是域名，因此中間多了這一道過程，計算機設(shè)計的目的還是要方便于人。

使用 dns.qry.name == "www.cctv.com" 過濾得到 http://www.cctv.com/ 對應(yīng)的 DNS 請求，如圖 6：

圖 6

可以看到 DNS 使用的是 UDP 協(xié)議，源端口是本機分配的端口，由系統(tǒng)的 UDP 協(xié)議棧進行分配，而目的端口是 53，前面也提到了。因此協(xié)議棧在發(fā)送 DNS 協(xié)議的時候，將目的端口賦值為 53，長度則是由 DNS 長度來決定。

同樣的 IP 層的目的地址從何而來？其實該地址是本機所配置的 dns 地址，如圖 7：

圖 7

由于本機使用的是 DHCP 服務(wù)且使用的是電信的寬帶，因此自動獲取的最近的一個電信的 DNS，因此這里的目的地址就是電信的 DNS。當然如果你手動配置了 DNS，這時候的目的 IP 就是你所配置的目標 DNS，例如 114.114.114.114，以及 8.8.8.8 這些較為知名的 DNS 服務(wù)器，可以親自手動設(shè)置下，抓包驗證。

有了 IP 層的地址，那么以太網(wǎng)層的信息如何獲取呢？首先上層是 Ipv4 協(xié)議，因此 type 字段就是確定的值，源地址就是本機的 MAC 地址，按照通常的思路，你可能理所當然的認為目的 MAC 應(yīng)該是目的 IP 所對應(yīng)的 MAC 地址，但是事實上并非如此。由于目的 IP 和源 IP 并不是處在同一個網(wǎng)段之中，通過 IP 地址和子網(wǎng)掩碼與的結(jié)果并不相同得知。同時 MAC 層的通信規(guī)定的是局域網(wǎng)范圍內(nèi)的通信過程，對于不在同一個局域網(wǎng)內(nèi)的主機來說，首先應(yīng)該把數(shù)據(jù)包交給網(wǎng)關(guān)設(shè)備，由網(wǎng)關(guān)設(shè)備進行轉(zhuǎn)發(fā)。

由于本機配置的網(wǎng)關(guān)為 192.168.0.1，圖 7 所示，因此可以斷定這里面配置的 MAC 為網(wǎng)關(guān)的 MAC 地址。因此在完成這個報文發(fā)送之前應(yīng)該還有一個過程，獲取網(wǎng)關(guān)的 MAC 地址，根據(jù)網(wǎng)關(guān)的 IP 地址獲取網(wǎng)關(guān)的 MAC 過程就是 ARP 的過程。

介紹一下 ARP 的主要原理，如下：

1. 先在 ARP 緩存中查看是否存在目的主機的的 IP 地址，windows 上可以通過在命令行輸入 arp -a 查看。如果有，就把這個硬件地址寫入相應(yīng)的 MAC 層中。
2. 如果沒有目的 IP 地址，將在 ARP 幀中的目的 MAC 部分寫全 F 形式表示廣播該數(shù)據(jù)，因此網(wǎng)段內(nèi)所有的主機或設(shè)備都能夠接收到該數(shù)據(jù)幀。除了目的主機外，所有接收到該 ARP 請求幀的主機和設(shè)備都會丟棄該 ARP 請求幀。
3. 目的主機收到請求后構(gòu)造并發(fā)送 ARP 應(yīng)答幀。
4. 源主機收到 ARP 響應(yīng)后，將目的主機的物理地址作為一條新記錄加入到 ARP 高速緩存表。

通過 ARP 過濾器進行過濾，如圖 8

圖 8

由于本機的 ARP 緩存中有網(wǎng)關(guān)的記錄，因此不用發(fā)送相應(yīng)的廣播包，但是發(fā)現(xiàn) ARP 請求中填寫了目的的 MAC 地址和 IP 地址，并且目的也給予了響應(yīng)。這有可能是 ARP 具體實現(xiàn)過程中的刷新 ARP 緩存的一種優(yōu)化策略，因為廣播包畢竟會造成網(wǎng)絡(luò)擁堵。

至此我們已經(jīng)分析到了四層模型中的鏈路層，最底層了。在獲取網(wǎng)關(guān)的 MAC 之后，會把該值填入 DNS 那條流中對應(yīng)的以太網(wǎng)層中，圖 6 中。網(wǎng)關(guān)在收到 DNS 報文之后，會使用路由選擇協(xié)議，根據(jù)目的 IP 地址，將該數(shù)據(jù)包轉(zhuǎn)發(fā)到下一跳網(wǎng)關(guān)路由器上，從而不斷的在一個個小的局域網(wǎng)內(nèi)部轉(zhuǎn)發(fā)，最終達到目標 IP 所在的局域網(wǎng)，然后送達目標 IP 服務(wù)器。這個過程和快遞的投送是類似的，快遞的投送有沒有借鑒該過程就不得而知了。

在 DNS 服務(wù)器收到相應(yīng)的請求之后，就將對應(yīng)的響應(yīng)報文返回給客戶端，如上圖 6，數(shù)據(jù)不斷通過路由選擇協(xié)議在一個個局域網(wǎng)之間流動?？蛻粼谑盏巾憫?yīng)報文后，將報文交由協(xié)議棧中不同的層進行解封裝處理，最終獲取域名對對應(yīng)的 IP 地址。

當然上述是基于 DNS 服務(wù)器中具有域名和 IP 的對應(yīng)關(guān)系，則會返回對應(yīng)的 IP 地址。如果域名服務(wù)器中沒有，會作何處理。因為域名服務(wù)器的行為，本地是無法觀測的，因此對于 DNS 原理作以下介紹。DNS 分為如下幾步：

1. 客戶端查看本地緩存表，如果本地緩存表中存在域名和 IP 的對應(yīng)關(guān)系，則可以獲取相應(yīng)的 IP 地址，在 windows 上的查看命令是 ipconfig /displaydns。當然有的瀏覽器也會緩存 IP 和域名的映射表，以加快連接的建立過程。但是各個瀏覽器的實現(xiàn)并不一致，這里不再討論。
2. 如果不存在，向 DNS 服務(wù)器發(fā)送 DNS 請求報文，來獲取相應(yīng)的 IP 地址。你可能會問 DNS 服務(wù)器在哪里？上面已經(jīng)介紹過了，可以查看本機 DNS 服務(wù)器的配置情況。
3. 同樣的道理 DNS 服務(wù)器也可能沒有相應(yīng)的域名和 IP 的映射表，這個時候由 DNS 服務(wù)器（而不是客戶端）會像根域名服務(wù)器發(fā)起請求 (全球 13 臺，主要控制在美國手中) 詢問，如果沒有，根域名給出的是頂級域名服務(wù)器的 IP，例如通知你去詢問 com 域服務(wù)器，com 域服務(wù)器上存在了所有 com 相關(guān)定義域名的一些記錄。當然如果訪問的是 mail.cctv.com 這樣一個域名，com 域名服務(wù)器有可能會通知繼續(xù)去詢問 cctv 這樣一個域名服務(wù)器等等，這是一個不斷迭代的過程，由 DNS 服務(wù)器來完成。最終 DNS 服務(wù)器給出相應(yīng)的 IP 地址，或者是報錯。

至此獲取訪問 www.cctv.com 主頁的那條流中 IP 地址，圖 2 所示，主要是通過 DNS。在分析的過程中順便分析了 DNS 流中 MAC 地址的獲取方法以及數(shù)據(jù)如何在網(wǎng)絡(luò)中不斷的流動。有了前面 DNS 傳輸?shù)睦樱瑯拥年P(guān)于該 HTTP 流中自頂向下的封裝和 DNS 是一樣的。

三、自底向上

客戶端發(fā)送報文的時候，數(shù)據(jù)在協(xié)議棧中的流動是打上每層協(xié)議的協(xié)議頭?？蛻粼谑盏巾憫?yīng)報文后，是如何獲取最終的網(wǎng)頁數(shù)據(jù)的呢？報文自底向上交，由協(xié)議棧中不同的層進行解封裝處理，MAC 層處理前 14 個字節(jié)，IP 層，TCP 層以及 HTTP 層根據(jù)該層頭部長度處理對應(yīng)的字節(jié)數(shù)。這是一個自底向上解碼的過程。在去掉所有協(xié)議頭之后，剩下的數(shù)據(jù)部分就是網(wǎng)頁數(shù)據(jù)。當然整個的網(wǎng)頁數(shù)據(jù)是在將每一個包的網(wǎng)頁數(shù)據(jù)按照順序進行組合后形成的，如圖 9：

圖 9

可以看到該網(wǎng)頁由 42 個報文組成，報之間的順序在 TCP 層已經(jīng)通過 Sequence Number 定義了，Sequence Number 表示的就是數(shù)據(jù)相對于開始的偏移，因此不用擔心亂序問題。既然數(shù)據(jù)在收到之后，是通過剝離協(xié)議頭，按照 TCP 的 Sequence Number 交給客戶端（也就是瀏覽器）時候，那么自然是可以根據(jù)報文數(shù)據(jù)來還原原始網(wǎng)頁數(shù)據(jù)的，原理已經(jīng)介紹過了。當然相應(yīng)的還原方法有多種，我在上一篇 chat 中基于 Wireshark 插件介紹了一種簡單實用的方法，感興趣的可以參考之，見這里。

上述其實反映的是各層協(xié)議之間是存在一定聯(lián)系，就是應(yīng)用層數(shù)據(jù)順序是由 TCP 傳輸層來決定的。當然 MAC 層有表示 IP 層協(xié)議的字段，以及 IP 層也有表示傳輸層協(xié)議字段也是各層聯(lián)系的一個體現(xiàn)。

我們接下來以一個更為明顯的例子加以說明。還記得在學(xué)習 TCP/IP 協(xié)議的時候，TCP 有 6 個標志位，像 ACK，F(xiàn)IN，SYN 都是喜聞樂見的標志位。但是 PUSH 這個標志位表示的是什么含義呢？在什么時候用呢？PUSH 標志位所表達的是發(fā)送方通知接收方應(yīng)該盡快的將這個報文段交給應(yīng)用層。傳輸層及以下的數(shù)據(jù)往往是由系統(tǒng)所帶的協(xié)議棧進行處理的，客戶端在收到一個個報文之后，經(jīng)由協(xié)議棧解封裝之后會立馬把數(shù)據(jù)交給應(yīng)用層去處理嗎？如果說在收到報文之后立馬就交給上層，這時候應(yīng)用層由于數(shù)據(jù)不全，可能也不會進行處理。而且每來一個報文就交一次，效率很低。因此傳輸層一般會是隔幾個報文，統(tǒng)一上交數(shù)據(jù)。什么時候上交數(shù)據(jù)呢，就是在發(fā)送方將 PUSH 標志位置 1 的時候。那么什么時候標志位會置 1 呢，通常是發(fā)送端覺得傳輸?shù)臄?shù)據(jù)應(yīng)用層可以進行處理了的時候，如圖 10 所示：

圖 10

由于通常網(wǎng)絡(luò)較好的時候，數(shù)據(jù)會以滿包狀態(tài)進行傳輸，當然這里面是 1494 個字節(jié)，當一段數(shù)據(jù)傳輸完畢就會出現(xiàn)包長度下降，這時候 PUSH 就置 1，提示傳輸層盡快刷新數(shù)據(jù)交由應(yīng)用層處理。其實一個更為明顯的例子是 ssl 握手階段，在服務(wù)器將證書傳輸完畢之后，是需要應(yīng)用層趕緊處理，進行證書鏈的驗證，因此會設(shè)置 PUSH 字段來告知傳輸層盡快上交數(shù)據(jù)，如圖 11：

圖 11

可以找一個 ssl 報文觀察，證書傳輸完畢時候，是否 PUSH 字段設(shè)置了。相信通過上述的分析，你不僅對于 PUSH 字段的實際應(yīng)用有所理解，也對各層協(xié)議之間的聯(lián)系印象深刻。

總結(jié)上述過程，對等傳輸就是 HTTP、TCP、IP、MAC 層分別建立鏈接。自頂向下就是分別打上各層的協(xié)議頭，各層的地址等信息如何獲取，又涉及到其他協(xié)議類似的過程。自底向上就是不斷解封裝過程，包括 MAC 層解封裝，IP 層解封裝，TCP 層解封裝，HTTP 層解封裝。當然各層協(xié)議之間不是獨立的，存在一定的耦合，比如 PUSH 的作用等等?；谏鲜龅囊粋€分析，相信對于協(xié)議的分層機制，以及數(shù)據(jù)傳輸背后協(xié)議的工作流程就能夠徹底的明白了。

新聞名稱：訪問一個網(wǎng)頁背后所經(jīng)歷了哪些過程
路徑分享：http://muchs.cn/news/98083.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供營銷型網(wǎng)站建設(shè)、App開發(fā)、定制網(wǎng)站、網(wǎng)站改版、網(wǎng)站內(nèi)鏈、做網(wǎng)站

廣告

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