計(jì)算機(jī)網(wǎng)絡(luò)八股文背誦版

作者：后端技術(shù)小牛說 2021-04-14 10:02:59

在不可靠的物理介質(zhì)上提供可靠的傳輸，接收來自物理層的位流形式的數(shù)據(jù)，并封裝成幀，傳送到上一層;同樣，也將來自上層的數(shù)據(jù)幀，拆裝為位流形式的數(shù)據(jù)轉(zhuǎn)發(fā)到物理層。

[[393039]]

簡(jiǎn)述OSI七層協(xié)議

OSI七層協(xié)議包括：物理層，數(shù)據(jù)鏈路層，網(wǎng)絡(luò)層，運(yùn)輸層，會(huì)話層，表示層，應(yīng)用層

簡(jiǎn)述TCP/IP五層協(xié)議

TCP/IP五層協(xié)議包括：物理層，數(shù)據(jù)鏈路層，網(wǎng)絡(luò)層，運(yùn)輸層，應(yīng)用層

物理層有什么作用

主要解決兩臺(tái)物理機(jī)之間的通信，通過二進(jìn)制比特流的傳輸來實(shí)現(xiàn)，二進(jìn)制數(shù)據(jù)表現(xiàn)為電流電壓上的強(qiáng)弱，到達(dá)目的地再轉(zhuǎn)化為二進(jìn)制機(jī)器碼。網(wǎng)卡、集線器工作在這一層。

數(shù)據(jù)鏈路層有什么作用

在不可靠的物理介質(zhì)上提供可靠的傳輸，接收來自物理層的位流形式的數(shù)據(jù)，并封裝成幀，傳送到上一層;同樣，也將來自上層的數(shù)據(jù)幀，拆裝為位流形式的數(shù)據(jù)轉(zhuǎn)發(fā)到物理層。這一層在物理層提供的比特流的基礎(chǔ)上，通過差錯(cuò)控制、流量控制方法，使有差錯(cuò)的物理線路變?yōu)闊o差錯(cuò)的數(shù)據(jù)鏈路。提供物理地址尋址功能。交換機(jī)工作在這一層。

網(wǎng)絡(luò)層有什么作用

將網(wǎng)絡(luò)地址翻譯成對(duì)應(yīng)的物理地址，并決定如何將數(shù)據(jù)從發(fā)送方路由到接收方，通過路由選擇算法為分組通過通信子網(wǎng)選擇最佳路徑。路由器工作在這一層。

傳輸層有什么作用

傳輸層提供了進(jìn)程間的邏輯通信，傳輸層向高層用戶屏蔽了下面網(wǎng)絡(luò)層的核心細(xì)節(jié)，使應(yīng)用程序看起來像是在兩個(gè)傳輸層實(shí)體之間有一條端到端的邏輯通信信道。

會(huì)話層有什么作用

建立會(huì)話：身份驗(yàn)證，權(quán)限鑒定等;保持會(huì)話：對(duì)該會(huì)話進(jìn)行維護(hù)，在會(huì)話維持期間兩者可以隨時(shí)使用這條會(huì)話傳輸局;斷開會(huì)話：當(dāng)應(yīng)用程序或應(yīng)用層規(guī)定的超時(shí)時(shí)間到期后，OSI會(huì)話層才會(huì)釋放這條會(huì)話。

表示層有什么作用

對(duì)數(shù)據(jù)格式進(jìn)行編譯，對(duì)收到或發(fā)出的數(shù)據(jù)根據(jù)應(yīng)用層的特征進(jìn)行處理，如處理為文字、圖片、音頻、視頻、文檔等，還可以對(duì)壓縮文件進(jìn)行解壓縮、對(duì)加密文件進(jìn)行解密等。

應(yīng)用層有什么作用

提供應(yīng)用層協(xié)議，如HTTP協(xié)議，F(xiàn)TP協(xié)議等等，方便應(yīng)用程序之間進(jìn)行通信。

TCP與UDP區(qū)別

TCP作為面向流的協(xié)議，提供可靠的、面向連接的運(yùn)輸服務(wù)，并且提供點(diǎn)對(duì)點(diǎn)通信 UDP作為面向報(bào)文的協(xié)議，不提供可靠交付，并且不需要連接，不僅僅對(duì)點(diǎn)對(duì)點(diǎn)，也支持多播和廣播

為何TCP可靠

TCP有三次握手建立連接，四次揮手關(guān)閉連接的機(jī)制。除此之外還有滑動(dòng)窗口和擁塞控制算法。最最關(guān)鍵的是還保留超時(shí)重傳的機(jī)制。對(duì)于每份報(bào)文也存在校驗(yàn)，保證每份報(bào)文可靠性。

