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 到顯示主頁的過程
-
DNS 解析,查找真正的 ip 地址
-
與服務器建立 TCP 連接
-
發送 HTTP 請求
-
服務器處理請求並返回 HTTP 報文
-
瀏覽器解析渲染頁面
-
連接結束
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,就會丟棄該連接。
-
tcp_keepalive_intvl = 15
-
tcp_keepalive_probes = 5
-
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 的后續版本。
-
用戶在瀏覽器里輸入一個 https 網址,然后連接到 server 的 443 端口。
-
服務器必須要有一套數字證書,可以自己制作,也可以向組織申請,區別就是自己頒發的證書需要客戶端驗證通過。這套證書其實就是一對公鑰和私鑰。
-
服務器將自己的數字證書(含有公鑰)發送給客戶端。
-
客戶端收到服務器端的數字證書之后,會對其進行檢查,如果不通過,則彈出警告框。如果證書沒問題,則生成一個密鑰(對稱加密),用證書的公鑰對它加密。
-
客戶端會發起 HTTPS 中的第二個 HTTP 請求,將加密之后的客戶端密鑰發送給服務器。
-
服務器接收到客戶端發來的密文之后,會用自己的私鑰對其進行非對稱解密,解密之后得到客戶端密鑰,然后用客戶端密鑰對返回數據進行對稱加密,這樣數據就變成了密文。
-
服務器將加密后的密文返回給客戶端。
-
客戶端收到服務器發返回的密文,用自己的密鑰(客戶端密鑰)對其進行對稱解密,得到服務器返回的數據。
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 的區別
-
TCP 面向連接((如打電話要先撥號建立連接);UDP 是無連接的,即發送數據之前不需要建立連接。
-
TCP 要求安全性,提供可靠的服務,通過 TCP 連接傳送的數據,不丟失、不重復、安全可靠。而 UDP 盡最大努力交付,即不保證可靠交付。
-
TCP 是點對點連接的,UDP 一對一,一對多,多對多都可以
-
TCP 傳輸效率相對較低,而 UDP 傳輸效率高,它適用於對高速傳輸和實時性有較高的通信或廣播通信。
-
TCP 適合用於網頁,郵件等;UDP 適合用於視頻,語音廣播等
-
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 的區別:
-
它們之間關鍵區別在,資源是否存在有效性;
-
301 資源還在只是換了一個位置,返回的是新位置的內容;
-
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 份數據:
-
第一份 Seq=1 先送到了,於是就 Ack 回 2;
-
第二份 Seq=2 也送到了,假設也正常,於是 ACK 回 3;
-
第三份 Seq=3 由於網絡等其他原因,沒送到;
-
第四份 Seq=4 也送到了,但是因為 Seq3 沒收到。所以 ACK 回 3;
-
后面的 Seq=4,5 的也送到了,但是 ACK 還是回復 3,因為 Seq=3 沒收到。
-
發送端連着收到三個重復冗余 ACK=3 的確認(實際上是 4 個,但是前面一個是正常的 ACK,后面三個才是重復冗余的),便知道哪個報文段在傳輸過程中丟失了,於是在定時器過期之前,重傳該報文段。
-
最后,接收到收到了 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