當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

「offer来了」2种递进学习思维，24道计网题目，保姆级巩固你的计网知识体系

發布時間：2023/12/4 编程问答 20 豆豆

生活随笔收集整理的這篇文章主要介紹了「offer来了」2种递进学习思维，24道计网题目，保姆级巩固你的计网知识体系小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

「面試專欄」前端面試之計算機網絡篇

?序言
🏐一、基礎知識環節
- 1、專欄學習
- 2、書籍學習
?二、思維導圖環節
🎳三、OSI七層模型
- 1、OSI模型是什么？
- 2、OSI七層模型遵循原則
🏏四、TCP與UDP
- 1、TCP與UDP的區別
- 2、TCP/UDP的優缺點
- - （1）TCP的優點
  - （2）TCP的缺點
  - （3）UDP的優點
  - （4）UDP的缺點
- 3、DDOS攻擊（由TCP和UDP的缺點引出DDOS攻擊問題）
- - （1）什么是DDOS攻擊？
  - （2）DDOS攻擊方式？
  - （3）如何應對DDOS攻擊？
- 4、TCP為什么可靠？
- 5、TCP的三次握手和四次揮手
- - （1）TCP的三次握手
  - （2）TCP為什么要三次握手？
  - （3）TCP的四次揮手
  - （4）TCP為什么要四次揮手？
  - （5）什么是面向連接協議？什么是面向無連接協議？
  - （6）為什么建立連接是三次握手，關閉連接是四次揮手呢？
  - （7）如果已經建立了連接，但是客戶端突然出現故障了該怎么辦？
🏒五、TCP的通信機制
- 1、TCP的重發控制
- 2、TCP的滑動窗口控制
- 3、滑動窗口的重發控制
- 4、TCP的流量控制機制
- 5、TCP的擁塞控制
🏸六、結束語
🐣彩蛋 One More Thing
- 🏷?pdf內容獲取
- 🏷?更新地址
- 🏷?番外篇

?序言

大家都知道，計算機網絡是前端面試中非常愛考的面試題了，不得不說是八股文的經典。在周一剛開始接觸計網時，也是一直看到類似于三次握手四次握手之類的問題。剛開始我是知識比較浮于表面，對計網知識的了解就一直停留在知道有那么一些內容。但隨著學習的深入，慢慢地我覺得，在了解一個東西之前，不僅僅要知道它是什么？還要知道它為什么出現？它的出現又解決了什么問題？這樣的學習會更加有利于將其運用到我們的日常開發中。

在下面這篇文章中，將分享在秋招備試的過程中我學習計網的一個過程，以及自己整理的關于計網常考的一些面經題。

下面開始進入今天文章的講解~😜

🏐一、基礎知識環節

1、專欄學習

剛開始面對的是學校發的一本非常厚重的書，u1s1，面對那接近1000頁的書，我的心里其實蠻奔潰的。后面在機緣巧合下，在一個公眾號上看到了一位前端博主的文章，零一。緊接著在 csdn 上看到他寫的很多精選專欄，看完他的博客之后，才下意識地感覺……原來還有寫的這么好的文章。這一段廢話有點多……以后有機會再談。

我當時先學的是零一博主的 TCP 專欄，博主的每一篇文章對小白都是極其友好類型，非常地通俗易懂。下面附上 TCP 專欄相關的文章鏈接👇

序號文章鏈接

1	【TCP/IP】概述網絡分層以及協議介紹	https://lpyexplore.blog.csdn.net/article/details/108925528
2	【TCP/IP】IP地址的劃分及其分類	https://lpyexplore.blog.csdn.net/article/details/108935757
3	【TCP/IP】鏈路層的簡單認識	https://lpyexplore.blog.csdn.net/article/details/109248705
4	【TCP/IP】詳解DNS具體作用過程	https://lpyexplore.blog.csdn.net/article/details/109128967
5	【TCP/IP】圖解TCP的通信機制	https://lpyexplore.blog.csdn.net/article/details/109133096
6	專欄傳送門	https://blog.csdn.net/l_ppp/category_10448348.html

以上文章可以按順序學哦~