為何UDP不可靠

UDP面向數(shù)據(jù)報(bào)無連接的，數(shù)據(jù)報(bào)發(fā)出去，就不保留數(shù)據(jù)備份了。僅僅在IP數(shù)據(jù)報(bào)頭部加入校驗(yàn)和復(fù)用。UDP沒有服務(wù)器和客戶端的概念。UDP報(bào)文過長的話是交給IP切成小段，如果某段報(bào)廢報(bào)文就廢了。

簡(jiǎn)述TCP粘包現(xiàn)象

TCP是面向流協(xié)議，發(fā)送的單位是字節(jié)流，因此會(huì)將多個(gè)小尺寸數(shù)據(jù)被封裝在一個(gè)tcp報(bào)文中發(fā)出去的可能性。可以簡(jiǎn)單的理解成客戶端調(diào)用了兩次send，服務(wù)器端一個(gè)recv就把信息都讀出來了。

TCP粘包現(xiàn)象處理方法

固定發(fā)送信息長度，或在兩個(gè)信息之間加入分隔符。

簡(jiǎn)述TCP協(xié)議的滑動(dòng)窗口

滑動(dòng)窗口是傳輸層進(jìn)行流量控制的一種措施，接收方通過通告發(fā) 送方自己的窗口大小，從而控制發(fā)送方的發(fā)送速度，防止發(fā)送方發(fā)送速度過快而導(dǎo)致自己被淹沒。

簡(jiǎn)述TCP協(xié)議的擁塞控制

擁塞是指一個(gè)或者多個(gè)交換點(diǎn)的數(shù)據(jù)報(bào)超載，TCP又會(huì)有重傳機(jī)制，導(dǎo)致過載。為了防止擁塞窗口cwnd增長過大引起網(wǎng)絡(luò)擁塞，還需要設(shè)置一個(gè)慢開始門限ssthresh狀態(tài)變量.

當(dāng)cwnd < ssthresh 時(shí)，使用慢開始算法。當(dāng)cwnd > ssthresh 時(shí)，停止使用慢開始算法而改用擁塞避免算法。當(dāng)cwnd = ssthresh 時(shí)，即可使用慢開始算法，也可使用擁塞避免算法。

慢開始：由小到大逐漸增加擁塞窗口的大小，每接一次報(bào)文，cwnd指數(shù)增加。

擁塞避免：cwnd緩慢地增大，即每經(jīng)過一個(gè)往返時(shí)間RTT就把發(fā)送方的擁塞窗口cwnd加1。

快恢復(fù)之前的策略：發(fā)送方判斷網(wǎng)絡(luò)出現(xiàn)擁塞，就把ssthresh設(shè)置為出現(xiàn)擁塞時(shí)發(fā)送方窗口值的一半，繼續(xù)執(zhí)行慢開始，之后進(jìn)行擁塞避免。

快恢復(fù)：發(fā)送方判斷網(wǎng)絡(luò)出現(xiàn)擁塞，就把ssthresh設(shè)置為出現(xiàn)擁塞時(shí)發(fā)送方窗口值的一半，并把cwnd設(shè)置為ssthresh的一半，之后進(jìn)行擁塞避免。

簡(jiǎn)述快重傳

如果在超時(shí)重傳定時(shí)器溢出之前，接收到連續(xù)的三個(gè)重復(fù)冗余ACK，發(fā)送端便知曉哪個(gè)報(bào)文段在傳輸過程中丟失了，于是重發(fā)該報(bào)文段，不需要等待超時(shí)重傳定時(shí)器溢出再發(fā)送該報(bào)文。

TCP三次握手過程

第一次握手:客戶端將標(biāo)志位SYN置為1，隨機(jī)產(chǎn)生一個(gè)值序列號(hào)seq=x，并將該數(shù)據(jù)包發(fā)送給服務(wù)端，客戶端進(jìn)入syn_sent狀態(tài)，等待服務(wù)端確認(rèn)。
第二次握手:服務(wù)端收到數(shù)據(jù)包后由標(biāo)志位SYN=1知道客戶端請(qǐng)求建立連接，服務(wù)端將標(biāo)志位SYN和 ACK都置為1，ack=x+1,隨機(jī)產(chǎn)生一個(gè)值seq=y，并將該數(shù)據(jù)包發(fā)送給客戶端以確認(rèn)連接請(qǐng)求，服務(wù)端進(jìn)入syn_rcvd狀態(tài)。
第三次握手:客戶端收到確認(rèn)后檢查,如果正確則將標(biāo)志位ACK為1，ack=y+1，并將該數(shù)據(jù)包發(fā)送給服務(wù)端，服務(wù)端進(jìn)行檢查如果正確則連接建立成功，客戶端和服務(wù)端進(jìn)入established狀態(tài)，完成三次握手，隨后客戶端和服務(wù)端之間可以開始傳輸數(shù)據(jù)了

