TCP協議之<你好——再見>

1：TCP協議簡介

2：TCP協議報頭的結構分析

3：TCP協議三次握手

4：TCP協議四次揮手

5：抓包實驗過程呈現

1、TCP協議簡介

做爲TCP/IP協議棧的核心協議之一，TCP協議早已成爲可靠數據傳輸的首選協議之一，衆多的協議都是基於TCP協議之上的，例如：遠程鏈接協議Telnet、ssh協議、http協議等。

TCP傳輸控制協議是一種面向鏈接的、可靠的、基於字節流的傳輸層通訊協議，在1981年由IETF的RFC793正式提出。

TCP協議的特性有：工做在傳輸層的面向鏈接的協議、全雙工協議、半關閉、錯誤檢查、數據打包成段爲報文進行排序、確認機制、錯誤檢查、恢復重傳、流量控制、擁塞控制四部分：慢啓動、擁塞控制、快速重傳和快速恢復。

TCP的主要功能是在互聯網中爲提供可靠的、面向鏈接的進程間通訊服務。其基本的功能以下：

1）基本數據傳輸

    TCP可以在通訊雙方間的每一個方向（即全雙工）傳送一個連續的字節流，並將必定數量的字節封裝成段而後經過互聯網傳輸。

2）可靠性

    TCP可以將數據從損壞、丟失、重複、亂序中恢復。

3）流控制

    TCP能爲數據發送者提供控制發送數據數量的手段。

4）複用

    　容許一個主機內的多個進程同時使用TCP。

5）面向鏈接

TCP是面向鏈接的協議，意味着通訊雙方必須先創建鏈接，而後才能傳輸數據，數據傳輸結束後必須關閉鏈接。使用面向鏈接的方式提供服務使得TCP可以經過保存鏈接信息等手段，更好地提供可靠數據交付。這意味着TCP沒法支持多播，多播只能使用UDP一類無鏈接的協議來完成。

2、TCP報頭的結構分析

TCP最重要的特性就是其傳輸的可靠性，要想鏈接TCP的可靠傳輸過程，那咱們必須先從TCP報文頭部的結構分析入手。接下來由小編帶你們參觀一下TCP報文的頭部。

對TCP報文首部的字段進行解讀：

源端口 ：本機應用進程端口

目的端口：目的主機應用進程端口

序列號：主機發送的數據報的序號（第幾個）

確認號：發送給對方下次要發送的數據報的序列號（暗示上個數據幀已經接收到了）

數據偏移：指數據報中的數據在本報文中的起始位置，反過來也就是TCP頭部的長度。TCP報文頭部是以4個字節爲單位的，數據偏移位爲四個字節，雖大表示15，因此最大能表示TCP報文頭部的長度爲15*4=60字節。報文的選項位是能夠不要的，所最小的長度是20字節。

保留位：顧名思義，正在保留。

URG：表示報文段中發送的數據是否包含緊急數據。後面的緊急指針字段（urgent pointer）只有當URG=1時纔有效

ACK：表示是否前面的確認號字段是否有效。ACK=1，表示有效。只有當ACK=1時，前面的確認號字段纔有效。TCP規定，鏈接創建後，ACK必須爲1,帶ACK標誌的TCP報文段稱爲確認報文段。（ack小寫表示確認號）

PSH：提示接收端應用程序應該當即從TCP接收緩衝區中讀走數據，爲接收後續數據騰出空間。若是爲1，則表示對方應當當即把數據提交給上層應用，而不是緩存起來，若是應用程序不將接收到的數據讀走，就會一直停留在TCP接收緩衝區中。

RST：若是收到一個RST=1的報文，說明與主機的鏈接出現了嚴重錯誤（如主機崩潰），必須釋放鏈接，而後再從新創建鏈接。或者說明上次發送給主機的數據有問題，主機拒絕響應，帶RST標誌的TCP報文段稱爲復位報文段

SYN：在創建鏈接時使用，用來同步序號。當SYN=1，ACK=0時，表示這是一個請求創建鏈接的報文段；當SYN=1，ACK=1時，表示對方贊成創建鏈接。SYN=1，說明這是一個請求創建鏈接或贊成創建鏈接的報文。只有在前兩次握手中SYN才置爲1，帶SYN標誌的TCP報文段稱爲同步報文段。

FIN：表示通知對方本端要關閉鏈接了，標記數據是否發送完畢。若是FIN=1，即告訴對方：「個人數據已經發送完畢，你能夠釋放鏈接了」，帶FIN標誌的TCP報文段稱爲結束報文段

窗口大小：表示如今充許對方發送的數據量，也就是告訴對方，從本報文段的確認號開始容許對方發送的數據量

校驗和：提供額外的可靠性

緊急指針：標記緊急數據在數據字段中的位置

選項部分：其最大長度可根據TCP首部長度進行推算。TCP首部長度用4位表示，選項部分最長爲40字節

最大報文段長度：Maxium Segment Size，MSS

指明本身指望對方發送TCP報文段時那個數據字段的長度。默認是536字節。數據字段的長度加上TCP首部的長度纔等於整個TCP報文段的長度。

窗口擴大：Windows Scaling

TCP首部的窗口大小字段長度是16位，因此其表示的最大數是65535。可是隨着時延和帶寬比較大的通訊產生（如衛星通訊），須要更大的窗口來知足性能和吞吐率，因此產生了這個窗口擴大選項。

時間戳： Timestamps

能夠用來計算RTT(往返時間)，發送方發送TCP報文時，把當前的時間值放入時間戳字段，接收方收到後發送確認報文時，把這個時間戳字段的值複製到確認報文中，當發送方收到確認報文後便可計算出RTT。也能夠用來防止迴繞序號PAWS，也能夠說能夠用來區分相同序列號的不一樣報文。由於序列號用32爲表示，每2^32個序列號就會產生迴繞，那麼使用時間戳字段就很容易區分相同序列號的不一樣報文。

1、TCP三次握手

經過對上面TCP報文首部的字段進行了一些認識，接下來跟隨小編去看看TCP是如何進行鏈接的。廢話很少說，直接上圖解釋：

在TCP三次握手的創建中，主動發出請求的一方稱爲客戶端，被動提供服務的一方是服務器端。從圖中，咱們能夠看出，在整個創建鏈接的過程當中，客戶端和服務器端共有5種狀態：Closed 、LISTEN、SYN-SENT、SYN-RCVD、ESTAB-LISHED。

CLOSED 沒有任何鏈接狀態

LISTEN 偵聽狀態，等待來自遠方TCP端口的鏈接請求

SYN-SENT 在發送鏈接請求後，等待對方確認

SYN-RECEIVED 在收到和發送一個鏈接請求後，等待對方確認

ESTABLISHED 表明傳輸鏈接創建，雙方進入數據傳送狀態

整個傳輸過程以下：

請求方發送請求創建鏈接的報文，報文中攜帶的標誌位SYN=1，seq=0，ACK=0,由上面咱們瞭解到SYN標誌位爲同步標誌位，代表，客戶端要與服務器創建鏈接，seq=0是攜帶包的序列號，由於這是傳輸過程當中的第一個包，因此沒有ack的值，在首次請求的時候，這是ACK標誌位惟一一次等於0的時候，由於，TCP協議規定，在創建鏈接後，ACK標誌位，必須爲1。

請求端發送完請求以後，立馬進入SYN-SENT 狀態進行同步等待，而處於監聽狀態的服務器端接收到請求後，若是條件知足，就給客戶端迴應一個統一進入同步狀態的報文，並當即進入SYN-RCVD狀態。

客戶端收到服務器的贊成創建鏈接報文後，再給服務器反饋一個確認收到的報文，並當即進入ESTAB-LISHED狀態。

服務器收到客戶的確認後，立馬進入ESTAB-LISHED。

