【面試】50道經典計算機網絡面試題


1. HTTP 常用的請求方式,區別和用途?

  • GET: 發送請求,獲取服務器數據

  • POST:向 URL 指定的資源提交數據

  • PUT:向服務器提交數據,以修改數據

  • HEAD: 請求頁面的首部,獲取資源的元信息

  • DELETE:刪除服務器上的某些資源。

  • CONNECT:建立連接隧道,用於代理服務器;

  • OPTIONS:列出可對資源實行的請求方法,常用於跨域

  • TRACE:追蹤請求 - 響應的傳輸路徑

2. HTTP 常用的狀態碼及含義?

  • 1xx:接受的請求正在處理 (信息性狀態碼)

  • 2xx:表示請求正常處理完畢 (成功狀態碼)

  • 3xx:表示重定向狀態,需要重新請求 (重定向狀態碼)

  • 4xx:服務器無法處理請求 (客戶端錯誤狀態碼)

  • 5xx:服務器處理請求出錯 (服務端錯誤狀態碼)

常用狀態碼如下:

  • 101 切換請求協議,從 HTTP 切換到 WebSocket

  • 200 請求成功,表示正常返回信息。

  • 301 永久重定向,會緩存

  • 302 臨時重定向,不會緩存

  • 400 請求錯誤

  • 403 服務器禁止訪問

  • 404 找不到與 URI 相匹配的資源。

  • 500 常見的服務器端錯誤

3. 從瀏覽器地址欄輸入 url 到顯示主頁的過程

  1. DNS 解析,查找真正的 ip 地址

  2. 與服務器建立 TCP 連接

  3. 發送 HTTP 請求

  4. 服務器處理請求並返回 HTTP 報文

  5. 瀏覽器解析渲染頁面

  6. 連接結束

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

每次 HTTP 請求都是獨立的,無相關的,默認不需要保存上下文信息的。我們來看個便於理解的例子:

有狀態:

  • A:今天吃啥子?

  • B:羅非魚!

  • A:味道怎么樣呀?

  • B:還不錯,好香。

無狀態:

A:今天吃啥子?

B:羅非魚!

A:味道怎么樣呀?

B:?啊?啥?什么鬼?什么味道怎么樣?

加下 cookie 這玩意:

  • A:今天吃啥子?

  • B:羅非魚

  • A:你今天吃的羅非魚味道怎么樣呀?

  • B:還不錯,好香。

5. HTTP 1.0,1.1,2.0 的版本區別

HTTP 1.0

  • HTTP 1.0 規定瀏覽器與服務器只保持短暫的連接,瀏覽器的每次請求都需要與服務器建立一個 TCP 連接,服務器完成請求處理后立即斷開 TCP 連接。它也可以強制開啟長鏈接,例如設置 Connection: keep-alive 這個字段

HTTP 1.1

  • 引入了長連接,即 TCP 連接默認不關閉,可以被多個請求復用

  • 引入了管道機制(pipelining),即在同一個 TCP 連接里面,客戶端可以同時發送多個請求。

  • 緩存處理,引入了更多的緩存控制策略,如 Cache-Control、Etag/If-None-Match 等。

  • 錯誤狀態管理,新增了 24 個錯誤狀態響應碼,如 409 表示請求的資源與資源的當前狀態發生沖突。

HTTP 2

  • 采用了多路復用,即在一個連接里,客戶端和瀏覽器都可以同時發送多個請求或回應,而且不用按照順序一一對應。

  • 服務端推送,HTTP 2 允許服務器未經請求,主動向客戶端發送資源

6. 說下計算機網絡體系結構

計算機網路體系結構主要有 ISO 七層模型、TCP/IP 四層模型、五層體系結構

ISO 七層模型

ISO 七層模型是國際標准化組織(ISO)制定的一個用於計算機或通信系統間互聯的標准體系。

  • 應用層:網絡服務與最終用戶的一個接口,協議有:HTTP FTP TFTP SMTP SNMP DNS TELNET HTTPS POP3 DHCP

  • 表示層:數據的表示、安全、壓縮。

  • 會話層:建立、管理、終止會話。對應主機進程,指本地主機與遠程主機正在進行的會話

  • 傳輸層:定義傳輸數據的協議端口號,以及流控和差錯校驗。協議有:TCP UDP,數據包一旦離開網卡即進入網絡傳輸層

  • 網絡層:進行邏輯地址尋址,實現不同網絡之間的路徑選擇。協議有:ICMP IGMP IP(IPV4 IPV6)

  • 數據鏈路層:建立邏輯連接、進行硬件地址尋址、差錯校驗等功能。

  • 物理層:建立、維護、斷開物理連接。

