面試官竟然把TCP三次握手、四次揮手問的這麼詳細?

2022.09.01
面試官竟然把TCP三次握手、四次揮手問的這麼詳細?
本文會圍繞,從三次握手和四次揮手相關的一系列核心問題,分享如何更準確回答和應對常見的面試問題,以後面對再刁鑽的面試官,你都可以隨意地跟他扯皮了。

TCP的定義

TCP全稱為Transmission Control Protocol(傳輸控制協議),是一種面向連接的、可靠的、基於字節流的傳輸層通信協議。TCP是為了在不可靠的互聯網絡上提供可靠的端到端字節流而專門設計的一個傳輸協議。

TCP的三次握手和四次揮手,可以說是老生常談的經典問題了,通常也作為各大公司常見的面試考題,具有一定的水平區分度。看似簡單的面試問題。如果你的回答不符合面試官期待的水準,有可能就直接涼涼了。

本文會圍繞,從三次握手和四次揮手相關的一系列核心問題,分享如何更準確回答和應對常見的面試問題,以後面對再刁鑽的面試官,你都可以隨意地跟他扯皮了

優雅回答三次握手

三次握手: 服務端新建套接字,綁定地址信息後開始監聽,進入LISTEN狀態。客戶端新建套接字綁定地址信息後調用connect,發送連接請求SYN,並進入SYN_SENT狀態,等待服務器的確認。服務端一旦監聽到連接請求,就會將連接放入內核等待隊列中,並向客戶端發送SYN和確認報文段ACK,進入SYN_RECD狀態。客戶端收到SYN+ACK報文後向服務端發送確認報文段ACK,並進入ESTABLISHED狀態,開始讀寫數據。服務端一旦收到客戶端的確認報文,就進入ESTABLISHED狀態,就可以進行讀寫數據了

圖片

1. 為什麼握手是三次,而不是兩次或者四次?

答:兩次不安全,四次沒必要。tcp通信需要確保雙方都具有數據收發的能力,得到ACK響應則認為對方具有數據收發的能力,因此雙方都要發送SYN確保對方具有通信的能力。

  • 第一次握手是客戶端發送SYN,服務端接收,服務端得出客戶端的發送能力和服務端的接收能力都正常;
  • 第二次握手是服務端發送SYN+ACK,客戶端接收,客戶端得出客戶端發送接收能力正常,服務端發送接收能力也都正常,但是此時服務器並不能確認客戶端的接收能力是否正常;
  • 第三次握手客戶端發送ACK,服務器接收,服務端才能得出客戶端發送接收能力正常,服務端自己發送接收能力也都正常。

2. 三次握手可以攜帶數據嗎?

答:第一次、第二次握手不可以攜帶數據,而第三次握手是可以攜帶數據的。假設第一次可以攜帶數據,如果有人惡意攻擊服務器,每次都在第一次握手中的SYN報文放入大量數據,重複發送大量SYN報文,此時服務器會花費大量內存空間來緩衝這些報文,服務器就更容易被攻擊了。

3. TCP三次握手失敗,服務端會如何處理?

答:握手失敗的原因有兩種,第一種是服務端沒有收到SYN,則什麼都不做;第二種是服務端回復了SYN+ACK後,長時間沒有收到ACK響應,則超時後就會發送RST重置連接報文,釋放資源

4. ISN代表什麼?意義何在?ISN是固定不變的嗎?ISN為何要動態隨機

答:ISN全稱是Initial Sequence Number,是TCP發送方的字節數據編號的原點,告訴對方我要開始發送數據的初始化序列號。

ISN如果是固定的,攻擊者很容易猜出後序的確認號,為了安全起見,避免被第三方猜到從而發送偽造的RST報文,因此ISN是動態生成的。

5. 什麼是半連接隊列

答:服務器第一次收到客戶端的SYN之後,就會處於SYN_RECD狀態,此時雙方還沒有完全建立連接。服務器會把這種狀態下的請求連接放在一個隊列裡,我們把這種隊列稱之為半連接隊列。當然還有一個全連接隊列,就是已經完成三次握手,建立起來連接的就會放在全連接隊列中,如果隊列滿了就有可能出現丟包現象。

優雅回答四次揮手

