面渣逆襲：三萬字，七十圖詳解計算機網路六十二問（建議收藏）

大家好，我是老三，開工大吉，虎年第一篇，面渣逆襲系列繼續！

這次給大家帶來了計算機網路六十二問，三萬字，七十圖詳解，大概是全網最全的網路面試題。

建議大家收藏了慢慢看，新的一年一定能夠跳槽加薪，虎年“豹”富！

基礎

1.說下計算機網路體系結構

計算機網路體系結構，一般有三種：ISO 七層模型、TCP/IP 四層模型、五層結構。

簡單說，OSI是一個理論上的網路通訊模型，TCP/IP是實際上的網路通訊模型，五層結構就是為了介紹網路原理而折中的網路通訊模型。

ISO 七層模型

ISO 七層模型是國際標準化組織（International Organization for Standardization）制定的一個用於計算機或通訊系統間互聯的標準體系。

• 應用層：通過應用程式之間的互動來完成特定網路應用，應用層協議定義的是應用程式間通訊和互動的規則，常見的協議有：HTTP FTP  SMTP SNMP DNS.
• 表示層：資料的表示、安全、壓縮。確保一個系統的應用層所傳送的資訊可以被另一個系統的應用層讀取。
• 會話層：建立、管理、終止會話，是使用者應用程式和網路之間的介面。
• 運輸層：提供源端與目的端之間提供可靠的透明資料傳輸，傳輸層協議為不同主機上執行的程式提供邏輯通訊。
• 網路層：將網路地址翻譯成對應的實體地址，實現不同網路之間的路徑選擇, 協議有 ICMP IGMP IP 等.
• 資料鏈路層：在物理層提供位元流服務的基礎上，建立相鄰結點之間的資料鏈路。
• 物理層：建立、維護、斷開物理連線。

TCP/IP 四層模型

• 應用層：對應於 OSI 參考模型的（應用層、表示層、會話層）。

• 傳輸層: 對應 OSI 的傳輸層，為應用層實體提供端到端的通訊功能，保證了資料包的順序傳送及資料的完整性。

• 網際層：對應於 OSI 參考模型的網路層，主要解決主機到主機的通訊問題。

• 網路介面層：與 OSI 參考模型的資料鏈路層、物理層對應。

五層體系結構

• 應用層：對應於 OSI 參考模型的（應用層、表示層、會話層）。

• 傳輸層：對應 OSI 參考模型的的傳輸層

• 網路層：對應 OSI 參考模型的的網路層

• 資料鏈路層：對應 OSI 參考模型的的資料鏈路層

• 物理層：對應 OSI 參考模型的的物理層。

2.說一下每一層對應的網路協議有哪些？

一張表格總結常見網路協議：

3.那麼資料在各層之間是怎麼傳輸的呢？

對於傳送方而言，從上層到下層層層包裝，對於接收方而言，從下層到上層，層層解開包裝。

• 傳送方的應用程式向接收方的應用程式傳送資料
• AP先將資料交給本主機的應用層，應用層加上本層的控制資訊H5就變成了下一層的資料單元
• 傳輸層收到這個資料單元后，加上本層的控制資訊H4，再交給網路層，成為網路層的資料單元
• 到了資料鏈路層，控制資訊被分成兩部分，分別加到本層資料單元的首部（H2）和尾部（T2）
• 最後的物理層，進行位元流的傳輸

這個過程類似寫信，寫一封信，每到一層，就加一個信封，寫一些地址的資訊。到了目的地之後，又一層層解封，傳向下一個目的地。

網路綜合

4.從瀏覽器位址列輸入 url 到顯示主頁的過程？

這道題，大概的過程比較簡單，但是有很多點可以細挖：DNS解析、TCP三次握手、HTTP報文格式、TCP四次揮手等等。

1. DNS 解析：將域名解析成對應的 IP 地址。
2. TCP連線：與伺服器通過三次握手，建立 TCP 連線
3. 向伺服器傳送 HTTP 請求
4. 伺服器處理請求，返回HTTp響應
5. 瀏覽器解析並渲染頁面
6. 斷開連線：TCP 四次揮手，連線結束

我們以輸入www.baidu.com 為例：

各個過程都使用了哪些協議？

5.說說 DNS 的解析過程？

DNS，英文全稱是 domain name system，域名解析系統，它的作用也很明確，就是域名和 IP 相互對映。

DNS 的解析過程如下圖：

假設你要查詢 www.baidu.com 的 IP 地址:

• 首先會查詢瀏覽器的快取,看看是否能找到www.baidu.com對應的IP地址，找到就直接返回；否則進行下一步。
• 將請求發往給本地DNS伺服器，如果查詢到也直接返回，否則繼續進行下一步；

• 本地DNS伺服器向根域名伺服器傳送請求，根域名伺服器返回負責com的頂級域名伺服器的IP地址的列表。
• 本地DNS伺服器再向其中一個負責com的頂級域名伺服器傳送一個請求，返回負責baidu.com的許可權域名伺服器的IP地址列表。
• 本地DNS伺服器再向其中一個許可權域名伺服器傳送一個請求，返回www.baidu.com所對應的IP地址。

6.說說 WebSocket 與 Socket 的區別？

• Socket 其實就是等於 IP 地址 + 埠 + 協議。

具體來說，Socket 是一套標準，它完成了對 TCP/IP 的高度封裝，遮蔽網路細節，以方便開發者更好地進行網路程式設計。

• WebSocket 是一個持久化的協議，它是伴隨 H5 而出的協議，用來解決 http 不支援持久化連線的問題。
• Socket 一個是網編程式設計的標準介面，而 WebSocket 則是應用層通訊協議。

7.說一下你瞭解的埠及對應的服務？

HTTP

8.說說 HTTP 常用的狀態碼及其含義？

HTTP狀態碼首先應該知道個大概的分類：

• 1XX：資訊性狀態碼
• 2XX：成功狀態碼
• 3XX：重定向狀態碼
• 4XX：客戶端錯誤狀態碼
• 5XX：服務端錯誤狀態碼

幾個常用的，面試之外，也應該記住：

之前寫過一篇：程式設計師五一被拉去相親，結果徹底搞懂了HTTP常用狀態碼，還比較有意思，可以看看。

說一下301和302的區別？

• 301：永久性移動，請求的資源已被永久移動到新位置。伺服器返回此響應時，會返回新的資源地址。
• 302：臨時性性移動，伺服器從另外的地址響應資源，但是客戶端還應該使用這個地址。

用一個比喻，301就是嫁人的新垣結衣，302就是有男朋友的長澤雅美。

9.HTTP 有哪些請求方式？

其中，POST、DELETE、PUT、GET的含義分別對應我們最熟悉的增、刪、改、查。

10.說⼀下 GET 和 POST 的區別？

可以從以下幾個方面來說明GET和POST的區別：

1. 從 HTTP 報文層面來看，GET 請求將資訊放在 URL，POST 將請求資訊放在請求體中。這一點使得 GET 請求攜帶的資料量有限，因為 URL 本身是有長度限制的，而 POST 請求的資料存放在報文體中，因此對大小沒有限制。而且從形式上看，GET 請求把資料放 URL 上不太安全，而 POST 請求把資料放在請求體裡想比較而言安全一些。
2. 從資料庫層面來看，GET 符合冪等性和安全性，而 POST 請求不符合。這個其實和 GET/POST 請求的作用有關。按照 HTTP 的約定，GET 請求用於檢視資訊，不會改變伺服器上的資訊；而 POST 請求用來改變伺服器上的資訊。正因為 GET 請求只檢視資訊，不改變資訊，對資料庫的一次或多次操作獲得的結果是一致的，認為它符合冪等性。安全性是指對資料庫操作沒有改變資料庫中的資料。
3. 從其他層面來看，GET 請求能夠被快取，GET 請求能夠儲存在瀏覽器的瀏覽記錄裡，GET 請求的 URL 能夠儲存為瀏覽器書籤。這些都是 POST 請求所不具備的。快取是 GET 請求被廣泛應用的根本，他能夠被快取也是因為它的冪等性和安全性，除了返回結果沒有其他多餘的動作，因此絕大部分的 GET 請求都被 CDN 快取起來了，大大減少了 Web 伺服器的負擔。

11.GET 的長度限制是多少？

HTTP中的GET方法是通過URL傳遞資料的，但是URL本身其實並沒有對資料的長度進行限制，真正限制GET長度的是瀏覽器。

例如IE瀏覽器對URL的最大限制是2000多個字元，大概2kb左右，像Chrome、Firefox等瀏覽器支援的URL字元數更多，其中FireFox中URL的最大長度限制是65536個字元，Chrome則是8182個字元。

這個長度限制也不是針對資料部分，而是針對整個URL。

12.HTTP 請求的過程與原理？

HTTP協議定義了瀏覽器怎麼向伺服器請求文件，以及伺服器怎麼把文件傳給瀏覽器。

• 每個伺服器都有一個程式，它不斷監聽TCP的埠80，以便發現是否有瀏覽器向它發出連線建立請求
• 監聽到連線請求，就會建立TCP連線
• 瀏覽器向伺服器發出瀏覽某個頁面的請求，伺服器接著就返回所請求的頁面作為響應
• 最後，釋放TCP連線

在瀏覽器和伺服器之間的請求和響應的互動，必須按照規定的格式和遵循一定的規則，這些格式和規則就是超文字傳輸協議HTTP。

PS:這道題和上面瀏覽器輸入網址發生了什麼那道題大差不差。

13.說一下HTTP的報文結構？

HTTP報文有兩種，HTTP請求報文和HTTP響應報文：

HTTP請求報文

HTTP 請求報文的格式如下：

GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*

HTTP 請求報文的第一行叫做請求行，後面的行叫做首部行，首部行後還可以跟一個實體主體。請求首部之後有一個空行，這個空行不能省略，它用來劃分首部與實體。

請求行包含三個欄位：

• 方法欄位：包括POST、GET等請方法。
• URL 欄位
• HTTP 版本欄位。

HTTP 響應報文

HTTP 響應報文的格式如下：

HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84
<html>
  <body>Hello World</body>
</html>

HTTP 響應報文的第一行叫做狀態行，後面的行是首部行，最後是實體主體。