為什么TCP握手需要三次，兩次行不行?

不行。TCP進(jìn)行可靠傳輸?shù)年P(guān)鍵就在于維護(hù)一個(gè)序列號(hào)，三次握手的過程即是通信雙方相互告知序列號(hào)起始值，并確認(rèn)對(duì)方已經(jīng)收到了序列號(hào)起始值。

如果只是兩次握手，至多只有客戶端的起始序列號(hào)能被確認(rèn)，服務(wù)器端的序列號(hào)則得不到確認(rèn)。

簡(jiǎn)述半連接隊(duì)列

TCP握手中，當(dāng)服務(wù)器處于SYN_RCVD 狀態(tài)，服務(wù)器會(huì)把此種狀態(tài)下請(qǐng)求連接放在一個(gè)隊(duì)列里，該隊(duì)列稱為半連接隊(duì)列。

簡(jiǎn)述SYN攻擊

SYN攻擊即利用TCP協(xié)議缺陷，通過發(fā)送大量的半連接請(qǐng)求，占用半連接隊(duì)列，耗費(fèi)CPU和內(nèi)存資源。

優(yōu)化方式：

縮短SYN Timeout時(shí)間
記錄IP，若連續(xù)受到某個(gè)IP的重復(fù)SYN報(bào)文，從這個(gè)IP地址來的包會(huì)被一概丟棄。

TCP四次揮手過程

第一次揮手：客戶端發(fā)送一個(gè)FIN，用來關(guān)閉客戶端到服務(wù)端的數(shù)據(jù)傳送，客戶端進(jìn)入fin_wait_1狀態(tài)。
第二次揮手：服務(wù)端收到FIN后，發(fā)送一個(gè)ACK給客戶端，確認(rèn)序號(hào)為收到序號(hào)+1，服務(wù)端進(jìn)入Close_wait狀態(tài)。此時(shí)TCP連接處于半關(guān)閉狀態(tài)，即客戶端已經(jīng)沒有要發(fā)送的數(shù)據(jù)了，但服務(wù)端若發(fā)送數(shù)據(jù)，則客戶端仍要接收。
第三次揮手：服務(wù)端發(fā)送一個(gè)FIN，用來關(guān)閉服務(wù)端到客戶端的數(shù)據(jù)傳送，服務(wù)端進(jìn)入Last_ack狀態(tài)。
第四次揮手：客戶端收到FIN后，客戶端進(jìn)入Time_wait狀態(tài)，接著發(fā)送一個(gè)ACK給服務(wù)端，確認(rèn)后，服務(wù)端進(jìn)入Closed狀態(tài)，完成四次揮手。

為什么TCP揮手需要4次

主要原因是當(dāng)服務(wù)端收到客戶端的 FIN 數(shù)據(jù)包后，服務(wù)端可能還有數(shù)據(jù)沒發(fā)完，不會(huì)立即close。

所以服務(wù)端會(huì)先將 ACK 發(fā)過去告訴客戶端我收到你的斷開請(qǐng)求了，但請(qǐng)?jiān)俳o我一點(diǎn)時(shí)間，這段時(shí)間用來發(fā)送剩下的數(shù)據(jù)報(bào)文，發(fā)完之后再將 FIN 包發(fā)給客戶端表示現(xiàn)在可以斷了。之后客戶端需要收到 FIN 包后發(fā)送 ACK 確認(rèn)斷開信息給服務(wù)端。

為什么四次揮手釋放連接時(shí)需要等待2MSL

MSL即報(bào)文最大生存時(shí)間。設(shè)置2MSL可以保證上一次連接的報(bào)文已經(jīng)在網(wǎng)絡(luò)中消失，不會(huì)出現(xiàn)與新TCP連接報(bào)文沖突的情況。

簡(jiǎn)述DNS協(xié)議

DNS協(xié)議是基于UDP的應(yīng)用層協(xié)議，它的功能是根據(jù)用戶輸入的域名，解析出該域名對(duì)應(yīng)的IP地址，從而給客戶端進(jìn)行訪問。

簡(jiǎn)述DNS解析過程

1、客戶機(jī)發(fā)出查詢請(qǐng)求，在本地計(jì)算機(jī)緩存查找，若沒有找到，就會(huì)將請(qǐng)求發(fā)送給dns服務(wù)器

