1、引言
TCP 這段看過好幾遍，老是記不住，沒辦法找工作涉及到網(wǎng)絡(luò)編程這塊，各種問 TCP 。今天好好整理一下握手和揮手過程。獻(xiàn)給跟我一樣忙碌，找工作的童鞋，歡迎大神批評指正。
2、TCP 的連接建立
上圖畫出了 TCP 建立連接的過程。假定主機 A 是 TCP 客戶端，B是服務(wù)端。最初兩端的 TCP 進程都處于 CLOSED 狀態(tài)。圖中在主機下面的是 TCP進程所處的狀態(tài)。A 是主動打開連接，B 是被動打開連接。
三次握手過程分析：
（1）首先A向B發(fā)出連接請求報文段，這時首部中的同步位SYN=1，同時選擇一個初始序號 seq=x。TCP規(guī)定，SYN報文段不能攜帶數(shù)據(jù)，但要消耗掉一個序號。這時，A進入SYN-SENT狀態(tài)。【備注：序號指的是 TCP 報文段首部20字節(jié)里的序號，TCP 連接傳送的字節(jié)流的每一個字節(jié)都按順序編號，具體可以看看 TCP 可靠傳輸實現(xiàn)的原理】
（2）B收到請求后，向A發(fā)送確認(rèn)。在確認(rèn)報文段中把SYN和ACK位都置為1，確認(rèn)號是ack=x+1,同時也為自己選擇一個初始序號seq=y。請注意，這個報文段也不能攜帶數(shù)據(jù)，但同樣要消耗掉一個序號。這時B進入SYN-RCVD狀態(tài)。
（3）A收到B的確認(rèn)后，還要向B給出確認(rèn)。確認(rèn)報文段的ACK置為1，確認(rèn)號ack=y+1，而自己的序號seq=x+1。這時，TCP連接已經(jīng)建立，A進入ESTABLISHED 狀態(tài)，當(dāng)B收到A的確認(rèn)后，也會進入 ESTABLISHED 狀態(tài)。
以上給出的連接建立過程就是常說的TCP三次握手。
2.1 為什么需要三次握手過程（面試經(jīng)常問）
為什么A還要發(fā)送一次確認(rèn)呢?這主要是為了防止已失效的連接請求報文段突然又傳送到了B，因而產(chǎn)生錯誤。
所謂已失效的連接請求報文段是這樣產(chǎn)生的。A發(fā)送連接請求，但因連接請求報文丟失而未收到確認(rèn)，于是A重發(fā)一次連接請求，成功后建立了連接。數(shù)據(jù)傳輸完畢后就釋放了連接?，F(xiàn)在假定A發(fā)出的第一個請求報文段并未丟失，而是在某個網(wǎng)絡(luò)節(jié)點長時間滯留了，以致延誤到連接釋放以后的某個時間才到達(dá)B。本來這是一個早已失效的報文段。但B收到此失效的連接請求報文段后，就誤以為A又發(fā)了一次新的連接請求，于是向A發(fā)出確認(rèn)報文段，同意建立連接。假如不采用三次握手，那么只要B發(fā)出確認(rèn)，新的連接就建立了。
由于A并未發(fā)出建立連接的請求，因此不會理睬B的確認(rèn)，也不會向B發(fā)送數(shù)據(jù)。但B卻以為新的運輸連接已經(jīng)建立了，并一直等待A發(fā)來數(shù)據(jù)，因此白白浪費了許多資源。
采用TCP三次握手的方法可以防止上述現(xiàn)象發(fā)生。例如在剛才的情況下，由于A不會向B的確認(rèn)發(fā)出確認(rèn)，連接就不會建立。
2.2 如果在TCP第三次握手中的報文段丟失了會發(fā)生什么情況?
Client認(rèn)為這個連接已經(jīng)建立，如果Client端向Server寫數(shù)據(jù)，Server端將以RST包響應(yīng)，方能感知到Server的錯誤。
3、TCP 連接釋放
四次握手（兩個二次握手）過程分析：
數(shù)據(jù)傳輸結(jié)束后，通信的雙方都可以釋放連接，并停止發(fā)送數(shù)據(jù)。假設(shè)現(xiàn)在客戶端和服務(wù)端都處于ESTABLISHED狀態(tài)。
（1）客戶端 A 的 TCP 進程先向服務(wù)端發(fā)出連接釋放報文段，并停止發(fā)送數(shù)據(jù)，主動關(guān)閉 TCP 連接。釋放連接報文段中 FIN=1，序號為 seq=u，該序號等于前面已經(jīng)傳送過去的數(shù)據(jù)的最后一個字節(jié)的序號加1。這時，A進入 FIN—WAIT-1 (終止等待1)狀態(tài)，等待 B 的確認(rèn)。TCP 規(guī)定，F(xiàn)IN報文段即使不攜帶數(shù)據(jù)，也要消耗掉一個序號。這是 TCP 連接釋放的第一次揮手。
（2）B收到連接釋放報文段后即發(fā)出確認(rèn)釋放連接的報文段，該報文段中，ACK=1，確認(rèn)號為ack=u+1，其自己的序號為v，該序號等于B前面已經(jīng)傳送過的數(shù)據(jù)的最后一個字節(jié)的序號加1。然后B進入CLOSE—WAIT(關(guān)閉等待)狀態(tài)，此時TCP服務(wù)器進程應(yīng)該通知上層的應(yīng)用進程，因而A到B這個方向的連接就釋放了，這時TCP處于半關(guān)閉狀態(tài)，即A已經(jīng)沒有數(shù)據(jù)要發(fā)了，但B若發(fā)送數(shù)據(jù)，A仍要接受，也就是說從B到A這個方向的連接并沒有關(guān)閉，這個狀態(tài)可能會持續(xù)一些時間。這是TCP連接釋放的第二次揮手。
（3）A收到B的確認(rèn)后，就進入了FIN—WAIT(終止等待2)狀態(tài)，等待B發(fā)出連接釋放報文段，如果B已經(jīng)沒有要向A發(fā)送的數(shù)據(jù)了，其應(yīng)用進程就通知TCP釋放連接。這時B發(fā)出的鏈接釋放報文段中，F(xiàn)IN=1，確認(rèn)號還必須重復(fù)上次已發(fā)送過的確認(rèn)號，即ack=u+1，序號seq=w，因為在半關(guān)閉狀態(tài)B可能又發(fā)送了一些數(shù)據(jù)，因此該序號為半關(guān)閉狀態(tài)發(fā)送的數(shù)據(jù)的最后一個字節(jié)的序號加1。這時B進入LAST—ACK(最后確認(rèn))狀態(tài)，等待A的確認(rèn)，這是TCP連接的第三次揮手。
（4）A收到B的連接釋放請求后，必須對此發(fā)出確認(rèn)。確認(rèn)報文段中，ACK=1，確認(rèn)號ack=w+1，而自己的序號seq=u+1，而后進入TIME—WAIT(時間等待)狀態(tài)。這時候，TCP連接還沒有釋放掉，必須經(jīng)過時間等待計時器設(shè)置的時間2MSL后，A才進入CLOSED狀態(tài)，時間MSL叫做最長報文壽命，RFC建議設(shè)為2分鐘，因此從A進入TIME—WAIT狀態(tài)后，要經(jīng)過4分鐘才能進入到CLOSED狀態(tài)，而B只要收到了A的確認(rèn)后，就進入了CLOSED狀態(tài)。二者都進入CLOSED狀態(tài)后，連接就完全釋放了，這是TCP連接的第四次揮手。
3.1 為什么需要四次揮手
①、為了保證A發(fā)送的最后一個ACK報文段能夠到達(dá)B。即最后這個確認(rèn)報文段很有可能丟失，那么B會超時重傳，然后A再一次確認(rèn)，同時啟動2MSL計時器，如此下去。如果沒有等待時間，發(fā)送完確認(rèn)報文段就立即釋放連接的話，B就無法重傳了（連接已被釋放，任何數(shù)據(jù)都不能出傳了），因而也就收不到確認(rèn)，就無法按照步驟進入CLOSE狀態(tài)，即必須收到確認(rèn)才能close。
②、防止“已失效的連接請求報文段”出現(xiàn)在連接中。經(jīng)過2MSL，那些在這個連接持續(xù)的時間內(nèi)，產(chǎn)生的所有報文段就可以都從網(wǎng)絡(luò)中消失。即在這個連接釋放的過程中會有一些無效的報文段滯留在樓閣結(jié)點，但是呢，經(jīng)過2MSL這些無效報文段就肯定可以發(fā)送到目的地，不會滯留在網(wǎng)絡(luò)中。這樣的話，在下一個連接中就不會出現(xiàn)上一個連接遺留下來的請求報文段了。
可以看出：B結(jié)束TCP連接的時間比A早一點，因為B收到確認(rèn)就斷開連接了，而A還得等待2MSL.
【備注】當(dāng)客戶端執(zhí)行主動關(guān)閉并進入TIME—WAIT是正常的，服務(wù)端執(zhí)行被動關(guān)閉，不會進入TIME—WAIT狀態(tài)，這說明，如果終止了一個客戶程序，并立即重啟該客戶程序，則新的客戶程序?qū)⒉辉僦赜孟嗤谋镜囟丝?，而是使用新的端口，這不會帶來什么問題，因為客戶端使用本地端口，而并不關(guān)心這個端口是多少。但對于服務(wù)器來說，情況就不同了，服務(wù)器總是用我們熟知的端口，那么在2MSL時間內(nèi)，重啟服務(wù)器就會出錯，為了避免這個錯誤，服務(wù)器給出了一個平靜時間的概念，這是說在2MSL時間內(nèi)，雖然可以重新啟動服務(wù)器，但是這個服務(wù)器還是要平靜的等待2MSL時間的過去才能進行下一次連接。
