前言:前面一篇文章《手把手寫C++服務器(15):網路編程入門第一個TCP專案》介紹了一個簡單入門級的TCP專案,這一篇文章重點講一講面試常見的TCP協議相關的十個問題,都是后端開發程式員必知必會的經典知識點,
目錄
問題一:講一下TCP三次握手四次揮手的程序
三次握手:
四次揮手:
問題二:TCP和UDP之間有什么區別?
問題三:TCP擁塞控制有哪幾種方法?什么是擁塞避免?什么是快速恢復?什么是擁塞發生?
擁塞控制常用方法:
擁塞視窗
擁塞避免
快速恢復
問題四:什么是慢啟動演算法?
問題五:什么是TCP黏包和拆包問題?為什么會產生?如何解決?
問題六:什么是滑動視窗機制?
問題七:什么是擁塞控制?什么是超時重傳機制?
擁塞控制
超時重傳機制
問題八:什么是SACK選擇性確認?
問題九:什么是SYN泛洪攻擊?如何防御SYN泛洪攻擊?
問題十:怎樣保證TCP可靠性?
參考:
問題一:講一下TCP三次握手四次揮手的程序
三次握手:

開始客戶端和服務器都處于CLOSED狀態,然后服務端開始監聽某個埠,進入LISTEN狀態
-
第一次握手(SYN=1, seq=x),發送完畢后,客戶端進入 SYN_SEND 狀態
-
第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1), 發送完畢后,服務器端進入 SYN_RCVD 狀態,
-
第三次握手(ACK=1,ACKnum=y+1),發送完畢后,客戶端進入 ESTABLISHED 狀態,當服務器端接收到這個包時,也進入 ESTABLISHED 狀態,TCP 握手,即可以開始資料傳輸,
四次揮手:

-
第一次揮手(FIN=1,seq=u),發送完畢后,客戶端進入FIN_WAIT_1 狀態
-
第二次揮手(ACK=1,ack=u+1,seq =v),發送完畢后,服務器端進入CLOSE_WAIT 狀態,客戶端接收到這個確認包之后,進入 FIN_WAIT_2 狀態
-
第三次揮手(FIN=1,ACK=1,seq=w,ack=u+1),發送完畢后,服務器端進入LAST_ACK 狀態,等待來自客戶端的最后一個ACK,
-
第四次揮手(ACK=1,seq=u+1,ack=w+1),客戶端接收到來自服務器端的關閉請求,發送一個確認包,并進入 TIME_WAIT狀態,等待了某個固定時間(兩個最大段生命周期,2MSL,2 Maximum Segment Lifetime)之后,沒有收到服務器端的 ACK ,認為服務器端已經正常關閉連接,于是自己也關閉連接,進入 CLOSED 狀態,服務器端接收到這個確認包之后,關閉連接,進入 CLOSED 狀態,
問題二:TCP和UDP之間有什么區別?
TCP提供面向連接的、可靠的資料流傳輸,而UDP提供的是非面向連接的、不可靠的資料流傳輸,
TCP傳輸單位稱為TCP報文段,UDP傳輸單位稱為用戶資料報,
TCP有擁塞控制和流量控制保證資料傳輸的安全性;UDP沒有擁塞控制,網路阻塞不會影響源主機的發送效率,
TCP是點對點的兩點間服務,UDP支持一對一、一對多、多對一、多對多的互動通信,
TCP首部開銷大,20位元組;UDP首部開銷小,8位元組,
TCP對應的協議和UDP對應的協議
TCP對應的協議:
(1) FTP:定義了檔案傳輸協議,使用21埠,
(2) Telnet:一種用于遠程登陸的埠,使用23埠,用戶可以以自己的身份遠程連接到計算機上,可提供基于DOS模式下的通信服務,
(3) SMTP:郵件傳送協議,用于發送郵件,服務器開放的是25號埠,
(4) POP3:它是和SMTP對應,POP3用于接收郵件,POP3協議所用的是110埠,
(5)HTTP:是從Web服務器傳輸超文本到本地瀏覽器的傳送協議,
UDP對應的協議:
(1) DNS:用于域名決議服務,將域名地址轉換為IP地址,DNS用的是53號埠,
(2) SNMP:簡單網路管理協議,使用161號埠,是用來管理網路設備的,由于網路設備很多,無連接的服務就體現出其優勢,
(3) TFTP(Trivial File Transfer Protocal),簡單檔案傳輸協議,該協議在熟知埠69上使用UDP服務,
問題三:TCP擁塞控制有哪幾種方法?什么是擁塞避免?什么是快速恢復?什么是擁塞發生?
擁塞控制常用方法:
-
慢啟動
-
擁塞避免
-
擁塞發生
-
快速恢復
擁塞視窗
發送方維持一個叫做擁塞視窗cwnd(congestion window)的狀態變數,擁塞視窗的大小取決于網路的擁塞程度,并且動態地在變化,發送方讓自己的發送視窗等于擁塞視窗,另外考慮到接受方的接收能力,發送視窗小于擁塞視窗,
擁塞避免
擁塞避免演算法讓擁塞視窗緩慢增長,即每經過一個往返時間RTT就把發送方的擁塞視窗cwnd加1,而不是加倍,這樣擁塞視窗按線性規律緩慢增長,
無論是在慢開始階段還是在擁塞避免階段,只要發送方判斷網路出現擁塞(其根據就是沒有收到確認,雖然沒有收到確認可能是其他原因的分組丟失,但是因為無法判定,所以都當做擁塞來處理),就把慢開始門限設定為出現擁塞時的發送視窗大小的一半,然后把擁塞視窗設定為1,執行慢開始演算法,

