前言

---

互聯網的原始目的，就是為了傳輸文本（文本對話）。那我們使用瀏覽器發送請求后頁面是如何呈現在我們面前的呢？ 接下來由圖片介紹下URL到呈現頁面的過程。

一、文本對話--從請求到響應

客戶端（瀏覽器）請求過程

我們在瀏覽器中輸入一個 URL，回車之后便會在瀏覽器中觀察到頁面內容。實際上這個過程是：

（1）瀏覽器向網站所在的服務器發送了一個 Request（請求）

（2）網站服務器接收到這個Request之后進行處理和解析

（3）然后返回對應的一個Response（響應）給瀏覽器，Response里面就包含了頁面的源代碼等內容

（4）瀏覽器再對其進行解析便將網頁呈現了出來。

這個文本對話的過程是建立在怎樣的規則上面呢？簡單說，這個通信的過程是基于TCP/IP通信協議族規范上實現的，完成從客戶端到服務器端等一系列信息交換的流程。

?

二、TCP/IP 協議族介紹

---

1、TCP/IP協議族是什么呢？

TCP/IP協議族的目的就是通過建立規則使計算機之間可以進行信息交換。

相互通信的雙方就必須基于相同的方法，比如由哪一邊先發起通信、使用哪種語言進行通信、怎樣結束通信等規則都需要事先確定，我們就把這種規則稱為協議（protocol）。通常我們說的TCP/IP協議族是互聯網相關的各類協議族的總稱。

TCP/IP協議族

TCP/IP協議族由那么多的協議組成，那功能上如何劃分的呢？

這里就說到TCP/IP重要的層次化劃分，按層次可以分為4層：應用層、傳輸層、網絡層和鏈路層。（層次化的好處在于每個層次內部的設計可以自由改動，并通過各層的接口關聯起來，而如果只有一個協議統籌就需要對所有涉及到的部分都重新設計。）

應用層、傳輸層、網絡層和鏈路層

2、TCP/IP各功能層的作用

（1）?應用層：決定了向用戶提供應用服務時候的通信活動。應用層負責傳送各種最終形態的數據，是直接與用戶打交道的層，典型協議是HTTP、FTP等。

（2）?傳輸層：負責傳送文本數據。傳輸層有兩個性質不同的協議： TCP（Transmission Control Protocol，傳輸控制協議）和 UDP（User Data Protocol，用戶數據報協議）。

TCP UDP

（3）?網絡層：負責分配地址和傳送二進制數據，主要協議是IP協議；

（4）?鏈路層：負責建立電路連接，是整個網絡的物理基礎，典型的協議包括以太網、ADSL等。

3、TCP/IP 通信傳輸流

在TCP/IP各功能層之間數據是如何流動傳輸的呢？

通信傳輸流

（1）首先作為發送端的客戶端在應用層（HTTP 協議）發出的 HTTP請求（如：想瀏覽www.baidu.com），并生成HTTP報文。

（2）為了傳輸方便，在傳輸層（TCP 協議）把從應用層處收到的數據（HTTP 請求報文）進行分割，并在 各個報文上打上標記序號及端口號后轉發給網絡層。

（3）在網絡層（IP 協議），增加作為通信目的地的 MAC 地址后轉發給鏈路層。

（4）給這些數據附加上以太網首部并進行發送處理，生成的以太網數據包將通過物理層傳輸給接收端。

（5）接收端的服務器在鏈路層接收到數據，按序往上層發送，一直到應用層。當傳輸到應用層，才能算真正接收到由客戶端發送過來的 HTTP 請求。

在通信過程每經過一層時必定會被打上一個該層所屬的首部信息。反之，接收端在層與層傳輸數據時，每經過一層時會把對應的首部消去。

三、基于TCP/IP通信過程

一張圖來說明請求到網頁呈現的通信過程（ 下圖基于IP 協議、TCP 協議 、DNS 服務和HTTP 協議的通信過程），并對每一步做說明：

通信過程

1、瀏覽器輸入URL發送請求

URL（Uniform Resource Locator，統一資源定位符），是使用 Web 瀏覽器等訪問 Web 頁面時需要輸入的網頁地址。

url

URL由以下元素組成：

URL格式介紹

（1） 傳送協議：http:或者https:等

（2） 層級URL標記符號：為“//”固定不變

（3） 登錄信息： 訪問資源需要的憑證信息（可省略）

（4） 服務器地址：通常為域名，有時為IP地址（實際通信中需要通過IP地址訪問，域名通過DNS服務器解析出IP地址）