2、書籍學習

學習完上面的5篇博客之后，前后大概花了15-20h左右的時間。看完之后，算是稍微入了個門。但是計網的內容遠遠不止這些，所以，在學習了博客文章之后，我繼續用書籍來深挖知識點。

搜尋了知乎和豆瓣，還有身邊的小伙伴的推薦，大家都說對前端比較友好的書籍是： 《圖解TCP/IP》 這一本書。看下圖👇

這本書以圖解的形式，講解了計算機網絡的大部分知識。可以說對入門選手和對看書就容易犯困的小伙伴來說實在是太太太友好了……強烈安利！

看完這本書之后，應對面試基本上算是足夠了。如果還有想要深挖的小伙伴，可以去看深色封面的那本書……只是聽過，但是我沒有看過，所以這里只簡單概括一下~

有了基礎知識預備之后，就可以看一下一些面經題目，嘗試著回顧和用自己的話語來回答。同時在文章下面的內容中，我也將對我遇到的系列題目進行歸納總結~

?二、思維導圖環節

我們先用一張思維導圖來了解該系列面經題的知識體系。具體如下圖👇

思維導圖收入囊中，下面開始分享面經題的解答流程~

🎳三、OSI七層模型

1、OSI模型是什么？

OSI 七層模型，即網絡通信的七個層次。之所以將其分為七個層次，是為了讓開發人員可以在不同領域分別實現整個系統的不同部分。就像一個非常龐大的工程，每個員工都有自己擅長的崗位和專門負責的工作。

那么七個層次主要包括：物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層以及應用層。

接下來談論各個層次的作用。

第一個，應用層。應用層是為應用程序提供服務并規定應用程序中通信相關的細節。包括文件傳輸、電子郵件、遠程登錄（虛擬終端）等協議。

第二個，表示層。表示層是將應用處理的信息轉換為適合網絡傳輸的格式，或將來自下一層的數據轉換為上一層能夠處理的格式。因此它主要負責數據格式的轉換。

第三個，會話層。會話層是負責建立和斷開通信連接，以及數據的分割等數據傳輸相關的管理。

第四個，傳輸層。傳輸層起著可靠傳輸的作用，它只在通信雙方的節點上進行處理，而無需在路由器上處理。

第五個，網絡層。網絡層將數據傳輸到目標地址上，目標地址可以是多個網絡通過路由器連接而成的某一個地址。因此這一層主要負責尋址和路由選擇。

第六個，數據鏈路層。數據鏈路層負責物理層面上互聯的、結點之間的通信傳輸。

第七個，物理層。負責0、1比特流（0、1序列）與電壓的高低、光的閃滅之間的互換。

2、OSI七層模型遵循原則

OSI參考模型遵循五個原則：

各個層級之間有清晰的邊界，便于理解各個層級的功能；
每個層實現的功能不一樣，并且不會互相影響；
層與層之間是服務與被服務關系；
層次劃分有利于國際標準協議的制定；
層次數目越多，就越能避免各個層之間的功能重復。

🏏四、TCP與UDP

1、TCP與UDP的區別

TCPUDP

TCP在傳輸層上	UDP在傳輸層上
面向連接	面向無連接
面向字節流	面向報文
一對一通信	一對一、一對多、多對一、多對多通信
需要建立可靠的連接	不需要建立可靠的連接
適用于可靠傳輸的應用：web browsing、email、文件傳輸等	適用于實時應用：線上游戲、直播、IP電話、語音會議等

白話文回答：

TCP 是面向連接的，UDP 是面向無連接的，即發送數據前不需要建立連接。
TCP 提供可靠的傳輸服務，通過 TCP 連接傳送的數據，無差錯，不丟失，不重復，且按序到達，而 UDP 則是盡最大努力交付，不保證可靠傳輸。
因此，因為 TCP 可靠，面向連接且不會丟失數據，所以 TCP 適合大數據量的交換。
TCP 面向字節流，實際是 TCP 把數據看成是一連串無結構的字節流； UDP 則是面向報文的，且沒有擁塞控制，因此，網絡出現擁堵的情況下不會使原主機的發送速率降低，但是這個過程會出現丟包，所以它對實時的應用很有用，比如 IP 電話、視頻會議和直播等等。
每一條 TCP 連接，只能是一對一的，UDP 則支持一對一、一對多、多對一和多對多的交互通信。
TCP 的首部開銷為20字節，而 UDP 的只有8字節。
綜上所述，TCP 是面向連接的可靠性傳輸，而 UDP 則是不可靠的。

