一、TCP協(xié)議簡介

一般問到TCP協(xié)議的時(shí)候 最常見的是TCP連接建立和斷開的過程，也就是三次握手和四次揮手，兩張圖足矣。

1.1 三次握手

1.2 四次揮手

二、常見面試題

2.1 TCP連接階段

2.1.1 發(fā)送序號和確認(rèn)序號問題

例： TCP建立連接的過程采用三次握手，已知第三次握手報(bào)文的發(fā)送序列號為1000，確認(rèn)序列號為2000，請問第二次握手報(bào)文的發(fā)送序列號和確認(rèn)序列號分別為？
答：看答案時(shí)請參考上面TCP連接建立的圖。
客戶端：發(fā)送X
服務(wù)端：發(fā)送Y， 確認(rèn)X+1
客戶端：發(fā)送X+1（1000），確認(rèn)Y+1（2000）
可以反推第二次為1999,確認(rèn)1000

2.1.2 SYN Flood 攻擊原理及防御

SYN Flood是當(dāng)前最流行的DoS（拒絕服務(wù)攻擊）與DDoS（分布式拒絕服務(wù)攻擊）的方式之一，這是一種利用TCP協(xié)議缺陷，發(fā)送大量偽造的TCP連接請求，從而使得被攻擊方資源耗盡（CPU滿負(fù)荷或內(nèi)存不足）的攻擊方式。

原理：
問題出在TCP連接的三次握手中，惡意的攻擊者大量發(fā)送SYN報(bào)文，服務(wù)器端將為了維護(hù)一個非常大的半連接列表而消耗非常多的資源----數(shù)以萬計(jì)的半連接，即使是簡單的保存并遍歷也會消耗非常多的CPU時(shí)間和內(nèi)存，何況還要不斷對這個列表中的IP進(jìn)行SYN+ACK的重試。實(shí)際上如果服務(wù)器的TCP/IP棧不夠強(qiáng)大，最后的結(jié)果往往是堆棧溢出崩潰---即使服務(wù)器端的系統(tǒng)足夠強(qiáng)大，服務(wù)器端也將忙于處理攻擊者偽造的TCP連接請求而無暇理睬客戶的正常請求（畢竟客戶端的正常請求比率非常之小），此時(shí)從正常客戶的角度看來，服務(wù)器失去響應(yīng)，這種情況我們稱作：服務(wù)器端受到了SYN Flood攻擊（SYN洪水攻擊）。
攻擊方式：

Direct Attack 攻擊方使用固定的源地址發(fā)起攻擊，這種方法對攻擊方的消耗最小

Spoofing Attack 攻擊方使用變化的源地址發(fā)起攻擊，這種方法需要攻擊方不停地修改源地址，實(shí)際上消耗也不大

Distributed Direct Attack 這種攻擊主要是使用僵尸網(wǎng)絡(luò)進(jìn)行固定源地址的攻擊

防御方法：

無效連接監(jiān)視釋放
不停監(jiān)視系統(tǒng)的半開連接和不活動連接，當(dāng)達(dá)到一定閾值時(shí)拆除這些連接，從而釋放系統(tǒng)資源。

延緩TCB分配方法
從前面SYN Flood原理可以看到，消耗服務(wù)器資源主要是因?yàn)楫?dāng)SYN數(shù)據(jù)報(bào)文一到達(dá)，系統(tǒng)立即分配TCB，從而占用了資源。而SYN Flood由于很難建立起正常連接，因此，當(dāng)正常連接建立起來后再分配TCB則可以有效地減輕服務(wù)器資源的消耗。常見的方法是使用Syn Cache和Syn Cookie技術(shù)。
Syn Cache技術(shù)：
這種技術(shù)是在收到SYN數(shù)據(jù)報(bào)文時(shí)不急于去分配TCB，而是先回應(yīng)一個SYN ACK報(bào)文，并在一個專用HASH表（Cache）中保存這種半開連接信息，直到收到正確的回應(yīng)ACK報(bào)文再分配TCB。
Syn Cookie技術(shù)：
Syn Cookie技術(shù)則完全不使用任何存儲資源，它使用一種特殊的算法生成Sequence Number，這種算法考慮到了對方的IP、端口、己方IP、端口的固定信息，以及對方無法知道而己方比較固定的一些信息，如MSS、時(shí)間等，在收到對方的ACK報(bào)文后，重新計(jì)算一遍，看其是否與對方回應(yīng)報(bào)文中的（Sequence Number-1）相同，從而決定是否分配TCB資源。

使用SYN Proxy防火墻
防火墻中提供一種SYN代理的功能，主要原理是對試圖穿越的SYN請求進(jìn)行驗(yàn)證后才放行。

2.1.3 為什么TCP建立連接要三次握手