四次揮手:

  • 客戶端主動調用close時,向服務端發送結束報文段FIN報,同時進入FIN_WAIT1狀態;
  • 服務器會收到結束報文段FIN報,服務器返回確認報文段ACK並進入CLOSE_WAIT狀態,此時如果服務端有數據要發送的話,客戶端依然需要接收。客戶端收到服務器對結束報文段的確認,就會進入到FIN_WAIT2狀態,開始等待服務器的結束報文段;
  • 服務器端數據發送完畢後,當服務器真正調用close關閉連接時,會向客戶端發送結束報文段FIN包,此時服務器進入LAST_ACK狀態,等待最後一個ACK的帶來;
  • 客戶端收到服務器發來的結束報文段, 進入TIME_WAIT, 並發出送確認報文段ACK;服務器收到了對結束報文段確認的ACK,進入CLOSED狀態,斷開連接。而客戶端要等待2MSL的時間,才會進入到CLOSED狀態。

圖片

6. 為什麼握手是三次,而揮手時需要四次呢?

答:其實在TCP握手的時候,接收端將SYN包和ACK確認包合併到一個包中發送的,所以減少了一次包的發送。對於四次揮手,由於TCP是全雙工通信,主動關閉方發送FIN請求不代表完全斷開連接,只能表示主動關閉方不再發送數據了。

而接收方可能還要發送數據,就不能立即關閉服務器端到客戶端的數據通道,所以就不能將服務端的FIN包和對客戶端的ACK包合併發送,只能先確認ACK,等服務器無需發送數據時在發送FIN包,所以四次揮手時需要四次數據包的交互

7. TIME_WAIT狀態有什麼作用,為什麼主動關閉方沒有直接進入CLOSED狀態釋放資源?

答:如果主動關閉方進入CLOSED狀態後,被動關閉方發送FIN包後沒有得到ACK確認,超時後就會重傳一個FIN包。如果客戶端沒有TIME_WAIT狀態而直接進入CLOSED狀態釋放資源,下次啟動新的客戶端就可能使用了與之前客戶端相同的地址信息,有兩個危害:

  • 第一種是這個剛啟動的新的客戶端綁定地址成功時,就會收到了一個重傳的FIN包,對新連接就會造成影響。
  • 第二種是如果該新客戶端向相同的服務端發送SYN連接請求,但是此時服務端處於LAST_ACK狀態,要求收到的是ACK而不是SYN,因此就會發送RST重新建立請求。

8. 為什麼TIME_WAIT狀態需要經過2MSL才能進入CLOASE狀態?

答:MSL指的是報文在網絡中最大生存時間。在客戶端發送對服務端的FIN確認包ACK後,這個ACK包有可能到達不了,服務器端如果接收不到ACK包就會重新發送FIN包。

所以客戶端發送ACK後需要留出2MSL時間(ACK到達服務器器+服務器發送FIN重傳包,一來一回)等待確認服務器端缺失收到了ACK包。也就是說客戶端如果等待2MSL時間也沒收到服務器端重傳的FIN包,則就可以確認服務器已經收到客戶端發送的ACK包。

9. 一台主機上出現大量的TIME_WAIT是什麼原因?應該如何處理?

答:TIME_WAIT是主動關閉方出現的,一台主機出現大量的TIME_WAIT證明這台主機上發起大量的主動關閉連接。常見於一些爬蟲服務器。這時候我們應該調整TIME_WAIT的等待時間,或者開啟套接字地址重用選項

10. 一台主機上出現大量的CLOSE_WAIT是什麼原因?應該如何處理?

答:CLOSE_WAIT是被動關閉方收到FIN請求進行回復之後的狀態,等待上層程序進一步處理,若出現大量CLOSE_WAIT,有可能是被動關閉方主機程序中忘了最後一步斷開連接後調用close釋放資源。這是一個BUG.,只需要加上對應的close 即可解決問題

11. TCP連接管理中的保活機制

答:TCP通信中,若兩端長時間沒有數據往來,則這時候每隔一段時間,服務端會向客戶端發送一個保活探測數據報,要求客戶端進行回复。若連續多次沒有收到響應,就認為連接已經斷開。長時間默認為7200s,每隔一段時間默認為75s,連續多次無響應默認為9次。這些數據都可以在套接字中修改,接口:Setsockopt。