• 狀態行包含了三個欄位：協議版本欄位、狀態碼和相應的狀態資訊。
• 實體部分是報文的主要部分，它包含了所請求的物件。
• 首部行首部可以分為四種首部，請求首部、響應首部、通用首部和實體首部。通用首部和實體首部在請求報文和響應報文中都可以設定，區別在於請求首部和響應首部。
  • 常見的請求首部有 Accept 可接收媒體資源的型別、Accept-Charset 可接收的字符集、Host 請求的主機名。
  • 常見的響應首部有 ETag 資源的匹配資訊，Location 客戶端重定向的 URI。
  • 常見的通用首部有 Cache-Control 控制快取策略、Connection 管理持久連線。
  • 常見的實體首部有 Content-Length 實體主體的大小、Expires 實體主體的過期時間、Last-Modified 資源的最後修改時間。

14.URI 和 URL 有什麼區別?

• URI，統一資源識別符號(Uniform Resource Identifier， URI)，標識的是Web上每一種可用的資源，如 HTML文件、影像、視訊片段、程式等都是由一個URI進行標識的。

• URL，統一資源定位符（Uniform Resource Location)，它是URI的一種子集，主要作用是提供資源的路徑。

它們的主要區別在於，URL除了提供了資源的標識，還提供了資源訪問的方式。這麼比喻，URI 像是身份證，可以唯一標識一個人，而 URL 更像一個住址，可以通過 URL 找到這個人——人類住址協議://地球/中國/北京市/海淀區/xx職業技術學院/14號宿舍樓/525號寢/張三.男。

15.說下 HTTP/1.0，1.1，2.0 的區別？

關鍵需要記住 HTTP/1.0 預設是短連線，可以強制開啟，HTTP/1.1 預設長連線，HTTP/2.0 採用多路複用。

HTTP/1.0

• 預設使用短連線，每次請求都需要建立一個 TCP 連線。它可以設定Connection: keep-alive 這個欄位，強制開啟長連線。

HTTP/1.1

• 引入了持久連線，即 TCP 連線預設不關閉，可以被多個請求複用。

• 分塊傳輸編碼，即服務端每產生一塊資料，就傳送一塊，用” 流模式” 取代” 快取模式”。

• 管道機制，即在同一個 TCP 連線裡面，客戶端可以同時傳送多個請求。

HTTP/2.0

• 二進位制協議，1.1 版本的頭資訊是文字（ASCII 編碼），資料體可以是文字或者二進位制；2.0 中，頭資訊和資料體都是二進位制。
• 完全多路複用，在一個連線裡，客戶端和瀏覽器都可以同時傳送多個請求或回應，而且不用按照順序一一對應。
• 報頭壓縮，HTTP 協議不帶有狀態，每次請求都必須附上所有資訊。Http/2.0 引入了頭資訊壓縮機制，使用 gzip 或 compress 壓縮後再傳送。
• 服務端推送，允許伺服器未經請求，主動向客戶端傳送資源。

16.HTTP/3瞭解嗎？

HTTP/3主要有兩大變化，傳輸層基於UDP、使用QUIC保證UDP可靠性。

HTTP/2存在的一些問題，比如重傳等等，都是由於TCP本身的特性導致的，所以HTTP/3在QUIC的基礎上進行發展而來，QUIC（Quick UDP Connections）直譯為快速UDP網路連線，底層使用UDP進行資料傳輸。

HTTP/3主要有這些特點：

• 使用UDP作為傳輸層進行通訊
• 在UDP的基礎上QUIC協議保證了HTTP/3的安全性，在傳輸的過程中就完成了TLS加密握手
• HTTPS 要建⽴⼀個連線，要花費 6 次互動，先是建⽴三次握⼿，然後是 TLS/1.3 的三次握⼿。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次互動合併成了 3 次，減少了互動次數。
• QUIC 有⾃⼰的⼀套機制可以保證傳輸的可靠性的。當某個流發⽣丟包時，只會阻塞這個流，其他流不會受到影響。

我們拿一張圖看一下HTTP協議的變遷：

17.HTTP 如何實現長連線？在什麼時候會超時？

什麼是 HTTP 的長連線？

1. HTTP 分為長連線和短連線，本質上說的是 TCP 的長短連線。TCP 連線是一個雙向的通道，它是可以保持一段時間不關閉的，因此 TCP 連線才具有真正的長連線和短連線這一說法。

2. TCP 長連線可以複用一個 TCP 連線，來發起多次的 HTTP 請求，這樣就可以減少資源消耗，比如一次請求 HTML，如果是短連線的話，可能還需要請求後續的 JS/CSS。

如何設定長連線？

通過在頭部（請求和響應頭）設定 Connection 欄位指定為keep-alive，HTTP/1.0 協議支援，但是是預設關閉的，從 HTTP/1.1 以後，連線預設都是長連線。

在什麼時候會超時呢？

• HTTP 一般會有 httpd 守護程式，裡面可以設定 keep-alive timeout，當 tcp 連線閒置超過這個時間就會關閉，也可以在 HTTP 的 header 裡面設定超時時間

• TCP 的 keep-alive 包含三個引數，支援在系統核心的 net.ipv4 裡面設定；當 TCP 連線之後，閒置了 tcp_keepalive_time，則會發生偵測包，如果沒有收到對方的 ACK，那麼會每隔 tcp_keepalive_intvl 再發一次，直到傳送了 tcp_keepalive_probes，就會丟棄該連線。

1. tcp_keepalive_intvl = 15
2. tcp_keepalive_probes = 5
3. tcp_keepalive_time = 1800

18.說說HTTP 與 HTTPS 有哪些區別？

1. HTTP 是超⽂本傳輸協議，資訊是明⽂傳輸，存在安全⻛險的問題。HTTPS 則解決 HTTP 不安全的缺陷，在TCP 和 HTTP ⽹絡層之間加⼊了 SSL/TLS 安全協議，使得報⽂能夠加密傳輸。

2. HTTP 連線建⽴相對簡單， TCP 三次握⼿之後便可進⾏ HTTP 的報⽂傳輸。⽽ HTTPS 在 TCP 三次握⼿之後，還需進⾏ SSL/TLS 的握⼿過程，才可進⼊加密報⽂傳輸。

3. HTTP 的端⼝號是 80，HTTPS 的端⼝號是 443。

4. HTTPS 協議需要向 CA（證書權威機構）申請數字證書，來保證伺服器的身份是可信的。

19.為什麼要用HTTPS？解決了哪些問題？

因為HTTP 是明⽂傳輸，存在安全上的風險：

竊聽⻛險，⽐如通訊鏈路上可以獲取通訊內容，使用者賬號被盜。

篡改⻛險，⽐如強制植⼊垃圾⼴告，視覺汙染。

冒充⻛險，⽐如冒充淘寶⽹站，使用者金錢損失。

所以引入了HTTPS，HTTPS 在 HTTP 與 TCP 層之間加⼊了 SSL/TLS 協議，可以很好的解決了這些風險：

• 資訊加密：互動資訊⽆法被竊取。

• 校驗機制：⽆法篡改通訊內容，篡改了就不能正常顯示。

• 身份證書：能證明淘寶是真淘寶。

所以SSL/TLS 協議是能保證通訊是安全的。

20.HTTPS工作流程是怎樣的？

這道題有幾個要點：公私鑰、數字證書、加密、對稱加密、非對稱加密。

HTTPS 主要工作流程：

1. 客戶端發起 HTTPS 請求，連線到服務端的 443 埠。
2. 服務端有一套數字證書（證書內容有公鑰、證書頒發機構、失效日期等）。
3. 服務端將自己的數字證書傳送給客戶端（公鑰在證書裡面，私鑰由伺服器持有）。
4. 客戶端收到數字證書之後，會驗證證書的合法性。如果證書驗證通過，就會生成一個隨機的對稱金鑰，用證書的公鑰加密。
5. 客戶端將公鑰加密後的金鑰傳送到伺服器。
6. 伺服器接收到客戶端發來的密文金鑰之後，用自己之前保留的私鑰對其進行非對稱解密，解密之後就得到客戶端的金鑰，然後用客戶端金鑰對返回資料進行對稱加密，醬紫傳輸的資料都是密文啦。
7. 伺服器將加密後的密文返回到客戶端。
8. 客戶端收到後，用自己的金鑰對其進行對稱解密，得到伺服器返回的資料。

這裡還畫了一張更詳盡的圖：

21.客戶端怎麼去校驗證書的合法性？

首先，服務端的證書從哪來的呢？

為了讓服務端的公鑰被⼤家信任，服務端的證書都是由 CA （Certificate Authority，證書認證機構）簽名的，CA就是⽹絡世界⾥的公安局、公證中⼼，具有極⾼的可信度，所以由它來給各個公鑰簽名，信任的⼀⽅簽發的證書，那必然證書也是被信任的。

CA 簽發證書的過程，如上圖左邊部分：

• ⾸先 CA 會把持有者的公鑰、⽤途、頒發者、有效時間等資訊打成⼀個包，然後對這些資訊進⾏ Hash 計算，得到⼀個 Hash 值；

• 然後 CA 會使⽤⾃⼰的私鑰將該 Hash 值加密，⽣成 Certificate Signature，也就是 CA 對證書做了簽名；

• 最後將 Certificate Signature 新增在⽂件證書上，形成數字證書；

客戶端校驗服務端的數字證書的過程，如上圖右邊部分：

• ⾸先客戶端會使⽤同樣的 Hash 演算法獲取該證書的 Hash 值 H1；
• 通常瀏覽器和作業系統中整合了 CA 的公鑰資訊，瀏覽器收到證書後可以使⽤ CA 的公鑰解密 Certificate
• Signature 內容，得到⼀個 Hash 值 H2 ；
• 最後⽐較 H1 和 H2，如果值相同，則為可信賴的證書，否則則認為證書不可信。

假如在HTTPS的通訊過程中，中間人篡改了證書原文，由於他沒有CA機構的私鑰，所以CA公鑰解密的內容就不一致。

22.如何理解 HTTP 協議是無狀態的？

這個無狀態的的狀態值的是什麼？是客戶端的狀態，所以字面意思，就是HTTP協議中服務端不會儲存客戶端的任何資訊。

比如當瀏覽器第一次傳送請求給伺服器時，伺服器響應了；如果同個瀏覽器發起第二次請求給伺服器時，它還是會響應，但是呢，伺服器不知道你就是剛才的那個瀏覽器。

那有什麼辦法記錄狀態呢？

主要有兩個辦法，Session和Cookie。

23.說說Session 和 Cookie 有什麼聯絡和區別?

先來看看什麼是 Session 和 Cookie ：