首先得回答三次握手的目的是同步連接雙方的序列號和確認(rèn)號并交換 TCP 窗口大小信息。
然后可以回答為什么兩次握手不行，兩次握手可能因?yàn)閬G包而出現(xiàn)死鎖，假設(shè)在兩次握手場景中，C向S發(fā)送請求，S收到并發(fā)送確認(rèn)請求給C，這時(shí)候S認(rèn)為連接已經(jīng)建立，并開始發(fā)送數(shù)據(jù)給C，但是那個確認(rèn)請求丟包了，C不認(rèn)為請求建立了，C當(dāng)然會拒絕接受S發(fā)送來的數(shù)據(jù)，并且再去請求連接。這樣，一個資源就死鎖了。
最后回答握手當(dāng)然可以四次五次一直握下去，但三次已經(jīng)夠了，就沒有必要了。
總結(jié)下來一句話，主要目的防止在網(wǎng)絡(luò)發(fā)生延遲或者丟包的情況下浪費(fèi)資源。

詳情請移步?TCP為什么要三次握手，不是兩次四次

2.2 TCP傳輸階段

2.2.1 滑動窗口以及擁塞控制

TCP協(xié)議作為一個可靠的面向流的傳輸協(xié)議，其可靠性和流量控制由滑動窗口協(xié)議保證，而擁塞控制則由控制窗口結(jié)合一系列的控制算法實(shí)現(xiàn)。

詳情請移步?tcp窗口滑動以及擁塞控制

2.3 TCP斷開階段

2.3.1 設(shè)置TIME_WAIT的原因

可靠地實(shí)現(xiàn)TCP全雙工連接的終止
TCP協(xié)議在關(guān)閉連接的四次握手過程中，最終的ACK是由主動關(guān)閉連接的一端（后面統(tǒng)稱A端）發(fā)出的，如果這個ACK丟失，對方（后面統(tǒng)稱B端）將重發(fā)出最終的FIN，因此A端必須維護(hù)狀態(tài)信息（TIME_WAIT）允許它重發(fā)最終的ACK。如果A端不維持TIME_WAIT狀態(tài)，而是處于CLOSED 狀態(tài)，那么A端將響應(yīng)RST分節(jié)，B端收到后將此分節(jié)解釋成一個錯誤（在java中會拋出connection reset的SocketException)。
因而，要實(shí)現(xiàn)TCP全雙工連接的正常終止，必須處理終止過程中四個分節(jié)任何一個分節(jié)的丟失情況，主動關(guān)閉連接的A端必須維持TIME_WAIT狀態(tài)

允許老的重復(fù)分節(jié)在網(wǎng)絡(luò)中消逝
TCP分節(jié)可能由于路由器異常而“迷途“，在迷途期間，TCP發(fā)送端可能因確認(rèn)超時(shí)而重發(fā)這個分節(jié)，迷途的分節(jié)在路由器修復(fù)后也會被送到最終目的地，這個遲到的迷途分節(jié)到達(dá)時(shí)可能會引起問題。在關(guān)閉“前一個連接”之后，馬上又重新建立起一個相同的IP和端口之間的“新連接”，“前一個連接”的迷途重復(fù)分組在“前一個連接”終止后到達(dá)，而被“新連接”收到了。為了避免這個情況，TCP協(xié)議不允許處于TIME_WAIT狀態(tài)的連接啟動一個新的可用連接，因?yàn)門IME_WAIT狀態(tài)持續(xù)2MSL，就可以保證當(dāng)成功建立一個新TCP連接的時(shí)候，來自舊連接重復(fù)分組已經(jīng)在網(wǎng)絡(luò)中消逝。

2.3.2 大量 TIME_WAIT 產(chǎn)生的原因及解決辦法

原因：對于基于TCP的HTTP協(xié)議，關(guān)閉TCP連接的是Server端，這樣，Server端會進(jìn)入TIME_WAIT狀態(tài)，可想而知，對于訪問量大的Web Server，會存在大量的TIME_WAIT狀態(tài)。

解決辦法：

開啟socket重用，允許將TIME_WAIT的socket重新用于TCP連接

開啟快速回收。

2.3.3 大量CLOSE_WAIT產(chǎn)生的原因及解決辦法

原因：對方關(guān)閉連接之后服務(wù)器程序自己沒有進(jìn)一步發(fā)出ack信號。換句話說，就是在對方連接 關(guān)閉之后，程序里 沒有檢測到，或者程序壓根就忘記了這個時(shí)候需要關(guān)閉連接，于是這個資源就一直被程序占著。
解決辦法：
具體問題具體解決，總結(jié)一句話就是在處理資源時(shí)一定要記住自己申請的資源要記得主動釋放。
詳情請移步?再談應(yīng)用環(huán)境下的TIME_WAIT和CLOSE_WAIT

2.3.4 為什么TCP斷開連接要四次揮手

因?yàn)閠cp是全雙工模式，接收到FIN時(shí)意味將沒有數(shù)據(jù)再發(fā)來，但是還是可以繼續(xù)發(fā)送數(shù)據(jù)。
詳情請移步?TCP為什么需要3次握手與4次揮手

2.4 其他

2.4.1 出現(xiàn)RST包的原因

RST：TCP首部中的6個標(biāo)志比特之一,表示重置連接、復(fù)位連接。

服務(wù)器端口未打開而客戶端來連接時(shí)

在一個已關(guān)閉的SOCKET上收到數(shù)據(jù)

請求超時(shí)

提前關(guān)閉

詳細(xì)請移步?幾種TCP連接中出現(xiàn)RST的情況

總結(jié)

以上是生活随笔為你收集整理的TCP协议-相关面试题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。