快速恢復
1.當收到3個重復ACK時,把ssthresh設定為cwnd的一半,把cwnd設定為ssthresh的值加3,然后重傳丟失的報文段,加3的原因是因為收到3個重復的ACK,表明有3個“老”的資料包離開了網路,
2.再收到重復的ACK時,擁塞視窗增加1,
3.當收到新的資料包的ACK時,把cwnd設定為第一步中的ssthresh的值,原因是因為該ACK確認了新的資料,說明從重復ACK時的資料都已收到,該恢復程序已經結束,可以回到恢復之前的狀態了,也即再次進入擁塞避免狀態,
問題四:什么是慢啟動演算法?
在 TCP 剛剛連接好,開始發送 TCP 報文段時,先讓擁塞視窗 cwnd = 1,即一個最大報文段長度 MSS,而在每收到一個對新的報文段的確認后,將 cwnd 加倍,即剛開始會增大一個 MSS,用這樣的方法逐步增大發送方的擁塞視窗 cwnd,可以使分組注入到網路的速率更加合理,例如,A 向 B 發送資料,當發送時 A 的擁塞視窗為 2,那么 A 一次可以發送兩個 TCP 報文段,當經過一個 RTT 后,A 收到 B 對剛才兩個報文的確認,于是就把擁塞視窗調整為 4,即下一次發送時就可以發送 4 個報文段,
使用慢開始演算法后,每經過一個傳輸輪次,擁塞視窗 cwnd 就會加倍,即 cwnd 的大小呈指數形式增長,這樣慢開始一直把擁塞視窗 cwnd 增大到一個規定的慢開始門限 ssthresh(閾值),然后改用擁塞避免演算法,
問題五:什么是TCP黏包和拆包問題?為什么會產生?如何解決?
TCP是面向流,沒有界限的一串資料,TCP底層并不了解上層業務資料的具體含義,它會根據TCP緩沖區的實際情況進行包的劃分,所以在業務上認為,一個完整的包可能會被TCP拆分成多個包進行發送,也有可能把多個小的包封裝成一個大的資料包發送,這就是所謂的TCP粘包和拆包問題,

