TCP協(xié)議的常見面試題

因為當Server端收到Client端的SYN連接請求報文后，可以直接發(fā)送SYN+ACK報文。其中ACK報文是用來應(yīng)答的，SYN報文是用來同步的。但是關(guān)閉連接時，當Server端收到FIN報文時，很可能并不會立即關(guān)閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，"你發(fā)的FIN報文我收到了"。只有等到我Server端所有的報文都發(fā)送完了，我才能發(fā)送FIN報文，因此不能一起發(fā)送。故需要四步握手。

這主要是為了防止已失效的連接請求報文段突然又傳到了B，因而產(chǎn)生錯誤。

現(xiàn)假定一種異常情況，即A發(fā)出的第一個連接請求報文段并沒有丟失，而是在某些網(wǎng)絡(luò)節(jié)點長時間滯留了，以致延誤到連接釋放后的某個時間才到達B。本來這是一個早已失效的報文段。但B受到此失效的連接請求報文段后，就誤以為是A又發(fā)出一次新的連接請求，于是就向A發(fā)出確認報文段，同意建立連接。假定不采用第三次報文握手，那么只要B發(fā)出確認，新的連接就建立了。

由于現(xiàn)在A并沒有發(fā)出建立連接的請求，因此不會理睬B的確認，也不會向B發(fā)送數(shù)據(jù)，但B卻以為新的運輸連接已經(jīng)建立了，并一直等待A發(fā)來的數(shù)據(jù)。B的許多資源就這樣白白浪費了。

采用三次握手連接，可以防止上述現(xiàn)象的發(fā)生。例如在剛才的異常情況下，A不會向B的確認發(fā)出確認，B由于收不到確認，就知道A并沒有要求建立連接，于是B就不會再建立連接。

• 第一，為了保證A發(fā)送的最后一個ACK報文段能夠到達B。假設(shè)網(wǎng)絡(luò)是不可靠的，有可以最后一個ACK丟失。所以TIME_WAIT狀態(tài)就是用來重發(fā)可能丟失的ACK報文。在Client發(fā)送出最后的ACK回復，但該ACK可能丟失。Server如果沒有收到ACK，將不斷重復發(fā)送FIN片段。所以Client不能立即關(guān)閉，它必須確認Server接收到了該ACK。Client會在發(fā)送出ACK之后進入到TIME_WAIT狀態(tài)。Client會設(shè)置一個計時器，等待2MSL的時間。如果在該時間內(nèi)再次收到FIN，那么Client會重發(fā)ACK并再次等待2MSL。所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)。MSL指一個片段在網(wǎng)絡(luò)中最大的存活時間，2MSL就是一個發(fā)送和一個回復所需的最大時間。如果直到2MSL，Client都沒有再次收到FIN，那么Client推斷ACK已經(jīng)被Server成功接收，則結(jié)束TCP連接。
• 第二，防止“已失效的連接請求報文段”出現(xiàn)在本連接中。A在發(fā)送完最后一個ACK報文段后，再經(jīng)過時間2MSL，就可以使本連接持續(xù)的時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡(luò)中消失。這樣就可以使下一個新的連接中不會出現(xiàn)這種舊的連接請求報文段。

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

原文鏈接： https://www.linuxprobe.com/tcp-usually-question.html