前言

---

互聯(lián)網(wǎng)的原始目的，就是為了傳輸文本（文本對(duì)話）。那我們使用瀏覽器發(fā)送請(qǐng)求后頁(yè)面是如何呈現(xiàn)在我們面前的呢？ 接下來(lái)由圖片介紹下URL到呈現(xiàn)頁(yè)面的過(guò)程。

一、文本對(duì)話--從請(qǐng)求到響應(yīng)

客戶端（瀏覽器）請(qǐng)求過(guò)程

我們?cè)跒g覽器中輸入一個(gè) URL，回車(chē)之后便會(huì)在瀏覽器中觀察到頁(yè)面內(nèi)容。實(shí)際上這個(gè)過(guò)程是：

（1）瀏覽器向網(wǎng)站所在的服務(wù)器發(fā)送了一個(gè) Request（請(qǐng)求）

（2）網(wǎng)站服務(wù)器接收到這個(gè)Request之后進(jìn)行處理和解析

（3）然后返回對(duì)應(yīng)的一個(gè)Response（響應(yīng)）給瀏覽器，Response里面就包含了頁(yè)面的源代碼等內(nèi)容

（4）瀏覽器再對(duì)其進(jìn)行解析便將網(wǎng)頁(yè)呈現(xiàn)了出來(lái)。

這個(gè)文本對(duì)話的過(guò)程是建立在怎樣的規(guī)則上面呢？簡(jiǎn)單說(shuō)，這個(gè)通信的過(guò)程是基于TCP/IP通信協(xié)議族規(guī)范上實(shí)現(xiàn)的，完成從客戶端到服務(wù)器端等一系列信息交換的流程。

?

二、TCP/IP 協(xié)議族介紹

---

1、TCP/IP協(xié)議族是什么呢？

TCP/IP協(xié)議族的目的就是通過(guò)建立規(guī)則使計(jì)算機(jī)之間可以進(jìn)行信息交換。

相互通信的雙方就必須基于相同的方法，比如由哪一邊先發(fā)起通信、使用哪種語(yǔ)言進(jìn)行通信、怎樣結(jié)束通信等規(guī)則都需要事先確定，我們就把這種規(guī)則稱(chēng)為協(xié)議（protocol）。通常我們說(shuō)的TCP/IP協(xié)議族是互聯(lián)網(wǎng)相關(guān)的各類(lèi)協(xié)議族的總稱(chēng)。

TCP/IP協(xié)議族

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

這里就說(shuō)到TCP/IP重要的層次化劃分，按層次可以分為4層：應(yīng)用層、傳輸層、網(wǎng)絡(luò)層和鏈路層。（層次化的好處在于每個(gè)層次內(nèi)部的設(shè)計(jì)可以自由改動(dòng)，并通過(guò)各層的接口關(guān)聯(lián)起來(lái)，而如果只有一個(gè)協(xié)議統(tǒng)籌就需要對(duì)所有涉及到的部分都重新設(shè)計(jì)。）

應(yīng)用層、傳輸層、網(wǎng)絡(luò)層和鏈路層

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

（1）?應(yīng)用層：決定了向用戶提供應(yīng)用服務(wù)時(shí)候的通信活動(dòng)。應(yīng)用層負(fù)責(zé)傳送各種最終形態(tài)的數(shù)據(jù)，是直接與用戶打交道的層，典型協(xié)議是HTTP、FTP等。

（2）?傳輸層：負(fù)責(zé)傳送文本數(shù)據(jù)。傳輸層有兩個(gè)性質(zhì)不同的協(xié)議： TCP（Transmission Control Protocol，傳輸控制協(xié)議）和 UDP（User Data Protocol，用戶數(shù)據(jù)報(bào)協(xié)議）。

TCP UDP

（3）?網(wǎng)絡(luò)層：負(fù)責(zé)分配地址和傳送二進(jìn)制數(shù)據(jù)，主要協(xié)議是IP協(xié)議；

（4）?鏈路層：負(fù)責(zé)建立電路連接，是整個(gè)網(wǎng)絡(luò)的物理基礎(chǔ)，典型的協(xié)議包括以太網(wǎng)、ADSL等。

3、TCP/IP 通信傳輸流

在TCP/IP各功能層之間數(shù)據(jù)是如何流動(dòng)傳輸?shù)哪?#xff1f;

通信傳輸流

（1）首先作為發(fā)送端的客戶端在應(yīng)用層（HTTP 協(xié)議）發(fā)出的 HTTP請(qǐng)求（如：想瀏覽www.baidu.com），并生成HTTP報(bào)文。

