TCP作為一種可靠傳輸控制協(xié)議，其核心思想：既要保證數(shù)據(jù)可靠傳輸，又要提高傳輸?shù)男?#xff0c;而用三次握手恰恰可以滿足以上兩方面的需求！

1.三次握手

? ? ? ? ?所謂的三次握手即TCP連接的建立。這個(gè)連接必須是一方主動打開，另一方被動打開的。TCP協(xié)議中，我們把主動發(fā)起請求的一端稱為『客戶端』，被動連接的一端稱為『服務(wù)端』。不管是客戶端還是服務(wù)端，TCP連接建立完后都能發(fā)送和接收數(shù)據(jù)。

?1.1 三次握手過程

? ? ? ?? 握手之前主動打開連接的客戶端結(jié)束CLOSED階段，被動打開的服務(wù)器端也結(jié)束CLOSED階段，并進(jìn)入LISTEN階段。隨后開始“三次握手”：

第一次握手
客戶端向服務(wù)端發(fā)送連接請求報(bào)文段。該報(bào)文段的頭部中SYN=1，ACK=0，seq=x。請求發(fā)送后，客戶端便進(jìn)入SYN-SENT狀態(tài)。

• PS1：SYN=1，ACK=0表示該報(bào)文段為連接請求報(bào)文。

• PS2：x為本次TCP通信的字節(jié)流的初始序號。
  TCP規(guī)定：SYN=1的報(bào)文段不能有數(shù)據(jù)部分，但要消耗掉一個(gè)序號。

第二次握手
服務(wù)端收到連接請求報(bào)文段后，如果同意連接，則會發(fā)送一個(gè)應(yīng)答：SYN=1，ACK=1，seq=y，ack=x+1。
該應(yīng)答發(fā)送完成后便進(jìn)入SYN-RCVD狀態(tài)。

• PS1：SYN=1，ACK=1表示該報(bào)文段為連接同意的應(yīng)答報(bào)文。

• PS2：seq=y表示服務(wù)端作為發(fā)送者時(shí)，發(fā)送字節(jié)流的初始序號。

• PS3：ack=x+1表示服務(wù)端希望下一個(gè)數(shù)據(jù)報(bào)發(fā)送序號從x+1開始的字節(jié)。

第三次握手
當(dāng)客戶端收到連接同意的應(yīng)答后，還要向服務(wù)端發(fā)送一個(gè)確認(rèn)報(bào)文段，表示：服務(wù)端發(fā)來的連接同意應(yīng)答已經(jīng)成功收到。
該報(bào)文段的頭部為：ACK=1，seq=x+1，ack=y+1。
客戶端發(fā)完這個(gè)報(bào)文段后便進(jìn)入ESTABLISHED狀態(tài)，服務(wù)端收到這個(gè)應(yīng)答后也進(jìn)入ESTABLISHED狀態(tài)，此時(shí)連接的建立完成！?

在客戶端與服務(wù)器端傳輸?shù)腡CP報(bào)文中，雙方的確認(rèn)號Ack和序號Seq的值，都是在彼此Ack和Seq值的基礎(chǔ)上進(jìn)行計(jì)算的，這樣做保證了TCP報(bào)文傳輸?shù)倪B貫性。一旦出現(xiàn)某一方發(fā)出的TCP報(bào)文丟失，便無法繼續(xù)"握手"，以此確保了"三次握手"的順利完成。

例如：

一句話概括，TCP連接握手握的是啥? ?
通信雙方數(shù)據(jù)原點(diǎn)的序列號！

1.2?TCP連接狀態(tài)

CLOSED：沒有任何連接狀態(tài)；

LISTENING：偵聽來自遠(yuǎn)方的TCP端口的連接請求；

? 首先服務(wù)端需要打開一個(gè)socket進(jìn)行監(jiān)聽，狀態(tài)為LISTEN。