• Cookie 是儲存在客戶端的一小塊文字串的資料。客戶端向伺服器發起請求時，服務端會向客戶端傳送一個 Cookie，客戶端就把 Cookie 儲存起來。在客戶端下次向同一伺服器再發起請求時，Cookie 被攜帶傳送到伺服器。服務端可以根據這個Cookie判斷使用者的身份和狀態。
• Session 指的就是伺服器和客戶端一次會話的過程。它是另一種記錄客戶狀態的機制。不同的是cookie儲存在客戶端瀏覽器中，而session儲存在伺服器上。客戶端瀏覽器訪問伺服器的時候，伺服器把客戶端資訊以某種形式記錄在伺服器上，這就是session。客戶端瀏覽器再次訪問時只需要從該session中查詢使用者的狀態。

Session 和 Cookie 到底有什麼不同呢？

• 儲存位置不一樣，Cookie 儲存在客戶端，Session 儲存在伺服器端。

• 儲存資料型別不一樣，Cookie 只能儲存ASCII，Session可以存任意資料型別，一般情況下我們可以在 Session 中保持一些常用變數資訊，比如說 UserId 等。

• 有效期不同，Cookie 可設定為長時間保持，比如我們經常使用的預設登入功能，Session 一般有效時間較短，客戶端關閉或者 Session 超時都會失效。

• 隱私策略不同，Cookie 儲存在客戶端，比較容易遭到不法獲取，早期有人將使用者的登入名和密碼儲存在 Cookie 中導致資訊被竊取；Session 儲存在服務端，安全性相對 Cookie 要好一些。

• 儲存大小不同， 單個Cookie儲存的資料不能超過4K，Session可儲存資料遠高於 Cookie。

Session 和 Cookie有什麼關聯呢？

可以使用Cookie記錄Session的標識。

• 使用者第一次請求伺服器時，伺服器根據使用者提交的資訊，建立對應的 Session，請求返回時將此 Session 的唯一標識資訊 SessionID 返回給瀏覽器，瀏覽器接收到伺服器返回的 SessionID 資訊後，會將此資訊存入 Cookie 中，同時 Cookie 記錄此 SessionID 是屬於哪個域名。
• 當使用者第二次訪問伺服器時，請求會自動判斷此域名下是否存在 Cookie 資訊，如果存在，則自動將 Cookie 資訊也傳送給服務端，服務端會從 Cookie 中獲取 SessionID，再根據 SessionID 查詢對應的 Session 資訊，如果沒有找到，說明使用者沒有登入或者登入失效，如果找到 Session 證明使用者已經登入可執行後面操作。

分散式環境下Session怎麼處理呢？

分散式環境下，客戶端請求經過負載均衡，可能會分配到不同的伺服器上，假如一個使用者的請求兩次沒有落到同一臺伺服器上，那麼在新的伺服器上就沒有記錄使用者狀態的Session。

這時候怎麼辦呢？

可以使用Redis等分散式快取來儲存Session，在多臺伺服器之間共享。

客戶端無法使用Cookie怎麼辦？

有可能客戶端無法使用Cookie，比如瀏覽器禁用Cookie，或者客戶端是安卓、IOS等等。

這時候怎麼辦？SessionID怎麼存？怎麼傳給服務端呢？

首先是SessionID的儲存，可以使用客戶端的本地儲存，比如瀏覽器的sessionStorage。

接下來怎麼傳呢？

• 拼接到URL裡：直接把SessionID作為URL的請求引數
• 放到請求頭裡：把SessionID放到請求的Header裡，比較常用。

TCP

24.詳細說一下 TCP 的三次握手機制

PS:TCP三次握手是最重要的知識點，一定要熟悉到問到即送分。

TCP提供面向連線的服務，在傳送資料前必須建立連線，TCP連線是通過三次握手建立的。

三次握手的過程：

• 最開始，客戶端和服務端都處於CLOSE狀態，服務端監聽客戶端的請求，進入LISTEN狀態

• 客戶端端傳送連線請求，第一次握手 (SYN=1, seq=x)，傳送完畢後，客戶端就進入 SYN_SENT 狀態
• 服務端確認連線，第二次握手 (SYN=1, ACK=1, seq=y, ACKnum=x+1)， 傳送完畢後，伺服器端就進入 SYN_RCV 狀態。

• 客戶端收到服務端的確認之後，再次向服務端確認，這就是第三次握手 (ACK=1，ACKnum=y+1)，傳送完畢後，客戶端進入 ESTABLISHED 狀態，當伺服器端接收到這個包時，也進入 ESTABLISHED 狀態。

TCP三次握手通俗比喻：

在二十年前的農村，電話沒有普及，手機就更不用說了，所以，通訊基本靠吼。

老張和老王是鄰居，這天老張下地了，結果家裡有事，熱心的鄰居老王趕緊跑到村口，開始叫喚老王。

• 老王：老張唉！我是老王，你能聽到嗎？

• 老張一聽，是老王的聲音：老王老王，我是老張，我能聽到，你能聽到嗎？

• 老王一聽，嗯，沒錯，是老張：老張，我聽到了，我有事要跟你說。

  "你老婆要生了，趕緊回家吧！"

老張風風火火地趕回家，老婆順利地生了個帶把的大胖小子。握手的故事充滿了幸福和美滿。

25.TCP 握手為什麼是三次，為什麼不能是兩次？不能是四次？

為什麼不能是兩次？

• 為了防止伺服器端開啟一些無用的連線增加伺服器開銷
• 防止已失效的連線請求報文段突然又傳送到了服務端，因而產生錯誤。

由於網路傳輸是有延時的(要通過網路光纖和各種中間代理伺服器)，在傳輸的過程中，比如客戶端發起了 SYN=1 的第一次握手。

如果伺服器端就直接建立了這個連線並返回包含 SYN、ACK 和 Seq 等內容的資料包給客戶端，這個資料包因為網路傳輸的原因丟失了，丟失之後客戶端就一直沒有接收到伺服器返回的資料包。

如果沒有第三次握手告訴伺服器端客戶端收的到伺服器端傳輸的資料的話，伺服器端是不知道客戶端有沒有接收到伺服器端返回的資訊的。

服務端就認為這個連線是可用的，埠就一直開著，等到客戶端因超時重新發出請求時，伺服器就會重新開啟一個埠連線。這樣一來，就會有很多無效的連線埠白白地開著，導致資源的浪費。

還有一種情況是已經失效的客戶端發出的請求資訊，由於某種原因傳輸到了伺服器端，伺服器端以為是客戶端發出的有效請求，接收後產生錯誤。

所以我們需要“第三次握手”來確認這個過程：

通過第三次握手的資料告訴服務端，客戶端有沒有收到伺服器“第二次握手”時傳過去的資料，以及這個連線的序號是不是有效的。若傳送的這個資料是“收到且沒有問題”的資訊，接收後伺服器就正常建立 TCP 連線，否則建立 TCP 連線失敗，伺服器關閉連線埠。由此減少伺服器開銷和接收到失效請求發生的錯誤。

為什麼不是四次？

簡單說，就是三次揮手已經足夠建立可靠的連線，沒有必要再多一次握手導致花費更多的時間建立連線。

26.三次握手中每一次沒收到報文會發生什麼情況？

• 第一次握手服務端未收到SYN報文

  服務端不會進行任何的動作，而客戶端由於一段時間內沒有收到服務端發來的確認報文，等待一段時間後會重新傳送SYN報文，如果仍然沒有回應，會重複這個過程，直到傳送次數超過最大重傳次數限制，就會返回連線建立失敗。

• 第二次握手客戶端未收到服務端響應的ACK報文

  客戶端會繼續重傳，直到次數限制；而服務端此時會阻塞在accept()處，等待客戶端傳送ACK報文

• 第三次握手服務端為收到客戶端傳送過來的ACK報文

  服務端同樣會採用類似客戶端的超時重傳機制，如果重試次數超過限制，則accept()呼叫返回-1，服務端建立連線失敗；而此時客戶端認為自己已經建立連線成功，因此開始向服務端傳送資料，但是服務端的accept()系統呼叫已經返回，此時不在監聽狀態，因此服務端接收到客戶端傳送來的資料時會傳送RST報文給客戶端，消除客戶端單方面建立連線的狀態。

27.第二次握手傳回了 ACK，為什麼還要傳回 SYN？

ACK是為了告訴客戶端傳來的資料已經接收無誤。

而傳回SYN是為了告訴客戶端，服務端響應的確實是客戶端傳送的報文。

28.第3次握手可以攜帶資料嗎？

第3次握手是可以攜帶資料的。

此時客戶端已經處於ESTABLISHED狀態。對於客戶端來說，它已經建立連線成功，並且確認服務端的接收和傳送能力是正常的。

第一次握手不能攜帶資料是出於安全的考慮，因為如果允許攜帶資料，攻擊者每次在SYN報文中攜帶大量資料，就會導致服務端消耗更多的時間和空間去處理這些報文，會造成CPU和記憶體的消耗。

29.說說半連線佇列和 SYN Flood 攻擊的關係？

什麼是半連線佇列？

TCP 進入三次握手前，服務端會從 CLOSED 狀態變為 LISTEN 狀態, 同時在內部建立了兩個佇列：半連線佇列（SYN 佇列）和全連線佇列（ACCEPT 佇列）。

顧名思義，半連線佇列存放的是三次握手未完成的連線，全連線佇列存放的是完成三次握手的連線。

• TCP 三次握手時，客戶端傳送 SYN 到服務端，服務端收到之後，便回覆 ACK 和 SYN，狀態由 LISTEN 變為 SYN_RCVD，此時這個連線就被推入了 SYN 佇列，即半連線佇列。
• 當客戶端回覆 ACK, 服務端接收後，三次握手就完成了。這時連線會等待被具體的應用取走，在被取走之前，它被推入 ACCEPT 佇列，即全連線佇列。

什麼是SYN Flood ？

SYN Flood 是一種典型的 DDos 攻擊，它在短時間內，偽造不存在的 IP 地址, 向伺服器傳送大量SYN 報文。當伺服器回覆 SYN+ACK 報文後，不會收到 ACK 回應報文，那麼SYN佇列裡的連線舊不會出對隊，久⽽久之就會佔滿服務端的 SYN 接收佇列（半連線佇列），使得伺服器不能為正常⽤戶服務。

那有什麼應對方案呢？

主要有 syn cookie 和 SYN Proxy 防火牆等。

• syn cookie：在收到 SYN 包後，伺服器根據一定的方法，以資料包的源地址、埠等資訊為引數計算出一個 cookie 值作為自己的 SYNACK 包的序列號，回覆 SYN+ACK 後，伺服器並不立即分配資源進行處理，等收到傳送方的 ACK 包後，重新根據資料包的源地址、埠計算該包中的確認序列號是否正確，如果正確則建立連線，否則丟棄該包。

