tcp連接(tcp連接三次握手)

什么是TCP連接

　　TCP即傳輸控制協議。TCP連接是互聯網連接協議集的一種。

　　TCP通信最重要的特征是：

　　有序和可靠。

　　有序通過將文本流分段并編號實現,可靠通過ACK回復和重復發送實現。

TCP連接狀態圖

　　參考文章:

　　TCP連接過程詳解

　　blog.163.com/hlz_2599/blog/static/142378474201151943414397/

什么是 TCP 連接

世界上絕大部分的 HTTP 通信都是通過 TCP/IP 承載的，TCP/IP 是全球計算機和網絡設備都在使用的一種常用的分組交換網絡分層協議集。客戶端應用程序可以打開一條 TCP/IP 連接，連接到世界上可能運行的任何一個服務器應用程序上。一旦連接建立起來，在不斷網的情況下，客戶端與服務器之間交換的報文就永遠不會丟失、受損或者失序。

TCP 連接詳解

1、先提出一個問題， 可以不進行三次握手直接往服務端發送數據包嗎？

是不可以的，也是可以的 ；

1）不可以是因為現在的TCP連接標準和規范要求傳輸數據前先確認兩端的狀態，有一端狀態不OK的話，發數據包有什么用呢；

2）說可以是站在網絡連接的角度，像 UDP 協議；

2、TCP三次握手

1）標志位、隨機序列號和確認序列號是在數據包的 TCP 首部里面；

2）幾個狀態是指客戶端和服務端連接過程中 socket 狀態；

3）第一次握手，客戶端向服務端發送數據包，該數據包中 SYN 標志位為 1，還有隨機生成的序列號c_q，客戶端狀態改為 SYN-SENT ；

4）第二次握手，服務端接收到客戶端發過來的數據包中 SYN 標志位為 1，就知道客戶端想和自己建立連接，服務端會根據自身的情況決定是拒絕連接，或確定連接，還是丟棄該數據包；

拒絕連接，會往客戶端發一個數據包，該數據包中 RST 標志位為 1，客戶端會報 Connection refud ；

丟棄客戶端的數據包，超過一定時間后客戶端會報 Connection timeout；

確定連接時會往客戶端發一個數據包，該數據包中 ACK 標志位為 1，確認序列號 ack=c_q+1，SYN 標志位為 1，隨機序列號 s_q，狀態由 LISTEN 改為 SYN-RCVD ；

5）第三次握手，客戶端接收到數據包會做校驗，校驗ACK標志位和確認序列號 ack=c_q+1，如果確定是服務端的確認數據包，改自己的狀態為 ESTABLISHED ，并給服務端發確認數據包；

6）服務端接到客戶端數據包，會校驗ACK標志位和確認序列號 ack=s_q+1，改自己的狀態為 ESTABLISHED ，之后就可以進行數據傳輸了；

7）建立連接時的數據包是沒有實際內容的，沒有應用層的數據；

8）建立連接之后發起的請求數據包，每個數據包都會封裝各層協議的頭部信息，標志位ACK為1，其他標志位變動；

9）網絡進程間的通信，一臺服務器內部的進程間通信不用這樣；

3、TCP 連接三次握手抓包

1）Socket 在 linux 系統中是一種特殊的文件，因為 linux 系統的理念就是【一切皆文件】，是系統內核級的功能；

2）以上定義比較具體，可以抽象來理解，是一個內核級的用于通信的功能層，包含一組接口函數，這些函數實際就是操作 socket 文件句柄文件描述符；

一個 TCP 連接由四要素【源IP、源Port、目標IP、目標Port】唯一標識，也即 socket 由這四要素唯一確定；

一個 TCP 連接的建立也就是客戶端、服務端創建了相對應的一對 socket，客戶端和服務端之間的通信也就是這對 socket 間的通信（物理層面是網卡在發送/接收比特流數據）；

3） 一個服務與另一個服務建立連接，他們的端口是什么呢 ？

客戶端發出請求端口號是隨機的，服務端是進程監聽的端口號；

2、socket 主要函數介紹

1、進程通信，一個進程只有一個監聽 socket，connect socket 是針對一個客戶的一個連接的，有很多個； 2、connect 函數內部在發起請求前會找系統隨機一個端口號； 3、連接建立后，客戶端發起請求傳輸數據，服務端會直接交給 connect socket 處理，不會交給監聽 socket 處理；

4、監聽 socket 在處理客戶端請求時，如果此時其他客戶端發請求過來，監聽 socket 是沒法處理的，此時系統會維護請求隊列由 backlog 參數指定；