注： TCP 需建立三次連接、且 TCP 的包可以進行分組發送，會產生建立連接開銷和分組開銷。

2、TCP/UDP的優缺點

（1）TCP的優點

可靠、穩定。
TCP 的可靠體現在 TCP 在傳遞數據之前，會有三次握手來建立連接；
且在數據傳遞時，有確認、窗口、重傳、擁塞控制等機制；
在數據完成傳送以后，還會通過斷開連接來節約資源。

（2）TCP的缺點

慢、效率低、占用系統資源高，易被攻擊。
TCP 在傳遞數據前，要先建立連接，這會消耗時間；
且在傳遞數據時，確認機制、重傳機制、擁塞控制機制等都會消耗大量的時間；
同時要在每臺設備上維護所有的傳輸連接，事實上，每個連接都會占用系統的 CPU 、內存等硬件資源；
而且，因為 TCP 有三次握手機制，這些也會導致 TCP 容易被人利用，實現 DOS 、 DDOS 等攻擊。

（3）UDP的優點

快、比TCP稍安全。
UDP 是一個無狀態的傳輸協議，且 UDP 沒有 TCP 的握手、確認、窗口、重傳、擁塞控制等機制，所以它在傳遞數據時非常快。沒有 TCP 的這些機制，UDP 較 TCP 能被攻擊者利用的漏洞就要少一些。
但 UDP 也是無法避免攻擊的，比如：UDP flood 攻擊。

（4）UDP的缺點

不可靠、不穩定。
因為 UDP 沒有 TCP 那些可靠的機制，所以在數據傳遞時，如果網絡質量不好，就會很容易丟包。

3、DDOS攻擊（由TCP和UDP的缺點引出DDOS攻擊問題）

（1）什么是DDOS攻擊？

分布式拒絕服務攻擊（Distributed denial of sevice attack）；
即向目標系統同時提出數量龐大的服務請求。

（2）DDOS攻擊方式？

攻擊者如何攻擊目標主機呢？

通過使網絡過載來干擾甚至阻斷正常的網絡通訊。
通過向服務器提出大量的服務請求、使服務器超負荷。
阻斷某一用戶訪問服務器。
阻斷某服務與特定系統或個人的通訊。

（3）如何應對DDOS攻擊？

黑名單。
DDOS 清洗：對用戶請求的數據進行實時監控，及時發現 DOS 攻擊等異常流量，在不影響正常業務開展的情況下清洗掉這些異常流量。
CDN 加速。
高仿服務器：高仿服務器主要是指能獨立防御50Gbps以上 ( 1Gbps=1024Mbps，即每秒1000M ) 的服務器，能夠幫助網站拒絕服務攻擊，定期掃描網絡主節點。

4、TCP為什么可靠？

TCP 會通過檢驗和、序列號、確認應答、重發控制、連接管理及窗口控制等機制實現可靠性傳輸。
那如何通過以上機制來實現可靠性傳輸呢？
在 TCP 中，當發送端的數據到達接收主機時，接收端主機會返回一個已收到消息的通知。這個消息叫做確認應答（ACK）。（確認應答）
相反，當發送端發送數據出去之后，且在一段時間內，沒有等到確認應答，則數據極有可能出現丟失的情況。
如果在一定時間內沒有等到確認應答，那么發送方就可以認為數據已經丟失，并進行重發。由此，即使產生了丟包，仍然能夠保證數據能夠到達對端，實現可靠傳輸。（丟包重發）
此外，也有可能因為一些其他原因導致確認應答延遲到達，此時，發送主機同樣會按照機制重發數據。（延遲重發）
但是這對于目標主機來說，簡直是一個巨大的災難。因為目標主機會反復收到相同的數據。
為此，需要引入一種新的機制，序列號。序列號能夠識別是否已經接收數據，及是否需要接收數據。（序列號）
序列號是按照順序給發送數據的每一個字節都標上號碼的編號。接收端會查詢所接收數據中 TCP 首部的序列號和數據的長度，將自己下一步應該接收的序號作為確認應答返送回去。（序列號）
就這樣，通過序列號、確認應答等機制，實現 TCP 的可靠傳輸。

