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

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

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

在分析 HTTP1.1 傳輸?shù)幕A上再去嘗試分析重定向以及 HTTPS，甚至已經開始應用的 HTTP2 等網站就變得很容易。需要說明的是本文只分析協(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 虛線所示，應用層之間互相通信，傳輸層之間互相交換數(shù)據(jù)，同理網絡層和物理層。這里面以 HTTP 這個常見的應用層協(xié)議為例說明對等傳輸。

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

圖 2

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

從 HTTP 這個應用層來說，通信過程是這樣的。

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

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

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

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

圖 3

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

圖 4

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

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

在一條流的結束時候，有四次揮手斷開相應的 TCP 連接，如圖 5：

圖 5

同樣的 IP 層是基于 IP 地址所建立的鏈接，MAC 是基于 MAC 地址多建立的鏈接。當然顯而易見的是，這些鏈接并不唯一。但是協(xié)議棧中各層析協(xié)議組合起來構成的鏈接在某個時刻就是唯一的一條鏈接，因此可以看到在復雜的網絡中數(shù)據(jù)為什么非常有秩序的從一個終端流向另一個終端，正是這一條條唯一的鏈接所決定，不會跑偏。同時也可以看到協(xié)議中非常重要的一個要素就是地址，無論是 MAC 地址，IP 地址，端口，URL 都是一種地址，而地址就是通信的目的地?；诘刂返逆溄泳蜆嫵闪藚f(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é)議的服務都會遵守。如果想了解關于更多的常見端口信息，可以參見我寫的文章，這里?？蛻舳说?IP 就是本機 IP，服務器的 IP 地址的獲取過程通過 DNS 來完成。

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

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

圖 6

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

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

圖 7

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

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

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

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

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

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

圖 8

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

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

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

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

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

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

三、自底向上

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

圖 9

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

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

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

圖 10

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

圖 11

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

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

新聞名稱：訪問一個網頁背后所經歷了哪些過程
路徑分享：http://jinyejixie.com/news/98083.html

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

廣告

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