TCP/IP 四層模型

  • 應用層:對應於 OSI 參考模型的(應用層、表示層、會話層),為用戶提供所需要的各種服務,例如:FTP、Telnet、DNS、SMTP 等

  • 傳輸層:對應 OSI 的傳輸層,為應用層實體提供端到端的通信功能,保證了數據包的順序傳送及數據的完整性。定義了 TCP 和 UDP 兩層協議。

  • 網際層:對應於 OSI 參考模型的網絡層,主要解決主機到主機的通信問題。三個主要協議:網際協議(IP)、互聯網組管理協議(IGMP)和互聯網控制報文協議(ICMP)

  • 網絡接口層:與 OSI 參考模型的數據鏈路層、物理層對應。它負責監視數據在主機和網絡之間的交換。

五層體系結構

  • 應用層:通過應用進程間的交互來完成特定網絡應用。對應於 OSI 參考模型的(應用層、表示層、會話層),應用層協議很多,如域名系統 DNS,HTTP 協議,支持電子郵件的 SMTP 協議等等。我們把應用層交互的數據單元稱為報文。

  • 傳輸層:負責向兩台主機進程之間的通信提供通用的數據傳輸服務。對應 OSI 參考模型的傳輸層,協議有傳輸控制協議 TCP 和 用戶數據協議 UDP。

  • 網絡層:對應 OSI 參考模型的的網絡層

  • 數據鏈路層:對應 OSI 參考模型的的數據鏈路層

  • 物理層:對應 OSI 參考模型的的物理層層。在物理層上所傳送的數據單位是比特。物理層 (physical layer) 的作用是實現相鄰計算機節點之間比特流的透明傳送,盡可能屏蔽掉具體傳輸介質和物理設備的差異。

7. POST 和 GET 有哪些區別?

  • 請求參數:GET 把參數包含在 URL 中,用 & 連接起來;POST 通過 request body 傳遞參數。

  • 請求緩存:GET 請求會被主動 Cache,而 POST 請求不會,除非手動設置。

  • 收藏為書簽:GET 請求支持收藏為書簽,POST 請求不支持。

  • 安全性:POST 比 GET 安全,GET 請求在瀏覽器回退時是無害的,而 POST 會再次請求。

  • 歷史記錄:GET 請求參數會被完整保留在瀏覽歷史記錄里,而 POST 中的參數不會被保留。

  • 編碼方式:GET 請求只能進行 url 編碼,而 POST 支持多種編碼方式。

  • 參數數據類型:GET 只接受 ASCII 字符,而 POST 沒有限制數據類型。

  • 數據包: GET 產生一個 TCP 數據包;POST 可能產生兩個 TCP 數據包。

8. 在交互過程中如果數據傳送完了,還不想斷開連接怎么辦,怎么維持?

在 HTTP 中響應體的 Connection 字段指定為 keep-alive

9. HTTP 如何實現長連接?在什么時候會超時?

HTTP 如何實現長連接

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

  • 長連接是指的是 TCP 連接,而不是 HTTP 連接。

  • TCP 長連接可以復用一個 TCP 連接來發起多次 HTTP 請求,這樣可以減少資源消耗,比如一次請求 HTML,短連接可能還需要請求后續的 JS/CSS/ 圖片等

要實現 HTTP 長連接,在響應頭設置 Connection 為 keep-alive,HTTP1.1 默認是長連接,而 HTTP 1.0 協議也支持長連接,但是默認是關閉的。

在什么時候會超時呢

  • 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

10. 講一下 HTTP 與 HTTPS 的區別。

HTTP,超文本傳輸協議,英文是 Hyper Text Transfer Protocol,是一個基於 TCP/IP 通信協議來傳遞數據的協議。HTTP 存在這幾個問題:

  • 請求信息明文傳輸,容易被竊聽截取。

  • 數據的完整性未校驗,容易被篡改

  • 沒有驗證對方身份,存在冒充危險