為什么會產生粘包和拆包呢?
-
要發送的資料小于TCP發送緩沖區的大小,TCP將多次寫入緩沖區的資料一次發送出去,將會發生粘包;
-
接收資料端的應用層沒有及時讀取接識訓沖區中的資料,將發生粘包;
-
要發送的資料大于TCP發送緩沖區剩余空間大小,將會發生拆包;
-
待發送資料大于MSS(最大報文長度),TCP在傳輸前將進行拆包,即TCP報文長度-TCP頭部長度>MSS,
解決方案:
-
發送端將每個資料包封裝為固定長度
-
在資料尾部增加特殊字符進行分割
-
將資料分為兩部分,一部分是頭部,一部分是內容體;其中頭部結構大小固定,且有一個欄位宣告內容體的大小,
問題六:什么是滑動視窗機制?
滑動視窗協議的基本作業流程就是由接收方通告視窗的大小,這個視窗稱為提出視窗,也就是接收方視窗,接收方提出的視窗則是被接識訓沖區所影響的,如果資料沒有被用戶行程使用那么接收方通告的視窗就會相應得到減小,發送視窗取決于接收方視窗的大小,可用視窗的大小等于接收方視窗減去發送但是沒有被確認的資料包大小,

問題七:什么是擁塞控制?什么是超時重傳機制?
擁塞控制
所謂的擁塞控制就是為了防止過多的資料注入網路中,這樣可以使網路中的路由器或鏈路不會過載,當出現擁塞時,端點并不能了解到擁塞發生的細節,對通信連接的端點來說,擁塞往往表現為通信時延的增加,擁塞控制和流量控制相似的地方是通過控制發送方發送資料的速率來達到效果,
擁塞控制與流量控制的區別:擁塞控制是讓網路能夠承受現有的網路負荷,它是一個全域性的程序,涉及所有的主機、所有的路由器,以及與降低網路傳輸性能有關的所有因素,而流量控制往往使指點對點通信量的控制,即接收端控制發送端,它所做的就是抑制發送端發送資料的速率,以便使接收端來得及接收,
為了更好地對傳輸層進行擁塞控制,有以下四種演算法:慢開始、擁塞避免、快重傳、快恢復,發送方在確定發送報文段的速率時,既要根據接收方的接收能力,又要從全域考慮不要使網路發生擁塞,因此,TCP 協議要求發送方維護以下兩個視窗:
(1) 接收視窗 rwnd,接收方根據目前接收快取大小所許諾的最新的視窗值,反映了接收方的容量,有接收方根據其放在 TCP 報文的首部的 "視窗" 欄位通知發送方,
(2) 擁塞視窗 cwnd,發送方根據自己估算的網路擁塞程度而設定的視窗值,反映了網路當前容量,只要網路沒有出現擁塞,擁塞視窗就再增大一些,以便把更多的分組發送出去,但只要網路出現擁塞,擁塞視窗就減少一些,以減少注入網路中的分組數,發送視窗的上限值應當取接收視窗 rwnd 和擁塞視窗 cwnd 中較小的一個,即:Min[rwnd, cwnd],
超時重傳機制
TCP 每發送一個報文段,就對這個報文段設定一次計時器,只要計時器設定的重傳時間到期但還沒有收到確認,就要重傳這一報文段,當檢測到接收資料有錯誤時,會采取直接丟棄出錯的資料,發送端等待接收端的確認超時后,會自動重發該報文段,
由于 IP 資料報在傳輸的時候選擇的路由變化很大,因此傳輸層的往返時延的方差很大,為了計算超時計時器的重傳時間,TCP 采用一種自適應演算法,它記錄一個報文段發出的時間,以及收到相應確認的時間,這兩個時間之差叫做報文段的往返時間(RTT),TCP 保留了 RTT 的一個加權平均往返時間 RTTs,當第一次測量 RTT 樣本時,RTTs 值就為所測量到的 RTT 樣本的值,但之后每測量一個新的 RTT 樣本,就按下式重新計算一次 RTTs:
新的 RTTs = ( 1- a ) * (舊的 RTTs) + a(新的RTT樣本)
在上式中 0 <= a < 1,若 a 很接近于零,表示新的 RTTs 值和舊的 RTTs 值相比變化不大,而受新的 RTT 樣本影響不大(RTT值更新較慢),若 a 接近于 1,則表示新的 RTTs 值受新的 RTT 樣本的影響較大(RTT值更新較快),[RFC 2988] 推薦的 a 值為 0.125,
所以超時計時器設定的超時重傳時間(RTO)應略大于上面得出的加權平均往返時間 RTTs,即 RTO = RTTs + 4RTTd,其中 RTTd 是 RTT 的偏差的加權平均值,它與 RTTs 和新的 RTT 樣本之差有關,當第一次測量時,RTTd 取為測量到的 RTT 樣本值的一半,以后測量中,使用下式計算:新的 RTTd = (1-β) *(舊的 RTTd) + β*|RTTs - 新的 RTT 樣本|,其中 β 是個小于 1 的系數,它的推薦值是 0.25,
問題八:什么是SACK選擇性確認?
在 TCP 頭部「選項」欄位里加一個 SACK 的東西,它可以將快取的地圖發送給發送方,這樣發送方就可以知道哪些資料收到了,哪些資料沒收到,知道了這些資訊,就可以只重傳丟失的資料,
如下圖,發送方收到了三次同樣的 ACK 確認報文,于是就會觸發快速重發機制,通過 SACK 資訊發現只有 200~299 這段資料丟失,則重發時,就只選擇了這個 TCP 段進行重復,