? 有提供某種服務(wù)才會處于LISTENING狀態(tài)，TCP狀態(tài)變化就是某個(gè)端口的狀態(tài)變化，提供一個(gè)服務(wù)就打開一個(gè)端口，例如：提供www服務(wù)默認(rèn)開的是80端口，提供ftp服務(wù)默認(rèn)的端口為21，當(dāng)提供的服務(wù)沒有被連接時(shí)就處于LISTENING狀態(tài)。FTP服務(wù)啟動后首先處于偵聽(LISTENING)狀態(tài)。處于偵聽LISTENING狀態(tài)時(shí)，該端口是開放的，等待連接，但還沒有被連接。就像你房子的門已經(jīng)敞開的，但還沒有人進(jìn)來。

? ?看LISTENING狀態(tài)最主要的是看本機(jī)開了哪些端口，這些端口都是哪個(gè)程序開的，關(guān)閉不必要的端口是保證安全的一個(gè)非常重要的方面，服務(wù)端口都對應(yīng)一個(gè)服務(wù)(應(yīng)用程序)，停止該服務(wù)就關(guān)閉了該端口，例如要關(guān)閉21端口只要停止IIS服務(wù)中的FTP服務(wù)即可。關(guān)于這方面的知識請參閱其它文章。

? ?如果你不幸中了服務(wù)端口的木馬，木馬也開個(gè)端口處于LISTENING狀態(tài)。

SYN-SENT：客戶端SYN_SENT狀態(tài)：

? 再發(fā)送連接請求后等待匹配的連接請求:客戶端通過應(yīng)用程序調(diào)用connect進(jìn)行active open.于是客戶端tcp發(fā)送一個(gè)SYN以請求建立一個(gè)連接.之后狀態(tài)置為SYN_SENT. 在發(fā)送連接請求后等待匹配的連接請求

? 當(dāng)請求連接時(shí)客戶端首先要發(fā)送同步信號給要訪問的機(jī)器，此時(shí)狀態(tài)為SYN_SENT，如果連接成功了就變?yōu)镋STABLISHED，正常情況下SYN_SENT狀態(tài)非常短暫。例如要訪問網(wǎng)站http://www.baidu.com,如果是正常連接的話，用TCPView觀察IE建立的連接會發(fā)現(xiàn)很快從SYN_SENT變?yōu)镋STABLISHED，表示連接成功。SYN_SENT狀態(tài)快的也許看不到。

? 如果發(fā)現(xiàn)有很多SYN_SENT出現(xiàn)，那一般有這么幾種情況，一是你要訪問的網(wǎng)站不存在或線路不好，二是用掃描軟件掃描一個(gè)網(wǎng)段的機(jī)器，也會出出現(xiàn)很多SYN_SENT，另外就是可能中了病毒了，例如中了"沖擊波"，病毒發(fā)作時(shí)會掃描其它機(jī)器，這樣會有很多SYN_SENT出現(xiàn)。

SYN-RECEIVED：服務(wù)器端狀態(tài)SYN_RCVD

? ? ? ? 再收到和發(fā)送一個(gè)連接請求后等待對方對連接請求的確認(rèn)

??當(dāng)服務(wù)器收到客戶端發(fā)送的同步信號時(shí)，將標(biāo)志位ACK和SYN置1發(fā)送給客戶端，此時(shí)服務(wù)器端處于SYN_RCVD狀態(tài)，如果連接成功了就變?yōu)镋STABLISHED，正常情況下SYN_RCVD狀態(tài)非常短暫。

? 如果發(fā)現(xiàn)有很多SYN_RCVD狀態(tài)，那你的機(jī)器有可能被SYN Flood的DoS(拒絕服務(wù)攻擊)攻擊了。

ESTABLISHED：代表一個(gè)打開的連接。

?ESTABLISHED狀態(tài)是表示兩臺機(jī)器正在傳輸數(shù)據(jù)，觀察這個(gè)狀態(tài)最主要的就是看哪個(gè)程序正在處于ESTABLISHED狀態(tài)。

?服務(wù)器出現(xiàn)很多ESTABLISHED狀態(tài)：netstat -nat |grep 9502或者使用lsof ?-i:9502可以檢測到。

?當(dāng)客戶端未主動close的時(shí)候就斷開連接：即客戶端發(fā)送的FIN丟失或未發(fā)送。

?這時(shí)候若客戶端斷開的時(shí)候發(fā)送了FIN包，則服務(wù)端將會處于CLOSE_WAIT狀態(tài)；

?這時(shí)候若客戶端斷開的時(shí)候未發(fā)送FIN包，則服務(wù)端處還是顯示ESTABLISHED狀態(tài)；

?結(jié)果客戶端重新連接服務(wù)器。

?而新連接上來的客戶端(也就是剛才斷掉的重新連上來了)在服務(wù)端肯定是ESTABLISHED; 如果客戶端重復(fù)的上演這種情況，那么服務(wù)端將會出現(xiàn)大量的假的ESTABLISHED連接和CLOSE_WAIT連接。

?最終結(jié)果就是新的其他客戶端無法連接上來，但是利用netstat還是能看到一條連接已經(jīng)建立，并顯示ESTABLISHED，但始終無法進(jìn)入程序代碼

FIN-WAIT-1：等待遠(yuǎn)程TCP連接中斷請求，或先前的連接中斷請求的確認(rèn)

? 主動關(guān)閉(active close)端應(yīng)用程序調(diào)用close，于是其TCP發(fā)出FIN請求主動關(guān)閉連接，之后進(jìn)入FIN_WAIT1狀態(tài)./* The socket is closed, and the connection is shutting down. 等待遠(yuǎn)程TCP的連接中斷請求，或先前的連接中斷請求的確認(rèn) */

? 如果服務(wù)器出現(xiàn)shutdown再重啟，使用netstat -nat查看，就會看到很多FIN-WAIT-1的狀態(tài)。就是因?yàn)榉?wù)器當(dāng)前有很多客戶端連接，直接關(guān)閉服務(wù)器后，無法接收到客戶端的ACK。

FIN-WAIT-2：從遠(yuǎn)程TCP等待連接中斷請求

? 主動關(guān)閉端接到ACK后，就進(jìn)入了FIN-WAIT-2，從遠(yuǎn)程TCP等待連接中斷請求

? 這就是著名的半關(guān)閉的狀態(tài)了，這是在關(guān)閉連接時(shí)，客戶端和服務(wù)器兩次握手之后的狀態(tài)。在這個(gè)狀態(tài)下，應(yīng)用程序還有接受數(shù)據(jù)的能力，但是已經(jīng)無法發(fā)送數(shù)據(jù)，但是也有一種可能是，客戶端一直處于FIN_WAIT_2狀態(tài)，而服務(wù)器則一直處于WAIT_CLOSE狀態(tài)，而直到應(yīng)用層來決定關(guān)閉這個(gè)狀態(tài)。

CLOSE-WAIT：等待從本地用戶發(fā)來的連接中斷請求

? 被動關(guān)閉(passive close)端TCP接到FIN后，就發(fā)出ACK以回應(yīng)FIN請求(它的接收也作為文件結(jié)束符傳遞給上層應(yīng)用程序),并進(jìn)入CLOSE_WAIT.等待從本地用戶發(fā)來的連接中斷請求

CLOSING：等待遠(yuǎn)程TCP對連接中斷的確認(rèn)

等待遠(yuǎn)程TCP對連接中斷的確認(rèn)

LAST-ACK：等待原來的發(fā)向遠(yuǎn)程TCP的連接中斷請求的確認(rèn)