2、本地dns服務(wù)器會(huì)在自己的區(qū)域里面查找，找到即根據(jù)此記錄進(jìn)行解析，若沒有找到，就會(huì)在本地的緩存里面查找

3、本地服務(wù)器沒有找到客戶機(jī)查詢的信息，就會(huì)將此請(qǐng)求發(fā)送到根域名dns服務(wù)器

4、根域名服務(wù)器解析客戶機(jī)請(qǐng)求的根域部分，它把包含的下一級(jí)的dns服務(wù)器的地址返回到客戶機(jī)的dns服務(wù)器地址

5、客戶機(jī)的dns服務(wù)器根據(jù)返回的信息接著訪問下一級(jí)的dns服務(wù)器

6、這樣遞歸的方法一級(jí)一級(jí)接近查詢的目標(biāo)，最后在有目標(biāo)域名的服務(wù)器上面得到相應(yīng)的IP信息

7、客戶機(jī)的本地的dns服務(wù)器會(huì)將查詢結(jié)果返回給我們的客戶機(jī)

8、客戶機(jī)根據(jù)得到的ip信息訪問目標(biāo)主機(jī)，完成解析過程

簡(jiǎn)述HTTP協(xié)議

http協(xié)議是超文本傳輸協(xié)議。它是基于TCP協(xié)議的應(yīng)用層傳輸協(xié)議，即客戶端和服務(wù)端進(jìn)行數(shù)據(jù)傳輸?shù)囊环N規(guī)則。該協(xié)議本身HTTP 是一種無狀態(tài)的協(xié)議。

簡(jiǎn)述cookie

HTTP 協(xié)議本身是無狀態(tài)的，為了使其能處理更加復(fù)雜的邏輯，HTTP/1.1 引入 Cookie 來保存狀態(tài)信息。

Cookie是由服務(wù)端產(chǎn)生的，再發(fā)送給客戶端保存，當(dāng)客戶端再次訪問的時(shí)候，服務(wù)器可根據(jù)cookie辨識(shí)客戶端是哪個(gè)，以此可以做個(gè)性化推送，免賬號(hào)密碼登錄等等。

簡(jiǎn)述session

session用于標(biāo)記特定客戶端信息，存在在服務(wù)器的一個(gè)文件里。一般客戶端帶Cookie對(duì)服務(wù)器進(jìn)行訪問，可通過cookie中的session id從整個(gè)session中查詢到服務(wù)器記錄的關(guān)于客戶端的信息。

簡(jiǎn)述http狀態(tài)碼和對(duì)應(yīng)的信息

1XX：接收的信息正在處理

2XX：請(qǐng)求正常處理完畢

3XX：重定向

4XX：客戶端錯(cuò)誤

5XX：服務(wù)端錯(cuò)誤

常見錯(cuò)誤碼：301：永久重定向 302：臨時(shí)重定向 304：資源沒修改，用之前緩存就行 400：客戶端請(qǐng)求的報(bào)文有錯(cuò)誤 403：表示服務(wù)器禁止訪問資源 404：表示請(qǐng)求的資源在服務(wù)器上不存在或未找到

轉(zhuǎn)發(fā)和重定向的區(qū)別

轉(zhuǎn)發(fā)是服務(wù)器行為。服務(wù)器直接向目標(biāo)地址訪問URL,將相應(yīng)內(nèi)容讀取之后發(fā)給瀏覽器，用戶瀏覽器地址欄URL不變，轉(zhuǎn)發(fā)頁面和轉(zhuǎn)發(fā)到的頁面可以共享request里面的數(shù)據(jù)。

重定向是利用服務(wù)器返回的狀態(tài)碼來實(shí)現(xiàn)的，如果服務(wù)器返回301或者302，瀏覽器收到新的消息后自動(dòng)跳轉(zhuǎn)到新的網(wǎng)址重新請(qǐng)求資源。用戶的地址欄url會(huì)發(fā)生改變，而且不能共享數(shù)據(jù)。

簡(jiǎn)述http1.0

規(guī)定了請(qǐng)求頭和請(qǐng)求尾，響應(yīng)頭和響應(yīng)尾(get post)

每一個(gè)請(qǐng)求都是一個(gè)單獨(dú)的連接，做不到連接的復(fù)用

簡(jiǎn)述http1.1的改進(jìn)

HTTP1.1默認(rèn)開啟長連接，在一個(gè)TCP連接上可以傳送多個(gè)HTTP請(qǐng)求和響應(yīng)。使用 TCP 長連接的方式改善了 HTTP/1.0 短連接造成的性能開銷。

