TCP三次握手和四次揮手、HTTP協議

時間 2019-11-29

原文原文鏈接

TCP三次握手和四次揮手

首先咱們知道HTTP協議一般承載於TCP協議之上，HTTPS承載於TLS或SSL協議層之上html

經過上面這張圖咱們可以知道。
在Http工做以前，Web瀏覽器經過網絡和Web服務器創建鏈鏈接，該鏈接是經過Tcp來完成的，該協議和Ip共同組成了Internet，即著名的Tcp/Ip協議族，Http是比Tcp更高的應用層協議，通常Tcp接口的端口好是80。
TCP 被稱爲「面向鏈接」的傳輸層協議。關於它的具體細節，就不展開了。你只需知道：傳輸層主要有兩個協議，分別是 TCP 和 UDP。TCP 比 UDP 更可靠。你能夠把 TCP 協議想象成某個水管，發送端這頭進水，接收端那頭就出水。而且 TCP 協議可以確保，先發送的數據先到達（與之相反，UDP 不保證這點）前端

1、TCP簡介

TCP(Transmission Control Protocol)　傳輸控制協議
TCP是主機對主機層的傳輸控制協議，提供可靠的鏈接服務，採用三次握手確認創建一個鏈接:
位碼即tcp標誌位,有6種標示:SYN(創建聯機) ACK(確認) PSH(傳送) FIN(結束) RST(重置) URG(緊急) Sequence number(順序號碼) Acknowledge number(確認號碼)web

2、TCP三次握手

第一次握手：客戶端發送了一個帶有SYN(創建鏈接)的Tcp報文到服務器，這個三次握手中的開始。表示客戶端想要和服務端創建鏈接。瀏覽器

第二次握手：服務端接收到客戶端的請求，返回客戶端報文，這個報文帶有SYN(創建鏈接)和ACK(確認)標誌，詢問客戶端是否準備好。緩存

第三次握手：.客戶端再次響應服務端一個ACK(確認)，表示我已經準備好。

思考：爲何要三次握手呢，有人說兩次握手就行了？
舉一個例子：已失效的鏈接請求報文段，
client發送了第一個鏈接的請求報文，可是因爲網絡很差，這個請求沒有當即到達服務端，而是在某個網絡節點中滯留了，直到某個時間纔到達server，原本這已是一個失效的報文，可是server端接收到這個請求報文後，仍是會想client發出確認的報文，表示贊成鏈接。假如不採用三次握手，那麼只要server發出確認，新的創建就鏈接了，但其實這個請求是失效的請求，client是不會理睬server的確認信息，也不會向服務端發送確認的請求，可是server認爲新的鏈接已經創建起來了，並一直等待client發來數據，這樣，server的不少資源就沒白白浪費掉了，採用三次握手就是爲了防止這種狀況的發生，server會由於收不到確認的報文，就知道client並無創建鏈接。這就是三次握手的做用。安全

3、TCP的四次揮手

第一次揮手：TCP發送一個FIN(結束)，用來關閉客戶到服務端的鏈接。服務器

第二次揮手：服務端收到這個FIN，他發回一個ACK(確認)，確認收到序號爲收到序號+1，和SYN同樣，一個FIN將佔用一個序號。網絡

第三次揮手：服務端發送一個FIN(結束)到客戶端，服務端關閉客戶端的鏈接。tcp

第四次揮手：客戶端發送ACK(確認)報文確認，並將確認的序號+1，這樣關閉完成。ide

思考：那麼爲何是4次揮手呢？
　　可能有人會有疑問，tcp我握手的時候爲什麼ACK(確認)和SYN(創建鏈接)是一塊兒發送。揮手的時候爲何是分開的時候發送呢.
　　由於當Server端收到Client端的SYN鏈接請求報文後，能夠直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。可是關閉鏈接時，當Server端收到FIN報文時，極可能並不會當即關閉SOCKET，因此只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端全部的報文都發送完了，我才能發送FIN報文，所以不能一塊兒發送。故須要四步握手。