HTTPS 就是為了解決 HTTP 存在問題的。HTTPS,英文是 HyperText Transfer Protocol over Secure Socket Layer,可以這么理解 Https 是身披 SSL (Secure Socket Layer) 的 HTTP,即 HTTPS 協議 = HTTP+SSL/TLS。通過 SSL 證書來驗證服務器的身份,並為瀏覽器和服務器之間的傳輸數據進行加密。

它們主要區別:

  • 數據是否加密: Http 是明文傳輸,HTTPS 是密文

  • 默認端口: Http 默認端口是 80,Https 默認端口是 443

  • 資源消耗:和 HTTP 通信相比,Https 通信會消耗更多的 CPU 和內存資源,因為需要加解密處理;

  • 安全性: http 不安全,https 比較安全。

11 . Https 流程是怎樣的?

  • HTTPS = HTTP + SSL/TLS,即用 SSL/TLS 對數據進行加密和解密,Http 進行傳輸。

  • SSL,即 Secure Sockets Layer(安全套接層協議),是網絡通信提供安全及數據完整性的一種安全協議。

  • TLS,即 Transport Layer Security (安全傳輸層協議),它是 SSL 3.0 的后續版本。

  1. 用戶在瀏覽器里輸入一個 https 網址,然后連接到 server 的 443 端口。

  2. 服務器必須要有一套數字證書,可以自己制作,也可以向組織申請,區別就是自己頒發的證書需要客戶端驗證通過。這套證書其實就是一對公鑰和私鑰。

  3. 服務器將自己的數字證書(含有公鑰)發送給客戶端。

  4. 客戶端收到服務器端的數字證書之后,會對其進行檢查,如果不通過,則彈出警告框。如果證書沒問題,則生成一個密鑰(對稱加密),用證書的公鑰對它加密。

  5. 客戶端會發起 HTTPS 中的第二個 HTTP 請求,將加密之后的客戶端密鑰發送給服務器。

  6. 服務器接收到客戶端發來的密文之后,會用自己的私鑰對其進行非對稱解密,解密之后得到客戶端密鑰,然后用客戶端密鑰對返回數據進行對稱加密,這樣數據就變成了密文。

  7. 服務器將加密后的密文返回給客戶端。

  8. 客戶端收到服務器發返回的密文,用自己的密鑰(客戶端密鑰)對其進行對稱解密,得到服務器返回的數據。

12. 對稱加密與非對稱加密有什么區別

對稱加密:加密和解密使用相同密鑰的加密算法。

非對稱加密:非對稱加密算法需要兩個密鑰(公開密鑰和私有密鑰)。公鑰與私鑰是成對存在的,如果用公鑰對數據進行加密,只有對應的私鑰才能解密。

13. 什么是 XSS 攻擊,如何避免?

XSS 攻擊,全稱跨站腳本攻擊(Cross-Site Scripting),這會與層疊樣式表 (Cascading Style Sheets, CSS) 的縮寫混淆,因此有人將跨站腳本攻擊縮寫為 XSS。它指的是惡意攻擊者往 Web 頁面里插入惡意 html 代碼,當用戶瀏覽該頁之時,嵌入其中 Web 里面的 html 代碼會被執行,從而達到惡意攻擊用戶的特殊目的。XSS 攻擊一般分三種類型:存儲型 、反射型 、DOM 型 XSS

XSS 是如何攻擊的?

拿反射型舉個例子吧,流程圖如下:

如何解決 XSS 攻擊問題

  • 不相信用戶的輸入,對輸入進行過濾,過濾標簽等,只允許合法值。

  • HTML 轉義

  • 對於鏈接跳轉,如 <a href="xxx" 等,要校驗內容,禁止以 script 開頭的非法鏈接。

  • 限制輸入長度等等

14. 請詳細介紹一下 TCP 的三次握手機制