（2）為了傳輸方便，在傳輸層（TCP 協(xié)議）把從應(yīng)用層處收到的數(shù)據(jù)（HTTP 請(qǐng)求報(bào)文）進(jìn)行分割，并在 各個(gè)報(bào)文上打上標(biāo)記序號(hào)及端口號(hào)后轉(zhuǎn)發(fā)給網(wǎng)絡(luò)層。

（3）在網(wǎng)絡(luò)層（IP 協(xié)議），增加作為通信目的地的 MAC 地址后轉(zhuǎn)發(fā)給鏈路層。

（4）給這些數(shù)據(jù)附加上以太網(wǎng)首部并進(jìn)行發(fā)送處理，生成的以太網(wǎng)數(shù)據(jù)包將通過(guò)物理層傳輸給接收端。

（5）接收端的服務(wù)器在鏈路層接收到數(shù)據(jù)，按序往上層發(fā)送，一直到應(yīng)用層。當(dāng)傳輸?shù)綉?yīng)用層，才能算真正接收到由客戶端發(fā)送過(guò)來(lái)的 HTTP 請(qǐng)求。

在通信過(guò)程每經(jīng)過(guò)一層時(shí)必定會(huì)被打上一個(gè)該層所屬的首部信息。反之，接收端在層與層傳輸數(shù)據(jù)時(shí)，每經(jīng)過(guò)一層時(shí)會(huì)把對(duì)應(yīng)的首部消去。

三、基于TCP/IP通信過(guò)程

一張圖來(lái)說(shuō)明請(qǐng)求到網(wǎng)頁(yè)呈現(xiàn)的通信過(guò)程（ 下圖基于IP 協(xié)議、TCP 協(xié)議 、DNS 服務(wù)和HTTP 協(xié)議的通信過(guò)程），并對(duì)每一步做說(shuō)明：

通信過(guò)程

1、瀏覽器輸入U(xiǎn)RL發(fā)送請(qǐng)求

URL（Uniform Resource Locator，統(tǒng)一資源定位符），是使用 Web 瀏覽器等訪問(wèn) Web 頁(yè)面時(shí)需要輸入的網(wǎng)頁(yè)地址。

url

URL由以下元素組成：

URL格式介紹

（1） 傳送協(xié)議：http:或者h(yuǎn)ttps:等

（2） 層級(jí)URL標(biāo)記符號(hào)：為“//”固定不變

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

（4） 服務(wù)器地址：通常為域名，有時(shí)為IP地址（實(shí)際通信中需要通過(guò)IP地址訪問(wèn)，域名通過(guò)DNS服務(wù)器解析出IP地址）

（5） 端口號(hào)：以數(shù)字方式表示，若為HTTP的默認(rèn)值“:80”可省略

（6） 路徑：以“/”字符區(qū)別路徑中的每一個(gè)目錄名稱(chēng)

（7） 查詢：GET模式的窗體參數(shù)，以“?”字符為起點(diǎn)，每個(gè)參數(shù)以“&”隔開(kāi)，再以“=”分開(kāi)參數(shù)名稱(chēng)與數(shù)據(jù)，通常以UTF8的URL編碼，避開(kāi)字符沖突的問(wèn)題

（8） 片段：以“#”字符為起點(diǎn)，使用片段標(biāo)識(shí)符通常可標(biāo)記出已獲取資源中的子資源

2、DNS對(duì)請(qǐng)求中的URL域名解析

DNS協(xié)議

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

計(jì)算機(jī)既可以被賦予IP地址，也可以被賦予主機(jī)名和域名，用戶通常使用主機(jī)名或域名來(lái)訪問(wèn)對(duì)方的計(jì)算機(jī)，而不是直接通過(guò) IP 地址訪問(wèn)。而計(jì)算機(jī)相對(duì)更容易處理一組數(shù)字，這時(shí)DNS域名解析服務(wù)應(yīng)運(yùn)而生。DNS 協(xié)議提供通過(guò)域名查找 IP 地址（或逆向從 IP 地址反查域名的服務(wù)）。

3、HTTP協(xié)議生成請(qǐng)求報(bào)文

HTTP協(xié)議：HyperText Transfer Protocol超文本傳輸協(xié)議位于應(yīng)用層，決定從客戶端到服務(wù)器端等一系列通信內(nèi)容及方式，這通過(guò)生成報(bào)文并發(fā)送完成通信。

HTTP協(xié)議

（1）請(qǐng)求報(bào)文的構(gòu)成

請(qǐng)求報(bào)文

（2）響應(yīng)報(bào)文的構(gòu)成

