歡迎光臨
每天分享高質量文章

圖解從 URL 到網頁通信原理

點擊上方“芋道原始碼”,選擇“設為星標

做積極的人,而不是積極廢人!

原始碼精品專欄

 

來源:http://t.cn/RBzkRYO

  • 前言
  • 一、文本對話–從請求到響應
  • 二、TCP/IP 協議族介紹
  • 三、基於TCP/IP通信過程
  • 四、TCP建立連接及斷開(重點補充)
  • 小結

前言

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

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

客戶端(瀏覽器)請求過程.jpg

我們在瀏覽器中輸入一個 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 協議的通信過程),並對每一步做說明:

通信過程.png

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

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

url

URL由以下元素組成:

URL格式介紹.png

(1) 傳送協議:http:或者https:等

(2) 層級URL標記符號:為“//”固定不變

(3) 登錄信息: 訪問資源需要的憑證信息(可省略)

(4) 服務器地址:通常為域名,有時為IP地址(實際通信中需要通過IP地址訪問,域名通過DNS服務器解析出IP地址)

(5) 端口號:以數字方式表示,若為HTTP的預設值“:80”可省略

(6) 路徑:以“/”字符區別路徑中的每一個目錄名稱

(7) 查詢:GET樣式的窗體引數,以“?”字符為起點,每個引數以“&”隔開,再以“=”分開引數名稱與資料,通常以UTF8的URL編碼,避開字符衝突的問題

(8) 片段:以“#”字符為起點,使用片段識別符號通常可標記出已獲取資源中的子資源

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

DNS協議.png

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次握手.png

5、IP協議實現資料傳遞到對方計算機

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

IP協議.png

6、接收並解析請求報文後回傳響應報文

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

接收端(服務器)響應報文同樣利用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連接的建立和釋放》

赞(0)

分享創造快樂