[[414422]]

本文轉(zhuǎn)載自微信公眾號(hào)「愛笑的架構(gòu)師」，作者雷小帥 。轉(zhuǎn)載本文請(qǐng)聯(lián)系愛笑的架構(gòu)師公眾號(hào)。

在面試中計(jì)算機(jī)網(wǎng)絡(luò)是面試官最喜歡考察的內(nèi)容之一，下面這奪命 20 問一定要掌握喲!

網(wǎng)絡(luò)分層

1、說說OSI 七層、TCP/IP 四層的關(guān)系和區(qū)別?

OSI 七層從下往上依次是：物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會(huì)話層、表示層、應(yīng)用層。一張圖給你整明白：

(圖片來源于網(wǎng)絡(luò))

TCP/IP 四層從下往上依次是：網(wǎng)絡(luò)接口層、網(wǎng)絡(luò)層、傳輸層、應(yīng)用層。與 OSI 七層的映射關(guān)系如下：

特點(diǎn)：

• 層與層之間相互獨(dú)立又相互依靠
• 上層依賴于下層，下層為上層提供服務(wù)

敲黑板：TCP/IP 四層是 OSI 七層的簡(jiǎn)化版，已經(jīng)成為實(shí)事國(guó)際標(biāo)準(zhǔn)。

TCP/IP

2、說說TCP 與 UDP 的區(qū)別?

先上一張對(duì)比圖：

總結(jié)

• TCP 向上層提供面向連接的可靠服務(wù) ，UDP 向上層提供無連接不可靠服務(wù)。
• UDP 沒有 TCP 傳輸可靠，但是可以在實(shí)時(shí)性要求搞的地方有所作為。
• 對(duì)數(shù)據(jù)準(zhǔn)確性要求高，速度可以相對(duì)較慢的，可以選用TCP。

3、TCP 是如何實(shí)現(xiàn)數(shù)據(jù)的可靠性?

一句話：通過校驗(yàn)和、序列號(hào)、確認(rèn)應(yīng)答、超時(shí)重傳、連接管理、流量控制、擁塞控制等機(jī)制來保證可靠性。

(1)校驗(yàn)和

在數(shù)據(jù)傳輸過程中，將發(fā)送的數(shù)據(jù)段都當(dāng)做一個(gè)16位的整數(shù)，將這些整數(shù)加起來，并且前面的進(jìn)位不能丟棄，補(bǔ)在最后，然后取反，得到校驗(yàn)和。

發(fā)送方：在發(fā)送數(shù)據(jù)之前計(jì)算校驗(yàn)和，并進(jìn)行校驗(yàn)和的填充。接收方：收到數(shù)據(jù)后，對(duì)數(shù)據(jù)以同樣的方式進(jìn)行計(jì)算，求出校驗(yàn)和，與發(fā)送方進(jìn)行比較。

(2)序列號(hào)

TCP 傳輸時(shí)將每個(gè)字節(jié)的數(shù)據(jù)都進(jìn)行了編號(hào)，這就是序列號(hào)。序列號(hào)的作用不僅僅是應(yīng)答作用，有了序列號(hào)能夠?qū)⒔邮盏降臄?shù)據(jù)根據(jù)序列號(hào)進(jìn)行排序，并且去掉重復(fù)的數(shù)據(jù)。

(3)確認(rèn)應(yīng)答

TCP 傳輸過程中，每次接收方接收到數(shù)據(jù)后，都會(huì)對(duì)傳輸方進(jìn)行確認(rèn)應(yīng)答，也就是發(fā)送 ACK 報(bào)文，這個(gè) ACK 報(bào)文中帶有對(duì)應(yīng)的確認(rèn)序列號(hào)，告訴發(fā)送方，接收了哪些數(shù)據(jù)，下一次數(shù)據(jù)從哪里傳。

(4)超時(shí)重傳