被動關(guān)閉端一段時(shí)間后，接收到文件結(jié)束符的應(yīng)用程序?qū)⒄{(diào)用CLOSE關(guān)閉連接。這導(dǎo)致它的TCP也發(fā)送一個(gè) FIN,等待對方的ACK.就進(jìn)入了LAST-ACK 等待原來發(fā)向遠(yuǎn)程TCP的連接中斷請求的確認(rèn)

使用并發(fā)壓力測試的時(shí)候，突然斷開壓力測試客戶端，服務(wù)器會看到很多LAST-ACK。

TIME-WAIT：等待足夠的時(shí)間以確保遠(yuǎn)程TCP接收到連接中斷請求的確認(rèn)

在主動關(guān)閉端接收到FIN后，TCP就發(fā)送ACK包，并進(jìn)入TIME-WAIT狀態(tài)，等待足夠的時(shí)間以確保遠(yuǎn)程TCP接收到連接中斷請求的確認(rèn) */

? ? ? TIME_WAIT等待狀態(tài)，這個(gè)狀態(tài)又叫做2MSL狀態(tài)，說的是在TIME_WAIT2發(fā)送了最后一個(gè)ACK數(shù)據(jù)報(bào)以后，要進(jìn)入TIME_WAIT狀態(tài)，這個(gè)狀態(tài)是防止最后一次握手的數(shù)據(jù)報(bào)沒有傳送到對方那里而準(zhǔn)備的(注意這不是四次握手，這是第四次握手的保險(xiǎn)狀態(tài))。這個(gè)狀態(tài)在很大程度上保證了雙方都可以正常結(jié)束，但是，問題也來了。由于插口的2MSL狀態(tài)(插口是IP和端口對的意思，socket)，使得應(yīng)用程序在2MSL時(shí)間內(nèi)是無法再次使用同一個(gè)插口的，對于客戶程序還好一些，但是對于服務(wù)程序，例如httpd，它總是要使用同一個(gè)端口來進(jìn)行服務(wù)，而在2MSL時(shí)間內(nèi)，啟動httpd就會出現(xiàn)錯(cuò)誤(插口被使用)。為了避免這個(gè)錯(cuò)誤，服務(wù)器給出了一個(gè)平靜時(shí)間的概念，這是說在2MSL時(shí)間內(nèi)，雖然可以重新啟動服務(wù)器，但是這個(gè)服務(wù)器還是要平靜的等待2MSL時(shí)間的過去才能進(jìn)行下一次連接。

1.3 TCP狀態(tài)遷移路線分析

client/server兩條路線講述TCP狀態(tài)遷移路線圖：

這是一個(gè)看起來比較復(fù)雜的狀態(tài)遷移圖，因?yàn)樗藘蓚€(gè)部分—-服務(wù)器的狀態(tài)遷移和客戶端的狀態(tài)遷移，如果從某一個(gè)角度出發(fā)來看這個(gè)圖，就會清晰許多，這里面的服務(wù)器和客戶端都不是絕對的，發(fā)送數(shù)據(jù)的就是客戶端，接受數(shù)據(jù)的就是服務(wù)器。

客戶端應(yīng)用程序的狀態(tài)遷移圖

客戶端的狀態(tài)可以用如下的流程來表示：

CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED

以上流程是在程序正常的情況下應(yīng)該有的流程，從書中的圖中可以看到，在建立連接時(shí)，當(dāng)客戶端收到SYN報(bào)文的ACK以后，客戶端就打開了數(shù)據(jù)交互地連接。

而結(jié)束連接則通常是客戶端主動結(jié)束的，客戶端結(jié)束應(yīng)用程序以后，需要經(jīng)歷FIN_WAIT_1，FIN_WAIT_2等狀態(tài)，這些狀態(tài)的遷移就是前面提到的結(jié)束連接的四次握手。

服務(wù)器的狀態(tài)遷移圖

服務(wù)器的狀態(tài)可以用如下的流程來表示：

CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED

在建立連接的時(shí)候，服務(wù)器端是在第三次握手之后才進(jìn)入數(shù)據(jù)交互狀態(tài)，而關(guān)閉連接則是在關(guān)閉連接的第二次握手以后(注意不是第四次)。而關(guān)閉以后還要等待客戶端給出最后的ACK包才能進(jìn)入初始的狀態(tài)。

其他狀態(tài)遷移

還有一些其他的狀態(tài)遷移，這些狀態(tài)遷移針對服務(wù)器和客戶端兩方面的總結(jié)如下

LISTEN->SYNSENT，對于這個(gè)解釋就很簡單了，服務(wù)器有時(shí)候也要打開連接的嘛。

SYN_SENT->SYN收到，服務(wù)器和客戶端在SYN_SENT狀態(tài)下如果收到SYN數(shù)據(jù)報(bào)，則都需要發(fā)送SYN的ACK數(shù)據(jù)報(bào)并把自己的狀態(tài)調(diào)整到SYN收到狀態(tài)，準(zhǔn)備進(jìn)入ESTABLISHED

SYN_SENT->CLOSED，在發(fā)送超時(shí)的情況下，會返回到CLOSED狀態(tài)。

SYN收到->LISTEN，如果受到RST包，會返回到LISTEN狀態(tài)。

SYN_收到->FIN_WAIT_1，這個(gè)遷移是說，可以不用到ESTABLISHED狀態(tài)，而可以直接跳轉(zhuǎn)到FIN_WAIT_1狀態(tài)并等待關(guān)閉。

1.4?查看TCP狀態(tài)命令

了解TCP狀態(tài)之后了解幾個(gè)linux查看tcp的狀態(tài)命令：

1)?netstat -nat查看TCP各個(gè)狀態(tài)的數(shù)量

2)lsof -i:port可以檢測到打開套接字的狀況

3)?sar -n SOCK查看tcp創(chuàng)建的連接數(shù)

4)?tcpdump -iany tcp port 9000對tcp端口為9000的進(jìn)行抓包

網(wǎng)絡(luò)測試常用命令;

1)ping:檢測網(wǎng)絡(luò)連接的正常與否,主要是測試延時(shí)、抖動、丟包率。

但是很多服務(wù)器為了防止攻擊，一般會關(guān)閉對ping的響應(yīng)。所以ping一般作為測試連通性使用。

ping命令后，會接收到對方發(fā)送的回饋信息，其中記錄著對方的IP地址和TTL。TTL是該字段指定IP包被路由器丟棄之前允許通過的最大網(wǎng)段數(shù)量。

TTL是IPv4包頭的一個(gè)8 bit字段。例如IP包在服務(wù)器中發(fā)送前設(shè)置的TTL是64，你使用ping命令后，得到服務(wù)器反饋的信息，其中的TTL為56，說明途中一共經(jīng)過了8道路由器的轉(zhuǎn)發(fā)，每經(jīng)過一個(gè)路由，TTL減1。

2)traceroute：raceroute 跟蹤數(shù)據(jù)包到達(dá)網(wǎng)絡(luò)主機(jī)所經(jīng)過的路由工具

traceroute hostname

3)pathping：是一個(gè)路由跟蹤工具，它將 ping 和 tracert 命令的功能與這兩個(gè)工具所不提供的其他信息結(jié)合起來，綜合了二者的功能

pathping www.baidu.com

4)mtr：以結(jié)合ping nslookup tracert 來判斷網(wǎng)絡(luò)的相關(guān)特性

5) nslookup:用于解析域名，一般用來檢測本機(jī)的DNS設(shè)置是否配置正確

2.?二次握手和四次握手

根據(jù)三次握手的核心思想我們來分析二、四次握手的過程。??

2.1 四次握手的過程:??

1.發(fā)送同步信號SYN+A的初始序列號?
2.B確認(rèn)收到A的同步信號，并記錄A‘s是到本地，命名B的ACK序列號
3.B發(fā)送同步信號SYN+B的初始序列號
4.A確認(rèn)收到B的同步信號，并記錄B‘s是到本地，命名A的ACK序列號

很顯然2和3這兩個(gè)步驟可以合并，只需要三次握手,可以提高連接的速度與效率。

2.2二次握手的過程:

1.A發(fā)送同步信號SYN+A的初始序列號
2.B發(fā)送同步信號SYN+B的初始序列號+B的ACK序號

這里有一個(gè)問題，A與B就A的初始序列號達(dá)成了一致.但是B無法知道A是否已經(jīng)接收到自己的同步信號,如果這個(gè)同步信號丟失了, A和B就B的初始序列號將無法達(dá)成一致。

如圖：

于是tcp的設(shè)計(jì)者將SYN這個(gè)同步標(biāo)志位SYN設(shè)計(jì)成占用一個(gè)字節(jié)的編號(FIN標(biāo)志位也是)，既然是一個(gè)字節(jié)的數(shù)據(jù)，按照tcp對有數(shù)據(jù)的tcp段必須確認(rèn)的原則，所以在這里A必須給B一個(gè)確認(rèn)，以確認(rèn)A已經(jīng)接收到B的同步信號。

有童鞋會說，如果A發(fā)給B的確認(rèn)丟了，該如何?會超時(shí)重傳這個(gè)ack嗎？不會！Tcp不會為沒有數(shù)據(jù)的ack超時(shí)重傳.
那該如何是好？B如果沒有收到A的ack，超時(shí)重傳自己的syn同步號，直到收到A的ack為止。

3.關(guān)于三次握手的連環(huán)發(fā)問

1. 三次握手的第一個(gè)包，即A發(fā)給B的SYN中途被丟，沒有到達(dá)B會怎么樣？
A會周期性超時(shí)重傳，直到收到B的確認(rèn)

2.三次握手的第二個(gè)包，即B發(fā)給A的SYN+ACK中途被丟，沒有到達(dá)A會怎么樣？?
B會周期性超時(shí)重傳，直到收到A的確認(rèn)?

3.三次握手的第三個(gè)包，即A發(fā)給B的ACK中途被丟，沒有到達(dá)B會怎么樣？

A發(fā)完ACK,單方面認(rèn)為TCP為Established狀態(tài)，而B顯然認(rèn)為TCP為Active狀態(tài):
a.假定此時(shí)雙方都沒有數(shù)據(jù)發(fā)送，B會周期性超時(shí)重傳，直到收到A的確認(rèn)，收到之后B的TCP連接也為Established狀態(tài)，雙向可以發(fā)包。
b.假定此時(shí)A有數(shù)據(jù)發(fā)送，B收到A的Data + ACK，自然會切換為established 狀態(tài)，并接受A的數(shù)據(jù)。
c.假定B有數(shù)據(jù)發(fā)送，數(shù)據(jù)發(fā)送不了，會一直周期性超時(shí)重傳SYN+ACK，直到收到A的確認(rèn)才可以發(fā)送數(shù)據(jù).

4.為什么連接建立需要三次握手，而不是兩次握手？
防止失效的連接請求報(bào)文段被服務(wù)端接收，從而產(chǎn)生錯(cuò)誤。

PS：失效的連接請求：若客戶端向服務(wù)端發(fā)送的連接請求丟失，客戶端等待應(yīng)答超時(shí)后就會再次發(fā)送連接請求，此時(shí)，上一個(gè)連接請求就是『失效的』。

若建立連接只需兩次握手，客戶端并沒有太大的變化，仍然需要獲得服務(wù)端的應(yīng)答后才進(jìn)入ESTABLISHED狀態(tài)，而服務(wù)端在收到連接請求后就進(jìn)入ESTABLISHED狀態(tài)。此時(shí)如果網(wǎng)絡(luò)擁塞，客戶端發(fā)送的連接請求遲遲到不了服務(wù)端，客戶端便超時(shí)重發(fā)請求，如果服務(wù)端正確接收并確認(rèn)應(yīng)答，雙方便開始通信，通信結(jié)束后釋放連接。此時(shí)，如果那個(gè)失效的連接請求抵達(dá)了服務(wù)端，由于只有兩次握手，服務(wù)端收到請求就會進(jìn)入ESTABLISHED狀態(tài)，等待發(fā)送數(shù)據(jù)或主動發(fā)送數(shù)據(jù)。但此時(shí)的客戶端早已進(jìn)入CLOSED狀態(tài)，服務(wù)端將會一直等待下去，這樣浪費(fèi)服務(wù)端連接資源。?

5.如果已經(jīng)建立了連接，但是客戶端突然出現(xiàn)故障了怎么辦？(網(wǎng)絡(luò)CLOSE)

TCP還設(shè)有一個(gè)保活計(jì)時(shí)器，顯然，客戶端如果出現(xiàn)故障，服務(wù)器不能一直等下去，白白浪費(fèi)資源。服務(wù)器每收到一次客戶端的請求后都會重新復(fù)位這個(gè)計(jì)時(shí)器，時(shí)間通常是設(shè)置為2小時(shí)，若兩小時(shí)還沒有收到客戶端的任何數(shù)據(jù)，服務(wù)器就會發(fā)送一個(gè)探測報(bào)文段，以后每隔75秒鐘發(fā)送一次。若一連發(fā)送10個(gè)探測報(bào)文仍然沒反應(yīng)，服務(wù)器就認(rèn)為客戶端出了故障，接著就關(guān)閉連接。

總結(jié)

以上是生活随笔為你收集整理的tcp当主动发出syn_（二）深入浅出TCPIP之再识TCP，理解TCP三次握手（上）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。