TCP三次握手和四次握手

TCP

TCP，提供面向連接的服務(wù)，在傳送數(shù)據(jù)之前必須先建立連接，數(shù)據(jù)傳送完成后要釋放連接。因此，TCP是一種可靠的運輸服務(wù)，但是正因為這樣，不可避免的增加了許多的開銷，比如確認(rèn)，流量控制等。對應(yīng)的應(yīng)用層協(xié)議主要有SMTP，Telnet，HTTP，F(xiàn)TP等。

TCP報文首部

源端口和目的端口

??計算機上的進程要和其他進程通信是要通過計算機端口的，而一個計算機端口某個時刻只能被一個進程占用，所以通過指定源端口和目標(biāo)端口，就可以知道是哪兩個進程需要通信。源端口、目標(biāo)端口是用16位表示的，可推算計算機的端口個數(shù)為2^16個

序號

??占4個字節(jié)，表示本報文段所發(fā)送數(shù)據(jù)的第一個字節(jié)的編號。在TCP連接中所傳送的字節(jié)流的每一個字節(jié)都會按順序編號。由于序列號由32位表示，所以每2^32個字節(jié)，就會出現(xiàn)序列號回繞，再次從 0 開始
??例如，一段報文的序號字段值是 301 ，而攜帶的數(shù)據(jù)共有100字段，顯然下一個報文段（如果還有的話）的數(shù)據(jù)序號應(yīng)該從401開始；

確認(rèn)號

??占4個字節(jié)，是期望收到對方下一個報文的第一個數(shù)據(jù)字節(jié)的序號
??例如，B收到了A發(fā)送過來的報文，其序列號字段是501，而數(shù)據(jù)長度是200字節(jié)，這表明B正確的收到了A發(fā)送的到序號700為止的數(shù)據(jù)。因此，B期望收到A的下一個數(shù)據(jù)序號是701，于是B在發(fā)送給A的確認(rèn)報文段中把確認(rèn)號置為701

數(shù)據(jù)偏移

??占4位，它指出TCP報文的數(shù)據(jù)距離TCP報文段的起始處有多遠(yuǎn)

保留

??占6位，保留今后使用，但目前應(yīng)都為0

緊急指針URG

??當(dāng)URG=1，表明緊急指針字段有效。告訴系統(tǒng)此報文段中有緊急數(shù)據(jù)

確認(rèn)ACK

??僅當(dāng)ACK=1時，確認(rèn)號字段才有效。TCP規(guī)定，在連接建立后所有報文的傳輸都必須把ACK置1

推送PSH

??當(dāng)兩個應(yīng)用進程進行交互式通信時，有時在一端的應(yīng)用進程希望在鍵入一個命令后立即就能收到對方的響應(yīng)，這時候就將PSH=1

復(fù)位RST

??當(dāng)RST=1，表明TCP連接中出現(xiàn)嚴(yán)重差錯，必須釋放連接，然后再重新建立連接

同步SYN

??在連接建立時用來同步序號。當(dāng)SYN=1，ACK=0，表明是連接請求報文，若同意連接，則響應(yīng)報文中應(yīng)該使SYN=1，ACK=1

終止FIN

??用來釋放連接。當(dāng)FIN=1，表明此報文的發(fā)送方的數(shù)據(jù)已經(jīng)發(fā)送完畢，并且要求釋放

窗口

??占2字節(jié)，表示現(xiàn)在允許對方發(fā)送的數(shù)據(jù)量，也就是告訴對方，從本報文段的確認(rèn)號開始允許對方發(fā)送的數(shù)據(jù)量，達(dá)到此值，需要ACK確認(rèn)后才能再繼續(xù)傳送后面數(shù)據(jù)

檢驗和

??占2字節(jié)，校驗首部和數(shù)據(jù)這兩部分，提供額外的可靠性

緊急指針

??占2字節(jié)，指出本報文段中的緊急數(shù)據(jù)的字節(jié)數(shù)

選項

??其最大長度可根據(jù)TCP首部長度進行推算。 TCP首部長度用4位表示，選項部分最長為：(2^4-1)*4-20=40字節(jié)

TCP三次握手