開始客戶端和服務器都處於 CLOSED 狀態,然后服務端開始監聽某個端口,進入 LISTEN 狀態

  • 第一次握手 (SYN=1, seq=x),發送完畢后,客戶端進入 SYN_SEND 狀態

  • 第二次握手 (SYN=1, ACK=1, seq=y, ACKnum=x+1), 發送完畢后,服務器端進入 SYN_RCV 狀態。

  • 第三次握手 (ACK=1,ACKnum=y+1),發送完畢后,客戶端進入 ESTABLISHED 狀態,當服務器端接收到這個包時

15. TCP 握手為什么是三次,不能是兩次?不能是四次?

TCP 握手為什么是三次呢?為了方便理解,我們以談戀愛為個例子:兩個人能走到一起,最重要的事情就是相愛,就是我愛你,並且我知道,你也愛我,接下來我們以此來模擬三次握手的過程:

為什么握手不能是兩次呢?

如果只有兩次握手,女孩子可能就不知道,她的那句我也愛你,男孩子是否收到,戀愛關系就不能愉快展開。

為什么握手不能是四次呢?

因為握手不能是四次呢?因為三次已經夠了,三次已經能讓雙方都知道:你愛我,我也愛你。而四次就多余了。

16. 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 狀態。

17. TCP 四次揮手過程中,客戶端為什么需要等待 2MSL, 才進入 CLOSED 狀態

2MSL,2 Maximum Segment Lifetime,即兩個最大段生命周期

  • 1 個 MSL 保證四次揮手中主動關閉方最后的 ACK 報文能最終到達對端

  • 1 個 MSL 保證對端沒有收到 ACK 那么進行重傳的 FIN 報文能夠到達

18. 為什么需要四次揮手?

舉個例子吧

小明和小紅打電話聊天,通話差不多要結束時,小紅說 “我沒啥要說的了”,小明回答 “我知道了”。但是小明可能還會有要說的話,小紅不能要求小明跟着自己的節奏結束通話,於是小明可能又嘰嘰歪歪說了一通,最后小明說 “我說完了”,小紅回答 “知道了”,這樣通話才算結束。

19. Session 和 Cookie 的區別。

我們先來看 Session 和 Cookie 的定義:

  • Cookie 是服務器發送到用戶瀏覽器,並保存在瀏覽器本地的一小塊文本串數據。它會在瀏覽器下次向同一服務器再發起請求時,被攜帶發送到服務器。通常,它用於告知服務端兩個請求是否來自同一瀏覽器,一樣用於保持用戶的登錄狀態等。Cookie 使基於無狀態的 HTTP 協議記錄穩定的狀態信息成為了可能。

  • session 指的就是服務器和客戶端一次會話的過程。Session 利用 Cookie 進行信息處理的,當用戶首先進行了請求后,服務端就在用戶瀏覽器上創建了一個 Cookie,當這個 Session 結束時,其實就是意味着這個 Cookie 就過期了。Session 對象存儲着特定用戶會話所需的屬性及配置信息。

Session 和 Cookie 到底有什么不同呢?

  • 存儲位置不一樣,Cookie 保存在客戶端,Session 保存在服務器端。

  • 存儲數據類型不一樣,Cookie 只能保存 ASCII,Session 可以存任意數據類型,一般情況下我們可以在 Session 中保持一些常用變量信息,比如說 UserId 等。

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

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

  • 存儲大小不同, 單個 Cookie 保存的數據不能超過 4K,Session 可存儲數據遠高於 Cookie。

來看個圖吧:

  • 用戶第一次請求服務器時,服務器根據用戶提交的信息,創建對應的 Session ,請求返回時將此 Session 的唯一標識信息 SessionID 返回給瀏覽器,瀏覽器接收到服務器返回的 SessionID 信息后,會將此信息存入 Cookie 中,同時 Cookie 記錄此 SessionID 屬於哪個域名。

  • 當用戶第二次訪問服務器時,請求會自動判斷此域名下是否存在 Cookie 信息,如果存在,則自動將 Cookie 信息也發送給服務端,服務端會從 Cookie 中獲取 SessionID,再根據 SessionID 查找對應的 Session 信息,如果沒有找到說明用戶沒有登錄或者登錄失效,如果找到 Session 證明用戶已經登錄可執行后面操作。