全連接隊列（completed connection queue）

半連接隊列（incomplete connection queue）

Linux 內核 2.2 版本之前 ，backlog 的大小等于全連接隊列和半連接隊列之和；

Linux 內核 2.2 版本之后 ，backlog 的大小之和全連接隊列有關系：

半連接隊列大小由 /proc/sys/net/ipv4/tcp_max_syn_backlog 文件指定，可以開很大；

全連接隊列大小由 /proc/sys/net/core/somaxconn 文件和 backlog 參數指定，取兩個中的最小值；

tomcat acceptCount 就是配置全連接隊列大小；

3、socket 函數在建立連接和數據傳輸的大概使用情況

4、TCP首部結構

1）2的16次方等于 65536，所以系統中端口號的限制個數為 65536，一般1024以下端口被系統占用；

2）標志位這里是 6 個，還有其他標志位的，只是這 6 個標志位常用；

3）q 序列號，ack 確認序列號，序列號在數據傳輸時分包用到。三次握手時 q 序列號是隨機的，沒有實際意義；

4）TCP 包首部后面接著的是 IP 包首部，再緊接著的是以太網包首部，其實都是加 0101010101 二進制位；

幾個常用標志位，首先一個標志位占一個 bit 位，只能是二進制中的 1 或 0；

1）SYN ，簡寫 S ，請求標志位，用來建立連接。在TCP三次握手中收到帶有該標志位的數據包，表示對方想與己方建立連接；

2）ACK ，簡寫【.】 ，請求確認/應答標志位，用于對對方的請求進行應答，對方收到含該標志位的數據包，會知道己方存在且可用。也會用在連接建立之后，己方發送響應數據給對方的數據包中；

3）FIN ，簡寫 F ，請求斷開標志位，用于斷開連接。對方收到己方的含該標志位的數據包，就知道己方想與它斷開連接，不再保持連接；

4）RST ，簡寫 R ，請求復位標志位，因網絡或己方服務原因導致有數據包丟失，己方接收到的數據包序列號與上一個數據包的序列號不銜接，那己方會發送含該標志位的數據包告訴對方，對方接收到含該標志位的數據包就知道己方要求它重新三次握手建立連接并重新發送丟失的數據包，一般斷點續傳會用到該標志位；

還有就是如果對方發過來的數據錯了，有問題，己方也會發送含該標志位的數據包；

5）PSH ，簡寫 P ，推送標志位，表示收到數據包后要立即交給應用程序去處理，不應該放在緩存中，read()/write() 都有緩存區；

6）URG ，簡寫 U ，緊急標志位，該標志位表示 tcp 包首部中的緊急指針域有效，督促中間層盡快處理；

7）ECE，在保留位中；

8）CWR，在保留位中；

5、TCP 抓包

1）服務端會根據自身情況，沒有要處理的數據時會把第二次和第三次揮手合并成一次揮手，此時標志位 FIN=1 / ACK=1；

2）MSL 是 Maximum Segment Lifetime 縮寫，指數據包在網絡中最大生存時間，RFC 建議是 2分鐘；

詳細描述：

1）客戶端、服務端都可以主動發起斷開連接；

2）第一次揮手，客戶端向服務端發送含 FIN=1 標志位的數據包，隨機序列號 q=m，此時客戶端狀態由 ESTABLISHED 變為 FIN_WAIT_1 ；

3）第二次揮手，服務端收到含 FIN=1 標志位的數據包，就知道客戶端要斷開連接，服務端會向客戶端發送含 ACK=1 標志位的應答數據包，確認序列號 ack=m+1，此時服務端狀態由 ESTABLISHED 變為 CLOSE_WAIT ；

4）客戶端收到含 ACK=1 標志位的應答數據包，知道服務端的可以斷開的意思，此時客戶端狀態由 FIN_WAIT_1 變為 FIN_WAIT_2 ；（第一、二次揮手也只是雙方交換一下意見而已）

5）第三次揮手，服務端處理完剩下的數據后再次向客戶端發送含 FIN=1 標志位的數據包，隨機序列號 q=n，告訴客戶端現在可以真正的斷開連接了，此時服務端狀態由 CLOSE_WAIT 變為 LAST_ACK ；