響應(yīng)報(bào)文

4、TCP協(xié)議提供可靠的字節(jié)流傳輸服務(wù)

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

（1）字節(jié)流服務(wù)（Byte Stream Service）是指，為了方便傳輸，將大塊數(shù)據(jù)分割成以報(bào)文段（segment） 為單位的數(shù)據(jù)包進(jìn)行管理。

（2）可靠的傳輸服務(wù)是指，能夠把數(shù)據(jù)準(zhǔn)確可靠地傳給對(duì)方。TCP 協(xié)議采用了三次握手連接等策略保證傳輸?shù)目煽啃?#xff08;三次握手，四次揮手文末會(huì)有重點(diǎn)補(bǔ)充）

3次握手

5、IP協(xié)議實(shí)現(xiàn)數(shù)據(jù)傳遞到對(duì)方計(jì)算機(jī)

IP（Internet Protocol）網(wǎng)際協(xié)議位于網(wǎng)絡(luò)層。 IP協(xié)議的作用在于實(shí)現(xiàn)數(shù)據(jù)包傳遞到對(duì)方計(jì)算機(jī)IP地址。而IP間的通信依賴于MAC 地址（網(wǎng)卡所屬的固定地址），還需要再通過(guò)ARP 協(xié)議根據(jù)通信方的 IP 地址反查出對(duì)應(yīng)的MAC 地址。

IP協(xié)議

6、接收并解析請(qǐng)求報(bào)文后回傳響應(yīng)報(bào)文

服務(wù)器接收及解析請(qǐng)求報(bào)文后回傳響應(yīng)報(bào)文

接收端（服務(wù)器）響應(yīng)報(bào)文同樣利用TCP/IP通信協(xié)議回傳

四、TCP建立連接及斷開(kāi)（重點(diǎn)補(bǔ)充）

TCP建立連接（3次握手）

TCP 提供面向有連接的通信傳輸，面向有連接是指在數(shù)據(jù)通信開(kāi)始之前先做好兩端之間的準(zhǔn)備工作。 三次握手是指建立一個(gè)TCP連接時(shí)需要客戶端和服務(wù)器端總共發(fā)送三個(gè)標(biāo)記包以確認(rèn)連接的建立。下面來(lái)看看三次握手的流程圖：

3次握手

第一次握手：客戶端將標(biāo)志位SYN置為1，隨機(jī)產(chǎn)生一個(gè)值seq=J，并將該數(shù)據(jù)包發(fā)送給服務(wù)器端，客戶端進(jìn)入SYN_SENT狀態(tài)，等待服務(wù)器端確認(rèn)。

第二次握手：服務(wù)器端收到數(shù)據(jù)包后由標(biāo)志位SYN=1知道客戶端請(qǐng)求建立連接，服務(wù)器端將標(biāo)志位SYN和ACK都置為1，ack=J+1，隨機(jī)產(chǎn)生一個(gè)值seq=K，并將該數(shù)據(jù)包發(fā)送給客戶端以確認(rèn)連接請(qǐng)求，服務(wù)器端進(jìn)入SYN_RCVD狀態(tài)。

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

為什么3次握手: 前兩次的握手很顯然是必須的，主要是最后一次，即客戶端收到服務(wù)端發(fā)來(lái)的確認(rèn)后為什么還要想服務(wù)端再發(fā)送一次確認(rèn)呢？這主要是為了防止已失效的請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端而產(chǎn)生連接的誤判。

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

TCP斷開(kāi)連接（4次揮手）

TCP連接是全雙工的，因此，每個(gè)方向都必須要單獨(dú)進(jìn)行關(guān)閉， 四次揮手即終止TCP連接，就是指斷開(kāi)一個(gè)TCP連接時(shí)，需要客戶端和服務(wù)端總共發(fā)送4個(gè)包以確認(rèn)連接的斷開(kāi)。 下面來(lái)看看四次揮手的流程圖：

4次揮手

注：中斷連接端可以是客戶端，也可以是服務(wù)器端。下文舉的例子是以客戶端發(fā)出中斷請(qǐng)求。

第一次揮手：客戶端發(fā)送一個(gè)FIN=M，用來(lái)關(guān)閉客戶端到服務(wù)器端的數(shù)據(jù)傳送，客戶端進(jìn)入FIN_WAIT_1狀態(tài)。意思是說(shuō)"我客戶端沒(méi)有數(shù)據(jù)要發(fā)給你了"，但是如果你服務(wù)器端還有數(shù)據(jù)沒(méi)有發(fā)送完成，則不必急著關(guān)閉連接，可以繼續(xù)發(fā)送數(shù)據(jù)。