• SYN Proxy 防火牆：伺服器防火牆會對收到的每一個 SYN 報文進行代理和回應，並保持半連線。等傳送方將 ACK 包返回後，再重新構造 SYN 包發到伺服器，建立真正的 TCP 連線。

30.說說 TCP 四次揮手的過程？

PS：問完三次握手，常常也會順道問問四次揮手，所以也是必須掌握知識點。

TCP 四次揮手過程：

• 資料傳輸結束之後，通訊雙方都可以主動發起斷開連線請求，這裡假定客戶端發起

• 客戶端傳送釋放連線報文，第一次揮手 (FIN=1，seq=u)，傳送完畢後，客戶端進入 FIN_WAIT_1 狀態。

• 服務端傳送確認報文，第二次揮手 (ACK=1，ack=u+1,seq =v)，傳送完畢後，伺服器端進入 CLOSE_WAIT 狀態，客戶端接收到這個確認包之後，進入 FIN_WAIT_2 狀態。

• 服務端傳送釋放連線報文，第三次揮手 (FIN=1，ACK1,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 狀態。

大白話說四次揮手：

假如單身狗博主有一個女朋友—由於博主上班九九六，下班肝部落格，導致沒有時間陪女朋友，女朋友忍無可忍。

• 女朋友：狗男人，最近你都不理我，你是不是不愛我了？你是不是外面有別的狗子了？我要和你分手？
• 沙雕博主一愣，怒火攻心：分手就分手，不陪你鬧了，等我把東西收拾收拾。

沙雕博主小心翼翼地裝起了自己的青軸機械鍵盤。

• 哼，蠢女人，我已經收拾完了，我先滾為敬，再見！
• 女朋友：滾，滾的遠遠的，越遠越好，我一輩子都不想再見到你。

揮手的故事總充滿了悲傷和遺憾！

31.TCP 揮手為什麼需要四次呢？

再來回顧下四次揮手雙方發 FIN 包的過程，就能理解為什麼需要四次了。

• 關閉連線時，客戶端向服務端傳送 FIN 時，僅僅表示客戶端不再傳送資料了但是還能接收資料。
• 服務端收到客戶端的 FIN 報文時，先回一個 ACK 應答報文，而服務端可能還有資料需要處理和傳送，等服務端不再傳送資料時，才傳送 FIN 報文給客戶端來表示同意現在關閉連線。

從上面過程可知，服務端通常需要等待完成資料的傳送和處理，所以服務端的 ACK 和 FIN 一般都會分開傳送，從而比三次握手導致多了一次。

32.TCP 四次揮手過程中，為什麼需要等待 2MSL, 才進入 CLOSED 關閉狀態？

為什麼需要等待？

1. 為了保證客戶端傳送的最後一個 ACK 報文段能夠到達服務端。 這個 ACK 報文段有可能丟失，因而使處在 LAST-ACK 狀態的服務端就收不到對已傳送的 FIN + ACK 報文段的確認。服務端會超時重傳這個 FIN+ACK 報文段，而客戶端就能在 2MSL 時間內（超時 + 1MSL 傳輸）收到這個重傳的 FIN+ACK 報文段。接著客戶端重傳一次確認，重新啟動 2MSL 計時器。最後，客戶端和伺服器都正常進入到 CLOSED 狀態。

2. 防止已失效的連線請求報文段出現在本連線中。客戶端在傳送完最後一個 ACK 報文段後，再經過時間 2MSL，就可以使本連線持續的時間內所產生的所有報文段都從網路中消失。這樣就可以使下一個連線中不會出現這種舊的連線請求報文段。

為什麼等待的時間是2MSL？

MSL 是 Maximum Segment Lifetime，報⽂最⼤⽣存時間，它是任何報⽂在⽹絡上存在的最⻓時間，超過這個時間報⽂將被丟棄。

TIME_WAIT 等待 2 倍的 MSL，⽐較合理的解釋是： ⽹絡中可能存在來⾃傳送⽅的資料包，當這些傳送⽅的資料包被接收⽅處理後⼜會向對⽅傳送響應，所以⼀來⼀回需要等待 2 倍的時間。

⽐如如果被動關閉⽅沒有收到斷開連線的最後的 ACK 報⽂，就會觸發超時重發 Fin 報⽂，另⼀⽅接收到 FIN 後，會重發 ACK 給被動關閉⽅， ⼀來⼀去正好 2 個 MSL。

33.保活計時器有什麼用？

除時間等待計時器外，TCP 還有一個保活計時器（keepalive timer）。

設想這樣的場景：客戶已主動與伺服器建立了 TCP 連線。但後來客戶端的主機突然發生故障。顯然，伺服器以後就不能再收到客戶端發來的資料。因此，應當有措施使伺服器不要再白白等待下去。這就需要使用保活計時器了。

伺服器每收到一次客戶端的資料，就重新設定保活計時器，時間的設定通常是兩個小時。若兩個小時都沒有收到客戶端的資料，服務端就傳送一個探測報文段，以後則每隔 75 秒鐘傳送一次。若連續傳送 10 個探測報文段後仍然無客戶端的響應，服務端就認為客戶端出了故障，接著就關閉這個連線。

34.CLOSE-WAIT 和 TIME-WAIT 的狀態和意義？

CLOSE-WAIT狀態有什麼意義？

服務端收到客戶端關閉連線的請求並確認之後，就會進入CLOSE-WAIT狀態。此時服務端可能還有一些資料沒有傳輸完成，因此不能立即關閉連線，而CLOSE-WAIT狀態就是為了保證服務端在關閉連線之前將待傳送的資料處理完。

TIME-WAIT有什麼意義？

TIME-WAIT狀態發生在第四次揮手，當客戶端向服務端傳送ACK確認報文後進入TIME-WAIT狀態。

它存在的意義主要是兩個：

• 防⽌舊連線的資料包

  如果客戶端收到服務端的FIN報文之後立即關閉連線，但是此時服務端對應的埠並沒有關閉，如果客戶端在相同埠建立新的連線，可能會導致新連線收到舊連線殘留的資料包，導致不可預料的異常發生。

• 保證連線正確關閉

  假設客戶端最後一次傳送的ACK包在傳輸的時候丟失了，由於TCP協議的超時重傳機制，服務端將重發FIN報文，如果客戶端沒有維持TIME-WAIT狀態而直接關閉的話，當收到服務端重新傳送的FIN包時，客戶端就會使用RST包來響應服務端，導致服務端以為有錯誤發生，然而實際關閉連線過程是正常的。

35.TIME_WAIT 狀態過多會導致什麼問題？怎麼解決？

TIME_WAIT 狀態過多會導致什麼問題?

如果伺服器有處於 TIME-WAIT 狀態的 TCP，則說明是由伺服器⽅主動發起的斷開請求。

過多的 TIME-WAIT 狀態主要的危害有兩種：

第⼀是記憶體資源佔⽤；

第⼆是對端⼝資源的佔⽤，⼀個 TCP 連線⾄少消耗⼀個本地端⼝；

怎麼解決TIME_WAIT 狀態過多？

• 伺服器可以設定SO_REUSEADDR套接字來通知核心，如果埠被佔用，但是TCP連線位於TIME_WAIT 狀態時可以重用埠。
• 還可以使用長連線的方式來減少TCP的連線和斷開，在長連線的業務裡往往不需要考慮TIME_WAIT狀態。

36.說說 TCP 報文首部的格式？

看一下TCP報文首部的格式：

• 16 位埠號：源埠號，主機該報文段是來自哪裡；目標埠號，要傳給哪個上層協議或應用程式

• 32 位序號：一次 TCP 通訊（從 TCP 連線建立到斷開）過程中某一個傳輸方向上的位元組流的每個位元組的編號。

• 32 位確認號：用作對另一方傳送的 tcp 報文段的響應。其值是收到的 TCP 報文段的序號值加 1。

• 4 位首部長度：表示 tcp 頭部有多少個 32bit 字（4 位元組）。因為 4 位最大能標識 15，所以 TCP 頭部最長是 60 位元組。

• 6 位標誌位：URG(緊急指標是否有效)，ACk（表示確認號是否有效），PST（緩衝區尚未填滿），RST（表示要求對方重新建立連線），SYN（建立連線訊息標誌接），FIN（表示告知對方本端要關閉連線了）

• 16 位視窗大小：是 TCP 流量控制的一個手段。這裡說的視窗，指的是接收通告視窗。它告訴對方本端的 TCP 接收緩衝區還能容納多少位元組的資料，這樣對方就可以控制傳送資料的速度。

• 16 位校驗和：由傳送端填充，接收端對 TCP 報文段執行 CRC 演算法以檢驗 TCP 報文段在傳輸過程中是否損壞。注意，這個校驗不僅包括 TCP 頭部，也包括資料部分。這也是 TCP 可靠傳輸的一個重要保障。

• 16 位緊急指標：一個正的偏移量。它和序號欄位的值相加表示最後一個緊急資料的下一位元組的序號。因此，確切地說，這個欄位是緊急指標相對當前序號的偏移，不妨稱之為緊急偏移。TCP 的緊急指標是傳送端向接收端傳送緊急資料的方法。

37.TCP 是如何保證可靠性的？

TCP主要提供了檢驗和、序列號/確認應答、超時重傳、最大訊息長度、滑動視窗控制等方法實現了可靠性傳輸。

1. 連線管理：TCP使用三次握手和四次揮手保證可靠地建立連線和釋放連線，這裡就不用多說了。

2. 校驗和：TCP 將保持它首部和資料的檢驗和。這是一個端到端的檢驗和，目的是檢測資料在傳輸過程中的任何變化。如果接收端的檢驗和有差錯，TCP 將丟棄這個報文段和不確認收到此報文段。

1. 序列號/確認應答：TCP 給傳送的每一個包進行編號，接收方會對收到的包進行應答，傳送方就會知道接收方是否收到對應的包，如果發現沒有收到，就會重發，這樣就能保證資料的完整性。就像老師上課，會問一句，這一章聽懂了嗎？沒聽懂再講一遍。

1. 流量控制：TCP 連線的每一方都有固定大小的緩衝空間，TCP的接收端只允許傳送端傳送接收端緩衝區能接納的資料。當接收方來不及處理髮送方的資料，能提示傳送方降低傳送的速率，防止包丟失。TCP 使用的流量控制協議是可變大小的滑動視窗協議。 （TCP 利用滑動視窗實現流量控制）

1. 最大訊息長度：在建立TCP連線的時候，雙方約定一個最大的長度（MSS）作為傳送的單位，重傳的時候也是以這個單位來進行重傳。理想的情況下是該長度的資料剛好不被網路層分塊。

1. 超時重傳：超時重傳是指傳送出去的資料包到接收到確認包之間的時間，如果超過了這個時間會被認為是丟包了，需要重傳。

1. 擁塞控制：如果網路非常擁堵，此時再傳送資料就會加重網路負擔，那麼傳送的資料段很可能超過了最大生存時間也沒有到達接收方，就會產生丟包問題。為此TCP引入慢啟動機制，先發出少量資料，就像探路一樣，先摸清當前的網路擁堵狀態後，再決定按照多大的速度傳送資料。

38.說說 TCP 的流量控制？

TCP 提供了一種機制，可以讓傳送端根據接收端的實際接收能力控制傳送的資料量，這就是流量控制。

TCP 通過滑動視窗來控制流量，我們看下簡要流程：

• 首先雙方三次握手，初始化各自的視窗大小，均為 400 個位元組。

• 假如當前傳送方給接收方傳送了 200 個位元組，那麼，傳送方的SND.NXT會右移 200 個位元組，也就是說當前的可用視窗減少了 200 個位元組。
• 接受方收到後，放到緩衝佇列裡面，REV.WND =400-200=200 位元組，所以 win=200 位元組返回給傳送方。接收方會在 ACK 的報文首部帶上縮小後的滑動視窗 200 位元組
• 傳送方又傳送 200 位元組過來，200 位元組到達，繼續放到緩衝佇列。不過這時候，由於大量負載的原因，接受方處理不了這麼多位元組，只能處理 100 位元組，剩餘的 100 位元組繼續放到緩衝佇列。這時候，REV.WND = 400-200-100=100 位元組，即 win=100 返回傳送方。
• 傳送方繼續傳送 100 位元組過來，這時候，接收視窗 win 變為 0。
• 傳送方停止傳送，開啟一個定時任務，每隔一段時間，就去詢問接受方，直到 win 大於 0，才繼續開始傳送。

39.詳細說說 TCP 的滑動視窗？

TCP 傳送一個資料，如果需要收到確認應答，才會傳送下一個資料。這樣的話就會有個缺點：效率會比較低。

“用一個比喻，我們在微信上聊天，你打完一句話，我回復一句之後，你才能打下一句。假如我沒有及時回覆呢？你是把話憋著不說嗎？然後傻傻等到我回復之後再接著發下一句？”

為了解決這個問題，TCP 引入了視窗，它是作業系統開闢的一個快取空間。視窗大小值表示無需等待確認應答，而可以繼續傳送資料的最大值。

TCP 頭部有個欄位叫 win，也即那個 16 位的視窗大小，它告訴對方本端的 TCP 接收緩衝區還能容納多少位元組的資料，這樣對方就可以控制傳送資料的速度，從而達到流量控制的目的。

“通俗點講，就是接受方每次收到資料包，在傳送確認報文的時候，同時告訴傳送方，自己的快取區還有多少空餘空間，緩衝區的空餘空間，我們就稱之為接受視窗大小。這就是 win。”

TCP 滑動視窗分為兩種: 傳送視窗和接收視窗。傳送端的滑動視窗包含四大部分，如下：

• 已傳送且已收到 ACK 確認
• 已傳送但未收到 ACK 確認
• 未傳送但可以傳送
• 未傳送也不可以傳送

• 深藍色框裡就是傳送視窗。

• SND.WND: 表示傳送視窗的大小, 上圖虛線框的格子數是 10個，即傳送視窗大小是 10。

• SND.NXT：下一個傳送的位置，它指向未傳送但可以傳送的第一個位元組的序列號。

• SND.UNA: 一個絕對指標，它指向的是已傳送但未確認的第一個位元組的序列號。

接收方的滑動視窗包含三大部分，如下：

• 已成功接收並確認
• 未收到資料但可以接收
• 未收到資料並不可以接收的資料

• 藍色框內，就是接收視窗。
• REV.WND: 表示接收視窗的大小, 上圖虛線框的格子就是 9 個。
• REV.NXT: 下一個接收的位置，它指向未收到但可以接收的第一個位元組的序列號。

40.瞭解Nagle 演算法和延遲確認嗎？

Nagle 演算法和延遲確認是幹什麼的？

當我們 TCP 報⽂的承載的資料⾮常⼩的時候，例如⼏個位元組，那麼整個⽹絡的效率是很低的，因為每個 TCP 報⽂中都會有 20 個位元組的 TCP 頭部，也會有 20 個位元組的 IP 頭部，⽽資料只有⼏個位元組，所以在整個報⽂中有效資料佔有的比例就會⾮常低。

這就好像快遞員開著⼤貨⻋送⼀個⼩包裹⼀樣浪費。

那麼就出現了常⻅的兩種策略，來減少⼩報⽂的傳輸，分別是：

• Nagle 演算法
• 延遲確認

Nagle 演算法

Nagle 演算法：任意時刻，最多隻能有一個未被確認的小段。所謂 “小段”，指的是小於 MSS 尺寸的資料塊，所謂 “未被確認”，是指一個資料塊傳送出去後，沒有收到對方傳送的 ACK 確認該資料已收到。

Nagle 演算法的策略：

• 沒有已傳送未確認報⽂時，⽴刻傳送資料。
• 存在未確認報⽂時，直到「沒有已傳送未確認報⽂」或「資料⻓度達到 MSS ⼤⼩」時，再傳送資料。

只要沒滿⾜上⾯條件中的⼀條，傳送⽅⼀直在囤積資料，直到滿⾜上⾯的傳送條件。

延遲確認

事實上當沒有攜帶資料的 ACK，它的⽹絡效率也是很低的，因為它也有 40 個位元組的 IP 頭 和 TCP 頭，但卻沒有攜帶資料包⽂。

為了解決 ACK 傳輸效率低問題，所以就衍⽣出了 TCP 延遲確認。

TCP 延遲確認的策略：

• 當有響應資料要傳送時，ACK 會隨著響應資料⼀起⽴刻傳送給對⽅

• 當沒有響應資料要傳送時，ACK 將會延遲⼀段時間，以等待是否有響應資料可以⼀起傳送

• 如果在延遲等待傳送 ACK 期間，對⽅的第⼆個資料包⽂⼜到達了，這時就會⽴刻傳送 ACK

一般情況下，Nagle 演算法和延遲確認不能一起使用，Nagle 演算法意味著延遲發，延遲確認意味著延遲接收，兩個湊在一起就會造成更大的延遲，會產生效能問題。

41.說說TCP 的擁塞控制？

什麼是擁塞控制？不是有了流量控制嗎？

前⾯的流量控制是避免傳送⽅的資料填滿接收⽅的快取，但是並不知道整個⽹絡之中發⽣了什麼。

⼀般來說，計算機⽹絡都處在⼀個共享的環境。因此也有可能會因為其他主機之間的通訊使得⽹絡擁堵。

在⽹絡出現擁堵時，如果繼續傳送⼤量資料包，可能會導致資料包時延、丟失等，這時 TCP 就會重傳資料，但是⼀重傳就會導致⽹絡的負擔更重，於是會導致更⼤的延遲以及更多的丟包，這個情況就會進⼊惡性迴圈被不斷地放⼤....

所以，TCP 不能忽略整個網路中發⽣的事，它被設計成⼀個⽆私的協議，當⽹絡傳送擁塞時，TCP 會⾃我犧牲，降低傳送的資料流。

於是，就有了擁塞控制，控制的⽬的就是避免傳送⽅的資料填滿整個⽹絡。

就像是一個水管，不能讓太多的水（資料流）流入水管，如果超過水管的承受能力，水管會被撐爆（丟包）。

傳送方維護一個擁塞視窗 cwnd（congestion window） 的變數，調節所要傳送資料的量。

什麼是擁塞窗⼝？和傳送窗⼝有什麼關係呢？

擁塞窗⼝ cwnd是傳送⽅維護的⼀個的狀態變數，它會根據⽹絡的擁塞程度動態變化的。

傳送窗⼝ swnd 和接收窗⼝ rwnd 是約等於的關係，那麼由於加⼊了擁塞窗⼝的概念後，此時傳送窗⼝的值是swnd = min(cwnd, rwnd)，也就是擁塞窗⼝和接收窗⼝中的最⼩值。

擁塞窗⼝ cwnd 變化的規則：

• 只要⽹絡中沒有出現擁塞， cwnd 就會增⼤；
• 但⽹絡中出現了擁塞， cwnd 就減少；

擁塞控制有哪些常用演算法？

擁塞控制主要有這幾種常用演算法：

• 慢啟動

• 擁塞避免

• 擁塞發生

• 快速恢復

慢啟動演算法

慢啟動演算法，慢慢啟動。

它表示 TCP 建立連線完成後，一開始不要傳送大量的資料，而是先探測一下網路的擁塞程度。由小到大逐漸增加擁塞視窗的大小，如果沒有出現丟包，每收到一個 ACK，就將擁塞視窗 cwnd 大小就加 1（單位是 MSS）。每輪次傳送視窗增加一倍，呈指數增長，如果出現丟包，擁塞視窗就減半，進入擁塞避免階段。

舉個例子：

• 連線建⽴完成後，⼀開始初始化 cwnd = 1 ，表示可以傳⼀個 MSS ⼤⼩的資料。
• 當收到⼀個 ACK 確認應答後，cwnd 增加 1，於是⼀次能夠傳送 2 個
• 當收到 2 個的 ACK 確認應答後， cwnd 增加 2，於是就可以⽐之前多發2 個，所以這⼀次能夠傳送 4 個
• 當這 4 個的 ACK 確認到來的時候，每個確認 cwnd 增加 1， 4 個確認 cwnd 增加 4，於是就可以⽐之前多發4 個，所以這⼀次能夠傳送 8 個。

發包的個數是指數性的增⻓。

為了防止 cwnd 增長過大引起網路擁塞，還需設定一個慢啟動閥值 ssthresh（slow start threshold）狀態變數。當cwnd到達該閥值後，就好像水管被關小了水龍頭一樣，減少擁塞狀態。即當 cwnd >ssthresh 時，進入了擁塞避免演算法。

擁塞避免演算法

一般來說，慢啟動閥值 ssthresh 是 65535 位元組，cwnd到達慢啟動閥值後

• 每收到一個 ACK 時，cwnd = cwnd + 1/cwnd

• 當每過一個 RTT 時，cwnd = cwnd + 1

顯然這是一個線性上升的演算法，避免過快導致網路擁塞問題。

接著上面慢啟動的例子，假定 ssthresh 為 8 ： ：

• 當 8 個 ACK 應答確認到來時，每個確認增加 1/8，8 個 ACK 確認 cwnd ⼀共增加 1，於是這⼀次能夠傳送 9個 MSS ⼤⼩的資料，變成了線性增⻓。

擁塞發生

當網路擁塞發生丟包時，會有兩種情況：

• RTO 超時重傳

• 快速重傳

如果是發生了 RTO 超時重傳，就會使用擁塞發生演算法

• 慢啟動閥值 sshthresh =  cwnd /2
• cwnd 重置為 1
• 進入新的慢啟動過程

這種方式就像是飆車的時候急剎車，還飛速倒車，這。。。

其實還有更好的處理方式，就是快速重傳。傳送方收到 3 個連續重複的 ACK 時，就會快速地重傳，不必等待 RTO 超時再重傳。

發⽣快速重傳的擁塞發⽣演算法：

• 擁塞視窗大小 cwnd = cwnd/2

• 慢啟動閥值 ssthresh = cwnd

• 進入快速恢復演算法

快速恢復

快速重傳和快速恢復演算法一般同時使用。快速恢復演算法認為，還有 3 個重複 ACK 收到，說明網路也沒那麼糟糕，所以沒有必要像 RTO 超時那麼強烈。

正如前面所說，進入快速恢復之前，cwnd 和 sshthresh 已被更新：

• cwnd = cwnd /2

- sshthresh = cwnd

然後，進⼊快速恢復演算法如下：

• cwnd = sshthresh  + 3
• 重傳重複的那幾個 ACK（即丟失的那幾個資料包）
• 如果再收到重複的 ACK，那麼 cwnd = cwnd +1
• 如果收到新資料的 ACK 後, cwnd = sshthresh。因為收到新資料的 ACK，表明恢復過程已經結束，可以再次進入了擁塞避免的演算法了。

42.說說 TCP 的重傳機制？

重傳包括超時重傳、快速重傳、帶選擇確認的重傳（SACK）、重複 SACK 四種。

超時重傳

超時重傳，是 TCP 協議保證資料可靠性的另一個重要機制，其原理是在傳送某一個資料以後就開啟一個計時器，在一定時間內如果沒有得到傳送的資料包的 ACK 報文，那麼就重新傳送資料，直到傳送成功為止。

超時時間應該設定為多少呢？

先來看下什麼叫 RTT（Round-Trip Time，往返時間）。

RTT 就是資料完全傳送完，到收到確認訊號的時間，即資料包的一次往返時間。

超時重傳時間，就是 RTO（Retransmission Timeout)。那麼，RTO 到底設定多大呢？

