三次握手
建立流程
服務(wù)端的TCP進(jìn)程先創(chuàng)建傳輸控制塊TCB，準(zhǔn)備接受客戶(hù)端進(jìn)程的連接請(qǐng)求，然后服務(wù)端進(jìn)程處于LISTEN狀態(tài)，等待客戶(hù)端的連接請(qǐng)求，如有，則作出響應(yīng)。
1、客戶(hù)端的TCP進(jìn)程也首先創(chuàng)建傳輸控制模塊TCB，然后向服務(wù)端發(fā)出連接請(qǐng)求報(bào)文段，該報(bào)文段首部中的SYN=1，ACK=0，同時(shí)選擇一個(gè)初始序號(hào) seq=x。TCP規(guī)定，SYN=1的報(bào)文段不能攜帶數(shù)據(jù)，但要消耗掉一個(gè)序號(hào)。這時(shí)，TCP客戶(hù)進(jìn)程進(jìn)入SYN—SENT（同步已發(fā)送）狀態(tài)，這是 TCP連接的第一次握手。
2、服務(wù)端收到客戶(hù)端發(fā)來(lái)的請(qǐng)求報(bào)文后，如果同意建立連接，則向客戶(hù)端發(fā)送確認(rèn)。確認(rèn)報(bào)文中的SYN=1，ACK=1，確認(rèn)號(hào)ack=x+1，同時(shí)為自己選擇一個(gè)初始序號(hào)seq=y。同樣該報(bào)文段也是SYN=1的報(bào)文段，不能攜帶數(shù)據(jù)，但同樣要消耗掉一個(gè)序號(hào)。這時(shí)，TCP服務(wù)端進(jìn)入SYN—RCVD（同 步收到）狀態(tài)，這是TCP連接的第二次握手。
3、TCP客戶(hù)端進(jìn)程收到服務(wù)端進(jìn)程的確認(rèn)后，還要向服務(wù)端給出確認(rèn)。確認(rèn)報(bào)文段的ACK=1，確認(rèn)號(hào)ack=y+1，而自己的序號(hào)為seq=x+1。 TCP的標(biāo)準(zhǔn)規(guī)定，ACK報(bào)文段可以攜帶數(shù)據(jù)，但如果不攜帶數(shù)據(jù)則不消耗序號(hào)，因此，如果不攜帶數(shù)據(jù)，則下一個(gè)報(bào)文段的序號(hào)仍為seq=x+1。這 時(shí)，TCP連接已經(jīng)建立，客戶(hù)端進(jìn)入ESTABLISHED（已建立連接）狀態(tài)。這是TCP連接的第三次握手，可以看出第三次握手客戶(hù)端已經(jīng)可以發(fā)送攜帶數(shù)據(jù)的報(bào)文段了。
當(dāng)服務(wù)端收到確認(rèn)后，也進(jìn)入ESTABLISHED（已建立連接）狀態(tài)。
四次揮手
注意：中斷連接端可以是Client端，也可以是Server端。
假設(shè)Client端發(fā)起中斷連接請(qǐng)求，也就是發(fā)送FIN報(bào)文。Server端接到FIN報(bào)文后，意思是說(shuō)"我Client端沒(méi)有數(shù)據(jù)要發(fā)給你了"，但是如果你還有數(shù)據(jù)沒(méi)有發(fā)送完成，則不必急著關(guān)閉Socket，可以繼續(xù)發(fā)送數(shù)據(jù)。所以你先發(fā)送ACK，"告訴Client端，你的請(qǐng)求我收到了，但是我還沒(méi)準(zhǔn)備好，請(qǐng)繼續(xù)你等我的消息"。這個(gè)時(shí)候Client端就進(jìn)入FIN_WAIT狀態(tài)，繼續(xù)等待Server端的FIN報(bào)文。當(dāng)Server端確定數(shù)據(jù)已發(fā)送完成，則向Client端發(fā)送FIN報(bào)文，"告訴Client端，好了，我這邊數(shù)據(jù)發(fā)完了，準(zhǔn)備好關(guān)閉連接了"。Client端收到FIN報(bào)文后，"就知道可以關(guān)閉連接了，但是他還是不相信網(wǎng)絡(luò)，怕Server端不知道要關(guān)閉，所以發(fā)送ACK后進(jìn)入TIME_WAIT狀態(tài)，如果Server端沒(méi)有收到ACK則可以重傳?！埃琒erver端收到ACK后，"就知道可以斷開(kāi)連接了"。Client端等待了2MSL后依然沒(méi)有收到回復(fù)，則證明Server端已正常關(guān)閉，那好，我Client端也可以關(guān)閉連接了。Ok，TCP連接就這樣關(guān)閉了！
建立流程
1、客戶(hù)端進(jìn)程發(fā)出連接釋放報(bào)文，并且停止發(fā)送數(shù)據(jù)。釋放數(shù)據(jù)報(bào)文首部，F(xiàn)IN=1，其序列號(hào)為seq=u（等于前面已經(jīng)傳送過(guò)來(lái)的數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加1），此時(shí)，客戶(hù)端進(jìn)入FIN-WAIT-1（終止等待1）狀態(tài)。 TCP規(guī)定，F(xiàn)IN報(bào)文段即使不攜帶數(shù)據(jù)，也要消耗一個(gè)序號(hào)。
2、服務(wù)器收到連接釋放報(bào)文，發(fā)出確認(rèn)報(bào)文，ACK=1，ack=u+1，并且?guī)献约旱男蛄刑?hào)seq=v，此時(shí)，服務(wù)端就進(jìn)入了CLOSE-WAIT（關(guān)閉等待）狀態(tài)。TCP服務(wù)器通知高層的應(yīng)用進(jìn)程，客戶(hù)端向服務(wù)器的方向就釋放了，這時(shí)候處于半關(guān)閉狀態(tài)，即客戶(hù)端已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送了，但是服務(wù)器若發(fā)送數(shù)據(jù)，客戶(hù)端依然要接受。這個(gè)狀態(tài)還要持續(xù)一段時(shí)間，也就是整個(gè)CLOSE-WAIT狀態(tài)持續(xù)的時(shí)間。
3、客戶(hù)端收到服務(wù)器的確認(rèn)請(qǐng)求后，此時(shí)，客戶(hù)端就進(jìn)入FIN-WAIT-2（終止等待2）狀態(tài)，等待服務(wù)器發(fā)送連接釋放報(bào)文（在這之前還需要接受服務(wù)器發(fā)送的最后的數(shù)據(jù)）。
4、服務(wù)器將最后的數(shù)據(jù)發(fā)送完畢后，就向客戶(hù)端發(fā)送連接釋放報(bào)文，F(xiàn)IN=1，ack=u+1，由于在半關(guān)閉狀態(tài)，服務(wù)器很可能又發(fā)送了一些數(shù)據(jù)，假定此時(shí)的序列號(hào)為seq=w，此時(shí)，服務(wù)器就進(jìn)入了LAST-ACK（最后確認(rèn)）狀態(tài)，等待客戶(hù)端的確認(rèn)。
5、客戶(hù)端收到服務(wù)器的連接釋放報(bào)文后，必須發(fā)出確認(rèn)，ACK=1，ack=w+1，而自己的序列號(hào)是seq=u+1，此時(shí)，客戶(hù)端就進(jìn)入了TIME-WAIT（時(shí)間等待）狀態(tài)。注意此時(shí)TCP連接還沒(méi)有釋放，必須經(jīng)過(guò)2??MSL（最長(zhǎng)報(bào)文段壽命）的時(shí)間后，當(dāng)客戶(hù)端撤銷(xiāo)相應(yīng)的TCB后，才進(jìn)入CLOSED狀態(tài)。
6、服務(wù)器只要收到了客戶(hù)端發(fā)出的確認(rèn)，立即進(jìn)入CLOSED狀態(tài)。同樣，撤銷(xiāo)TCB后，就結(jié)束了這次的TCP連接。可以看到，服務(wù)器結(jié)束TCP連接的時(shí)間要比客戶(hù)端早一些。
常見(jiàn)問(wèn)題：
為什么建立時(shí)需要三次握手、斷開(kāi)時(shí)需要四次揮手？
因?yàn)楫?dāng)Server端收到Client端的SYN連接請(qǐng)求報(bào)文后，可以直接發(fā)送SYN+ACK報(bào)文。其中ACK報(bào)文是用來(lái)應(yīng)答的，SYN報(bào)文是用來(lái)同步的。但是關(guān)閉連接時(shí)，當(dāng)Server端收到FIN報(bào)文時(shí)，很可能并不會(huì)立即關(guān)閉SOCKET，所以只能先回復(fù)一個(gè)ACK報(bào)文，告訴Client端，”你發(fā)的FIN報(bào)文我收到了”。只有等到我Server端所有的報(bào)文都發(fā)送完了，我才能發(fā)送FIN報(bào)文，因此不能一起發(fā)送。故需要四步握手。
為什么TIME_WAIT狀態(tài)需要經(jīng)過(guò)2MSL(最大報(bào)文段生存時(shí)間)才能返回到CLOSE狀態(tài)？
雖然按道理，四個(gè)報(bào)文都發(fā)送完畢，我們可以直接進(jìn)入CLOSE狀態(tài)了，但是我們必須假象網(wǎng)絡(luò)是不可靠的，有可以最后一個(gè)ACK丟失。所以TIME_WAIT狀態(tài)就是用來(lái)重發(fā)可能丟失的ACK報(bào)文。
為什么不能用兩次握手進(jìn)行連接？
3次握手完成兩個(gè)重要的功能，既要雙方做好發(fā)送數(shù)據(jù)的準(zhǔn)備工作(雙方都知道彼此已準(zhǔn)備好)，也要允許雙方就初始序列號(hào)進(jìn)行協(xié)商，這個(gè)序列號(hào)在握手過(guò)程中被發(fā)送和確認(rèn)。
現(xiàn)在把三次握手改成僅需要兩次握手，死鎖是可能發(fā)生的。作為例子，考慮計(jì)算機(jī)S和C之間的通信，假定C給S發(fā)送一個(gè)連接請(qǐng)求分組，S收到了這個(gè)分組，并發(fā) 送了確認(rèn)應(yīng)答分組。按照兩次握手的協(xié)定，S認(rèn)為連接已經(jīng)成功地建立了，可以開(kāi)始發(fā)送數(shù)據(jù)分組?？墒牵珻在S的應(yīng)答分組在傳輸中被丟失的情況下，將不知道S 是否已準(zhǔn)備好，不知道S建立什么樣的序列號(hào)，C甚至懷疑S是否收到自己的連接請(qǐng)求分組。在這種情況下，C認(rèn)為連接還未建立成功，將忽略S發(fā)來(lái)的任何數(shù)據(jù)分 組，只等待連接確認(rèn)應(yīng)答分組。而S在發(fā)出的分組超時(shí)后，重復(fù)發(fā)送同樣的分組。這樣就形成了死鎖。
如果已經(jīng)建立了連接，但是客戶(hù)端突然出現(xiàn)故障了怎么辦？
TCP還設(shè)有一個(gè)?；钣?jì)時(shí)器，顯然，客戶(hù)端如果出現(xiàn)故障，服務(wù)器不能一直等下去，白白浪費(fèi)資源。服務(wù)器每收到一次客戶(hù)端的請(qǐng)求后都會(huì)重新復(fù)位這個(gè)計(jì)時(shí)器，時(shí)間通常是設(shè)置為2小時(shí)，若兩小時(shí)還沒(méi)有收到客戶(hù)端的任何數(shù)據(jù)，服務(wù)器就會(huì)發(fā)送一個(gè)探測(cè)報(bào)文段，以后每隔75分鐘發(fā)送一次。若一連發(fā)送10個(gè)探測(cè)報(bào)文仍然沒(méi)反應(yīng)，服務(wù)器就認(rèn)為客戶(hù)端出了故障，接著就關(guān)閉連接。
各個(gè)狀態(tài)機(jī)：
FIN_WAIT_1: FIN_WAIT_1和FIN_WAIT_2狀態(tài)的真正含義都是表示等待對(duì)方的FIN報(bào)文。而這兩種狀態(tài)的區(qū)別是： FIN_WAIT_1狀態(tài)實(shí)際上是當(dāng)SOCKET在ESTABLISHED狀態(tài)時(shí)，它想主動(dòng)關(guān)閉連接，向?qū)Ψ桨l(fā)送了FIN報(bào)文，此時(shí)該SOCKET即進(jìn)入到FIN_WAIT_1狀態(tài)。而當(dāng)對(duì)方回應(yīng)ACK報(bào)文后，則進(jìn)入到FIN_WAIT_2狀態(tài)，當(dāng)然在實(shí)際的正常情況下，無(wú)論對(duì)方何種情況下，都應(yīng)該馬上回應(yīng)ACK報(bào)文，所以FIN_WAIT_1狀態(tài)一般是比較難見(jiàn)到的，而FIN_WAIT_2狀態(tài)還有時(shí)常?？梢杂胣etstat看到。（主動(dòng)方）
FIN_WAIT_2：上面已經(jīng)詳細(xì)解釋了這種狀態(tài)，實(shí)際上FIN_WAIT_2狀態(tài)下的SOCKET，表示半連接，也即有一方要求close連接，但另外一方告訴對(duì)方，我暫時(shí)還有點(diǎn)數(shù)據(jù)需要傳送給你(ACK信息)，稍后再關(guān)閉連接。（主動(dòng)方）
TIME_WAIT: 表示收到了對(duì)方的FIN報(bào)文，并發(fā)送出了ACK報(bào)文，就等2MSL后即可回到CLOSED可用狀態(tài)了。如果FIN_WAIT_1狀態(tài)下，收到了對(duì)方同時(shí)帶FIN標(biāo)志和ACK標(biāo)志的報(bào)文時(shí)，可以直接進(jìn)入到TIME_WAIT狀態(tài)，而無(wú)須經(jīng)過(guò)FIN_WAIT_2狀態(tài)。（主動(dòng)方）
CLOSING（比較少見(jiàn)）: 這種狀態(tài)比較特殊，實(shí)際情況中應(yīng)該是很少見(jiàn)，屬于一種比較罕見(jiàn)的例外狀態(tài)。正常情況下，當(dāng)你發(fā)送FIN報(bào)文后，按理來(lái)說(shuō)是應(yīng)該先收到（或同時(shí)收到）對(duì)方的ACK報(bào)文，再收到對(duì)方的FIN報(bào)文。但是CLOSING狀態(tài)表示你發(fā)送FIN報(bào)文后，并沒(méi)有收到對(duì)方的ACK報(bào)文，反而卻也收到了對(duì)方的FIN報(bào)文。什么情況下會(huì)出現(xiàn)此種情況呢？其實(shí)細(xì)想一下，也不難得出結(jié)論：那就是如果雙方幾乎在同時(shí)close一個(gè)SOCKET的話(huà)，那么就出現(xiàn)了雙方同時(shí)發(fā)送FIN報(bào)文的情況，也即會(huì)出現(xiàn)CLOSING狀態(tài)，表示雙方都正在關(guān)閉SOCKET連接。
CLOSE_WAIT: 這種狀態(tài)的含義其實(shí)是表示在等待關(guān)閉。怎么理解呢？當(dāng)對(duì)方close一個(gè)SOCKET后發(fā)送FIN報(bào)文給自己，你系統(tǒng)毫無(wú)疑問(wèn)地會(huì)回應(yīng)一個(gè)ACK報(bào)文給對(duì)方，此時(shí)則進(jìn)入到CLOSE_WAIT狀態(tài)。接下來(lái)呢，實(shí)際上你真正需要考慮的事情是查看你是否還有數(shù)據(jù)發(fā)送給對(duì)方，如果沒(méi)有的話(huà)，那么你也就可以close這個(gè)SOCKET，發(fā)送FIN報(bào)文給對(duì)方，也即關(guān)閉連接。所以你在CLOSE_WAIT狀態(tài)下，需要完成的事情是等待你去關(guān)閉連接。（被動(dòng)方）
LAST_ACK: 這個(gè)狀態(tài)還是比較容易好理解的，它是被動(dòng)關(guān)閉一方在發(fā)送FIN報(bào)文后，最后等待對(duì)方的ACK報(bào)文。當(dāng)收到ACK報(bào)文后，也即可以進(jìn)入到CLOSED可用狀態(tài)了。（被動(dòng)方）
CLOSED: 表示連接中斷。
通過(guò)抓包理解分析：
這里采用的是ssh方式遠(yuǎn)程連接至虛擬機(jī)通過(guò)wireshark軟件獲取的以下結(jié)果
三次握手：
四次揮手：
數(shù)據(jù)包：
針對(duì)seq和ack的理解：
在講這個(gè)之前，首先大家需要知道TCP屬于面向連接的協(xié)議，而UDP屬于無(wú)連接的協(xié)議。因?yàn)檫@一特性導(dǎo)致了數(shù)據(jù)通過(guò)TCP來(lái)傳輸?shù)臅r(shí)候，如果因?yàn)槠渌騺G包，那么數(shù)據(jù)包將會(huì)重傳。
（wireshark的seq不是從0開(kāi)始的，之所以默認(rèn)是從0開(kāi)始是軟件設(shè)計(jì)的時(shí)候?yàn)榱宋覀儽阌谟^(guān)察，所以從0開(kāi)始。修改辦法： Edit -> Preferences ->protocols ->TCP去掉勾選項(xiàng)Relative sequence number便可以恢復(fù)。）
取值范圍為2^32-1，當(dāng)取值范圍到達(dá)最大的時(shí)候，重置為0重新開(kāi)始。
seq的理解：
通過(guò)比較數(shù)據(jù)包的報(bào)文發(fā)現(xiàn)seq的值==request+前面的ack值。如果沒(méi)有丟包seq保持不變。
ack的理解：
通過(guò)比較數(shù)據(jù)包的報(bào)文發(fā)現(xiàn)ack的值==response+前面的ack值。
如有不對(duì)，請(qǐng)各位大佬幫忙斧正！謝謝！