在進(jìn)行 TCP 傳輸時(shí)，由于存在確認(rèn)應(yīng)答與序列號(hào)機(jī)制，也就是說發(fā)送方發(fā)送一部分?jǐn)?shù)據(jù)后，都會(huì)等待接收方發(fā)送的 ACK 報(bào)文，并解析 ACK 報(bào)文，判斷數(shù)據(jù)是否傳輸成功。如果發(fā)送方發(fā)送完數(shù)據(jù)后，遲遲都沒有接收到接收方傳來的 ACK 報(bào)文，那么就對(duì)剛剛發(fā)送的數(shù)據(jù)進(jìn)行重發(fā)。

(5)連接管理

就是指三次握手、四次揮手的過程。

(6)流量控制

如果發(fā)送方的發(fā)送速度太快，會(huì)導(dǎo)致接收方的接收緩沖區(qū)填充滿了，這時(shí)候繼續(xù)傳輸數(shù)據(jù)，就會(huì)造成大量丟包，進(jìn)而引起丟包重傳等等一系列問題。TCP 支持根據(jù)接收端的處理能力來決定發(fā)送端的發(fā)送速度，這就是流量控制機(jī)制。

具體實(shí)現(xiàn)方式：接收端將自己的接收緩沖區(qū)大小放入 TCP 首部的『窗口大小』字段中，通過 ACK 通知發(fā)送端。

(7)擁塞控制

TCP 傳輸過程中一開始就發(fā)送大量數(shù)據(jù)，如果當(dāng)時(shí)網(wǎng)絡(luò)非常擁堵，可能會(huì)造成擁堵加劇。所以 TCP 引入了慢啟動(dòng)機(jī)制，在開始發(fā)送數(shù)據(jù)的時(shí)候，先發(fā)少量的數(shù)據(jù)探探路。

4、說說 TCP 協(xié)議如何提高傳輸效率?

一句話：TCP 協(xié)議提高效率的方式有滑動(dòng)窗口、快重傳、延遲應(yīng)答、捎帶應(yīng)答等。

(1)滑動(dòng)窗口

如果每一個(gè)發(fā)送的數(shù)據(jù)段，都要收到 ACK 應(yīng)答之后再發(fā)送下一個(gè)數(shù)據(jù)段，這樣的話我們效率很低，大部分時(shí)間都用在了等待 ACK 應(yīng)答上了。

為了提高效率我們可以一次發(fā)送多條數(shù)據(jù)，這樣就能使等待時(shí)間大大減少，從而提高性能。窗口大小指的是無需等待確認(rèn)應(yīng)答而可以繼續(xù)發(fā)送數(shù)據(jù)的最大值。

(2)快重傳

快重傳也叫高速重發(fā)控制。

那么如果出現(xiàn)了丟包，需要進(jìn)行重傳。一般分為兩種情況：

情況一：數(shù)據(jù)包已經(jīng)抵達(dá)，ACK被丟了。這種情況下，部分ACK丟了并不影響，因?yàn)榭梢酝ㄟ^后續(xù)的ACK進(jìn)行確認(rèn);

情況二：數(shù)據(jù)包直接丟了。發(fā)送端會(huì)連續(xù)收到多個(gè)相同的 ACK 確認(rèn)，發(fā)送端立即將對(duì)應(yīng)丟失的數(shù)據(jù)重傳。

(3)延遲應(yīng)答

如果接收數(shù)據(jù)的主機(jī)立刻返回ACK應(yīng)答，這時(shí)候返回的窗口大小可能比較小。

• 假設(shè)接收端緩沖區(qū)為1M，一次收到了512K的數(shù)據(jù);如果立刻應(yīng)答，返回的窗口就是512K;
• 但實(shí)際上可能處理端處理速度很快，10ms之內(nèi)就把512K的數(shù)據(jù)從緩存區(qū)消費(fèi)掉了;
• 在這種情況下，接收端處理還遠(yuǎn)沒有達(dá)到自己的極限，即使窗口再放大一些，也能處理過來;
• 如果接收端稍微等一會(huì)在應(yīng)答，比如等待200ms再應(yīng)答，那么這個(gè)時(shí)候返回的窗口大小就是1M;

窗口越大，網(wǎng)絡(luò)吞吐量就越大，傳輸效率就越高;我們的目標(biāo)是在保證網(wǎng)絡(luò)不擁塞的情況下盡量提高傳輸效率。