在發送創建鏈接的報文中須要將SYN標誌位標記爲1，在確認報文中，並不須要SYN，但必需要使ACK=1。

1、TCP協議四次揮手

有聚必有散，在雙方都進行傳輸完成後，須要斷開鏈接，一樣的爲了體現TCP的可靠性，斷開鏈接的時候也不能草草斷開，必須確保雙方都贊成了斷開，並確認斷開才行。不廢話，上圖說明：

看到沒，創建鏈接容易，但是斷開可不是那麼簡單，所謂的善始善終，也許正是TCP的體現吧。猛地看去貌似有些亂，可是仔細的分析一下發現，斷開的過程當中一共有ESTAB-LISHED、FIN-WAIT1、FIN-WAIT2、CLOSE-WAIT、LAST-ACK、TIME-WAIT、CLOSED七種狀態。

CLOSED 沒有任何鏈接狀態

FIN-WAIT-1 主動關閉,主機已發送關閉鏈接請求，等待對方確認

FIN-WAIT-2主動關閉,主機已收到對方關閉傳輸鏈接確認，等待對方發送關閉傳輸鏈接請求

TIME-WAIT 完成雙向傳輸鏈接關閉，等待全部分組消失

CLOSE-WAIT 被動關閉,收到對方發來的關閉鏈接請求，並已確認

LAST-ACK 被動關閉,等待最後一個關閉傳輸鏈接確認，並等待全部分組消失

CLOSING 雙方同時嘗試關閉傳輸鏈接，等待對方確認

過程說明：

當一方以爲沒什麼服務須要的時候，請求斷開鏈接，發送的報文中攜帶的FIN標誌位爲1，表示這是一個終結會話的報文。

當服務器收到後，一看這是一個請求斷開鏈接的報文，這個時候服務器就會考慮，看是否還有數據須要發送或者正在發送，這個時候分兩種狀況，咱們先說一種，另外一種，在下文進行說明，當服務器還有數據須要發送或者正在發送的時候，服務器給客戶端發送一個確認收到斷開鏈接請求的報文，這個報文是不攜帶標誌位FIN=1的，由於，只是一個確認收到客戶端信息的報文，並無贊成立馬斷開，由於服務器有數據正在傳輸。

當客戶端收到服務器的確認報文後，一看報文中標誌位FIN沒有爲1，說明服務器可能還沒傳輸完畢，因而，客戶端就進入FIN-WAIT2階段進行等待。

當服務器數據傳輸完畢以後，會主動向客戶端發送請求斷開鏈接的報文，並攜帶標誌位FIN=1 的報文，這個時候服務器進入LAST-ACK（最後確認階段），它要等客戶端收到個人請求後才能斷開呀，因此進入最後的確認等待階段。

客戶端收到斷開鏈接的報文後，立馬發送確認報文，確認收到了服務器的斷開請求，攜帶標誌位ACK=1的報文，並當即進入最後的TIME-WAIT階段，這個階段時長爲兩個最大傳輸時長（2MSL），是爲了確保正在路上的數據包在斷開接收端口以前能所有到達。計時一到就關閉。

服務器端收到客戶端的確認報文後當即進入關閉狀態，一個完整的TCP鏈接正式結束。

額外補充：

若是客戶端和服務器端同時發送請求斷開鏈接報文，就會同時進入closeing狀態。發送確認報文，進行斷開，中間的FIN-WAIT2階段會省略。

5、抓包實驗過程呈現

到這裏，一個完整的TCP鏈接創建而且成功斷開。接下來小編帶你去捉幾個包看看，驗證這個過程，廢話不說，截圖爲證：

    三次握手的包，頭兩個包帶有標誌位SYN=1，最後一個位ACK=1進行確認。

    哈哈，看吧，是否是與文中介紹的對上號了呢。說明這個實驗是一個完美的實驗，每一步都很是的準確。到這裏，小編的實驗就結束了，若是有什麼不足的地方，請多多指教，若是你有疑問，小編很樂於幫助你解答疑惑。