【面試】50道經(jīng)典計(jì)算機(jī)網(wǎng)絡(luò)面試題

1. HTTP 常用的請(qǐng)求方式，區(qū)別和用途？

• GET: 發(fā)送請(qǐng)求，獲取服務(wù)器數(shù)據(jù)

• POST：向 URL 指定的資源提交數(shù)據(jù)

• PUT：向服務(wù)器提交數(shù)據(jù)，以修改數(shù)據(jù)

• HEAD: 請(qǐng)求頁面的首部，獲取資源的元信息

• DELETE：刪除服務(wù)器上的某些資源。

• CONNECT：建立連接隧道，用于代理服務(wù)器；

• OPTIONS：列出可對(duì)資源實(shí)行的請(qǐng)求方法，常用于跨域

• TRACE：追蹤請(qǐng)求 - 響應(yīng)的傳輸路徑

2. HTTP 常用的狀態(tài)碼及含義？

• 1xx：接受的請(qǐng)求正在處理 （信息性狀態(tài)碼）

• 2xx：表示請(qǐng)求正常處理完畢 （成功狀態(tài)碼）

• 3xx：表示重定向狀態(tài)，需要重新請(qǐng)求 （重定向狀態(tài)碼）

• 4xx：服務(wù)器無法處理請(qǐng)求 （客戶端錯(cuò)誤狀態(tài)碼）

• 5xx：服務(wù)器處理請(qǐng)求出錯(cuò) （服務(wù)端錯(cuò)誤狀態(tài)碼）

常用狀態(tài)碼如下：

• 101 切換請(qǐng)求協(xié)議，從 HTTP 切換到 WebSocket

• 200 請(qǐng)求成功，表示正常返回信息。

• 301 永久重定向，會(huì)緩存

• 302 臨時(shí)重定向，不會(huì)緩存

• 400 請(qǐng)求錯(cuò)誤

• 403 服務(wù)器禁止訪問

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

• 500 常見的服務(wù)器端錯(cuò)誤

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

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

2. 與服務(wù)器建立 TCP 連接

3. 發(fā)送 HTTP 請(qǐng)求

4. 服務(wù)器處理請(qǐng)求并返回 HTTP 報(bào)文

5. 瀏覽器解析渲染頁面

6. 連接結(jié)束

4. 如何理解 HTTP 協(xié)議是無狀態(tài)的

每次 HTTP 請(qǐng)求都是獨(dú)立的，無相關(guān)的，默認(rèn)不需要保存上下文信息的。我們來看個(gè)便于理解的例子：

有狀態(tài)：

• A：今天吃啥子？

• B：羅非魚！

• A：味道怎么樣呀？

• B：還不錯(cuò)，好香。

  
  

無狀態(tài)：

A：今天吃啥子？

B：羅非魚！

A：味道怎么樣呀？

B：？啊？啥？什么鬼？什么味道怎么樣？

加下 cookie 這玩意：

• A：今天吃啥子？

• B：羅非魚

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

• B：還不錯(cuò)，好香。

5. HTTP 1.0，1.1，2.0 的版本區(qū)別

HTTP 1.0

• HTTP 1.0 規(guī)定瀏覽器與服務(wù)器只保持短暫的連接，瀏覽器的每次請(qǐng)求都需要與服務(wù)器建立一個(gè) TCP 連接，服務(wù)器完成請(qǐng)求處理后立即斷開 TCP 連接。它也可以強(qiáng)制開啟長鏈接，例如設(shè)置 Connection: keep-alive 這個(gè)字段

HTTP 1.1

• 引入了長連接，即 TCP 連接默認(rèn)不關(guān)閉，可以被多個(gè)請(qǐng)求復(fù)用。

• 引入了管道機(jī)制（pipelining），即在同一個(gè) TCP 連接里面，客戶端可以同時(shí)發(fā)送多個(gè)請(qǐng)求。

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

• 錯(cuò)誤狀態(tài)管理，新增了 24 個(gè)錯(cuò)誤狀態(tài)響應(yīng)碼，如 409 表示請(qǐng)求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突。

HTTP 2

• 采用了多路復(fù)用，即在一個(gè)連接里，客戶端和瀏覽器都可以同時(shí)發(fā)送多個(gè)請(qǐng)求或回應(yīng)，而且不用按照順序一一對(duì)應(yīng)。

• 服務(wù)端推送，HTTP 2 允許服務(wù)器未經(jīng)請(qǐng)求，主動(dòng)向客戶端發(fā)送資源

6. 說下計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)

計(jì)算機(jī)網(wǎng)路體系結(jié)構(gòu)主要有 ISO 七層模型、TCP/IP 四層模型、五層體系結(jié)構(gòu)

