TCP/IP--圖解從URL到網頁通訊原理

時間 2019-11-15

標籤 tcp 圖解 url 網頁通訊原理欄目系統網絡简体版

原文原文鏈接

前言

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

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

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

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

（2）網站服務器接收到這個Request以後進行處理和解析瀏覽器

（3）而後返回對應的一個Response（響應）給瀏覽器，Response裏面就包含了頁面的源代碼等內容服務器

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

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

2、TCP/IP 協議族介紹

一、TCP/IP協議族是什麼呢？

TCP/IP協議族的目的就是經過創建規則使計算機之間能夠進行信息交換。socket

相互通訊的雙方就必須基於相同的方法，好比由哪一邊先發起通訊、使用哪一種語言進行通訊、怎樣結束通訊等規則都須要事先肯定，咱們就把這種規則稱爲協議（protocol）。一般咱們說的TCP/IP協議族是互聯網相關的各種協議族的總稱。tcp

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

這裏就說到TCP/IP重要的層次化劃分，按層次能夠分爲4層：應用層、傳輸層、網絡層和鏈路層。（層次化的好處在於每一個層次內部的設計能夠自由改動，並經過各層的接口關聯起來，而若是隻有一個協議統籌就須要對全部涉及到的部分都從新設計。）post

二、TCP/IP各功能層的做用

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

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

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

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

三、TCP/IP 通訊傳輸流

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

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

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

（3）在網絡層（IP 協議），增長做爲通訊目的地的 MAC 地址後轉發給鏈路層。

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

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

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

3、基於TCP/IP通訊過程

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

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

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

URL由如下元素組成：

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

（2）層級URL標記符號：爲「//」固定不變

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

（4）服務器地址：一般爲域名，有時爲IP地址（實際通訊中須要經過IP地址訪問，域名經過DNS服務器解析出IP地址）

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

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

（7）查詢：GET模式的窗體參數，以「?」字符爲起點，每一個參數以「&」隔開，再以「=」分開參數名稱與數據，一般以UTF8的URL編碼，避開字符衝突的問題

（8）片斷：以「#」字符爲起點，使用片斷標識符一般可標記出已獲取資源中的子資源

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

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

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

三、HTTP協議生成請求報文

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

（1）請求報文的構成

（2）響應報文的構成

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

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

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

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

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

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

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

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

4、TCP創建鏈接及斷開（重點補充）

TCP創建鏈接（3次握手）

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

第一次握手：客戶端將標誌位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個包以確認鏈接的斷開。下面來看看四次揮手的流程圖：

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

第一次揮手：客戶端發送一個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）定義的鏈接在這段時間內將不能被再用，這樣就可使下一個新的鏈接中不會出現這種舊的鏈接以前延遲的報文段。