python_面試題_TCP的三次握手與四次揮手問題

1.相關問題

問題1: 請詳細描述三次握手和四次揮手的過程，並畫出狀態圖

問題2: 四次揮手中TIME_WAIT狀態存在的目的是什麼?

問題3: TCP是經過什麼機制保障可靠性的?

 

2.問題回答

問題1：

狀態圖以下

補充知識：TCP報文中共計6個標誌位，每一個標誌位佔1個字節，即URG、ACK、PSH、RST、SYN、FIN等

• URG：緊急指針（urgent pointer）有效。
• ACK：確認序號有效。
• PSH：接收方應該儘快將這個報文交給應用層。
• RST：重置鏈接。
• SYN：發起一個新鏈接。
• FIN：釋放一個鏈接。

三次握手詳情

1. 第一次握手：Client將標誌位SYN置爲1，隨機產生一個值seq=a，並將該數據包發送給Server，Client進入SYN_SENT狀態，等待Server確認。
2. 第二次握手：Server收到數據包後由標誌位SYN=1知道Client請求創建鏈接，Server將標誌位SYN和ACK都置爲1，ack=a+1，隨機產生一個值seq=b，並將該數據包發送給Client以確認鏈接請求，Server進入SYN_RCVD狀態。
3. 第三次握手：Client收到確認後，檢查ack是否爲a+1，ACK是否爲1，若是正確則將標誌位ACK置爲1，ack=b+1，並將該數據包發送給Server，Server檢查ack是否爲b+1，ACK是否爲1，若是正確則鏈接創建成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間能夠開始傳輸數據了。

四次揮手詳情（被動關閉）

1. 第一次揮手：Client發送一個FIN，隨機產生一個值seq=a，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。
2. 第二次揮手：Server收到FIN後，發送一個ACK給Client，ack=a+1，Server進入CLOSE_WAIT狀態。
3. 第三次揮手：Server發送一個FIN，隨機產生一個值seq=b,用來關閉Server到Client的數據傳送，同時發送ACK標誌位，ack=a+1,Server進入LAST_ACK狀態。
4. 第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接着發送一個ACK給Server，ack=b+1，Server進入CLOSED狀態，完成四次揮手。

補充1：

　　SYN攻擊：在三次握手過程當中，Server發送SYN-ACK以後，收到Client的ACK以前的TCP鏈接稱爲半鏈接（half-open connect），此時Server處於SYN_RCVD狀態，當收到ACK後，Server轉入ESTABLISHED狀態。SYN攻擊就是Client在短期內僞造大量不存在的IP地址，並向Server不斷地發送SYN包，Server回覆確認包，並等待Client的確認，因爲源地址是不存在的，所以，Server須要不斷重發直至超時，這些僞造的SYN包將產時間佔用未鏈接隊列，致使正常的SYN請求由於隊列滿而被丟棄，從而引發網絡堵塞甚至系統癱瘓。SYN攻擊時一種典型的DDOS攻擊，檢測SYN攻擊的方式很是簡單，即當Server上有大量半鏈接狀態且源IP地址是隨機的，則能夠判定遭到SYN攻擊了，使用以下命令可讓之現行：
#netstat -nap | grep SYN_RECV

補充2：

　　四次揮手的同時關閉情況：實際中還會出現同時發起主動關閉的狀況，具體流程以下圖

 

問題2：

在四次揮手中，第三次揮手結束後，Client端進入TIME_WAIT狀態，客戶端不會立刻進入closed狀態，理由以下

1. 等待2MSL時間段，確保Client端發送的FIN報文，Server端能夠接收，若是Server端沒有收到第四次揮手，則會對Client端重發第三次揮手，確保Client能夠正確關閉，若是沒有進入TIME_WAIT狀態，則Client端就沒法接收Server端的發來的報文。簡略：確保客戶端正確關閉。
2. 一個鏈接結束，網絡內路由或者是網絡包還會繼續保留一段時間，在tcp鏈接結束後，在舊TCP鏈接對應的網絡包消失以前，才容許創建新的TCP鏈接。簡略：在新的TCP創建以前，確保舊的TCP連接對應的網絡包正確的結束。

 

問題3：

TCP傳輸的可靠性主要靠如下手段來保證傳輸