ISO 七層模型

ISO 七層模型是國際標(biāo)準(zhǔn)化組織（ISO）制定的一個(gè)用于計(jì)算機(jī)或通信系統(tǒng)間互聯(lián)的標(biāo)準(zhǔn)體系。

• 應(yīng)用層：網(wǎng)絡(luò)服務(wù)與最終用戶的一個(gè)接口，協(xié)議有：HTTP FTP TFTP SMTP SNMP DNS TELNET HTTPS POP3 DHCP

• 表示層：數(shù)據(jù)的表示、安全、壓縮。

• 會(huì)話層：建立、管理、終止會(huì)話。對(duì)應(yīng)主機(jī)進(jìn)程，指本地主機(jī)與遠(yuǎn)程主機(jī)正在進(jìn)行的會(huì)話

• 傳輸層：定義傳輸數(shù)據(jù)的協(xié)議端口號(hào)，以及流控和差錯(cuò)校驗(yàn)。協(xié)議有：TCP UDP，數(shù)據(jù)包一旦離開網(wǎng)卡即進(jìn)入網(wǎng)絡(luò)傳輸層

• 網(wǎng)絡(luò)層：進(jìn)行邏輯地址尋址，實(shí)現(xiàn)不同網(wǎng)絡(luò)之間的路徑選擇。協(xié)議有：ICMP IGMP IP（IPV4 IPV6）

• 數(shù)據(jù)鏈路層：建立邏輯連接、進(jìn)行硬件地址尋址、差錯(cuò)校驗(yàn)等功能。

• 物理層：建立、維護(hù)、斷開物理連接。

TCP/IP 四層模型

• 應(yīng)用層：對(duì)應(yīng)于 OSI 參考模型的（應(yīng)用層、表示層、會(huì)話層），為用戶提供所需要的各種服務(wù)，例如：FTP、Telnet、DNS、SMTP 等

• 傳輸層：對(duì)應(yīng) OSI 的傳輸層，為應(yīng)用層實(shí)體提供端到端的通信功能，保證了數(shù)據(jù)包的順序傳送及數(shù)據(jù)的完整性。定義了 TCP 和 UDP 兩層協(xié)議。

• 網(wǎng)際層：對(duì)應(yīng)于 OSI 參考模型的網(wǎng)絡(luò)層，主要解決主機(jī)到主機(jī)的通信問題。三個(gè)主要協(xié)議：網(wǎng)際協(xié)議（IP）、互聯(lián)網(wǎng)組管理協(xié)議（IGMP）和互聯(lián)網(wǎng)控制報(bào)文協(xié)議（ICMP）

• 網(wǎng)絡(luò)接口層：與 OSI 參考模型的數(shù)據(jù)鏈路層、物理層對(duì)應(yīng)。它負(fù)責(zé)監(jiān)視數(shù)據(jù)在主機(jī)和網(wǎng)絡(luò)之間的交換。

五層體系結(jié)構(gòu)

• 應(yīng)用層：通過應(yīng)用進(jìn)程間的交互來完成特定網(wǎng)絡(luò)應(yīng)用。對(duì)應(yīng)于 OSI 參考模型的（應(yīng)用層、表示層、會(huì)話層），應(yīng)用層協(xié)議很多，如域名系統(tǒng) DNS，HTTP 協(xié)議，支持電子郵件的 SMTP 協(xié)議等等。我們把應(yīng)用層交互的數(shù)據(jù)單元稱為報(bào)文。

• 傳輸層：負(fù)責(zé)向兩臺(tái)主機(jī)進(jìn)程之間的通信提供通用的數(shù)據(jù)傳輸服務(wù)。對(duì)應(yīng) OSI 參考模型的傳輸層，協(xié)議有傳輸控制協(xié)議 TCP 和 用戶數(shù)據(jù)協(xié)議 UDP。

• 網(wǎng)絡(luò)層：對(duì)應(yīng) OSI 參考模型的的網(wǎng)絡(luò)層

• 數(shù)據(jù)鏈路層：對(duì)應(yīng) OSI 參考模型的的數(shù)據(jù)鏈路層

• 物理層：對(duì)應(yīng) OSI 參考模型的的物理層層。在物理層上所傳送的數(shù)據(jù)單位是比特。物理層 (physical layer) 的作用是實(shí)現(xiàn)相鄰計(jì)算機(jī)節(jié)點(diǎn)之間比特流的透明傳送，盡可能屏蔽掉具體傳輸介質(zhì)和物理設(shè)備的差異。

7. POST 和 GET 有哪些區(qū)別？

• 請(qǐng)求參數(shù)：GET 把參數(shù)包含在 URL 中，用 & 連接起來；POST 通過 request body 傳遞參數(shù)。

• 請(qǐng)求緩存：GET 請(qǐng)求會(huì)被主動(dòng) Cache，而 POST 請(qǐng)求不會(huì)，除非手動(dòng)設(shè)置。

• 收藏為書簽：GET 請(qǐng)求支持收藏為書簽，POST 請(qǐng)求不支持。

• 安全性：POST 比 GET 安全，GET 請(qǐng)求在瀏覽器回退時(shí)是無害的，而 POST 會(huì)再次請(qǐng)求。

• 歷史記錄：GET 請(qǐng)求參數(shù)會(huì)被完整保留在瀏覽歷史記錄里，而 POST 中的參數(shù)不會(huì)被保留。

• 編碼方式：GET 請(qǐng)求只能進(jìn)行 url 編碼，而 POST 支持多種編碼方式。

• 參數(shù)數(shù)據(jù)類型：GET 只接受 ASCII 字符，而 POST 沒有限制數(shù)據(jù)類型。

• 數(shù)據(jù)包: GET 產(chǎn)生一個(gè) TCP 數(shù)據(jù)包；POST 可能產(chǎn)生兩個(gè) TCP 數(shù)據(jù)包。

8. 在交互過程中如果數(shù)據(jù)傳送完了，還不想斷開連接怎么辦，怎么維持？

在 HTTP 中響應(yīng)體的 Connection 字段指定為 keep-alive

9. HTTP 如何實(shí)現(xiàn)長連接？在什么時(shí)候會(huì)超時(shí)？

HTTP 如何實(shí)現(xiàn)長連接？

• HTTP 分為長連接和短連接，其實(shí)本質(zhì)上說的是 TCP 的長短連接。TCP 連接是一個(gè)雙向的通道，它是可以保持一段時(shí)間不關(guān)閉的，因此 TCP 連接才有真正的長連接和短連接這一個(gè)說法。

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

• TCP 長連接可以復(fù)用一個(gè) TCP 連接來發(fā)起多次 HTTP 請(qǐng)求，這樣可以減少資源消耗，比如一次請(qǐng)求 HTML，短連接可能還需要請(qǐng)求后續(xù)的 JS/CSS/ 圖片等

要實(shí)現(xiàn) HTTP 長連接，在響應(yīng)頭設(shè)置 Connection 為 keep-alive，HTTP1.1 默認(rèn)是長連接，而 HTTP 1.0 協(xié)議也支持長連接，但是默認(rèn)是關(guān)閉的。

在什么時(shí)候會(huì)超時(shí)呢？

• HTTP 一般會(huì)有 httpd 守護(hù)進(jìn)程，里面可以設(shè)置 keep-alive timeout，當(dāng) tcp 鏈接閑置超過這個(gè)時(shí)間就會(huì)關(guān)閉，也可以在 HTTP 的 header 里面設(shè)置超時(shí)時(shí)間

• TCP 的 keep-alive 包含三個(gè)參數(shù)，支持在系統(tǒng)內(nèi)核的 net.ipv4 里面設(shè)置：當(dāng) TCP 連接之后，閑置了 tcp_keepalive_time，則會(huì)發(fā)生偵測包，如果沒有收到對(duì)方的 ACK，那么會(huì)每隔 tcp_keepalive_intvl 再發(fā)一次，直到發(fā)送了 tcp_keepalive_probes，就會(huì)丟棄該連接。

1. tcp_keepalive_intvl = 15

2. tcp_keepalive_probes = 5

3. tcp_keepalive_time = 1800

10. 講一下 HTTP 與 HTTPS 的區(qū)別。

HTTP，超文本傳輸協(xié)議，英文是 Hyper Text Transfer Protocol，是一個(gè)基于 TCP/IP 通信協(xié)議來傳遞數(shù)據(jù)的協(xié)議。HTTP 存在這幾個(gè)問題：

• 請(qǐng)求信息明文傳輸，容易被竊聽截取。

• 數(shù)據(jù)的完整性未校驗(yàn)，容易被篡改

• 沒有驗(yàn)證對(duì)方身份，存在冒充危險(xiǎn)

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

它們主要區(qū)別：

• 數(shù)據(jù)是否加密: Http 是明文傳輸，HTTPS 是密文

• 默認(rèn)端口: Http 默認(rèn)端口是 80，Https 默認(rèn)端口是 443

• 資源消耗：和 HTTP 通信相比，Https 通信會(huì)消耗更多的 CPU 和內(nèi)存資源，因?yàn)樾枰咏饷芴幚恚?/span>

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

11 . Https 流程是怎樣的？

• HTTPS = HTTP + SSL/TLS，即用 SSL/TLS 對(duì)數(shù)據(jù)進(jìn)行加密和解密，Http 進(jìn)行傳輸。

• SSL，即 Secure Sockets Layer（安全套接層協(xié)議），是網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議。

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

1. 用戶在瀏覽器里輸入一個(gè) https 網(wǎng)址，然后連接到 server 的 443 端口。

2. 服務(wù)器必須要有一套數(shù)字證書，可以自己制作，也可以向組織申請(qǐng)，區(qū)別就是自己頒發(fā)的證書需要客戶端驗(yàn)證通過。這套證書其實(shí)就是一對(duì)公鑰和私鑰。

3. 服務(wù)器將自己的數(shù)字證書（含有公鑰）發(fā)送給客戶端。

4. 客戶端收到服務(wù)器端的數(shù)字證書之后，會(huì)對(duì)其進(jìn)行檢查，如果不通過，則彈出警告框。如果證書沒問題，則生成一個(gè)密鑰（對(duì)稱加密），用證書的公鑰對(duì)它加密。

5. 客戶端會(huì)發(fā)起 HTTPS 中的第二個(gè) HTTP 請(qǐng)求，將加密之后的客戶端密鑰發(fā)送給服務(wù)器。

6. 服務(wù)器接收到客戶端發(fā)來的密文之后，會(huì)用自己的私鑰對(duì)其進(jìn)行非對(duì)稱解密，解密之后得到客戶端密鑰，然后用客戶端密鑰對(duì)返回?cái)?shù)據(jù)進(jìn)行對(duì)稱加密，這樣數(shù)據(jù)就變成了密文。

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

8. 客戶端收到服務(wù)器發(fā)返回的密文，用自己的密鑰（客戶端密鑰）對(duì)其進(jìn)行對(duì)稱解密，得到服務(wù)器返回的數(shù)據(jù)。

12. 對(duì)稱加密與非對(duì)稱加密有什么區(qū)別

對(duì)稱加密：加密和解密使用相同密鑰的加密算法。

非對(duì)稱加密：非對(duì)稱加密算法需要兩個(gè)密鑰（公開密鑰和私有密鑰）。公鑰與私鑰是成對(duì)存在的，如果用公鑰對(duì)數(shù)據(jù)進(jìn)行加密，只有對(duì)應(yīng)的私鑰才能解密。

13. 什么是 XSS 攻擊，如何避免？

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

XSS 是如何攻擊的？

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

如何解決 XSS 攻擊問題

• 不相信用戶的輸入，對(duì)輸入進(jìn)行過濾，過濾標(biāo)簽等，只允許合法值。

• HTML 轉(zhuǎn)義

• 對(duì)于鏈接跳轉(zhuǎn)，如 <a href="xxx" 等，要校驗(yàn)內(nèi)容，禁止以 script 開頭的非法鏈接。

• 限制輸入長度等等

14. 請(qǐng)?jiān)敿?xì)介紹一下 TCP 的三次握手機(jī)制

開始客戶端和服務(wù)器都處于 CLOSED 狀態(tài)，然后服務(wù)端開始監(jiān)聽某個(gè)端口，進(jìn)入 LISTEN 狀態(tài)

• 第一次握手 (SYN=1, seq=x)，發(fā)送完畢后，客戶端進(jìn)入 SYN_SEND 狀態(tài)

• 第二次握手 (SYN=1, ACK=1, seq=y, ACKnum=x+1)， 發(fā)送完畢后，服務(wù)器端進(jìn)入 SYN_RCV 狀態(tài)。

• 第三次握手 (ACK=1，ACKnum=y+1)，發(fā)送完畢后，客戶端進(jìn)入 ESTABLISHED 狀態(tài)，當(dāng)服務(wù)器端接收到這個(gè)包時(shí)

15. TCP 握手為什么是三次，不能是兩次？不能是四次？

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

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

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

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

因?yàn)槲帐植荒苁撬拇文兀恳驗(yàn)槿我呀?jīng)夠了，三次已經(jīng)能讓雙方都知道：你愛我，我也愛你。而四次就多余了。

16. TCP 四次揮手過程？

• 第一次揮手 (FIN=1，seq=u)，發(fā)送完畢后，客戶端進(jìn)入 FIN_WAIT_1 狀態(tài)

• 第二次揮手 (ACK=1，ack=u+1,seq =v)，發(fā)送完畢后，服務(wù)器端進(jìn)入 CLOSE_WAIT 狀態(tài)，客戶端接收到這個(gè)確認(rèn)包之后，進(jìn)入 FIN_WAIT_2 狀態(tài)

