tcp 三次握手，四次揮手幾常見面試題

 

TCP報文首部

 

1. 源端口和目的端口，各占2個字節，分別寫入源端口和目的端口；
2. 序號，占4個字節，TCP連接中傳送的字節流中的每個字節都按順序編號。例如，一段報文的序號字段值是 301 ，而攜帶的數據共有100字段，顯然下一個報文段（如果還有的話）的數據序號應該從401開始；
3. 確認號，占4個字節，是期望收到對方下一個報文的第一個數據字節的序號。例如，B收到了A發送過來的報文，其序列號字段是501，而數據長度是200字節，這表明B正確的收到了A發送的到序號700為止的數據。因此，B期望收到A的下一個數據序號是701，於是B在發送給A的確認報文段中把確認號置為701；
4. 數據偏移，占4位，它指出TCP報文的數據距離TCP報文段的起始處有多遠；
5. 保留，占6位，保留今后使用，但目前應都位0；
6. 緊急URG，當URG=1，表明緊急指針字段有效。告訴系統此報文段中有緊急數據；
7. 確認ACK，僅當ACK=1時，確認號字段才有效。TCP規定，在連接建立后所有報文的傳輸都必須把ACK置1；
8. 推送PSH，當兩個應用進程進行交互式通信時，有時在一端的應用進程希望在鍵入一個命令后立即就能收到對方的響應，這時候就將PSH=1；
9. 復位RST，當RST=1，表明TCP連接中出現嚴重差錯，必須釋放連接，然后再重新建立連接；
10. 同步SYN，在連接建立時用來同步序號。當SYN=1，ACK=0，表明是連接請求報文，若同意連接，則響應報文中應該使SYN=1，ACK=1；
11. 終止FIN，用來釋放連接。當FIN=1，表明此報文的發送方的數據已經發送完畢，並且要求釋放；
12. 窗口，占2字節，指的是通知接收方，發送本報文你需要有多大的空間來接受；
13. 檢驗和，占2字節，校驗首部和數據這兩部分；
14. 緊急指針，占2字節，指出本報文段中的緊急數據的字節數；
15. 選項，長度可變，定義一些其他的可選的參數

TCP連接的建立（三次握手）

最開始的時候客戶端和服務器都是處於CLOSED狀態。主動打開連接的為客戶端，被動打開連接的是服務器。

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

    

 

TCP連接的釋放（四次揮手）

數據傳輸完畢后，雙方都可釋放連接。最開始的時候，客戶端和服務器都是處於ESTABLISHED狀態，然后客戶端主動關閉，服務器被動關閉。

1. 客戶端進程發出連接釋放報文，並且停止發送數據。釋放數據報文首部，FIN=1，其序列號為seq=u（等於前面已經傳送過來的數據的最后一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即使不攜帶數據，也要消耗一個序號。
2. 服務器收到連接釋放報文，發出確認報文，ACK=1，ack=u+1，並且帶上自己的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，但是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。
3. 客戶端收到服務器的確認請求后，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送連接釋放報文（在這之前還需要接受服務器發送的最后的數據）。
4. 服務器將最后的數據發送完畢后，就向客戶端發送連接釋放報文，FIN=1，ack=u+1，由於在半關閉狀態，服務器很可能又發送了一些數據，假定此時的序列號為seq=w，此時，服務器就進入了LAST-ACK（最后確認）狀態，等待客戶端的確認。
5. 客戶端收到服務器的連接釋放報文后，必須發出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP連接還沒有釋放，必須經過2∗

5. MSL（最長報文段壽命）的時間后，當客戶端撤銷相應的TCB后，才進入CLOSED狀態。
6. 服務器只要收到了客戶端發出的確認，立即進入CLOSED狀態。同樣，撤銷TCB后，就結束了這次的TCP連接。可以看到，服務器結束TCP連接的時間要比客戶端早一些。

 

 

 1.為什么需要三次握手，兩次不可以嗎？或者四次、五次可以嗎？
我們來分析一種特殊情況，假設客戶端請求建立連接，發給服務器SYN包等待服務器確認，服務器收到確認后，如果是兩次握手，假設服務器給客戶端在第二次握手時發送數據，數據從服務器發出，服務器認為連接已經建立，但在發送數據的過程中數據丟失，客戶端認為連接沒有建立，會進行重傳。假設每次發送的數據一直在丟失，客戶端一直SYN，服務器就會產生多個無效連接，占用資源，這個時候服務器可能會掛掉。這個現象就是我們聽過的“SYN的洪水攻擊”。
總結：第三次握手是為了防止：如果客戶端遲遲沒有收到服務器返回確認報文，這時會放棄連接，重新啟動一條連接請求，但問題是：服務器不知道客戶端沒有收到，所以他會收到兩個連接，浪費連接開銷。如果每次都是這樣，就會浪費多個連接開銷。

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

MSL（Maximum Segment Lifetime），TCP允許不同的實現可以設置不同的MSL值。