6）第四次揮手，客戶端收到服務端再次發送的含 FIN=1 標志位的數據包，就知道服務端處理好了可以斷開連接了，但是客戶端為了慎重起見，不會立馬關閉連接，而是改狀態，且向服務端發送含 ACK=1 標志位的應答數據包，確認序列號 ack=n+1，此時客戶端狀態由 FIN_WAIT_2 變為 TIME_WAIT ；

等待 2 個MSL 時間還是未收到服務端發過來的數據，則表明服務端已經關閉連接了，客戶端也會關閉連接釋放資源，此時客戶端狀態由 TIME_WAIT 變為 CLOSED ；

也就是說 TIME_WAIT 狀態存在時長在 1~4分鐘；

7）服務端收到含 ACK=1 標志位的應答數據包，知道客戶端確認可以斷開了，就立即關閉連接釋放資源，此時服務端狀態由 LAST_ACK 變為 CLOSED ；

SYN 洪水攻擊（SYN Flood）

是一種 DoS攻擊（拒絕服務攻擊），大概原理是偽造大量的TCP請求，服務端收到大量的第一次握手的數據包，且都會發第二次握手數據包去回應，但是因為 IP 是偽造的，一直都不會有第三次握手數據包，導致服務端存在大量的半連接，即 SYN_RCVD 狀態的連接，導致半連接隊列被塞滿，且服務端默認會發 5 個第二次握手數據包，耗費大量 CPU 和內存資源，使得正常的連接請求進不來；

TCP連接建立過程

在TCP／IP中，TCP協議通過三次握手來建立連接，從而提供可靠的連接服務。

第一次握手：建立連接后，客戶端向服務器發送syn包（syn＝j），進入SYN＿SEND狀態，等待服務器確認；

第二次握手：當服務器收到syn包時，必須確認客戶端的syn（ack＝j＋1）并發送一個syn包（syn＝k），即syn＋ack包。此時，服務器進入SYN＿RECV狀態。

第三次握手：SYN＋ACK包，客戶端收到服務器端發來的確認包ACK（ACK＝k＋1），來發送這個包來發送，客戶端和服務器端進入建立狀態，完成三路握手。

擴展資料：

重要概念：

無關的隊列：三重握手協議、服務器維護一個獨立隊列，為每個客戶的SYN包創建一個條目（SYN＝j）表明服務器已經收到了SYN包和確認發送到客戶，等待客戶的確認包。

這些條目標識的連接處于服務器的Syn＿RECV狀態，當服務器接收到客戶機的確認包時，它將刪除該條目，服務器將進入已建立的狀態。

Backlog參數：表示要保持的未連接隊列的最大數量。

當服務器發送synack包時，如果沒有收到客戶端確認包，服務器將進行第一次重傳，等待一段時間仍然沒有收到客戶端確認包，然后進行第二次重傳。

如果重傳號超過系統指定的最大重傳號，系統將從半連接隊列中刪除連接信息。注意每個重傳的等待時間可能不相同。

半連接生存時間：指半連接隊列中條目的最長生存時間，即從接收SYN包到確認無效消息的最長服務時間。這個時間值是所有重傳請求包的最長等待時間的總和。有時我們也稱半連接生存時間為超時時間，SYN＿RECV生存時間。

“TCP連接”究竟是什么意思？

我們經常聽到"建立TCP連接"，"服務器的連接數量有限"等，但仔細一想，連接究竟是個什么東西，是和電話一樣兩端連起一根線？似乎有點抽象不是么？

1.久違的分組交換網絡
似乎這個概念只有在學校里學計算機網絡才能接觸到，但不過今天的話題其實和它離不開關系。我們知道最早的電話網絡是以很容易理解的形式存在的，就是單純的一根線加兩端的設備，設備之間所溝通的所有信息都通過一根特定的電纜來回傳輸，如下圖：

這樣的連接是我們特別好理解的，搭起兩邊的線，就是一個連接嘛！但是，我們討論的是計算機網絡！(嚴肅臉)，計算機網絡中兩個設備節點是如何通信？

計算機網絡采取分組交換技術，什么意思呢？就是我有【一塊數據】要發給對方小蒼，那我會把這【一塊數據】分成N份【單位數據】，分別發出去，而每份【單位數據】走哪條路是不一定的，但是這些【單位數據】總要全部達到小蒼手里，小蒼再根據【單位數據】里記錄的序號拼接起來，組成完整的【一塊數據】。這就是分組的意思所在。

2.協議和協議實現
上面不小心把TCP的大體實現給說了，實際上在具體的應用中，光有大體思路是不行的，還有很多細節問題，需要兩個設備之間提前約定好協議，才能協同完成通信。舉個例子：A向B發了10份【單位數據】，而B其實只收到9份【單位數據】，怎么辦？