• 第三次揮手 (FIN=1，ACK1,seq=w,ack=u+1)，發(fā)送完畢后，服務(wù)器端進(jìn)入 LAST_ACK 狀態(tài)，等待來自客戶端的最后一個(gè) ACK。

• 第四次揮手 (ACK=1，seq=u+1,ack=w+1)，客戶端接收到來自服務(wù)器端的關(guān)閉請(qǐng)求，發(fā)送一個(gè)確認(rèn)包，并進(jìn)入 TIME_WAIT 狀態(tài)，等待了某個(gè)固定時(shí)間（兩個(gè)最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，沒有收到服務(wù)器端的 ACK ，認(rèn)為服務(wù)器端已經(jīng)正常關(guān)閉連接，于是自己也關(guān)閉連接，進(jìn)入 CLOSED 狀態(tài)。服務(wù)器端接收到這個(gè)確認(rèn)包之后，關(guān)閉連接，進(jìn)入 CLOSED 狀態(tài)。

17. TCP 四次揮手過程中，客戶端為什么需要等待 2MSL, 才進(jìn)入 CLOSED 狀態(tài)

2MSL，2 Maximum Segment Lifetime，即兩個(gè)最大段生命周期

• 1 個(gè) MSL 保證四次揮手中主動(dòng)關(guān)閉方最后的 ACK 報(bào)文能最終到達(dá)對(duì)端

• 1 個(gè) MSL 保證對(duì)端沒有收到 ACK 那么進(jìn)行重傳的 FIN 報(bào)文能夠到達(dá)

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

舉個(gè)例子吧

小明和小紅打電話聊天，通話差不多要結(jié)束時(shí)，小紅說 “我沒啥要說的了”，小明回答 “我知道了”。但是小明可能還會(huì)有要說的話，小紅不能要求小明跟著自己的節(jié)奏結(jié)束通話，于是小明可能又嘰嘰歪歪說了一通，最后小明說 “我說完了”，小紅回答 “知道了”，這樣通話才算結(jié)束。

19. Session 和 Cookie 的區(qū)別。

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

• Cookie 是服務(wù)器發(fā)送到用戶瀏覽器，并保存在瀏覽器本地的一小塊文本串?dāng)?shù)據(jù)。它會(huì)在瀏覽器下次向同一服務(wù)器再發(fā)起請(qǐng)求時(shí)，被攜帶發(fā)送到服務(wù)器。通常，它用于告知服務(wù)端兩個(gè)請(qǐng)求是否來自同一瀏覽器，一樣用于保持用戶的登錄狀態(tài)等。Cookie 使基于無狀態(tài)的 HTTP 協(xié)議記錄穩(wěn)定的狀態(tài)信息成為了可能。

• session 指的就是服務(wù)器和客戶端一次會(huì)話的過程。Session 利用 Cookie 進(jìn)行信息處理的，當(dāng)用戶首先進(jìn)行了請(qǐng)求后，服務(wù)端就在用戶瀏覽器上創(chuàng)建了一個(gè) Cookie，當(dāng)這個(gè) Session 結(jié)束時(shí)，其實(shí)就是意味著這個(gè) Cookie 就過期了。Session 對(duì)象存儲(chǔ)著特定用戶會(huì)話所需的屬性及配置信息。

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

• 存儲(chǔ)位置不一樣，Cookie 保存在客戶端，Session 保存在服務(wù)器端。

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

• 有效期不同，Cookie 可設(shè)置為長時(shí)間保持，比如我們經(jīng)常使用的默認(rèn)登錄功能，Session 一般有效時(shí)間較短，客戶端關(guān)閉或者 Session 超時(shí)都會(huì)失效。

• 隱私策略不同，Cookie 存儲(chǔ)在客戶端，比較容易遭到不法獲取，早期有人將用戶的登錄名和密碼存儲(chǔ)在 Cookie 中導(dǎo)致信息被竊取；Session 存儲(chǔ)在服務(wù)端，安全性相對(duì) Cookie 要好一些。

• 存儲(chǔ)大小不同， 單個(gè) Cookie 保存的數(shù)據(jù)不能超過 4K，Session 可存儲(chǔ)數(shù)據(jù)遠(yuǎn)高于 Cookie。

來看個(gè)圖吧：