1. ACK確認機制：簡單的說就是發送隨機生成一個數字，接收端在確認收到數據，提取隨機數並加1，返回發送端，告知確認收到數據包，同時也保證數據接收的惟一性
2. 超時重傳：發送方在必定時間內未收到對方的回傳的ack確認碼，則將數據從新發送，保證數據傳輸的一致性
3. 滑動窗口：看補充
4. 流量控制：看補充

建議：滑動窗口與流量控制視狀況是否說明

補充：滑動窗口與流量控制

1）.滑動窗口：

「窗口」對應的是一段能夠被髮送者發送的字節序列，其連續的範圍稱之爲「窗口」；

「滑動」則是指這段「容許發送的範圍」是能夠隨着發送的過程而變化的，方式就是按順序「滑動」。

1. TCP協議的兩端分別爲發送者A和接收者B，因爲是全雙工協議，所以A和B應該分別維護着一個獨立的發送緩衝區和接收緩衝區，因爲對等性（A發B收和B發A收），咱們以A發送B接收的狀況做爲例子；
2. 發送窗口是發送緩存中的一部分，是能夠被TCP協議發送的那部分，其實應用層須要發送的全部數據都被放進了發送者的發送緩衝區；
3. 發送窗口中相關的有四個概念：已發送並收到確認的數據（再也不發送窗口和發送緩衝區以內）、已發送但未收到確認的數據（位於發送窗口之中）、容許發送但還沒有發送的數據以及發送窗口外發送緩衝區內暫時不容許發送的數據；
4. 每次成功發送數據以後，發送窗口就會在發送緩衝區中按順序移動，將新的數據包含到窗口中準備發送；

案例以下：

     TCP創建鏈接的初始，B會告訴A本身的接收窗口大小，好比爲‘20’：
     字節31-50爲發送窗口

     A發送11個字節後，發送窗口位置不變，B接收到了亂序的數據分組：

     只有當A成功發送了數據，即發送的數據獲得了B的確認以後，纔會移動滑動窗口離開已發送的數據；同時B則確認連續的數據分組，對於亂序的分組則先接收下來，避免網絡重複傳遞：

2）.流量控制

     流量控制方面主要有兩個要點須要掌握。一是TCP利用滑動窗口實現流量控制的機制；二是如何考慮流量控制中的傳輸效率。
1. 流量控制
     所謂流量控制，主要是接收方傳遞信息給發送方，使其不要發送數據太快，是一種端到端的控制。主要的方式就是返回的ACK中會包含本身的接收窗口的大小，而且利用大小來控制發送方的數據發送，案例如圖：

     這裏面涉及到一種狀況，若是B已經告訴A本身的緩衝區已滿，因而A中止發送數據；等待一段時間後，B的緩衝區出現了富餘，因而給A發送報文告訴A個人rwnd大小爲400，可是這個報文不幸丟失了，因而就出現A等待B的通知||B等待A發送數據的死鎖狀態。爲了處理這種問題，TCP引入了持續計時器（Persistence timer），當A收到對方的零窗口通知時，就啓用該計時器，時間到則發送一個1字節的探測報文，對方會在此時迴應自身的接收窗口大小，若是結果仍未0，則重設持續計時器，繼續等待。
2. 傳遞效率
     一個顯而易見的問題是：單個發送字節單個確認，和窗口有一個空餘即通知發送方發送一個字節，無疑增長了網絡中的許多沒必要要的報文（請想一想爲了一個字節數據而添加的40字節頭部吧！），因此咱們的原則是儘量一次多發送幾個字節，或者窗口空餘較多的時候通知發送方一次發送多個字節。對於前者咱們普遍使用Nagle算法，即：

• 若發送應用進程要把發送的數據逐個字節地送到TCP的發送緩存，則發送方就把第一個數據字節先發送出去，把後面的字節先緩存起來；
• 當發送方收到第一個字節的確認後（也獲得了網絡狀況和對方的接收窗口大小），再把緩衝區的剩餘字節組成合適大小的報文發送出去；
• 當到達的數據已達到發送窗口大小的一半或以達到報文段的最大長度時，就當即發送一個報文段；

     對於後者咱們每每的作法是讓接收方等待一段時間，或者接收方得到足夠的空間容納一個報文段或者等到接受緩存有一半空閒的時候，再通知發送方發送數據。

ok