TCP協議大家都應該是知道的，但協議只是想法，真正起作用的是在路由節點和設備節點上的協議軟件，是運行在設備上的具體執行者，它根據協議指導，對具體數據進行控制和操作。這兒就不往下展開了。

認識到協議和協議軟件這一點非常重要，因為連接的限制恰恰就是受軟件在設備中資源分配的影響的。

3.連接的真面目
上面說的第一種電話網絡，如果兩個設備搭設了一條線，那么兩個電話就一定確定對方在線，因為他倆獨享一條實時存在的線。但計算機網絡的連接呢？

向上面的圖一樣(圖里不深究TCP，僅僅用來說明連接大體過程)，其實他們倆并不能確保對方就是在線，只是通過幾番確認，認為對方一直會在。而如果確認了對方存在，那么就會為以后的對話通訊分配內存、CPU處理時間等資源，每個設備都會在本地去維持這么一個狀態，來告訴自己是有一個連接的，這些設備所花的資源和維護的狀態，就是連接。而整個網絡是不會記錄有著一條連接的，所以說連接只是記錄在各個設備的一個狀態信息。

那么，到現在我們知道了，連接其實并不是所謂的有一根電線連起兩個設備，而是兩方確認了一下對方的存在后，自己在本地記錄的狀態。那么下面可以討論一下以前迷惑重重的概念了。

4.為什么服務器都有連接數量的限制？
這里只做討論。我認為是有兩點：

物理帶寬的限制，決定了一個時間段內發起連接的數據包不會超過某個數，造成了設備的鏈接數量的限制。
維持連接需要分配內存等資源，設備的資源有限，決定了一定有個最大連接數的極限。

5.待續
通過連接往外延伸的話題不少，先到此為止吧，有時間再補。

TCP連接詳解

通過設置linux參數 net.ipv4.tcp_fin_timeout = 30 ，可以調整
如發現系統存在大量TIME_WAIT狀態的連接，通過調整內核參數解決：
編輯文件/etc/sysctl.conf，加入以下內容

tcp 通過序列號q記錄已經發送的數據刻度，通過ack記錄已經接收的數據量。q記錄的是發送的數據，ack記錄的是接收的數據量。單位是字節（8bit）

tcp在每次發包時都會計算往復時間及其偏差。將這個往返時間和偏差相加，重發超時時間就是比這個總和要稍大一點的值。
由于最初的數據包還不知道往返時間，所以其重發超時一般設置為6s左右。

在建立tcp連接時，三次握手的時候會計算mss（最大消息長度），建立連接的雙方會把自己的接口能適應的mss值放到tcp首部里面發送給對方，最后取較小的那個mss。

tcp窗口大小指的是無需等待確認應答而可以繼續發送數據的最大值，窗口大小為4個端。即在收到確認應答之前可以發送的數據的段數。
接收端沒有按序列順序收到數據端時，會不停的發送確認應答，并將當前收到的順序出問題的數據放到緩沖區。發送端連續三次收到相同序列號的數據段時，會重新發送該段的數據。接收端在接收到遺失的數據的時候會將數據與緩沖區的數據組合，重新按順序確定ack的序列號，繼續接收數據。
tcp窗口的大小是由接收端的處理能力決定的，接收端會在ack的tcp首部中將能處理的窗口大小傳給發送端。

擁塞窗口是限制每次發送的數據的大小，初始值是1mss，也就是慢啟動。隨著正常的收發的進行，擁塞窗口的值會不斷的增加。但是不會超過接收端處理窗口的大小。
一開始擁塞窗口每次都會翻倍的增長，在超過慢啟動閾值后增長速度會減慢。
增長速率=一個數據段的大小 / 擁塞窗口的大小 *一個數據段的大小
超時重發時，擁塞窗口會變為1mss， 慢啟動閾值為原有窗口的一半
重復確認應答時，慢啟動閾值為原有窗口的一半，擁塞窗口會變為慢啟動閾值+3數據端，

1、已發送的數據收到了ack回執
2、可以發送mss大小的數據時
只有以上兩個數據都滿足時才發送數據。會有延遲，對延遲敏感的需求可以關。

1、收到2*最大端長度的數據
2、最大延遲0.5s發送確認應答

將tcp的確認應答和回執數據通過一個包發送。
接收數據之后等待應用處理生成返回數據以后在發送回復時同時發送回執。
需要開啟延遲確認應答。