• 用戶第一次請(qǐng)求服務(wù)器時(shí)，服務(wù)器根據(jù)用戶提交的信息，創(chuàng)建對(duì)應(yīng)的 Session ，請(qǐng)求返回時(shí)將此 Session 的唯一標(biāo)識(shí)信息 SessionID 返回給瀏覽器，瀏覽器接收到服務(wù)器返回的 SessionID 信息后，會(huì)將此信息存入 Cookie 中，同時(shí) Cookie 記錄此 SessionID 屬于哪個(gè)域名。

• 當(dāng)用戶第二次訪問服務(wù)器時(shí)，請(qǐng)求會(huì)自動(dòng)判斷此域名下是否存在 Cookie 信息，如果存在，則自動(dòng)將 Cookie 信息也發(fā)送給服務(wù)端，服務(wù)端會(huì)從 Cookie 中獲取 SessionID，再根據(jù) SessionID 查找對(duì)應(yīng)的 Session 信息，如果沒有找到說明用戶沒有登錄或者登錄失效，如果找到 Session 證明用戶已經(jīng)登錄可執(zhí)行后面操作。

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

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

• 其次，TCP 的可靠性，還體現(xiàn)在有狀態(tài) ;TCP 會(huì)記錄哪些數(shù)據(jù)發(fā)送了，哪些數(shù)據(jù)被接受了，哪些沒有被接受，并且保證數(shù)據(jù)包按序到達(dá)，保證數(shù)據(jù)傳輸不出差錯(cuò)。

• 再次，TCP 的可靠性，還體現(xiàn)在可控制。它有數(shù)據(jù)包校驗(yàn)、ACK 應(yīng)答、超時(shí)重傳 (發(fā)送方)、失序數(shù)據(jù)重傳（接收方）、丟棄重復(fù)數(shù)據(jù)、流量控制（滑動(dòng)窗口）和擁塞控制等機(jī)制。

21. TCP 和 UDP 的區(qū)別

1. TCP 面向連接（（如打電話要先撥號(hào)建立連接）;UDP 是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接。

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

3. TCP 是點(diǎn)對(duì)點(diǎn)連接的，UDP 一對(duì)一，一對(duì)多，多對(duì)多都可以

4. TCP 傳輸效率相對(duì)較低，而 UDP 傳輸效率高，它適用于對(duì)高速傳輸和實(shí)時(shí)性有較高的通信或廣播通信。

5. TCP 適合用于網(wǎng)頁，郵件等；UDP 適合用于視頻，語音廣播等

6. TCP 面向字節(jié)流，UDP 面向報(bào)文

22. TCP 報(bào)文首部有哪些字段，說說其作用

• 16 位端口號(hào)：源端口號(hào)，主機(jī)該報(bào)文段是來自哪里；目標(biāo)端口號(hào)，要傳給哪個(gè)上層協(xié)議或應(yīng)用程序

• 32 位序號(hào)：一次 TCP 通信（從 TCP 連接建立到斷開）過程中某一個(gè)傳輸方向上的字節(jié)流的每個(gè)字節(jié)的編號(hào)。

• 32 位確認(rèn)號(hào)：用作對(duì)另一方發(fā)送的 tcp 報(bào)文段的響應(yīng)。其值是收到的 TCP 報(bào)文段的序號(hào)值加 1。

• 4 位頭部長度：表示 tcp 頭部有多少個(gè) 32bit 字（4 字節(jié)）。因?yàn)?4 位最大能標(biāo)識(shí) 15，所以 TCP 頭部最長是 60 字節(jié)。

• 6 位標(biāo)志位：URG (緊急指針是否有效)，ACk（表示確認(rèn)號(hào)是否有效），PSH（緩沖區(qū)尚未填滿），RST（表示要求對(duì)方重新建立連接），SYN（建立連接消息標(biāo)志接），F(xiàn)IN（表示告知對(duì)方本端要關(guān)閉連接了）

• 16 位窗口大小：是 TCP 流量控制的一個(gè)手段。這里說的窗口，指的是接收通告窗口。它告訴對(duì)方本端的 TCP 接收緩沖區(qū)還能容納多少字節(jié)的數(shù)據(jù)，這樣對(duì)方就可以控制發(fā)送數(shù)據(jù)的速度。

• 16 位校驗(yàn)和：由發(fā)送端填充，接收端對(duì) TCP 報(bào)文段執(zhí)行 CRC 算法以檢驗(yàn) TCP 報(bào)文段在傳輸過程中是否損壞。注意，這個(gè)校驗(yàn)不僅包括 TCP 頭部，也包括數(shù)據(jù)部分。這也是 TCP 可靠傳輸?shù)囊粋€(gè)重要保障。