• 如果 RTO 設定很大，等了很久都沒重發，這樣肯定就不行。

• 如果 RTO 設定很小，那很可能資料都沒有丟失，就開始重發了，這會導致網路阻塞，從而惡性迴圈，導致更多的超時出現。

一般來說，RTO 略微大於 RTT，效果是最佳的。

其實，RTO 有個標準方法的計算公式，也叫 Jacobson / Karels 演算法。

1. 首先計算 SRTT（即計算平滑的 RTT）

SRTT = (1 - α) * SRTT + α * RTT  //求 SRTT 的加權平均

1. 其次，計算 RTTVAR (round-trip time variation)

RTTVAR = (1 - β) * RTTVAR + β * (|RTT - SRTT|) //計算 SRTT 與真實值的差距

1. 最後，得出最終的 RTO

RTO = µ * SRTT + ∂ * RTTVAR  =  SRTT + 4·RTTVAR  

在 Linux 下，α = 0.125，β = 0.25， μ = 1，∂ = 4。別問這些引數是怎麼來的，它們是大量實踐，調出的最優引數。

超時重傳不是十分完美的重傳方案，它有這些缺點：

• 當一個報文丟失時，會等待一定的超時週期，才重傳分組，增加了端到端的時延。
• 當一個報文丟失時，在其等待超時的過程中，可能會出現這種情況：其後的報文段已經被接收端接收但卻遲遲得不到確認，傳送端會認為也丟失了，從而引起不必要的重傳，既浪費資源也浪費時間。