(4)捎帶應(yīng)答

在延遲應(yīng)答的基礎(chǔ)上，很多情況下，客戶端服務(wù)器在應(yīng)用層也是一發(fā)一收的。這時(shí)候常常采用捎帶應(yīng)答的方式來提高效率，而ACK響應(yīng)常常伴隨著數(shù)據(jù)報(bào)文共同傳輸。如：三次握手。

5、你知道 TCP 如何處理?yè)砣麊?

網(wǎng)絡(luò)擁塞現(xiàn)象是指到達(dá)通信網(wǎng)絡(luò)中某一部分的分組數(shù)量過多，使得該部分網(wǎng)絡(luò)來不及處理，以致引起這部分乃至整個(gè)網(wǎng)絡(luò)性能下降的現(xiàn)象，嚴(yán)重時(shí)甚至?xí)?dǎo)致網(wǎng)絡(luò)通信業(yè)務(wù)陷入停頓，即出現(xiàn)死鎖現(xiàn)象。擁塞控制是處理網(wǎng)絡(luò)擁塞現(xiàn)象的一種機(jī)制。

擁塞控制的四個(gè)階段:

• 慢啟動(dòng)
• 擁塞避免
• 快速重傳
• 快速恢復(fù)

6、講一下三次握手和四次揮手全過程

三次握手的過程給面試官甩一張圖：

四次揮手的過程再給面試官甩一張圖：

7、為什么 TCP 鏈接需要三次握手，兩次不可以么，為什么?

• 兩次握手只能保證單向連接是暢通的

第一步，客戶端給服務(wù)端發(fā)送一條消息：你好，服務(wù)端。第二步，服務(wù)端收到消息，同時(shí)給客戶端回復(fù)一條消息：收到!你好客戶端。

這樣的兩次握手過程， 客戶端給服務(wù)端打招呼，服務(wù)端收到了，說明客戶端可以正常給服務(wù)端發(fā)送數(shù)據(jù)。但是服務(wù)端給客戶端打招呼，服務(wù)端沒有收到反饋，也就不能確保服務(wù)端是否能正常給客戶端發(fā)送消息。

• 只有經(jīng)過第三次握手，才能確保雙向都可以接收到對(duì)方的發(fā)送的數(shù)據(jù) 第三步，客戶端收到服務(wù)端發(fā)送的消息，回復(fù)：收到!這樣就證明了客戶端能正常收到服務(wù)端的消息。

8、IP地址是怎樣分類的，你知道嗎?

先說一下 IP 的基本特點(diǎn)：

• IP地址由四段組成，每個(gè)字段是一個(gè)字節(jié)，8位，最大值是255。
• IP地址由兩部分組成，即網(wǎng)絡(luò)地址和主機(jī)地址。網(wǎng)絡(luò)地址表示其屬于互聯(lián)網(wǎng)的哪一個(gè)網(wǎng)絡(luò)，主機(jī)地址表示其屬于該網(wǎng)絡(luò)中的哪一臺(tái)主機(jī)。

IP 地址主要分為A、B、C三類及特殊地址D、E這五類，甩一張圖：

A類：(1.0.0.0-126.0.0.0)一般用于大型網(wǎng)絡(luò)。

B類：(128.0.0.0-191.255.0.0)一般用于中等規(guī)模網(wǎng)絡(luò)。

C類：(192.0.0.0-223.255.255.0)一般用于小型網(wǎng)絡(luò)。

D類：是多播地址，地址的網(wǎng)絡(luò)號(hào)取值于224~239之間，一般用于多路廣播用戶。

E類：是保留地址。地址的網(wǎng)絡(luò)號(hào)取值于240~255之間。

HTTP協(xié)議

9、講一下 http1.1 和 http2 有什么區(qū)別?

HTTP1.1

• 持久連接
• 請(qǐng)求管道化
• 增加緩存處理(新的字段如cache-control)
• 增加 Host 字段、支持?jǐn)帱c(diǎn)傳輸?shù)?/li>