最開始的時候 客戶端A 和 服務(wù)器B 都是處于CLOSED狀態(tài)。主動打開連接的為客戶端，被動打開連接的是服務(wù)端

1. TCP服務(wù)器B 進程先創(chuàng)建傳輸控制塊TCB，時刻準(zhǔn)備接受客戶A 進程的連接請求，此時 服務(wù)器B 就進入了LISTEN（收聽）狀態(tài);
2. TCP客戶A 進程也是先創(chuàng)建傳輸控制塊TCB，然后向服務(wù)器B 發(fā)出連接請求報文，這是報文首部中的同部位SYN=1，同時選擇一個初始序列號 seq=x ，此時，TCP客戶端A 進程進入了 SYN-SENT（同步已發(fā)送）狀態(tài)。TCP規(guī)定，SYN報文段（SYN=1的報文段）不能攜帶數(shù)據(jù)，但需要消耗掉一個序號。
3. TCP服務(wù)器B 收到請求報文后，如果同意連接，則發(fā)出確認(rèn)報文。確認(rèn)報文中應(yīng)該 ACK=1，SYN=1，確認(rèn)號是ack=x+1，同時也要為自己初始化一個序列號 seq=y，此時，TCP服務(wù)器B 進程進入了SYN-RCVD（同步收到）狀態(tài)。這個報文也不能攜帶數(shù)據(jù)，但是同樣要消耗一個序號。
4. TCP客戶A 進程收到確認(rèn)后，還要向服務(wù)器B 給出確認(rèn)。確認(rèn)報文的ACK=1，ack=y+1，自己的序列號seq=x+1，此時，TCP連接建立，客戶端A 進入ESTABLISHED（已建立連接）狀態(tài)。
5. 當(dāng)服務(wù)器B 收到客戶端A 的確認(rèn)后也進入ESTABLISHED（已建立連接）狀態(tài)，此后雙方就可以開始通信了。

為什么TCP客戶端A最后還要發(fā)送一次確認(rèn)呢？

??主要是防止已經(jīng)失效的鏈接請求報文突然又傳送到了服務(wù)器B，從而產(chǎn)生錯誤。

為什么要三次握手，而不是兩次握手呢？

??如果使用兩次握手建立連接，客戶端A 發(fā)送了第一個請求連接并且沒有丟失，只是因為在網(wǎng)絡(luò)結(jié)點中滯留時間過長，由于TCP的客戶端A 此次沒有收到確認(rèn)的報文，以為服務(wù)器B 沒有收到，此時重新向服務(wù)器B 發(fā)送這條報文，此后客戶端A 和服務(wù)器B 經(jīng)過兩次握手完成了連接欸，傳輸數(shù)據(jù)，然后關(guān)閉連接。此時此前滯留的那一次請求連接，網(wǎng)絡(luò)通暢了到達(dá)了服務(wù)器B ，這個報文本該是失效的，但是，兩次握手的機制將會讓客戶端A 和服務(wù)器B 再次建立連接，這將導(dǎo)致不必要的錯誤和資源的浪費。
??如果采用的是三次握手，就算是那一次失效的報文傳送過來了，服務(wù)端B 接受到了那條失效報文并且回復(fù)了確認(rèn)報文，但是客戶端A 不會再次發(fā)出確認(rèn)。由于服務(wù)器B 收不到確認(rèn)，就知道客戶端A 并沒有請求連接。

TCP四次握手

數(shù)據(jù)傳輸完畢后，雙方都可釋放連接。最開始的時候，客戶端A 和服務(wù)器B 都是處于ESTABLISHED（建立）狀態(tài)，然后客戶端A 主動關(guān)閉，服務(wù)器B 被動關(guān)閉