（5） 端口號：以數字方式表示，若為HTTP的默認值“:80”可省略

（6） 路徑：以“/”字符區別路徑中的每一個目錄名稱

（7） 查詢：GET模式的窗體參數，以“?”字符為起點，每個參數以“&”隔開，再以“=”分開參數名稱與數據，通常以UTF8的URL編碼，避開字符沖突的問題

（8） 片段：以“#”字符為起點，使用片段標識符通常可標記出已獲取資源中的子資源

2、DNS對請求中的URL域名解析

DNS協議

DNS（Domain Name System）服務是和 HTTP協議一樣位于應用層的協議，它提供域名到 IP 地址之間的解析服務。

計算機既可以被賦予IP地址，也可以被賦予主機名和域名，用戶通常使用主機名或域名來訪問對方的計算機，而不是直接通過 IP 地址訪問。而計算機相對更容易處理一組數字，這時DNS域名解析服務應運而生。DNS 協議提供通過域名查找 IP 地址（或逆向從 IP 地址反查域名的服務）。

3、HTTP協議生成請求報文

HTTP協議：HyperText Transfer Protocol超文本傳輸協議位于應用層，決定從客戶端到服務器端等一系列通信內容及方式，這通過生成報文并發送完成通信。

HTTP協議

（1）請求報文的構成

請求報文

（2）響應報文的構成

響應報文

4、TCP協議提供可靠的字節流傳輸服務

TCP協議：Transmission Control Protocol傳輸控制協議，位于傳輸層。

（1）字節流服務（Byte Stream Service）是指，為了方便傳輸，將大塊數據分割成以報文段（segment） 為單位的數據包進行管理。

（2）可靠的傳輸服務是指，能夠把數據準確可靠地傳給對方。TCP 協議采用了三次握手連接等策略保證傳輸的可靠性（三次握手，四次揮手文末會有重點補充）

3次握手

5、IP協議實現數據傳遞到對方計算機

IP（Internet Protocol）網際協議位于網絡層。 IP協議的作用在于實現數據包傳遞到對方計算機IP地址。而IP間的通信依賴于MAC 地址（網卡所屬的固定地址），還需要再通過ARP 協議根據通信方的 IP 地址反查出對應的MAC 地址。

IP協議

6、接收并解析請求報文后回傳響應報文

服務器接收及解析請求報文后回傳響應報文

接收端（服務器）響應報文同樣利用TCP/IP通信協議回傳

四、TCP建立連接及斷開（重點補充）

TCP建立連接（3次握手）

TCP 提供面向有連接的通信傳輸，面向有連接是指在數據通信開始之前先做好兩端之間的準備工作。 三次握手是指建立一個TCP連接時需要客戶端和服務器端總共發送三個標記包以確認連接的建立。下面來看看三次握手的流程圖：

3次握手

第一次握手：客戶端將標志位SYN置為1，隨機產生一個值seq=J，并將該數據包發送給服務器端，客戶端進入SYN_SENT狀態，等待服務器端確認。

第二次握手：服務器端收到數據包后由標志位SYN=1知道客戶端請求建立連接，服務器端將標志位SYN和ACK都置為1，ack=J+1，隨機產生一個值seq=K，并將該數據包發送給客戶端以確認連接請求，服務器端進入SYN_RCVD狀態。

第三次握手：客戶端收到確認后，檢查ack是否為J+1，ACK是否為1，如果正確則將標志位ACK置為1，ack=K+1，并將該數據包發送給服務器端，服務器端檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，客戶端和服務器端進入ESTABLISHED狀態，完成三次握手建立連接，隨后客戶端與服務器端之間可以開始傳輸數據了。

為什么3次握手: 前兩次的握手很顯然是必須的，主要是最后一次，即客戶端收到服務端發來的確認后為什么還要想服務端再發送一次確認呢？這主要是為了防止已失效的請求報文段突然又傳送到了服務端而產生連接的誤判。