注：序列號主要是讓接收端可以丟棄數據并返回下一個應答號，這樣就不會頻繁地收到同一個數據。

5、TCP的三次握手和四次揮手

（1）TCP的三次握手

場景模擬：

如通話一樣，比如我現在跟面試官您打電話。那我會先問，喂，您好，聽得到嗎？
你會回我說，聽到啦！那你能聽到我的話嗎？
我會再回你說，聽到了，我們可以開始聊天了。

三次握手：

首先，客戶端會發送一個帶有 SYN 標志的數據包給對方；
接收方收到以后，會返回一個帶有 SYN/ACK 標志的數據包返回給發送端，代表成功傳達消息；
之后發送端再回傳一個帶有 ACK 標志的數據包，代表握手結束。

（2）TCP為什么要三次握手？

驗證服務端和客戶端是否遵循 TCP/IP 協議；
為了防止已失效的連接請求報文段突然又傳送到服務端，避免錯誤產生。

（3）TCP的四次揮手

第一次揮手：

客戶端進程發出連接釋放報文，并且停止發送數據。

第二次揮手：

服務器收到連接釋放報文，發出確認報文，此時，服務端就進行了 close-wait （關閉等待）狀態。（客戶端向服務器方向釋放了，但是服務器發送數據，客戶端依然要接收）
客戶端收到服務器的確認請求后，客戶端就進入了 Fin-wait-2 （終止等待2）狀態，等待服務器發送連接釋放報文（在這之前還需要接收服務器發送的最后數據）。

第三次揮手：

服務器將最后的數據發送完畢后，就向客戶端發送連接釋放報文，服務器就進入了 Last-ack （最后確認）。

第四次揮手：

客戶端收到服務器的連接釋放報文后，必須發出確認，客戶端就進入了 time-wait （時間等待）狀態。
服務端只要收到了客戶端發出的確認，立即進入 closed 狀態。
至此，就結束了這次的 TCP 連接。（服務器結束 TCP 連接的時間要比客戶端早一些）

（4）TCP為什么要四次揮手？

之所以要四次揮手，其實是確保雙方數據都已發送完畢。
TCP 是全雙工模式，這就意味著，當主機1 發送 FIN 報文段時，只是表示主機1 已經沒有數據要發送了，主機1 告訴主機2 ，它的數據已經全部發送完畢了。
當主機2 返回 ACK 報文段時，表示它已經知道主機1 沒有數據發送了，但是主機2 還是可以發送數據到主機1 的。
當主機2 也發送了 FIN 報文段時，這個時候就表示主機2 也沒有數據要發送了，就會告訴主機1 ，我也沒有數據要發送了。
最后，主機1 再發送 ACK 報文段來確認握手結束，之后彼此就會愉快的斷開此次的 TCP 連接。

（5）什么是面向連接協議？什么是面向無連接協議？

面向連接協議：

通信雙方在通信時，需要事先建立好一條虛擬的通信線路。
通信過程有“建立連接、維護連接、斷開連接“三個階段。

面向無連接協議：

與面向連接相對，通信雙方不需要事先建立通信線路，而是把每個帶有目的地址的報文分組送到通信線路上，由系統自主選定線路進行傳輸。
面向無連接只有“傳送數據”的過程。

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

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

注： ①②③表示第一二三次揮手

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

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

注： 10x75=750s=12.5min

🏒五、TCP的通信機制

1、TCP的重發控制

我們都知道，在數據傳輸過程中可能會因為各種原因出現丟包現象，而當出現丟包現象時，即發送端在發完數據并等待一段時間以后，未接收到接收方應答，則視為丟包，于是就會進行重發。
其中，丟包現象分為兩種：①發送過程丟包；②接收過程丟包。
那么，發送端發送完數據以后多久沒有收到確認應答才判定數據丟包了呢？
這個一般都是隨著網絡環境的變化而變化的， TCP 會在每次發包時計算往返時間以及偏差來決定等待時間。
若重發后又出現了丟包，則下一次等待的時間會以2倍、4倍的指數函數增長。
但它肯定是不會無限進行重發的，當重發次數達到一定程度后^[1]，會判定為網絡異常，兩端通信就會被強制關閉。

[1]：TCP 有一個保活計時器，如果在 2h 后還沒有收到客戶端的數據，那么就會重新復位這個計時器，之后每隔 75s 會發送一次，如果一連發送10個還是沒有收到，那么就會斷開連接。

2、TCP的滑動窗口控制

解題：

什么原因導致需要有滑動窗口？
有了滑動窗口后可以解決什么問題？

白話文回答：

我們都知道，數據不應該一次性發送，不然丟失了都不知道往哪里找，因此應該采取 分段發送 的措施。
但是呢， TCP 將數據分段發送，雖然提高了傳輸的可靠性，但是存在著一個致命的缺點，那就是 效率非常低 。
因為每發送一段數據，都要等待接收端的確認應答后才能繼續發送，若整個數據的分段較多，那么通信的性能就會很低了，因此 TCP 引入了窗口這個概念。
所謂窗口，表示的是無需等待接收方的確認應答而可以連續發送多段數據。
舉個例子：假設要發送 4 段數據，如果每次都要發送后接收完才能再重新發送，那來回就得 8 次。但如果用滑動窗口的話，四段數據可以同時發出去，接收端再返回相應的確認應答給發送方。
這個時候發送方會根據相應的確認應答繼續發送比該確認序列中序列號大的數據即可。

3、滑動窗口的重發控制

若使用滑動窗口這一技術后，即使某段數據出現丟包現象，也不會造成很大的影響。
因為接收端會一邊接收發送端傳過來的數據，一邊用某種方式告知發送端前面丟失了哪一段數據。

4、TCP的流量控制機制

為什么需要流量控制機制？

有時，發送端發送給接收端的數據超過了接收端的最大承載能力，就會造成數據無法接收的情況，從而導致之后會進行數據重發，這樣子會非常浪費性能。

如何解決這種問題呢？引出流量控制機制

為了防止上述情況發生，TCP 提供了一種機制（即流量控制機制）來使得發送端每次發送的數據盡可能的在接收端的承載范圍之內。
而實現方式就是，接收端向發送端告知自己能夠接收的數據大小，如此一來，發送端每次發送的數據就都不會超過該值，我們成該值為窗口大小。
一旦接收端暫時無法接收任何數據，它會告知發送端，因此發送端會暫停數據的發送。
但為了后續數據的正常發送，發送端會不時地向接收端發送一個 窗口探測 ，試探性地看一下接收端能否繼續接收數據。

5、TCP的擁塞控制

因為出現了窗口控制，數據不再是一段一段發送，而是連續發送多段數據包，因此有時候如果出現網絡擁堵的情況下，而我們又同時發送了大量的數據包，這很有可能會導致網絡癱瘓。
TCP運用了一種叫做 慢啟動 的技巧緩解上述問題。那何為 慢啟動 呢？
就是不要在一開始就瞬間發送大量數據包，而是先發送一部分，然后再根據收發情況再發送更多的數據包。
總結就是每次發送的數據包會以 1,2,4 的指數型增長，但窗口大小也不會無限指數型增大，而是會達到某個值時進行一些調整，該值稱為 慢啟動閾值 。

流量控制機制和擁塞控制機制的區別：

流量控制是以接收端為主導，接收端明確自己想要的窗口大小，然后發送端再把數據發送給接收端；
而擁塞控制機制則是以發送端為主導，發送端試探性的以1,2,4的指數型增長給接收端發送數據，探測接收端的承載能力，等到接收端不能再接收數據時，發送端就會知道接收端沒法承載這么多數據，于是就會進行向下調整。