HTTP2.0

• 二進(jìn)制分幀
• 多路復(fù)用(或連接共享)
• 頭部壓縮
• 服務(wù)器推送

10、說說 HTTP 和HTTPS 的區(qū)別?

(1)HTTPS 協(xié)議需要到 CA 申請(qǐng)證書，一般免費(fèi)證書較少，因而需要一定費(fèi)用。(2)HTTP 是超文本傳輸協(xié)議，信息是明文傳輸，HTTPS 則是具有安全性的 SSL 加密傳輸協(xié)議。(3)HTTP 和 HTTPS 使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。(4)HTTP 的連接很簡(jiǎn)單，是無狀態(tài)的;HTTPS 協(xié)議是由 SSL+HTTP 協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比 HTTP 協(xié)議安全。

11、你知道對(duì)稱加密和非對(duì)稱加密的區(qū)別和原理嗎?

對(duì)稱密鑰加密是指加密和解密使用同一個(gè)密鑰的方式，這種方式存在的最大問題就是密鑰發(fā)送問題，即如何安全地將密鑰發(fā)給對(duì)方;

而非對(duì)稱加密是指使用一對(duì)非對(duì)稱密鑰，即公鑰和私鑰，公鑰可以隨意發(fā)布，但私鑰只有自己知道。發(fā)送密文的一方使用對(duì)方的公鑰進(jìn)行加密處理，對(duì)方接收到加密信息后，使用自己的私鑰進(jìn)行解密。

由于非對(duì)稱加密的方式不需要發(fā)送用來解密的私鑰，所以可以保證安全性;但是和對(duì)稱加密比起來，它比較慢，所以我們還是要用對(duì)稱加密來傳送消息，但對(duì)稱加密所使用的密鑰我們可以通過非對(duì)稱加密的方式發(fā)送出去。

12、常見的狀態(tài)碼有哪些?

1×× : 請(qǐng)求處理中，請(qǐng)求已被接受，正在處理

2×× : 請(qǐng)求成功，請(qǐng)求被成功處理 200 OK

3×× : 重定向，要完成請(qǐng)求必須進(jìn)行進(jìn)一步處理 301 : 永久性轉(zhuǎn)移 302 ：暫時(shí)性轉(zhuǎn)移 304 ：已緩存

4×× : 客戶端錯(cuò)誤，請(qǐng)求不合法 400：Bad Request,請(qǐng)求有語(yǔ)法問題 403：拒絕請(qǐng)求 404：客戶端所訪問的頁(yè)面不存在

5×× : 服務(wù)器端錯(cuò)誤，服務(wù)器不能處理合法請(qǐng)求 500 ：服務(wù)器內(nèi)部錯(cuò)誤 503 ：服務(wù)不可用，稍等

13、http中常見的header字段有哪些?

cookie，請(qǐng)求時(shí)傳遞給服務(wù)端的cookie信息 set-cookie，響應(yīng)報(bào)文首部設(shè)置要傳遞給客戶端的cookie信息 allow，支持什么HTTP方法 last-modified，資源的最后修改時(shí)間 expires,設(shè)置資源緩存的失敗日期 content-language，實(shí)體的資源語(yǔ)言 content-encoding，實(shí)體的編碼格式 content-length，實(shí)體主體部分的大小單位是字節(jié) content-range，返回的實(shí)體的哪些范圍 content-type，哪些類型 accept-ranges，處理的范圍請(qǐng)求 age，告訴客戶端服務(wù)器在多久前創(chuàng)建了響應(yīng) vary，代理服務(wù)器的緩存信息 location，用于指定重定向后的URI If-Match，值是資源的唯一標(biāo)識(shí) User-Agent，將創(chuàng)建請(qǐng)求的瀏覽器和用戶代理名稱等信息傳遞給服務(wù)器 Transfer-Encoding，傳輸報(bào)文的主體編碼方式 connection，管理持久連接，keep-alive , close Cache-Control，控制瀏覽器的強(qiáng)緩存

14、Get與POST的區(qū)別

(1)GET 一般用來從服務(wù)器上獲取資源，POST 一般用來創(chuàng)建資源;