1. 客戶端A 進程發(fā)出連接釋放報文，并且停止發(fā)送數(shù)據(jù)。釋放數(shù)據(jù)報文首部，F(xiàn)IN=1，其序列號為seq=u（等于前面已經(jīng)傳送過來的數(shù)據(jù)的最后一個字節(jié)的序號加1），此時，客戶端A 進入FIN-WAIT-1（終止等待1）狀態(tài)。 TCP規(guī)定，F(xiàn)IN報文段即使不攜帶數(shù)據(jù)，也要消耗一個序號。
2. 服務(wù)器B 收到連接釋放報文，發(fā)出確認(rèn)報文，ACK=1，ack=u+1，并且?guī)献约旱男蛄刑杝eq=v，此時，服務(wù)端B 就進入了CLOSE-WAIT（關(guān)閉等待）狀態(tài)。TCP服務(wù)器B 通知高層的應(yīng)用進程，客戶端A 向服務(wù)器B 的方向就釋放了，這時候處于半關(guān)閉狀態(tài)，即客戶端A 已經(jīng)沒有數(shù)據(jù)要發(fā)送了，但是服務(wù)器B 若發(fā)送數(shù)據(jù)，客戶端A 依然要接受。這個狀態(tài)還要持續(xù)一段時間，也就是整個CLOSE-WAIT狀態(tài)持續(xù)的時間。
3. 客戶端A 收到服務(wù)器B 的確認(rèn)請求后，此時，客戶端A 就進入FIN-WAIT-2（終止等待2）狀態(tài)，等待服務(wù)器B 發(fā)送連接釋放報文（在這之前還需要接受服務(wù)器B 發(fā)送的最后的數(shù)據(jù)）。
4. 服務(wù)器B 將最后的數(shù)據(jù)發(fā)送完畢后，就向客戶端A 發(fā)送連接釋放報文，F(xiàn)IN=1，ack=u+1，由于在半關(guān)閉狀態(tài)，服務(wù)器B 很可能又發(fā)送了一些數(shù)據(jù)，假定此時的序列號為seq=w，此時，服務(wù)器B 就進入了LAST-ACK（最后確認(rèn)）狀態(tài)，等待客戶端A 的確認(rèn)。
5. 客戶端A 收到服務(wù)器B 的連接釋放報文后，必須發(fā)出確認(rèn)，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端A 就進入了TIME-WAIT（時間等待）狀態(tài)。注意此時TCP連接還沒有釋放，必須經(jīng)過2? *?MSL（最長報文段壽命）的時間后，當(dāng)客戶端A 撤銷相應(yīng)的TCB后，才進入CLOSED狀態(tài)。
6. 服務(wù)器B 只要收到了客戶端A 發(fā)出的確認(rèn)，立即進入CLOSED狀態(tài)。同樣，撤銷TCB后，就結(jié)束了這次的TCP連接。可以看到，服務(wù)器B 結(jié)束TCP連接的時間要比客戶端A 早一些。

為什么客戶端A最后還要等待2MSL呢？

1. 保證客戶端A 發(fā)送的最后一個ACK報文能夠到達(dá)服務(wù)器B，因為這個ACK報文可能丟失，站在服務(wù)器B 的角度看來，我已經(jīng)發(fā)送了FIN+ACK報文請求斷開了，客戶端A 還沒有給我回應(yīng)，應(yīng)該是我發(fā)送的請求斷開報文它沒有收到，于是服務(wù)器B 又會重新發(fā)送一次，而客戶端A 就能在這個2MSL時間段內(nèi)收到這個重傳的報文，接著給出回應(yīng)報文，并且會重啟2MSL計時器。
2. 防止類似與“三次握手”中提到了的“已經(jīng)失效的連接請求報文段”出現(xiàn)在本連接中?？蛻舳薃 發(fā)送完最后一個確認(rèn)報文后，在這個2MSL時間中，就可以使本連接持續(xù)的時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡(luò)中消失。這樣新的連接中不會出現(xiàn)舊連接的請求報文。

為什么建立連接是三次握手，關(guān)閉連接確是四次揮手呢？

??建立連接的時候， 服務(wù)器B 在LISTEN狀態(tài)下，收到建立連接請求的SYN報文后，把ACK和SYN放在一個報文里發(fā)送給客戶端A。
??而關(guān)閉連接時，服務(wù)器B 收到對方的FIN報文時，僅僅表示對方不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)，而自己也未必全部數(shù)據(jù)都發(fā)送給對方了，所以己方可以立即關(guān)閉，也可以發(fā)送一些數(shù)據(jù)給對方后，再發(fā)送FIN報文給對方來表示同意現(xiàn)在關(guān)閉連接，因此，己方ACK和FIN一般都會分開發(fā)送，從而導(dǎo)致多了一次。