第一，保證客戶端發送的最后一個ACK報文能夠到達服務器，因為這個ACK報文可能丟失，站在服務器的角度看來，我已經發送了FIN+ACK報文請求斷開了，客戶端還沒有給我回應，應該是我發送的請求斷開報文它沒有收到，於是服務器又會重新發送一次，而客戶端就能在這個2MSL時間段內收到這個重傳的報文，接着給出回應報文，並且會重啟2MSL計時器。

第二，防止類似與“三次握手”中提到了的“已經失效的連接請求報文段”出現在本連接中。客戶端發送完最后一個確認報文后，在這個2MSL時間中，就可以使本連接持續的時間內所產生的所有報文段都從網絡中消失。這樣新的連接中不會出現舊連接的請求報文。

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

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

 

3，如果已經建立了連接，但是客戶端突然出現故障了怎么辦？

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

4，為什么要三次握手

保證可靠的核心就是雙方都需要確認自己發送和接受信息的功能正常,但因為網絡環境的不穩定性,這一秒能收發下一秒可能網絡核心就發生嚴重擁塞,所以世界上不存在完全可靠的通信協議.
兩次握手會怎樣?
若建立連接只需兩次握手，客戶端並沒有太大的變化，在獲得服務端的應答后進入ESTABLISHED狀態，即確認自己的發送和接受信息的功能正常.
但如果服務端在收到連接請求后就進入ESTABLISHED狀態,不能保證客戶端能收到自己的信息,此時如果網絡擁塞，客戶端發送的連接請求遲遲到不了服務端，客戶端便超時重發請求，如果服務端正確接收並確認應答，雙方便開始通信，通信結束后釋放連接。
此時，如果那個失效的連接請求抵達了服務端，由於只有兩次握手，服務端收到請求就會進入ESTABLISHED狀態，等待發送數據或主動發送數據。但此時的客戶端早已進入CLOSED狀態，服務端將會一直等待下去，這樣浪費服務端連接資源.

5，為什么要四次揮手

TCP連接的釋放一共需要四步,因此稱為『四次揮手』.我們知道,TCP連接是雙向的,因此在四次揮手中,前兩次揮手用於斷開一個方向的連接，后兩次揮手用於斷開另一方向的連接.
第一次揮手:
若A認為數據發送完成,則它需要向B發送連接釋放請求.該請求只有報文頭,頭中攜帶的主要參數為:FIN=1,seq=u.此時,A將進入FIN-WAIT-1狀態.

1，FIN=1表示該報文段是一個連接釋放請求. 2，seq=u,u-1是A向B發送的最后一個字節的序號.

 

第二次揮手:
B收到連接釋放請求后,會通知相應的應用程序,告訴它A向B這個方向的連接已經釋放.此時B進入CLOSE-WAIT狀態,並向A發送連接釋放的應答,其報文頭包含: ACK=1,seq=v,ack=u+1.
ACK=1：除TCP連接請求報文段以外,TCP通信過程中所有數據報的ACK都為1，表示應答.

1，seq=v，v-1是B向A發送的最后一個字節的序號. 2，ack=u+1表示希望收到從第u+1個字節開始的報文段,並且已經成功接收了前u個字節.A收到該應答,進入FIN-WAIT-2狀態,等待B發送連接釋放請求.

第二次揮手完成后，A到B方向的連接已經釋放，B不會再接收數據，A也不會再發送數據。但B到A方向的連接仍然存在，B可以繼續向A發送數據。

第三次揮手:
當B向A發完所有數據后,向A發送連接釋放請求,請求頭中包含:
FIN=1,ACK=1,seq=w,ack=u+1.隨后B進入LAST-ACK狀態.

第四次揮手:
A收到釋放請求后,向B發送確認應答,此時A進入TIME-WAIT狀態.該狀態會持續2MSL時間,若該時間段內沒有B的重發請求的話,就進入CLOSED狀態,撤銷TCB.當B收到確認應答后,也便進入CLOSED狀態,撤銷TCB.

6，為什么TCP客戶端最后還要發送一次確認呢？

一句話，主要防止已經失效的連接請求報文突然又傳送到了服務器，從而產生錯誤。

如果使用的是兩次握手建立連接，假設有這樣一種場景，客戶端發送了第一個請求連接並且沒有丟失，只是因為在網絡結點中滯留的時間太長了，由於TCP的客戶端遲遲沒有收到確認報文，以為服務器沒有收到，此時重新向服務器發送這條報文，此后客戶端和服務器經過兩次握手完成連接，傳輸數據，然后關閉連接。此時此前滯留的那一次請求連接，網絡通暢了到達了服務器，這個報文本該是失效的，但是，兩次握手的機制將會讓客戶端和服務器再次建立連接，這將導致不必要的錯誤和資源的浪費。

如果采用的是三次握手，就算是那一次失效的報文傳送過來了，服務端接受到了那條失效報文並且回復了確認報文，但是客戶端不會再次發出確認。由於服務器收不到確認，就知道客戶端並沒有請求連接。