(2)GET 是冪等的，即讀取同一個(gè)資源，總是得到相同的數(shù)據(jù)，而 POST 不是冪等的。GET 不會(huì)改變服務(wù)器上的資源，而 POST 會(huì)對(duì)服務(wù)器資源進(jìn)行改變;

(3)從請(qǐng)求參數(shù)形式上看，GET 請(qǐng)求的數(shù)據(jù)會(huì)附在URL之后;而 POST 請(qǐng)求會(huì)把提交的數(shù)據(jù)則放置在是HTTP請(qǐng)求報(bào)文的請(qǐng)求體中。

(4)POST 的安全性要比 GET 的安全性高，因?yàn)?GET 請(qǐng)求提交的數(shù)據(jù)將明文出現(xiàn)在 URL 上，而 POST 請(qǐng)求參數(shù)則被包裝到請(qǐng)求體中，相對(duì)更安全。

(5)GET 請(qǐng)求的長(zhǎng)度受限于瀏覽器或服務(wù)器對(duì)URL長(zhǎng)度的限制，允許發(fā)送的數(shù)據(jù)量比較小，而POST請(qǐng)求則是沒有大小限制的。

15、DNS 的尋址過程你知道嗎?

(1)在瀏覽器中輸入www.baidu.com域名，操作系統(tǒng)會(huì)先檢查自己本地的 hosts 文件是否有這個(gè)網(wǎng)址映射關(guān)系，如果有就先調(diào)用這個(gè)IP地址映射，完成域名解析。

(2)如果 hosts 里沒有這個(gè)域名的映射，則查找本地 DNS 解析器緩存，是否有這個(gè)網(wǎng)址映射關(guān)系，如果有直接返回，完成域名解析。

(3)如果 hosts 與本地 DNS 解析器緩存都沒有相應(yīng)的網(wǎng)址映射關(guān)系，首先會(huì)找 TCP/IP 參數(shù)中設(shè)置的首選 DNS 服務(wù)器，在此我們叫它本地 DNS 服務(wù)器，此服務(wù)器收到查詢時(shí)，如果要查詢的域名，包含在本地配置區(qū)域資源中，則返回解析結(jié)果給客戶機(jī)，完成域名解析，此解析具有權(quán)威性。

(4)如果要查詢的域名，不由本地 DNS 服務(wù)器區(qū)域解析，但該服務(wù)器已緩存了此網(wǎng)址映射關(guān)系，則調(diào)用這個(gè) IP 地址映射，完成域名解析，此解析不具有權(quán)威性。

(5)如果本地 DNS 服務(wù)器本地區(qū)域文件與緩存解析都失效，則根據(jù)本地 DNS 服務(wù)器的設(shè)置(是否設(shè)置轉(zhuǎn)發(fā)器)進(jìn)行查詢，如果未用轉(zhuǎn)發(fā)模式，本地 DNS 就把請(qǐng)求發(fā)至13臺(tái)根 DNS ，根 DNS 服務(wù)器收到請(qǐng)求后會(huì)判斷這個(gè)域名(.com)是誰(shuí)來授權(quán)管理，并會(huì)返回一個(gè)負(fù)責(zé)該頂級(jí)域名服務(wù)器的一個(gè)IP。本地 DNS 服務(wù)器收到IP信息后，將會(huì)聯(lián)系負(fù)責(zé) .com 域的這臺(tái)服務(wù)器。這臺(tái)負(fù)責(zé) .com 域的服務(wù)器收到請(qǐng)求后，如果自己無法解析，它就會(huì)找一個(gè)管理.com域的下一級(jí)DNS服務(wù)器地址(baidu.com)給本地 DNS 服務(wù)器。當(dāng)本地 DNS 服務(wù)器收到這個(gè)地址后，就會(huì)找 baidu.com 域服務(wù)器，重復(fù)上面的動(dòng)作，進(jìn)行查詢，直至找到 www.baidu.com 主機(jī)。