20. TCP 是如何保證可靠性的

  • 首先,TCP 的連接是基於三次握手,而斷開則是四次揮手。確保連接和斷開的可靠性。

  • 其次,TCP 的可靠性,還體現在有狀態 ;TCP 會記錄哪些數據發送了,哪些數據被接受了,哪些沒有被接受,並且保證數據包按序到達,保證數據傳輸不出差錯。

  • 再次,TCP 的可靠性,還體現在可控制。它有數據包校驗、ACK 應答、超時重傳 (發送方)、失序數據重傳(接收方)、丟棄重復數據、流量控制(滑動窗口)和擁塞控制等機制。

21. TCP 和 UDP 的區別

  1. TCP 面向連接((如打電話要先撥號建立連接);UDP 是無連接的,即發送數據之前不需要建立連接。

  2. TCP 要求安全性,提供可靠的服務,通過 TCP 連接傳送的數據,不丟失、不重復、安全可靠。而 UDP 盡最大努力交付,即不保證可靠交付。

  3. TCP 是點對點連接的,UDP 一對一,一對多,多對多都可以

  4. TCP 傳輸效率相對較低,而 UDP 傳輸效率高,它適用於對高速傳輸和實時性有較高的通信或廣播通信。

  5. TCP 適合用於網頁,郵件等;UDP 適合用於視頻,語音廣播等

  6. TCP 面向字節流,UDP 面向報文

22. TCP 報文首部有哪些字段,說說其作用

  • 16 位端口號:源端口號,主機該報文段是來自哪里;目標端口號,要傳給哪個上層協議或應用程序

  • 32 位序號:一次 TCP 通信(從 TCP 連接建立到斷開)過程中某一個傳輸方向上的字節流的每個字節的編號。

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

  • 4 位頭部長度:表示 tcp 頭部有多少個 32bit 字(4 字節)。因為 4 位最大能標識 15,所以 TCP 頭部最長是 60 字節。

  • 6 位標志位:URG (緊急指針是否有效),ACk(表示確認號是否有效),PSH(緩沖區尚未填滿),RST(表示要求對方重新建立連接),SYN(建立連接消息標志接),FIN(表示告知對方本端要關閉連接了)

  • 16 位窗口大小:是 TCP 流量控制的一個手段。這里說的窗口,指的是接收通告窗口。它告訴對方本端的 TCP 接收緩沖區還能容納多少字節的數據,這樣對方就可以控制發送數據的速度。

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

  • 16 位緊急指針:一個正的偏移量。它和序號字段的值相加表示最后一個緊急數據的下一字節的序號。因此,確切地說,這個字段是緊急指針相對當前序號的偏移,不妨稱之為緊急偏移。TCP 的緊急指針是發送端向接收端發送緊急數據的方法。

23. HTTP 狀態碼 301 和 302 的區別?

  • 301(永久移動)請求的網頁已被永久移動到新位置。服務器返回此響應(作為對 GET 或 HEAD 請求的響應)時,會自動將請求者轉到新位置。

  • 302:(臨時移動)服務器目前正從不同位置的網頁響應請求,但請求者應繼續使用原有位置來進行以后的請求。此代碼與響應 GET 和 HEAD 請求的 301 代碼類似,會自動將請求者轉到不同的位置。

HTTP 狀態碼 301 與 302 的區別:

  1. 它們之間關鍵區別在,資源是否存在有效性;

  2. 301 資源還在只是換了一個位置,返回的是新位置的內容;

  3. 302 資源暫時失效,返回的是一個臨時的代替頁上。

24. 聊聊 TCP 的重傳機制

超時重傳

TCP 為了實現可靠傳輸,實現了重傳機制。最基本的重傳機制,就是超時重傳,即在發送數據報文時,設定一個定時器,每間隔一段時間,沒有收到對方的 ACK 確認應答報文,就會重發該報文。

這個間隔時間,一般設置為多少呢?我們先來看下什么叫 RTT(Round-Trip Time,往返時間)

RTT 就是,一個數據包從發出去到回來的時間,即數據包的一次往返時間。超時重傳時間,就是 Retransmission Timeout ,簡稱 RTO

RTO 設置多久呢?

  • 如果 RTO 比較小,那很可能數據都沒有丟失,就重發了,這會導致網絡阻塞,會導致更多的超時出現。

  • 如果 RTO 比較大,等到花兒都謝了還是沒有重發,那效果就不好了。

一般情況下,RTO 略大於 RTT,效果是最好的。一些小伙伴會問,超時時間有沒有計算公式呢?有的!有個標准方法算 RTO 的公式,也叫 Jacobson / Karels 算法。我們一起來看下計算 RTO 的公式

1. 先計算 SRTT(計算平滑的 RTT)

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

2. 再計算 RTTVAR (round-trip time variation)

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

3. 最終的 RTO

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

其中,α = 0.125,β = 0.25, μ = 1,∂ = 4,這些參數都是大量結果得出的最優參數。

但是,超時重傳會有這些缺點:

  • 當一個報文段丟失時,會等待一定的超時周期然后才重傳分組,增加了端到端的時延。

  • 當一個報文段丟失時,在其等待超時的過程中,可能會出現這種情況:其后的報文段已經被接收端接收但卻遲遲得不到確認,發送端會認為也丟失了,從而引起不必要的重傳,既浪費資源也浪費時間。

並且,TCP 有個策略,就是超時時間間隔會加倍。超時重傳需要等待很長時間。因此,還可以使用快速重傳機制

快速重傳

快速重傳機制,它不以時間驅動,而是以數據驅動。它基於接收端的反饋信息來引發重傳。

一起來看下快速重傳流程:

發送端發送了 1,2,3,4,5,6 份數據:

  1. 第一份 Seq=1 先送到了,於是就 Ack 回 2;

  2. 第二份 Seq=2 也送到了,假設也正常,於是 ACK 回 3;

  3. 第三份 Seq=3 由於網絡等其他原因,沒送到;

  4. 第四份 Seq=4 也送到了,但是因為 Seq3 沒收到。所以 ACK 回 3;

  5. 后面的 Seq=4,5 的也送到了,但是 ACK 還是回復 3,因為 Seq=3 沒收到。

  6. 發送端連着收到三個重復冗余 ACK=3 的確認(實際上是 4 個,但是前面一個是正常的 ACK,后面三個才是重復冗余的),便知道哪個報文段在傳輸過程中丟失了,於是在定時器過期之前,重傳該報文段。

  7. 最后,接收到收到了 Seq3,此時因為 Seq=4,5,6 都收到了,於是 ACK 回 7.

快速重傳還可能會有個問題:ACK 只向發送端告知最大的有序報文段,到底是哪個報文丟失了呢?並不確定!那到底該重傳多少個包呢?

是重傳 Seq3 呢?還是重傳 Seq3、Seq4、Seq5、Seq6 呢?因為發送端並不清楚這三個連續的 ACK3 是誰傳回來的。

帶選擇確認的重傳(SACK)

為了解決快速重傳的問題:應該重傳多少個包 ? TCP 提供了 SACK 方法(帶選擇確認的重傳,Selective Acknowledgment)。

SACK 機制就是,在快速重傳的基礎上,接收端返回最近收到的報文段的序列號范圍,這樣發送端就知道接收端哪些數據包沒收到,醬紫就很清楚該重傳哪些數據包啦。SACK 標記是加在 TCP 頭部選項字段里面的。

如上圖中,發送端收到了三次同樣的 ACK=30 的確認報文,於是就會觸發快速重發機制,通過 SACK 信息發現只有 30~39 這段數據丟失,於是重發時就只選擇了這個 30~39 的 TCP 報文段進行重發。

D-SACK

D-SACK,即 Duplicate SACK(重復 SACK),在 SACK 的基礎上做了一些擴展,,主要用來告訴發送方,有哪些數據包自己重復接受了。DSACK 的目的是幫助發送方判斷,是否發生了包失序、ACK 丟失、包重復或偽重傳。讓 TCP 可以更好的做網絡流控。來看個圖吧:

25. IP 地址有哪些分類?

一句話概括,IP 地址 = 網絡號 + 主機號。

  • 網絡號:它標志主機(或路由器)所連接到的網絡,網絡地址表示屬於互聯網的哪一個網絡

  • 主機號:它標志該主機(或路由器),主機地址表示其屬於該網絡中的哪一台主機

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):以 11110 開頭,保留位為將來使用

鏈接:https://learnku.com/articles/59484


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM