TCP三次握手過程
1 主機(jī)A通過向主機(jī)B 發(fā)送一個(gè)含有同步序列號的標(biāo)志位的數(shù)據(jù)段給主機(jī)B ,向主機(jī)B 請求建立連接,通過這個(gè)數(shù)據(jù)段,
主機(jī)A告訴主機(jī)B 兩件事:我想要和你通信;你可以用哪個(gè)序列號作為起始數(shù)據(jù)段來回應(yīng)我.
2 主機(jī)B 收到主機(jī)A的請求后,用一個(gè)帶有確認(rèn)應(yīng)答(ACK)和同步序列號(SYN)標(biāo)志位的數(shù)據(jù)段響應(yīng)主機(jī)A,也告訴主機(jī)A兩件事:
我已經(jīng)收到你的請求了,你可以傳輸數(shù)據(jù)了;你要用哪個(gè)序列號作為起始數(shù)據(jù)段來回應(yīng)我
3 主機(jī)A收到這個(gè)數(shù)據(jù)段后,再發(fā)送一個(gè)確認(rèn)應(yīng)答,確認(rèn)已收到主機(jī)B 的數(shù)據(jù)段:"我已收到回復(fù),我現(xiàn)在要開始傳輸實(shí)際數(shù)據(jù)了
這樣3次握手就完成了,主機(jī)A和主機(jī)B 就可以傳輸數(shù)據(jù)了.
3次握手的特點(diǎn)
沒有應(yīng)用層的數(shù)據(jù)
SYN這個(gè)標(biāo)志位只有在TCP建產(chǎn)連接時(shí)才會(huì)被置1
握手完成后SYN標(biāo)志位被置0
4次斷開
1 當(dāng)主機(jī)A完成數(shù)據(jù)傳輸后,將控制位FIN置1,提出停止TCP連接的請求
2 主機(jī)B收到FIN后對其作出響應(yīng),確認(rèn)這一方向上的TCP連接將關(guān)閉,將ACK置1
3 由B 端再提出反方向的關(guān)閉請求,將FIN置1
4 主機(jī)A對主機(jī)B的請求進(jìn)行確認(rèn),將ACK置1,雙方向的關(guān)閉結(jié)束.
由TCP的三次握手和四次斷開可以看出,TCP使用面向連接的通信方式,大大提高了數(shù)據(jù)通信的可靠性,使發(fā)送數(shù)據(jù)端
和接收端在數(shù)據(jù)正式傳輸前就有了交互,為數(shù)據(jù)正式傳輸打下了可靠的基礎(chǔ)
名詞解釋
ACKTCP報(bào)頭的控制位之一,對數(shù)據(jù)進(jìn)行確認(rèn).確認(rèn)由目的端發(fā)出,用它來告訴發(fā)送端這個(gè)序列號之前的數(shù)據(jù)段
都收到了.比如,確認(rèn)號為X,則表示前X-1個(gè)數(shù)據(jù)段都收到了,只有當(dāng)ACK=1時(shí),確認(rèn)號才有效,當(dāng)ACK=0時(shí),確認(rèn)號無效,這時(shí)會(huì)要求重傳數(shù)據(jù),保證數(shù)據(jù)的完整性.
SYN同步序列號,TCP建立連接時(shí)將這個(gè)位置1
FIN發(fā)送端完成發(fā)送任務(wù)位,當(dāng)TCP完成數(shù)據(jù)傳輸需要斷開時(shí),提出斷開連接的一方將這位置1
為什么不能兩次握手能進(jìn)行連接？
我們知道赌蔑，3次握手完成兩個(gè)重要的功能，既要雙方做好發(fā)送數(shù)據(jù)的準(zhǔn)備工作(雙方都知道彼此已準(zhǔn)備好)娃惯，也要允許雙方就初始序列號進(jìn)行協(xié)商，這個(gè)序列號在握手過程中被發(fā)送和確認(rèn)趾浅。Server ?Client。
防止失效的連接請求報(bào)文段突然又傳送到主機(jī)S（第一次握手延遲送到）
失效的連接請求報(bào)文段是指：主機(jī) A 發(fā)出的連接請求沒有收到主機(jī) B 的確認(rèn)浅侨，于是經(jīng)過一段時(shí)間后，主機(jī) A 又重新向主機(jī) B 發(fā)送連接請求如输，且建立成功，順序完成數(shù)據(jù)傳輸挨决。考慮這樣一種特殊情況脖祈，主機(jī) A 第一次發(fā)送的連接請求并沒有丟失，而是因?yàn)榫W(wǎng)絡(luò)節(jié)點(diǎn)導(dǎo)致延遲達(dá)到主機(jī) B 慎陵，主機(jī) B 以為是主機(jī) A 又發(fā)起的新連接，于是主機(jī) B 同意連接席纽，并向主機(jī) A 發(fā)回確認(rèn)，但是此時(shí)主機(jī) A 根本不會(huì)理會(huì)润梯，主機(jī) B 就一直在等待主機(jī) A 發(fā)送數(shù)據(jù)甥厦，導(dǎo)致主機(jī) B 的資源浪費(fèi)
現(xiàn)在把三次握手改成僅需要兩次握手，死鎖是可能發(fā)生的刀疙。（第二次握手丟失）
作為例子，考慮計(jì)算機(jī)S和C之間的通信谦秧，假定C給S發(fā)送一個(gè)連接請求分組，S收到了這個(gè)分組疚鲤，并發(fā)送了確認(rèn)應(yīng)答分組。按照兩次握手的協(xié)定揩悄，S認(rèn)為連接已經(jīng)成功地建立了，可以開始發(fā)送數(shù)據(jù)分組删性。可是蹬挺，C在S的應(yīng)答分組在傳輸中被丟失的情況下它掂，將不知道S是否已準(zhǔn)備好溯泣，不知道S建立什么樣的序列號，C甚至懷疑S是否收到自己的連接請求分組垃沦。在這種情況下用押，C認(rèn)為連接還未建立成功，將忽略S發(fā)來的任何數(shù)據(jù)分組蜻拨，只等待連接確認(rèn)應(yīng)答分組。而S在發(fā)出的分組超時(shí)后缎讼，重復(fù)發(fā)送同樣的分組。這樣就形成了死鎖血崭。
為什么TIME_WAIT狀態(tài)還需要等2MSL后才能返回到CLOSED狀態(tài)？
這是因?yàn)殡m然雙方都同意關(guān)閉連接了夹纫，而且握手的4個(gè)報(bào)文也都協(xié)調(diào)和發(fā)送完畢，按理可以直接回到CLOSED狀態(tài)（就好比從SYN_SEND狀態(tài)到ESTABLISH狀態(tài)那樣）捷凄；但是因?yàn)槲覀儽仨氁傧刖W(wǎng)絡(luò)是不可靠的跺涤，你無法保證你最后發(fā)送的ACK報(bào)文會(huì)一定被對方收到，因此對方處于LAST_ACK狀態(tài)下的SOCKET可能會(huì)因?yàn)槌瑫r(shí)未收到ACK報(bào)文桶错，而重發(fā)FIN報(bào)文胀蛮，所以這個(gè)TIME_WAIT狀態(tài)的作用就是用來重發(fā)可能丟失的ACK報(bào)文。
在TCP連接中粪狼，當(dāng)被動(dòng)關(guān)閉連接的一方(圖中client)發(fā)送的FIN報(bào)文到達(dá)時(shí)，被動(dòng)關(guān)閉連接的一方會(huì)發(fā)送ACK確認(rèn)報(bào)文再榄，并且進(jìn)入TIME_WAIT狀態(tài)，并且等待2MSL時(shí)間段(MSL:maximum segment life)困鸥。這么做有下述兩個(gè)原因：
1、被動(dòng)關(guān)閉連接的一方(圖中的server)在一段時(shí)間內(nèi)沒有收到對方的ACK確認(rèn)數(shù)據(jù)包澜术，會(huì)重新發(fā)送FIN數(shù)據(jù)包艺蝴，因而主動(dòng)關(guān)閉連接的一方需要停留在等待狀態(tài)以處理對方重新發(fā)送的FIN數(shù)據(jù)包鸟废。否則他會(huì)回應(yīng)一個(gè)RST數(shù)據(jù)包給被動(dòng)關(guān)閉連接的一方，使得對方莫名其妙侮攀。
2、在TIME_WAIT狀態(tài)下兰英，不允許應(yīng)用程序在當(dāng)前ip和端口上和之前通信的client(這個(gè)client的ip和端口號不變)建立一個(gè)新的連接。這樣就能避免新的連接收到之前的ip和端口一致的連接殘存在網(wǎng)絡(luò)中的數(shù)據(jù)包陨闹。這也是TIME_WAIT狀態(tài)的等待時(shí)間被設(shè)置為2MSL的原因，以確保網(wǎng)絡(luò)上當(dāng)前連接兩個(gè)方向上尚未接收的TCP報(bào)文已經(jīng)全部消失趋厉。
http://blog.csdn.net/qq276592716/article/details/19762121
http://blog.csdn.net/qq_34501940/article/details/51119726