並且，對於 TCP，如果發生一次超時重傳，時間間隔下次就會加倍。

快速重傳

TCP 還有另外⼀種快速重傳（Fast Retransmit）機制，它不以時間為驅動，⽽是以資料驅動重傳。

它不以時間驅動，而是以資料驅動。它是基於接收端的反饋資訊來引發重傳的。

可以用它來解決超時重發的時間等待問題，快速重傳流程如下：

在上圖，傳送⽅發出了 1，2，3，4，5 份資料：

• 第⼀份 Seq1 先送到了，於是就 Ack 回 2；

• 結果 Seq2 因為某些原因沒收到，Seq3 到達了，於是還是 Ack 回 2；

• 後⾯的 Seq4 和 Seq5 都到了，但還是 Ack 回 2，因為 Seq2 還是沒有收到；

• 傳送端收到了三個 Ack = 2 的確認，知道了 Seq2 還沒有收到，就會在定時器過期之前，重傳丟失的 Seq2。

• 最後，收到了 Seq2，此時因為 Seq3，Seq4，Seq5 都收到了，於是 Ack 回 6 。

快速重傳機制只解決了⼀個問題，就是超時時間的問題，但是它依然⾯臨著另外⼀個問題。就是重傳的時候，是重傳之前的⼀個，還是重傳所有的問題。

⽐如對於上⾯的例⼦，是重傳 Seq2 呢？還是重傳 Seq2、Seq3、Seq4、Seq5 呢？因為傳送端並不清楚這連續的三個 Ack 2 是誰傳回來的。

根據 TCP 不同的實現，以上兩種情況都是有可能的。可⻅，這是⼀把雙刃劍。

為了解決不知道該重傳哪些 TCP 報⽂，於是就有 SACK ⽅法。

帶選擇確認的重傳（SACK）

為了解決應該重傳多少個包的問題? TCP 提供了帶選擇確認的重傳（即 SACK，Selective Acknowledgment）。

SACK 機制就是，在快速重傳的基礎上，接收方返回最近收到報文段的序列號範圍，這樣傳送方就知道接收方哪些資料包是沒收到的。這樣就很清楚應該重傳哪些資料包。

如上圖中，傳送⽅收到了三次同樣的 ACK 確認報⽂，於是就會觸發快速重發機制，通過 SACK 資訊發現只有200~299 這段資料丟失，則重發時，就只選擇了這個 TCP 段進⾏重發。

重複 SACK（D-SACK）

D-SACK，英文是 Duplicate SACK，是在 SACK 的基礎上做了一些擴充套件，主要用來告訴傳送方，有哪些資料包，自己重複接受了。

DSACK 的目的是幫助傳送方判斷，是否發生了包失序、ACK 丟失、包重複或偽重傳。讓 TCP 可以更好的做網路流控。

例如ACK丟包導致的資料包重複：

• 接收⽅發給傳送⽅的兩個 ACK 確認應答都丟失了，所以傳送⽅超時後，重傳第⼀個資料包（3000 ~

3499）

• 於是接收⽅發現資料是重複收到的，於是回了⼀個 SACK = 3000~3500，告訴「傳送⽅」 3000~3500的資料早已被接收了，因為 ACK 都到了 4000 了，已經意味著 4000 之前的所有資料都已收到，所以這個SACK 就代表著 D-SACK 。這樣傳送⽅就知道了，資料沒有丟，是接收⽅的 ACK 確認報⽂丟了。

43.說說TCP 的粘包和拆包？

TCP 的粘包和拆包更多的是業務上的概念！

什麼是TCP粘包和拆包？

TCP 是面向流，沒有界限的一串資料。TCP 底層並不瞭解上層業務資料的具體含義，它會根據 TCP 緩衝區的實際情況進行包的劃分，所以在業務上認為，一個完整的包可能會被 TCP 拆分成多個包進行傳送，也有可能把多個小的包封裝成一個大的資料包傳送，這就是所謂的 TCP 粘包和拆包問題。

為什麼會產生粘包和拆包呢?

• 要傳送的資料小於 TCP 傳送緩衝區的大小，TCP 將多次寫入緩衝區的資料一次傳送出去，將會發生粘包；

• 接收資料端的應用層沒有及時讀取接收緩衝區中的資料，將發生粘包；

• 要傳送的資料大於 TCP 傳送緩衝區剩餘空間大小，將會發生拆包；

• 待傳送資料大於 MSS（最大報文長度），TCP 在傳輸前將進行拆包。即 TCP 報文長度 - TCP 頭部長度 > MSS。

那怎麼解決呢？

• 傳送端將每個資料包封裝為固定長度
• 在資料尾部增加特殊字元進行分割
• 將資料分為兩部分，一部分是頭部，一部分是內容體；其中頭部結構大小固定，且有一個欄位宣告內容體的大小。

UDP

UDP問的不多，基本上是被拿來和TCP比較。

44.說說 TCP 和 UDP 的區別？

最根本區別：TCP 是面向連線，而 UDP 是無連線。

可以這麼形容：TCP是打電話，UDP是大喇叭。

說說TCP和UDP的應用場景？

• TCP應用場景： 效率要求相對低，但對準確性要求相對高的場景。因為傳輸中需要對資料確認、重發、排序等操作，相比之下效率沒有UDP高。例如：檔案傳輸（準確高要求高、但是速度可以相對慢）、收發郵件、遠端登入。
• UDP應用場景： 效率要求相對高，對準確性要求相對低的場景。例如：QQ聊天、線上視訊、網路語音電話（即時通訊，速度要求高，但是出現偶爾斷續不是太大問題，並且此處完全不可以使用重發機制）、廣播通訊（廣播、多播）。

45.為什麼QQ採用UDP協議？

PS：這是多年前的老題了，拉出來懷懷舊。

• 首先，QQ並不是完全基於UDP實現。比如在使用QQ進行檔案傳輸等活動的時候，就會使用TCP作為可靠傳輸的保證。
• 使用UDP進行互動通訊的好處在於，延遲較短，對資料丟失的處理比較簡單。同時，TCP是一個全雙工協議，需要建立連線，所以網路開銷也會相對大。
• 如果使用QQ語音和QQ視訊的話，UDP的優勢就更為突出了，首先延遲較小。最重要的一點是不可靠傳輸，這意味著如果資料丟失的話，不會有重傳。因為使用者一般來說可以接受影像稍微模糊一點，聲音稍微不清晰一點，但是如果在幾秒鐘以後再出現之前丟失的畫面和聲音，這恐怕是很難接受的。
• 由於QQ的伺服器設計容量是海量級的應用，一臺伺服器要同時容納十幾萬的併發連線，因此伺服器端只有採用UDP協議與客戶端進行通訊才能保證這種超大規模的服務