問題九:什么是SYN泛洪攻擊?如何防御SYN泛洪攻擊?
SYN Flood是一種典型的DoS (Denial of Service,拒絕服務) 攻擊,它在短時間內,偽造不存在的IP地址,向服務器大量發起SYN報文,當服務器回復SYN+ACK報文后,不會收到ACK回應報文,導致服務器上建立大量的半連接半連接佇列滿了,這就無法處理正常的TCP請求啦,
主要有 syn cookie和SYN Proxy防火墻等方案應對,
-
syn cookie:在收到SYN包后,服務器根據一定的方法,以資料包的源地址、埠等資訊為引數計算出一個cookie值作為自己的SYNACK包的序列號,回復SYN+ACK后,服務器并不立即分配資源進行處理,等收到發送方的ACK包后,重新根據資料包的源地址、埠計算該包中的確認序列號是否正確,如果正確則建立連接,否則丟棄該包,
-
SYN Proxy防火墻:服務器防火墻會對收到的每一個SYN報文進行代理和回應,并保持半連接,等發送方將ACK包回傳后,再重新構造SYN包發到服務器,建立真正的TCP連接,
問題十:怎樣保證TCP可靠性?
這是一個綜合性的問題,涉及上述講好幾個問題,
從以下幾個方面回答:
- 首先要說,三次握手四次揮手是可靠性的基礎
- 位元組編號機制
- 滑動視窗機制
- 超時重傳機制
- 快速恢復機制
- 擁塞避免機制
- 面試說這么多夠了,會說的還能再扯一點其他的……
參考:
- https://blog.csdn.net/qq_41895747/article/details/104699853
- https://blog.csdn.net/BIggyGuan/article/details/108410136
- https://blog.csdn.net/qq_38289815/article/details/100176632
- https://zhuanlan.zhihu.com/p/101134290
- https://mp.weixin.qq.com/s/xa--iwKsIBFqr1CLqRr6qA
- 《計算機網路》
- 《圖解TCP/IP》
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/290260.html
標籤:其他
上一篇:保姆級教你三字訣15天玩會Linux系統-避免踩坑!!!收藏不虧
下一篇:網路(五)