第二次揮手：服務(wù)器端收到FIN后，先發(fā)送ack=M+1，告訴客戶端，“你的請(qǐng)求我收到了，但是我還沒(méi)準(zhǔn)備好，請(qǐng)繼續(xù)你等我的消息。”這個(gè)時(shí)候客戶端就進(jìn)入FIN_WAIT_2狀態(tài)，繼續(xù)等待服務(wù)器端的FIN報(bào)文。

第三次揮手：當(dāng)服務(wù)器端確定數(shù)據(jù)已發(fā)送完成，則向客戶端發(fā)送FIN=N報(bào)文，告訴客戶端，好了，我這邊數(shù)據(jù)發(fā)完了，準(zhǔn)備好關(guān)閉連接了。服務(wù)器端進(jìn)入LAST_ACK狀態(tài)。

第四次揮手：客戶端收到FIN=N報(bào)文后，就知道可以關(guān)閉連接了，但是他還是不相信網(wǎng)絡(luò)，怕服務(wù)器端不知道要關(guān)閉，所以發(fā)送ACK=1，ack=N+1后進(jìn)入TIME_WAIT狀態(tài)，如果服務(wù)器端沒(méi)有收到ACK則可以重傳。服務(wù)器端收到ACK后，就知道可以斷開(kāi)連接了（CLOSED狀態(tài)）。客戶端等待了2MSL（時(shí)間MSL叫做最長(zhǎng)報(bào)文壽命，RFC建議設(shè)為2分鐘）后依然沒(méi)有收到回復(fù)，則證明服務(wù)器端已正常關(guān)閉，客戶端也可以關(guān)閉連接了。最終完成了四次握手。

為什么4次揮手：TCP協(xié)議是一種面向連接的、可靠的字節(jié)流的運(yùn)輸層通信協(xié)議，TCP是全雙工模式，這就意味著，當(dāng)客戶端發(fā)出FIN報(bào)文段時(shí)，只是表示客戶端已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送了，客戶端告訴服務(wù)器，它的數(shù)據(jù)已經(jīng)全部發(fā)送完畢了；但是，這個(gè)時(shí)候客戶端還是可以接受來(lái)自服務(wù)器的數(shù)據(jù)；當(dāng)服務(wù)器返回ACK報(bào)文段時(shí)，表示它已經(jīng)知道客戶端沒(méi)有數(shù)據(jù)發(fā)送了，但是主機(jī)2還是可以發(fā)送數(shù)據(jù)到客戶端的；當(dāng)服務(wù)器也發(fā)送了FIN報(bào)文段時(shí)，這個(gè)時(shí)候就表示服務(wù)器也沒(méi)有數(shù)據(jù)要發(fā)送了，就會(huì)告訴客戶端，我也沒(méi)有數(shù)據(jù)要發(fā)送了，之后彼此就會(huì)愉快的中斷這次TCP連接。

為什么客戶端TIME_WAIT等待2MSL： （1）為了保證客戶端發(fā)送的最后一個(gè)ACK報(bào)文段能夠到達(dá)服務(wù)器。該ACK報(bào)文段很有可能丟失，因而使處于在LIST—ACK狀態(tài)的服務(wù)器收不到對(duì)已發(fā)送的FIN+ACK報(bào)文段的確認(rèn)，服務(wù)器可能會(huì)重傳這個(gè)FIN+ACK報(bào)文段，而客戶端就在這2MSL時(shí)間內(nèi)收到這個(gè)重傳的FIN+ACK報(bào)文段，接著客戶端重傳一次確認(rèn)，重新啟動(dòng)2MSL計(jì)時(shí)器，最后客戶端和服務(wù)器都進(jìn)入CLOSED狀態(tài)。（2）防止已失效的請(qǐng)求連接出現(xiàn)在本連接中。在連接處于2MSL等待時(shí)，任何遲到的報(bào)文段將被丟棄，因?yàn)樘幱?MSL等待的，由該插口（插口是IP和端口對(duì)的意思，socket）定義的連接在這段時(shí)間內(nèi)將不能被再用，這樣就可以使下一個(gè)新的連接中不會(huì)出現(xiàn)這種舊的連接之前延遲的報(bào)文段。

?

小結(jié)

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

---

參考文獻(xiàn)：

《圖解http》（下載地址）

《一篇文章帶你熟悉 TCP/IP 協(xié)議（網(wǎng)絡(luò)協(xié)議篇二）》

阮一峰《tcp-ip模型》

《【網(wǎng)絡(luò)協(xié)議】TCP連接的建立和釋放》

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。