4、TCP和UDP的區別

我這裏簡單列舉幾個，由於我尚未研究UDP這個協議。

1.基於鏈接與無鏈接；(UDP是非鏈接)

2.對系統資源的要求（TCP較多，UDP少

3.UDP程序結構較簡單

4.流模式與數據報模式；(TCP是流模式）

5.TCP保證數據正確性，UDP可能丟包，TCP保證數據順序，UDP不保證

TCP 協議11種狀態

三次握手之狀態

四次握手之狀態

TIME_WAIT存在的意義

syn滑動窗口概念。發送好多syn，可是其中有的延遲，若是沒有time wite，直接關閉，再去鏈接有可能延遲的syn返回狀態，那麼就知道是誰了
客戶端沒有發送ack確認就關閉鏈接，那麼服務器狀態一直保持LAST_ACK狀態

一.HTTP簡介

1.HTTP協議，即超文本傳輸協議(Hypertext transfer protocol)。是一種詳細規定了瀏覽器和萬維網(WWW = World Wide Web)服務器之間互相通訊的規則，經過因特網傳送萬維網文檔的數據傳送協議。

2.HTTP協議做爲TCP/IP模型中應用層的協議也不例外。HTTP協議一般承載於TCP協議之上，有時也承載於TLS或SSL協議層之上，這個時候，就成了咱們常說的HTTPS。以下圖：

3.HTTP是一個應用層協議，由請求和響應構成，是一個標準的客戶端服務器模型。HTTP是一個無狀態的協議。

4.HTTP默認的端口號爲80，HTTPS的端口號爲443。

5.瀏覽網頁是HTTP的主要應用，可是這並不表明HTTP就只能應用於網頁的瀏覽。HTTP是一種協議，只要通訊的雙方都遵照這個協議，HTTP就能有用武之地。好比我們經常使用的QQ，迅雷這些軟件，都會使用HTTP協議(還包括其餘的協議)。

二.HTTP特色

一、簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。

二、靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。

三、HTTP 0.9和1.0使用非持續鏈接：限制每次鏈接只處理一個請求，服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。HTTP 1.1使用持續鏈接：沒必要爲每一個web對象建立一個新的鏈接，一個鏈接能夠傳送多個對象，採用這種方式能夠節省傳輸時間。

四、無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。

五、支持B/S及C/S模式。

三.HTTP工做流程

一次HTTP操做稱爲一個事務，其工做過程可分爲四步：

1.首先客戶機與服務器須要創建鏈接。只要單擊某個超級連接，HTTP的工做開始。
2.創建鏈接後，客戶機發送一個請求給服務器，請求方式的格式爲：統一資源標識符（URL）、協議版本號，後邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。
3.服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，後邊是MIME信息包括服務器信息、實體信息和可能的內容。
4.客戶端接收服務器所返回的信息經過瀏覽器顯示在用戶的顯示屏上，而後客戶機與服務器斷開鏈接。
若是在以上過程當中的某一步出現錯誤，那麼產生錯誤的信息將返回到客戶端，有顯示屏輸出。對於用戶來講，這些過程是由HTTP本身完成的，用戶只要用鼠標點擊，等待信息顯示就能夠了。

四.HTTP之請求消息Request

客戶端發送一個HTTP請求到服務器的請求消息包括如下格式：

請求行、請求頭部、空行和請求數據四個部分組成。

Get請求例子

第一部分：請求行，用來講明請求類型,要訪問的資源以及所使用的HTTP版本.

GET說明請求類型爲GET,[/562f25980001b1b106000338.jpg]爲要訪問的資源，該行的最後一部分說明使用的是HTTP1.1版本。

第二部分：請求頭部，緊接着請求行（即第一行）以後的部分，用來講明服務器要使用的附加信息

從第二行起爲請求頭部，HOST將指出請求的目的地.User-Agent,服務器端和客戶端腳本都能訪問它,它是瀏覽器類型檢測邏輯的重要基礎.該信息由你的瀏覽器來定義,而且在每一個請求中自動發送等等

第三部分：空行，請求頭部後面的空行是必須的

即便第四部分的請求數據爲空，也必須有空行。

第四部分：請求數據也叫主體，能夠添加任意的其餘數據。

這個例子的請求數據爲空。

POST請求例子

第一部分：請求行，第一行明瞭是post請求，以及http1.1版本。
第二部分：請求頭部，第二行至第六行。
第三部分：空行，第七行的空行。
第四部分：請求數據，第八行。

五.HTTP之響應消息Response

通常狀況下，服務器接收並處理客戶端發過來的請求後會返回一個HTTP的響應消息。

HTTP響應也由四個部分組成，分別是：狀態行、消息報頭、空行和響應正文。

第一部分：狀態行，由HTTP協議版本號，狀態碼，狀態消息三部分組成。

第一行爲狀態行，（HTTP/1.1）代表HTTP版本爲1.1版本，狀態碼爲200，狀態消息爲（ok）

第二部分：消息報頭，用來講明客戶端要使用的一些附加信息

第二行和第三行和第四行爲消息報頭，
Date:生成響應的日期和時間；Content-Type:指定了MIME類型的HTML(text/html),編碼類型是ISO-8859-1

第三部分：空行，消息報頭後面的空行是必須的

第四部分：響應正文，服務器返回給客戶端的文本信息。

空行後面的html部分爲響應正文。

6.HTTP之狀態碼

狀態代碼有三位數字組成，第一個數字定義了響應的類別，共分五種類別:

1xx：指示信息--表示請求已接收，繼續處理

2xx：成功--表示請求已被成功接收、理解、接受

3xx：重定向--要完成請求必須進行更進一步的操做

4xx：客戶端錯誤--請求有語法錯誤或請求沒法實現

5xx：服務器端錯誤--服務器未能實現合法的請求

常見狀態碼：

7.HTTP請求方法

根據HTTP標準，HTTP請求可使用多種請求方法。
HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

8.HTTP工做原理

　　HTTP協議定義Web客戶端如何從Web服務器請求Web頁面，以及服務器如何把Web頁面傳送給客戶端。HTTP協議採用了請求/響應模型。客戶端向服務器發送一個請求報文，請求報文包含請求的方法、URL、協議版本、請求頭部和請求數據。服務器以一個狀態行做爲響應，響應的內容包括協議的版本、成功或者錯誤代碼、服務器信息、響應頭部和響應數據。

如下是 HTTP 請求/響應的步驟：

一、客戶端鏈接到Web服務器

一個HTTP客戶端，一般是瀏覽器，與Web服務器的HTTP端口（默認爲80）創建一個TCP套接字鏈接。例如，http://www.oakcms.cn。

二、發送HTTP請求

經過TCP套接字，客戶端向Web服務器發送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求數據4部分組成。

三、服務器接受請求並返回HTTP響應

Web服務器解析請求，定位請求資源。服務器將資源複本寫到TCP套接字，由客戶端讀取。一個響應由狀態行、響應頭部、空行和響應數據4部分組成。

四、釋放鏈接TCP鏈接

若connection 模式爲close，則服務器主動關閉TCP鏈接，客戶端被動關閉鏈接，釋放TCP鏈接;若connection 模式爲keepalive，則該鏈接會保持一段時間，在該時間內能夠繼續接收請求;

五、客戶端瀏覽器解析HTML內容

客戶端瀏覽器首先解析狀態行，查看代表請求是否成功的狀態代碼。而後解析每個響應頭，響應頭告知如下爲若干字節的HTML文檔和文檔的字符集。客戶端瀏覽器讀取響應數據HTML，根據HTML的語法對其進行格式化，並在瀏覽器窗口中顯示。