• 16 位緊急指針：一個(gè)正的偏移量。它和序號(hào)字段的值相加表示最后一個(gè)緊急數(shù)據(jù)的下一字節(jié)的序號(hào)。因此，確切地說，這個(gè)字段是緊急指針相對(duì)當(dāng)前序號(hào)的偏移，不妨稱之為緊急偏移。TCP 的緊急指針是發(fā)送端向接收端發(fā)送緊急數(shù)據(jù)的方法。

23. HTTP 狀態(tài)碼 301 和 302 的區(qū)別？

• 301（永久移動(dòng)）請(qǐng)求的網(wǎng)頁已被永久移動(dòng)到新位置。服務(wù)器返回此響應(yīng)（作為對(duì) GET 或 HEAD 請(qǐng)求的響應(yīng)）時(shí)，會(huì)自動(dòng)將請(qǐng)求者轉(zhuǎn)到新位置。

• 302：（臨時(shí)移動(dòng)）服務(wù)器目前正從不同位置的網(wǎng)頁響應(yīng)請(qǐng)求，但請(qǐng)求者應(yīng)繼續(xù)使用原有位置來進(jìn)行以后的請(qǐng)求。此代碼與響應(yīng) GET 和 HEAD 請(qǐng)求的 301 代碼類似，會(huì)自動(dòng)將請(qǐng)求者轉(zhuǎn)到不同的位置。

HTTP 狀態(tài)碼 301 與 302 的區(qū)別：

1. 它們之間關(guān)鍵區(qū)別在，資源是否存在有效性；

2. 301 資源還在只是換了一個(gè)位置，返回的是新位置的內(nèi)容；

3. 302 資源暫時(shí)失效，返回的是一個(gè)臨時(shí)的代替頁上。

24. 聊聊 TCP 的重傳機(jī)制

超時(shí)重傳

TCP 為了實(shí)現(xiàn)可靠傳輸，實(shí)現(xiàn)了重傳機(jī)制。最基本的重傳機(jī)制，就是超時(shí)重傳，即在發(fā)送數(shù)據(jù)報(bào)文時(shí)，設(shè)定一個(gè)定時(shí)器，每間隔一段時(shí)間，沒有收到對(duì)方的 ACK 確認(rèn)應(yīng)答報(bào)文，就會(huì)重發(fā)該報(bào)文。

這個(gè)間隔時(shí)間，一般設(shè)置為多少呢？我們先來看下什么叫 RTT（Round-Trip Time，往返時(shí)間）。

RTT 就是，一個(gè)數(shù)據(jù)包從發(fā)出去到回來的時(shí)間，即數(shù)據(jù)包的一次往返時(shí)間。超時(shí)重傳時(shí)間，就是 Retransmission Timeout ，簡稱 RTO。

RTO 設(shè)置多久呢？

• 如果 RTO 比較小，那很可能數(shù)據(jù)都沒有丟失，就重發(fā)了，這會(huì)導(dǎo)致網(wǎng)絡(luò)阻塞，會(huì)導(dǎo)致更多的超時(shí)出現(xiàn)。

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

一般情況下，RTO 略大于 RTT，效果是最好的。一些小伙伴會(huì)問，超時(shí)時(shí)間有沒有計(jì)算公式呢？有的！有個(gè)標(biāo)準(zhǔn)方法算 RTO 的公式，也叫 Jacobson / Karels 算法。我們一起來看下計(jì)算 RTO 的公式

1. 先計(jì)算 SRTT（計(jì)算平滑的 RTT）

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

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

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

3. 最終的 RTO

RTO = μ * SRTT + ? * RTTVAR  =  SRTT + 4·RTTVAR  

其中，α = 0.125，β = 0.25， μ = 1，? = 4，這些參數(shù)都是大量結(jié)果得出的最優(yōu)參數(shù)。

但是，超時(shí)重傳會(huì)有這些缺點(diǎn)：

• 當(dāng)一個(gè)報(bào)文段丟失時(shí)，會(huì)等待一定的超時(shí)周期然后才重傳分組，增加了端到端的時(shí)延。

• 當(dāng)一個(gè)報(bào)文段丟失時(shí)，在其等待超時(shí)的過程中，可能會(huì)出現(xiàn)這種情況：其后的報(bào)文段已經(jīng)被接收端接收但卻遲遲得不到確認(rèn)，發(fā)送端會(huì)認(rèn)為也丟失了，從而引起不必要的重傳，既浪費(fèi)資源也浪費(fèi)時(shí)間。

并且，TCP 有個(gè)策略，就是超時(shí)時(shí)間間隔會(huì)加倍。超時(shí)重傳需要等待很長時(shí)間。因此，還可以使用快速重傳機(jī)制。

快速重傳