(6)如果用的是轉(zhuǎn)發(fā)模式，此 DNS 服務(wù)器就會(huì)把請(qǐng)求轉(zhuǎn)發(fā)至上一級(jí) DNS 服務(wù)器，由上一級(jí)服務(wù)器進(jìn)行解析，上一級(jí)服務(wù)器如果不能解析，或找根 DNS 或把轉(zhuǎn)請(qǐng)求轉(zhuǎn)至上上級(jí)，以此循環(huán)。不管是本地 DNS 服務(wù)器用是是轉(zhuǎn)發(fā)，還是根提示，最后都是把結(jié)果返回給本地 DNS 服務(wù)器，由此 DNS 服務(wù)器再返回給客戶機(jī)。

16、在瀏覽器中輸入一個(gè)www.baidu.com后執(zhí)行的全部過程?

總體流程

域名解析 -> 建立TCP連接(三次握手)-> 發(fā)起http請(qǐng)求 -> 服務(wù)器響應(yīng)http請(qǐng)求，瀏覽器得到html代碼 -> 瀏覽器解析html代碼，并請(qǐng)求html代碼中的資源(如 js、css、圖片等)-> 瀏覽器對(duì)頁(yè)面進(jìn)行渲染呈獻(xiàn)給用戶。

17、Session、Cookie 的區(qū)別

• session 在服務(wù)器端，cookie 在客戶端(瀏覽器)
• session 默認(rèn)被存儲(chǔ)在服務(wù)器的一個(gè)文件里(不是內(nèi)存)
• session 的運(yùn)行依賴 session id，而 session id 是存在 cookie 中的，也就是說，如果瀏覽器禁用了 cookie ，同時(shí) session 也會(huì)失效(但是可以通過其它方式實(shí)現(xiàn)，比如在 url 中傳遞 session_id)
• session 可以放在 文件、數(shù)據(jù)庫(kù)、或內(nèi)存中都可以。

用戶驗(yàn)證這種場(chǎng)合一般會(huì)用 session

18、有哪些 web 性能優(yōu)化技術(shù)?

• DNS查詢優(yōu)化
• 客戶端緩存
• 優(yōu)化TCP連接
• 避免重定向
• 網(wǎng)絡(luò)邊緣的緩存
• 條件緩存
• 壓縮和代碼極簡(jiǎn)化
• 圖片優(yōu)化

網(wǎng)絡(luò)安全

19、什么是 XSS 攻擊?

XSS 即(Cross Site Scripting)中文名稱為：跨站腳本攻擊。XSS的重點(diǎn)不在于跨站點(diǎn)，而在于腳本的執(zhí)行。

XSS的原理是：

惡意攻擊者在web頁(yè)面中會(huì)插入一些惡意的script代碼。當(dāng)用戶瀏覽該頁(yè)面的時(shí)候，那么嵌入到web頁(yè)面中script代碼會(huì)執(zhí)行，因此會(huì)達(dá)到惡意攻擊用戶的目的。

XSS攻擊最主要有如下分類：反射型、存儲(chǔ)型、及 DOM-based型。反射性和DOM-baseed型可以歸類為非持久性XSS攻擊。存儲(chǔ)型可以歸類為持久性XSS攻擊。

20、什么是跨站攻擊CSRF?

CSRF(Cross Site Request Forgery，跨站域請(qǐng)求偽造)是一種網(wǎng)絡(luò)的攻擊方式，它在 2007 年曾被列為互聯(lián)網(wǎng) 20 大安全隱患之一，也被稱為『One Click Attack』或者 『Session Riding』，通?？s寫為CSRF或者XSRF，是一種對(duì)網(wǎng)站的惡意利用。

聽起來像跨站腳本(XSS)，但它與XSS非常不同，并且攻擊方式幾乎相左。

XSS利用站點(diǎn)內(nèi)的信任用戶，而CSRF則通過偽裝來自受信任用戶的請(qǐng)求來利用受信任的網(wǎng)站。與XSS攻擊相比，CSRF攻擊往往不大流行(因此對(duì)其進(jìn)行防范的資源也相當(dāng)稀少)和難以防范，所以被認(rèn)為比XSS更具危險(xiǎn)性。