簡單總結一下：UDP協議是無連線方式的協議，它的效率高，速度快，佔資源少，對伺服器的壓力比較小。但是其傳輸機制為不可靠傳送，必須依靠輔助的演算法來完成傳輸控制。QQ採用的通訊協議以UDP為主，輔以TCP協議。

46.UDP協議為什麼不可靠？

UDP在傳輸資料之前不需要先建立連線，遠地主機的運輸層在接收到UDP報文後，不需要確認，提供不可靠交付。總結就以下四點：

• 不保證訊息交付：不確認，不重傳，無超時
• 不保證交付順序：不設定包序號，不重排，不會發生隊首阻塞
• 不跟蹤連線狀態：不必建立連線或重啟狀態機
• 不進行擁塞控制：不內建客戶端或網路反饋機制

47.DNS為什麼要用UDP?

更準確地說，DNS既使用TCP又使用UDP。

當進行區域傳送（主域名伺服器向輔助域名伺服器傳送變化的那部分資料）時會使用TCP，因為資料同步傳送的資料量比一個請求和應答的資料量要多，而TCP允許的報文長度更長，因此為了保證資料的正確性，會使用基於可靠連線的TCP。

當客戶端想DNS伺服器查詢域名（域名解析）的時候，一般返回的內容不會超過UDP報文的最大長度，即512位元組，用UDP傳輸時，不需要建立連線，從而大大提高了響應速度，但這要求域名解析伺服器和域名伺服器都必須自己處理超時和重傳從而保證可靠性。

IP

48.IP 協議的定義和作用？

IP協議是什麼？

IP協議（Internet Protocol）又被稱為網際網路協議，是支援網間互聯的資料包協議，工作在網際層，主要目的就是為了提高網路的可擴充套件性。

通過網際協議IP，可以把參與互聯的，效能各異的網路看作一個統一的網路。

和傳輸層TCP相比，IP協議是一種無連線/不可靠、盡力而為的資料包傳輸服務，和TCP協議一起構成了TCP/IP協議的核心。

IP協議有哪些作用？

IP協議主要有以下幾個作用：

• 定址和路由：在IP資料包中攜帶源IP地址和目的IP地址來表示該資料包的源主機和目標主機。IP資料包在傳輸過程中，每個中間節點（IP閘道器、路由器）只根據網路地址來進行轉發，如果中間節點是路由器，則路由器會根據路由表選擇合適的路徑。IP協議根據路由選擇協議提供的路由資訊對IP資料包進行轉發，直至目標主機。
• 分段和重組：IP資料包在傳輸過程中可能會經過不同的網路，在不同的網路中資料包的最大長度限制是不同的，IP協議通過給每個IP資料包分配一個識別符號以及分段與組裝的相關資訊，使得資料包在不同的網路中能夠被傳輸，被分段後的IP資料包可以獨立地在網路中進行轉發，在達到目標主機後由目標主機完成重組工作，恢復出原來的IP資料包。

傳輸層協議和網路層協議有什麼區別？

網路層協議負責提供主機間的邏輯通訊；傳輸層協議負責提供程式間的邏輯通訊。

49.IP 地址有哪些分類？

一個IP地址在這鞥個網際網路範圍內是惟一的，一般可以這麼認為，IP 地址 = {<網路號>，<主機號>}。

1. 網路號：它標誌主機所連線的網路地址表示屬於網際網路的哪一個網路。

2. 主機號：它標誌主機地址表示其屬於該網路中的哪一臺主機。

IP 地址分為 A，B，C，D，E 五大類：

• A 類地址 (1~126)：以 0 開頭，網路號佔前 8 位，主機號佔後面 24 位。

• B 類地址 (128~191)：以 10 開頭，網路號佔前 16 位，主機號佔後面 16 位。

• C 類地址 (192~223)：以 110 開頭，網路號佔前 24 位，主機號佔後面 8 位。

• D 類地址 (224~239)：以 1110 開頭，保留為多播地址。

• E 類地址 (240~255)：以 1111開頭，保留位為將來使用

50.域名和 IP 的關係？一個 IP 可以對應多個域名嗎？

• IP地址在同一個網路中是惟一的，用來標識每一個網路上的裝置，其相當於一個人的身份證號
• 域名在同一個網路中也是惟一的，就像是一個人的名字、綽號

假如你有多個不用的綽號，你的朋友可以用其中任何一個綽號叫你，但你的身份證號碼卻是惟一的。但同時你的綽號也可能和別人重複，假如你不在，有人叫你的綽號，其它人可能就答應了。

一個域名可以對應多個IP，但這種情況DNS做負載均衡的，在使用者訪問過程中，一個域名只能對應一個IP。

而一個IP卻可以對應多個域名，是一對多的關係。

51.IPV4 地址不夠如何解決？

我們知道，IP地址有32位，可以標記2的32次方個地址，聽起來很多，但是全球的網路裝置數量已經遠遠超過這個數字，所以IPV4地址已經不夠用了，那怎麼解決呢？

• DHCP：動態主機配置協議，動態分配IP地址，只給接入網路的裝置分配IP地址，因此同一個MAC地址的裝置，每次接入網際網路時，得到的IP地址不一定是相同的，該協議使得空閒的IP地址可以得到充分利用。
• CIDR：無類別域間路由。CIDR消除了傳統的A類、B類、C類地址以及劃分子網的概念，因而更加有效地分配IPv4的地址空間，但無法從根本上解決地址耗盡的問題。
• NAT：網路地址轉換協議，我們知道屬於不同區域網的主機可以使用相同的IP地址，從而一定程度上緩解了IP資源枯竭的問題，然而主機在區域網中使用的IP地址是不能在公網中使用的，當區域網主機想要與公網主機進行通訊時，NAT方法可以將該主機IP地址轉換為全球IP地址。該協議能夠有效解決IP地址不足的問題。
• IPv6：作為接替IPv4的下一代網際網路協議，其可以實現2的128次方個地址，而這個數量級，即使給地球上每一粒沙子都分配一個IP地址也夠用，該協議能夠從根本上解決IPv4地址不夠用的問題。

52.說下 ARP 協議的工作過程？

ARP 協議，Address Resolution Protocol，地址解析協議，它是用於實現 IP 地址到 MAC 地址的對映。

1. 首先，每臺主機都會在自己的 ARP 緩衝區中建立一個 ARP 列表，以表示 IP 地址和 MAC 地址的對應關係。

2. 當源主機需要將一個資料包要傳送到目的主機時，會首先檢查自己的 ARP 列表，是否存在該 IP 地址對應的 MAC 地址；如果有﹐就直接將資料包傳送到這個 MAC 地址；如果沒有，就向本地網段發起一個 ARP 請求的廣播包，查詢此目的主機對應的 MAC 地址。此 ARP 請求的資料包裡，包括源主機的 IP 地址、硬體地址、以及目的主機的 IP 地址。

3. 網路中所有的主機收到這個 ARP 請求後，會檢查資料包中的目的 IP 是否和自己的 IP 地址一致。如果不相同，就會忽略此資料包；如果相同，該主機首先將傳送端的 MAC 地址和 IP 地址新增到自己的 ARP 列表中，如果 ARP 表中已經存在該 IP 的資訊，則將其覆蓋，然後給源主機傳送一個 ARP 響應資料包，告訴對方自己是它需要查詢的 MAC 地址。

4. 源主機收到這個 ARP 響應資料包後，將得到的目的主機的 IP 地址和 MAC 地址新增到自己的 ARP 列表中，並利用此資訊開始資料的傳輸。如果源主機一直沒有收到 ARP 響應資料包，表示 ARP 查詢失敗。

53.為什麼既有IP地址，又有MAC 地址？

MAC地址和IP地址都有什麼作用？

• MAC地址是資料鏈路層和物理層使用的地址，是寫在網路卡上的實體地址，用來定義網路裝置的位置，不可變更。
• IP地址是網路層和以上各層使用的地址，是一種邏輯地址。IP地址用來區別網路上的計算機。

為什麼有了MAC地址還需要IP地址？

如果我們只使用MAC地址進行定址的話，我們需要路由器記住每個MAC地址屬於哪個子網，不然一次路由器收到資料包都要滿世界尋找目的MAC地址。而我們知道MAC地址的長度為48位，也就是最多共有2的48次方個MAC地址，這就意味著每個路由器需要256T的記憶體，顯然是不現實的。

和MAC地址不同，IP地址是和地域相關的，在一個子網中的裝置，我們給其分配的IP地址字首都是一樣的，這樣路由器就能根據IP地址的字首知道這個裝置屬於哪個子網，剩下的定址就交給子網內部實現，從而大大減少了路由器所需要的記憶體。

為什麼有了IP地址還需要MAC地址？

• 只有當裝置連入網路時，才能根據他進入了哪個子網來為其分配IP地址，在裝置還沒有IP地址的時候，或者在分配IP的過程中。我們需要MAC地址來區分不同的裝置。

• IP 地址可以比作為地址，MAC 地址為收件人，在一次通訊過程中，兩者是缺一不可的。

54.ICMP 協議的功能？

ICMP（Internet Control Message Protocol） ，網際控制報文協議。

• ICMP 協議是一種面向無連線的協議，用於傳輸出錯報告控制資訊。

• 它是一個非常重要的協議，它對於網路安全具有極其重要的意義。它屬於網路層協議，主要用於在主機與路由器之間傳遞控制資訊，包括報告錯誤、交換受限控制和狀態資訊等。

• 當遇到 IP 資料無法訪問目標、IP 路由器無法按當前的傳輸速率轉發資料包等情況時，會自動傳送 ICMP 訊息。

比如我們日常使用得比較多的 ping，就是基於 ICMP 的。

55.說下 ping 的原理？

ping，Packet Internet Groper，是一種因特網包探索器，用於測試網路連線量的程式。Ping 是工作在 TCP/IP 網路體系結構中應用層的一個服務命令， 主要是向特定的目的主機傳送 ICMP（Internet Control Message Protocol 因特網報文控制協議） 請求報文，測試目的站是否可達及瞭解其有關狀態。

一般來說，ping 可以用來檢測網路通不通。它是基於ICMP協議工作的。假設機器 A ping 機器 B，工作過程如下：