快速重傳機(jī)制，它不以時(shí)間驅(qū)動(dòng)，而是以數(shù)據(jù)驅(qū)動(dòng)。它基于接收端的反饋信息來引發(fā)重傳。

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

發(fā)送端發(fā)送了 1，2，3，4，5,6 份數(shù)據(jù):

1. 第一份 Seq=1 先送到了，于是就 Ack 回 2；

2. 第二份 Seq=2 也送到了，假設(shè)也正常，于是 ACK 回 3；

3. 第三份 Seq=3 由于網(wǎng)絡(luò)等其他原因，沒送到；

4. 第四份 Seq=4 也送到了，但是因?yàn)?Seq3 沒收到。所以 ACK 回 3；

5. 后面的 Seq=4,5 的也送到了，但是 ACK 還是回復(fù) 3，因?yàn)?Seq=3 沒收到。

6. 發(fā)送端連著收到三個(gè)重復(fù)冗余 ACK=3 的確認(rèn)（實(shí)際上是 4 個(gè)，但是前面一個(gè)是正常的 ACK，后面三個(gè)才是重復(fù)冗余的），便知道哪個(gè)報(bào)文段在傳輸過程中丟失了，于是在定時(shí)器過期之前，重傳該報(bào)文段。

7. 最后，接收到收到了 Seq3，此時(shí)因?yàn)?Seq=4，5，6 都收到了，于是 ACK 回 7.

但快速重傳還可能會(huì)有個(gè)問題：ACK 只向發(fā)送端告知最大的有序報(bào)文段，到底是哪個(gè)報(bào)文丟失了呢？并不確定！那到底該重傳多少個(gè)包呢？

是重傳 Seq3 呢？還是重傳 Seq3、Seq4、Seq5、Seq6 呢？因?yàn)榘l(fā)送端并不清楚這三個(gè)連續(xù)的 ACK3 是誰傳回來的。

帶選擇確認(rèn)的重傳（SACK）

為了解決快速重傳的問題：應(yīng)該重傳多少個(gè)包 ? TCP 提供了 SACK 方法（帶選擇確認(rèn)的重傳，Selective Acknowledgment）。

SACK 機(jī)制就是，在快速重傳的基礎(chǔ)上，接收端返回最近收到的報(bào)文段的序列號(hào)范圍，這樣發(fā)送端就知道接收端哪些數(shù)據(jù)包沒收到，醬紫就很清楚該重傳哪些數(shù)據(jù)包啦。SACK 標(biāo)記是加在 TCP 頭部選項(xiàng)字段里面的。

如上圖中，發(fā)送端收到了三次同樣的 ACK=30 的確認(rèn)報(bào)文，于是就會(huì)觸發(fā)快速重發(fā)機(jī)制，通過 SACK 信息發(fā)現(xiàn)只有 30~39 這段數(shù)據(jù)丟失，于是重發(fā)時(shí)就只選擇了這個(gè) 30~39 的 TCP 報(bào)文段進(jìn)行重發(fā)。

D-SACK

D-SACK，即 Duplicate SACK（重復(fù) SACK），在 SACK 的基礎(chǔ)上做了一些擴(kuò)展，，主要用來告訴發(fā)送方，有哪些數(shù)據(jù)包自己重復(fù)接受了。DSACK 的目的是幫助發(fā)送方判斷，是否發(fā)生了包失序、ACK 丟失、包重復(fù)或偽重傳。讓 TCP 可以更好的做網(wǎng)絡(luò)流控。來看個(gè)圖吧：

25. IP 地址有哪些分類？

一句話概括，IP 地址 = 網(wǎng)絡(luò)號(hào) + 主機(jī)號(hào)。

• 網(wǎng)絡(luò)號(hào)：它標(biāo)志主機(jī)（或路由器）所連接到的網(wǎng)絡(luò)，網(wǎng)絡(luò)地址表示屬于互聯(lián)網(wǎng)的哪一個(gè)網(wǎng)絡(luò)

• 主機(jī)號(hào)：它標(biāo)志該主機(jī)（或路由器），主機(jī)地址表示其屬于該網(wǎng)絡(luò)中的哪一臺(tái)主機(jī)

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

• A 類地址 (1~126)：以 0 開頭，網(wǎng)絡(luò)號(hào)占前 8 位，主機(jī)號(hào)占后 24 位。

• B 類地址 (128~191)：以 10 開頭，網(wǎng)絡(luò)號(hào)占前 16 位，主機(jī)號(hào)占后 16 位。

• C 類地址 (192~223)：以 110 開頭，網(wǎng)絡(luò)號(hào)占前 24 位，主機(jī)號(hào)占后 8 位。

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

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

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