- connect() api調(diào)用發(fā)生在第1次握手之后
- accept() api調(diào)用發(fā)生在3次握手之后
- “三次握手”的目的是“為了防止已失效的連接請求報文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯誤”
- 因為tcp是全雙工模式，接收到FIN時意味將沒有數(shù)據(jù)再發(fā)來，但是還是可以繼續(xù)發(fā)送數(shù)據(jù)，所以斷開連接時必須是四次握手
為什么需要3次握手
謝希仁版《計算機網(wǎng)絡(luò)》中的例子是這樣的，“已失效的連接請求報文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的第一個連接請求報文段并沒有丟失，而是在某個網(wǎng)絡(luò)結(jié)點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段后，就誤認為是client再次發(fā)出的一個新的連接請求。于是就向client發(fā)出確認報文段，同意建立連接。假設(shè)不采用“三次握手”，那么只要server發(fā)出確認，新的連接就建立了。由于現(xiàn)在client并沒有發(fā)出建立連接的請求，因此不會理睬server的確認，也不會向server發(fā)送數(shù)據(jù)。但server卻以為新的運輸連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)。這樣，server的很多資源就白白浪費掉了。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況，client不會向server的確認發(fā)出確認。server由于收不到確認，就知道client并沒有要求建立連接?！?。主要目的防止server端一直等待，浪費資源。
補充
第一個包，即A發(fā)給B的SYN 中途被丟，沒有到達B
A會周期性超時重傳，直到收到B的確認第二個包，即B發(fā)給A的SYN +ACK 中途被丟，沒有到達A
B會周期性超時重傳，直到收到A的確認-
第三個包，即A發(fā)給B的ACK 中途被丟，沒有到達B
A發(fā)完ACK，單方面認為TCP為 Established狀態(tài)，而B顯然認為TCP為Active狀態(tài)：假定此時雙方都沒有數(shù)據(jù)發(fā)送，B會周期性超時重傳，直到收到A的確認，收到之后B的TCP 連接也為 Established狀態(tài)，雙向可以發(fā)包。
假定此時A有數(shù)據(jù)發(fā)送，B收到A的 Data + ACK，自然會切換為established 狀態(tài)，并接受A的 Data。
假定B有數(shù)據(jù)發(fā)送，數(shù)據(jù)發(fā)送不了，會一直周期性超時重傳SYN + ACK，直到收到A的確認才可以發(fā)送數(shù)據(jù)。
為什么需要4次揮手
因為當Server端收到Client端的SYN連接請求報文后，可以直接發(fā)送SYN+ACK報文。其中ACK報文是用來應(yīng)答的，SYN報文是用來同步的。但是關(guān)閉連接時，當Server端收到FIN報文時，很可能并不會立即關(guān)閉SOCKET，所以只能先回復(fù)一個ACK報文，告訴Client端，"你發(fā)的FIN報文我收到了"。只有等到我Server端所有的報文都發(fā)送完了，我才能發(fā)送FIN報文，因此不能一起發(fā)送。故需要四步握手。
4次揮手過程狀態(tài)
FIN_WAIT_1: 這個狀態(tài)要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態(tài)的真正含義都是表示等待對方的FIN報文。而這兩種狀態(tài)的區(qū)別是：FIN_WAIT_1狀態(tài)實際上是當SOCKET在ESTABLISHED狀態(tài)時，它想主動關(guān)閉連接，向?qū)Ψ桨l(fā)送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1狀態(tài)。而當對方回應(yīng)ACK報文后，則進入到FIN_WAIT_2狀態(tài)，當然在實際的正常情況下，無論對方何種情況下，都應(yīng)該馬上回應(yīng)ACK報文，所以FIN_WAIT_1狀態(tài)一般是比較難見到的，而FIN_WAIT_2狀態(tài)還有時常?？梢杂胣etstat看到。（主動方）
FIN_WAIT_2：上面已經(jīng)詳細解釋了這種狀態(tài)，實際上FIN_WAIT_2狀態(tài)下的SOCKET，表示半連接，也即有一方要求close連接，但另外還告訴對方，我暫時還有點數(shù)據(jù)需要傳送給你(ACK信息)，稍后再關(guān)閉連接。（主動方）
TIME_WAIT: 表示收到了對方的FIN報文，并發(fā)送出了ACK報文，就等2MSL后即可回到CLOSED可用狀態(tài)了。如果FIN_WAIT_1狀態(tài)下，收到了對方同時帶FIN標志和ACK標志的報文時，可以直接進入到TIME_WAIT狀態(tài)，而無須經(jīng)過FIN_WAIT_2狀態(tài)。（主動方）
CLOSING（比較少見）: 這種狀態(tài)比較特殊，實際情況中應(yīng)該是很少見，屬于一種比較罕見的例外狀態(tài)。正常情況下，當你發(fā)送FIN報文后，按理來說是應(yīng)該先收到（或同時收到）對方的 ACK報文，再收到對方的FIN報文。但是CLOSING狀態(tài)表示你發(fā)送FIN報文后，并沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什么情況下會出現(xiàn)此種情況呢？其實細想一下，也不難得出結(jié)論：那就是如果雙方幾乎在同時close一個SOCKET的話，那么就出現(xiàn)了雙方同時發(fā)送FIN報文的情況，也即會出現(xiàn)CLOSING狀態(tài)，表示雙方都正在關(guān)閉SOCKET連接。
CLOSE_WAIT: 這種狀態(tài)的含義其實是表示在等待關(guān)閉。怎么理解呢？當對方close一個SOCKET后發(fā)送FIN報文給自己，你系統(tǒng)毫無疑問地會回應(yīng)一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態(tài)。接下來呢，實際上你真正需要考慮的事情是察看你是否還有數(shù)據(jù)發(fā)送給對方，如果沒有的話，那么你也就可以 close這個SOCKET，發(fā)送FIN報文給對方，也即關(guān)閉連接。所以你在CLOSE_WAIT狀態(tài)下，需要完成的事情是等待你去關(guān)閉連接。（被動方）
LAST_ACK: 這個狀態(tài)還是比較容易好理解的，它是被動關(guān)閉一方在發(fā)送FIN報文后，最后等待對方的ACK報文。當收到ACK報文后，也即可以進入到CLOSED可用狀態(tài)了。（被動方）
CLOSED: 表示連接中斷。