1. ping 通知系統，新建一個固定格式的 ICMP 請求資料包
2. ICMP 協議，將該資料包和目標機器 B 的 IP 地址打包，一起轉交給 IP 協議層
3. IP 層協議將本機 IP 地址為源地址，機器 B 的 IP 地址為目標地址，加上一些其他的控制資訊，構建一個 IP 資料包
4. 先獲取目標機器 B 的 MAC 地址。
5. 資料鏈路層構建一個資料幀，目的地址是 IP 層傳過來的 MAC 地址，源地址是本機的 MAC 地址
6. 機器 B 收到後，對比目標地址，和自己本機的 MAC 地址是否一致，符合就處理返回，不符合就丟棄。
7. 根據目的主機返回的 ICMP 回送回答報文中的時間戳，從而計算出往返時間
8. 最終顯示結果有這幾項：傳送到目的主機的 IP 地址、傳送 & 收到 & 丟失的分組數、往返時間的最小、最大 & 平均值

網路安全

56.說說有哪些安全攻擊？

網路安全攻擊主要分為兩種型別，被動攻擊和主動攻擊：

• 被動攻擊：是指攻擊者從網路上竊聽他人的通訊內容，通常把這類攻擊稱為截獲，被動攻擊主要有兩種形式：訊息內容洩露攻擊和流量分析攻擊。由於攻擊者沒有修改資料，使得這種攻擊很難被檢測到。
• 主動攻擊：直接對現有的資料和服務造成影響，常見的主動攻擊型別有：
  • 篡改：攻擊者故意篡改網路上送的報文，甚至把完全偽造的報文傳送給接收方。
  • 惡意程式：惡意程式種類繁多，包括計算機病毒、計算機蠕蟲、特洛伊木馬、後門入侵、流氓軟體等等。
  • 拒絕服務Dos：攻擊者向伺服器不停地傳送分組，使伺服器無法提供正常服務。

57.DNS劫持瞭解嗎？

DNS劫持即域名劫持，是通過將原域名對應的IP地址進行替換，從而使使用者訪問到錯誤的網站，或者使使用者無法正常訪問網站的一種攻擊方式。

域名劫持往往只能在特定的網路範圍內進行，範圍外的DNS伺服器能夠返回正常的IP地址。攻擊者可以冒充原域名所屬機構，通過電子郵件的方式修改組織機構的域名註冊資訊，或者將域名轉讓給其它主持，並將新的域名資訊儲存在所指定的DNS伺服器中，從而使使用者無法對原域名來進行解析以訪問目標地址。

DNS劫持的步驟是什麼樣的？

1. 獲取要劫持的域名資訊：攻擊者會首先訪問域名查詢要劫持的站點的域名資訊。
2. 控制域名響應的E-Mail賬號：在獲取到域名資訊後，攻擊者通過暴力破解或者專門的方法破解公司註冊域名時使用的E-mail賬號所對應的密碼，更高階的攻擊者甚至能夠直接對E-Mail進行資訊竊取。
3. 修改註冊資訊：當攻擊者破解了E-Mail後，會利用相關的更改功能修改該域名的註冊資訊，包括域名擁有者資訊，DNS伺服器資訊等。
4. 使用E-Mail收發確認函：在修改完註冊資訊後，攻擊者E-Mail在真正擁有者之前收到修改域名註冊資訊的相關確認資訊，並回復確認修改檔案，待網路公司恢復已成功修改信件後，攻擊者便成功完成DNS劫持。

怎麼應對DNS劫持？

• 直接通過IP地址訪問網站，避開DNS劫持
• 由於域名劫持往往只能在特定的網路範圍內進行，因此一些高階使用者可以通過網路設定讓DNS指向正常的域名伺服器以實現對目標網址的正常訪問，例如計算機首選DNS伺服器的地址固定為8.8.8.8。

58.什麼是 CSRF 攻擊？如何避免？

什麼是 CSRF 攻擊？

CSRF，跨站請求偽造（英文全稱是 Cross-site request forgery），是一種挾持使用者在當前已登入的 Web 應用程式上執行非本意的操作的攻擊方法。

CSRF 是如何攻擊的呢？

來看一個例子：

1. 使用者登陸銀行，沒有退出，瀏覽器包含了 使用者 在銀行的身份認證資訊。

2. 攻擊者將偽造的轉賬請求，包含在在帖子

3. 使用者在銀行網站保持登陸的情況下，瀏覽帖子

4. 將偽造的轉賬請求連同身份認證資訊，傳送到銀行網站

5. 銀行網站看到身份認證資訊，以為就是 使用者的合法操作，最後造成使用者資金損失。

怎麼應對 CSRF 攻擊呢？

• 檢查 Referer 欄位

  HTTP頭中的Referer欄位記錄了該 HTTP 請求的來源地址。在通常情況下，訪問一個安全受限頁面的請求來自於同一個網站，而如果黑客要對其實施 CSRF攻擊，他一般只能在他自己的網站構造請求。因此，可以通過驗證Referer值來防禦CSRF 攻擊。

• 新增校驗 token

  以在 HTTP 請求中以引數的形式加入一個隨機產生的 token，並在伺服器端建立一個攔截器來驗證這個 token，如果請求中沒有token或者 token 內容不正確，則認為可能是 CSRF 攻擊而拒絕該請求。

• 敏感操作多重校驗

  對一些敏感的操作，除了需要校驗使用者的認證資訊，還可以通過郵箱確認、驗證碼確認這樣的方式多重校驗。

59.什麼是 DoS、DDoS、DRDoS 攻擊？

• DOS: (Denial of Service), 翻譯過來就是拒絕服務, 一切能引起拒絕 行為的攻擊都被稱為 DOS 攻擊。最常見的 DoS 攻擊就有計算機網路寬頻攻擊、連通性攻擊。

• DDoS: (Distributed Denial of Service)，翻譯過來是分散式拒絕服務。是指處於不同位置的多個攻擊者同時向一個或幾個目標發動攻擊，或者一個攻擊者控制了位於不同位置的多臺機器，並利用這些機器對受害者同時實施攻擊。

  主要形式有流量攻擊和資源耗盡攻擊，常見的 DDoS攻擊有： SYN Flood、Ping of Death、ACK Flood、UDP Flood 等。

• DRDoS: (Distributed Reflection Denial of Service)，中文是分散式反射拒絕服務，該方式靠的是傳送大量帶有被害者 IP 地址的資料包給攻擊主機，然後攻擊主機對 IP 地址源做出大量回應，從而形成拒絕服務攻擊。

如何防範DDoS?

針對DDoS中的流量攻擊，最直接的方法是增加頻寬，理論上只要頻寬大於攻擊流量就可以了，但是這種方法成本非常高。在有充足頻寬的前提下，我們應該儘量提升路由器、網路卡、交換機等硬體設施的配置。

針對資源耗盡攻擊，我們可以升級主機伺服器硬體，在網路頻寬得到保證的前提下，使得伺服器能夠有效對抗海量的SYN攻擊包。我們也可以安裝專業的抗DDoS防火牆，從而對抗SYN Flood等流量型攻擊。瓷碗，負載均衡，CDN等技術都能有效對抗DDos攻擊。

60.什麼是 XSS 攻擊，如何避免?

XSS 攻擊也是比較常見，XSS，叫跨站指令碼攻擊（Cross-Site Scripting），因為會與層疊樣式表 (Cascading Style Sheets, CSS) 的縮寫混淆，因此有人將跨站指令碼攻擊縮寫為 XSS。它指的是惡意攻擊者往 Web 頁面裡插入惡意 html 程式碼，當使用者瀏覽網頁的時候，嵌入其中 Web 裡面的 html 程式碼會被執行，從而達到惡意攻擊使用者的特殊目的。

XSS 攻擊一般分三種型別：儲存型 、反射型 、DOM 型 XSS

XSS 是如何攻擊的呢？

簡單說，XSS的攻擊方式就是想辦法“教唆”使用者的瀏覽器去執行一些這個網頁中原本不存在的前端程式碼。

拿反射型舉個例子吧，流程圖如下：

1. 攻擊者構造出特殊的 URL，其中包含惡意程式碼。
2. 使用者開啟帶有惡意程式碼的 URL 時，訪問正常網站伺服器
3. 網站服務端將惡意程式碼從 URL 中取出，拼接在 HTML 中返回給瀏覽器。
4. 使用者瀏覽器接收到響應後解析執行，混在其中的惡意程式碼也被執行，請求惡意伺服器，傳送使用者資料
5. 攻擊者就可以竊取使用者的資料，以此冒充使用者的行為，呼叫目標網站介面執行攻擊者指定的操作。

如何應對 XSS 攻擊？

• 對輸入進行過濾，過濾標籤等，只允許合法值。
• HTML 轉義
• 對於連結跳轉，如<a href="xxx" 等，要校驗內容，禁止以 script 開頭的非法連結。
• 限制輸入長度

61.對稱加密與非對稱加密有什麼區別？

對稱加密：指加密和解密使用同一金鑰，優點是運算速度較快，缺點是如何安全將金鑰傳輸給另一方。常見的對稱加密演算法有：DES、AES 等。

非對稱加密：指的是加密和解密使用不同的金鑰（即公鑰和私鑰）。公鑰與私鑰是成對存在的，如果用公鑰對資料進行加密，只有對應的私鑰才能解密。常見的非對稱加密演算法有 RSA。

62.RSA和AES演算法有什麼區別？

• RSA

  採用非對稱加密的方式，採用公鑰進行加密，私鑰解密的形式。其私鑰長度一般較長，由於需要大數的乘冪求模等運算，其運算速度較慢，不合適大量資料檔案加密。

• AES

  採用對稱加密的方式，其祕鑰長度最長只有256個位元，加密和解密速度較快，易於硬體實現。由於是對稱加密，通訊雙方在進行資料傳輸前需要獲知加密金鑰。

---

參考：

[1]. 2W字！梳理50道經典計算機網路面試題（收藏版）

[2]. 小林coding 《圖解網路》

[3].“三次握手，四次揮手”這麼講，保證你忘不了

[4]. 艾小仙 《我要進大廠》

[5]. 《圖解HTTP》

[6]. 淺析DNS域名解析過程

[7]. 「2021」高頻前端面試題彙總之計算機網路篇

[8]. 計算機網路

[9]. 謝希仁編著《計算機網路》

[10].《圖解TCP/IP》

[11].TCP的可靠性傳輸是如何保證的

[12].前端安全系列（一）：如何防止XSS攻擊？

---