支持管道(pipeline)網(wǎng)絡(luò)傳輸，只要第一個(gè)請(qǐng)求發(fā)出去了，不必等其回來，就可以發(fā)第二個(gè)請(qǐng)求出去，可以減少整體的響應(yīng)時(shí)間。

服務(wù)端無法主動(dòng)push

簡(jiǎn)述HTTP短連接與長連接區(qū)別

HTTP中的長連接短連接指HTTP底層TCP的連接。

短連接：客戶端與服務(wù)器進(jìn)行一次HTTP連接操作，就進(jìn)行一次TCP連接，連接結(jié)束TCP關(guān)閉連接。

長連接：如果HTTP頭部帶有參數(shù)keep-alive，即開啟長連接網(wǎng)頁完成打開后，底層用于傳輸數(shù)據(jù)的TCP連接不會(huì)直接關(guān)閉，會(huì)根據(jù)服務(wù)器設(shè)置的保持時(shí)間保持連接，保持時(shí)間過后連接關(guān)閉。

簡(jiǎn)述http2.0的改進(jìn)

提出多路復(fù)用。多路復(fù)用前，文件時(shí)串行傳輸?shù)模?qǐng)求a文件，b文件只能等待，并且連接數(shù)過多。引入多路復(fù)用，a文件b文件可以同時(shí)傳輸。

引入了二進(jìn)制數(shù)據(jù)幀。其中幀對(duì)數(shù)據(jù)進(jìn)行順序標(biāo)識(shí)，有了序列id，服務(wù)器就可以進(jìn)行并行傳輸數(shù)據(jù)。

http與https的區(qū)別

http所有傳輸?shù)膬?nèi)容都是明文，并且客戶端和服務(wù)器端都無法驗(yàn)證對(duì)方的身份。https具有安全性的ssl加密傳輸協(xié)議，加密采用對(duì)稱加密， https協(xié)議需要到ca申請(qǐng)證書，一般免費(fèi)證書很少，需要交費(fèi)。

簡(jiǎn)述TLS/SSL, HTTP, HTTPS的關(guān)系

SSL全稱為Secure Sockets Layer即安全套接層，其繼任為TLSTransport Layer Security傳輸層安全協(xié)議，均用于在傳輸層為數(shù)據(jù)通訊提供安全支持。

可以將HTTPS協(xié)議簡(jiǎn)單理解為HTTP協(xié)議+TLS/SSL

https的連接過程

瀏覽器將支持的加密算法信息發(fā)給服務(wù)器

服務(wù)器選擇一套瀏覽器支持的加密算法，以證書的形式回發(fā)給瀏覽器

客戶端(SSL/TLS)解析證書驗(yàn)證證書合法性，生成對(duì)稱加密的密鑰，我們將該密鑰稱之為client key，即客戶端密鑰，用服務(wù)器的公鑰對(duì)客戶端密鑰進(jìn)行非對(duì)稱加密。

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

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

服務(wù)器將加密后的密文發(fā)送給客戶端

客戶端收到服務(wù)器發(fā)送來的密文，用客戶端密鑰對(duì)其進(jìn)行對(duì)稱解密，得到服務(wù)器發(fā)送的數(shù)據(jù)。這樣HTTPS中的第二個(gè)HTTP請(qǐng)求結(jié)束，整個(gè)HTTPS傳輸完成

Get與Post區(qū)別

Get：指定資源請(qǐng)求數(shù)據(jù)，刷新無害，Get請(qǐng)求的數(shù)據(jù)會(huì)附加到URL中，傳輸數(shù)據(jù)的大小受到url的限制。

Post：向指定資源提交要被處理的數(shù)據(jù)。刷新會(huì)使數(shù)據(jù)會(huì)被重復(fù)提交。post在發(fā)送數(shù)據(jù)前會(huì)先將請(qǐng)求頭發(fā)送給服務(wù)器進(jìn)行確認(rèn)，然后才真正發(fā)送數(shù)據(jù)。

Get方法參數(shù)有大小限制嗎

一般HTTP協(xié)議里并不限制參數(shù)大小限制。但一般由于get請(qǐng)求是直接附加到地址欄里面的，由于瀏覽器地址欄有長度限制，因此使GET請(qǐng)求在瀏覽器實(shí)現(xiàn)層面上看會(huì)有長度限制。

了解REST API嗎

REST API全稱為表述性狀態(tài)轉(zhuǎn)移(Representational State Transfer，REST)即利用HTTP中g(shù)et、post、put、delete以及其他的HTTP方法構(gòu)成REST中數(shù)據(jù)資源的增刪改查操作：