考慮如下的情況： 客戶端發送了一個連接請求報文段到服務端，但是在某些網絡節點上長時間滯留了，所以客戶端又超時重發了一個連接請求報文段該服務端，而后正常建立連接，數據傳輸完畢，并釋放了連接。 如果這時候第一次發送的請求報文段（已過期的）延遲了一段時間后，又到了服務端，很顯然，這本是一個早已失效的報文段，但是服務端收到后會誤以為客戶端又發出了一次連接請求，于是向客戶端發出確認報文段，并同意建立連接。假設不采用三次握手，這時服務端只要發送了確認，新的連接就建立了。但由于客戶端現階段沒有發出建立連接的請求，因此不會理會服務端的確認，也不會向服務端發送數據，而服務端卻認為新的連接已經建立了，并在一直等待客戶端發送數據，這樣服務端就會一直等待下去，直到超出保活計數器的設定值，而將客戶端判定為出了問題，才會關閉這個連接。這樣就浪費了很多服務器的資源。而如果采用三次握手，客戶端沒有再向服務端發出確認，服務端由于收不到確認，就知道客戶端沒有要求建立連接，從而不建立該連接。

TCP斷開連接（4次揮手）

TCP連接是全雙工的，因此，每個方向都必須要單獨進行關閉， 四次揮手即終止TCP連接，就是指斷開一個TCP連接時，需要客戶端和服務端總共發送4個包以確認連接的斷開。 下面來看看四次揮手的流程圖：

4次揮手

注：中斷連接端可以是客戶端，也可以是服務器端。下文舉的例子是以客戶端發出中斷請求。

第一次揮手：客戶端發送一個FIN=M，用來關閉客戶端到服務器端的數據傳送，客戶端進入FIN_WAIT_1狀態。意思是說"我客戶端沒有數據要發給你了"，但是如果你服務器端還有數據沒有發送完成，則不必急著關閉連接，可以繼續發送數據。

第二次揮手：服務器端收到FIN后，先發送ack=M+1，告訴客戶端，“你的請求我收到了，但是我還沒準備好，請繼續你等我的消息。”這個時候客戶端就進入FIN_WAIT_2狀態，繼續等待服務器端的FIN報文。

第三次揮手：當服務器端確定數據已發送完成，則向客戶端發送FIN=N報文，告訴客戶端，好了，我這邊數據發完了，準備好關閉連接了。服務器端進入LAST_ACK狀態。

第四次揮手：客戶端收到FIN=N報文后，就知道可以關閉連接了，但是他還是不相信網絡，怕服務器端不知道要關閉，所以發送ACK=1，ack=N+1后進入TIME_WAIT狀態，如果服務器端沒有收到ACK則可以重傳。服務器端收到ACK后，就知道可以斷開連接了（CLOSED狀態）。客戶端等待了2MSL（時間MSL叫做最長報文壽命，RFC建議設為2分鐘）后依然沒有收到回復，則證明服務器端已正常關閉，客戶端也可以關閉連接了。最終完成了四次握手。

為什么4次揮手：TCP協議是一種面向連接的、可靠的字節流的運輸層通信協議，TCP是全雙工模式，這就意味著，當客戶端發出FIN報文段時，只是表示客戶端已經沒有數據要發送了，客戶端告訴服務器，它的數據已經全部發送完畢了；但是，這個時候客戶端還是可以接受來自服務器的數據；當服務器返回ACK報文段時，表示它已經知道客戶端沒有數據發送了，但是主機2還是可以發送數據到客戶端的；當服務器也發送了FIN報文段時，這個時候就表示服務器也沒有數據要發送了，就會告訴客戶端，我也沒有數據要發送了，之后彼此就會愉快的中斷這次TCP連接。

為什么客戶端TIME_WAIT等待2MSL： （1）為了保證客戶端發送的最后一個ACK報文段能夠到達服務器。該ACK報文段很有可能丟失，因而使處于在LIST—ACK狀態的服務器收不到對已發送的FIN+ACK報文段的確認，服務器可能會重傳這個FIN+ACK報文段，而客戶端就在這2MSL時間內收到這個重傳的FIN+ACK報文段，接著客戶端重傳一次確認，重新啟動2MSL計時器，最后客戶端和服務器都進入CLOSED狀態。（2）防止已失效的請求連接出現在本連接中。在連接處于2MSL等待時，任何遲到的報文段將被丟棄，因為處于2MSL等待的，由該插口（插口是IP和端口對的意思，socket）定義的連接在這段時間內將不能被再用，這樣就可以使下一個新的連接中不會出現這種舊的連接之前延遲的報文段。

?

小結

以上，我們了解TCP/IP協議的作用及通信的流程，針對Http協議后續再做詳細介紹。

---

參考文獻：

《圖解http》（下載地址）

《一篇文章帶你熟悉 TCP/IP 協議（網絡協議篇二）》

阮一峰《tcp-ip模型》

《【網絡協議】TCP連接的建立和釋放》

總結

以上是生活随笔為你收集整理的图解从 URL 到网页通信原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。