計(jì)算機(jī)網(wǎng)絡(luò)八股文背誦版
肝了一份計(jì)算機(jī)網(wǎng)絡(luò)的八股文，給各位準(zhǔn)備春招的小伙伴獻(xiàn)上，不多說，開背！！
簡述OSI七層協(xié)議
OSI七層協(xié)議包括：物理層，數(shù)據(jù)鏈路層，網(wǎng)絡(luò)層，運(yùn)輸層，會話層，表示層， 應(yīng)用層
簡述TCP/IP五層協(xié)議
TCP/IP五層協(xié)議包括：物理層，數(shù)據(jù)鏈路層，網(wǎng)絡(luò)層，運(yùn)輸層，應(yīng)用層
物理層有什么作用
主要解決兩臺物理機(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ò)地址翻譯成對應(yīng)的物理地址，并決定如何將數(shù)據(jù)從發(fā)送方路由到接收方，通過路由選擇算法為分組通過通信子網(wǎng)選擇最佳路徑。路由器工作在這一層。
傳輸層有什么作用
傳輸層提供了進(jìn)程間的邏輯通信，傳輸層向高層用戶屏蔽了下面網(wǎng)絡(luò)層的核心細(xì)節(jié)，使應(yīng)用程序看起來像是在兩個(gè)傳輸層實(shí)體之間有一條端到端的邏輯通信信道。
會話層有什么作用
建立會話：身份驗(yàn)證，權(quán)限鑒定等；保持會話：對該會話進(jìn)行維護(hù)，在會話維持期間兩者可以隨時(shí)使用這條會話傳輸局；斷開會話：當(dāng)應(yīng)用程序或應(yīng)用層規(guī)定的超時(shí)時(shí)間到期后，OSI會話層才會釋放這條會話。
表示層有什么作用
對數(shù)據(jù)格式進(jìn)行編譯，對收到或發(fā)出的數(shù)據(jù)根據(jù)應(yīng)用層的特征進(jìn)行處理，如處理為文字、圖片、音頻、視頻、文檔等，還可以對壓縮文件進(jìn)行解壓縮、對加密文件進(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)對點(diǎn)通信 UDP作為面向報(bào)文的協(xié)議，不提供可靠交付，并且不需要連接，不僅僅對點(diǎn)對點(diǎn)，也支持多播和廣播
為何TCP可靠
TCP有三次握手建立連接，四次揮手關(guān)閉連接的機(jī)制。除此之外還有滑動(dòng)窗口和擁塞控制算法。最最關(guān)鍵的是還保留超時(shí)重傳的機(jī)制。對于每份報(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)文就廢了。
簡述TCP粘包現(xiàn)象
TCP是面向流協(xié)議，發(fā)送的單位是字節(jié)流，因此會將多個(gè)小尺寸數(shù)據(jù)被封裝在一個(gè)tcp報(bào)文中發(fā)出去的可能性。可以簡單的理解成客戶端調(diào)用了兩次send，服務(wù)器端一個(gè)recv就把信息都讀出來了。
TCP粘包現(xiàn)象處理方法
固定發(fā)送信息長度，或在兩個(gè)信息之間加入分隔符。
簡述TCP協(xié)議的滑動(dòng)窗口
滑動(dòng)窗口是傳輸層進(jìn)行流量控制的一種措施，接收方通過通告發(fā) 送方自己的窗口大小，從而控制發(fā)送方的發(fā)送速度，防止發(fā)送方發(fā)送速度過快而導(dǎo)致自己被淹沒。
簡述TCP協(xié)議的擁塞控制
擁塞是指一個(gè)或者多個(gè)交換點(diǎn)的數(shù)據(jù)報(bào)超載，TCP又會有重傳機(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)行擁塞避免。
簡述快重傳
如果在超時(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è)值序列號seq=x，并將該數(shù)據(jù)包發(fā)送給服務(wù)端，客戶端 進(jìn)入syn_sent狀態(tài)，等待服務(wù)端確認(rèn)。 第二次握手:服務(wù)端收到數(shù)據(jù)包后由標(biāo)志位SYN=1知道客戶端請求建立連接，服務(wù)端將標(biāo)志位SYN和 ACK都置為1，ack=x+1,隨機(jī)產(chǎn)生一個(gè)值seq=y，并將該數(shù)據(jù)包發(fā)送給客戶端以確認(rèn)連接請求，服務(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è)序列號，三次握手的過程即是通信雙方相互告知序列號起始值， 并確認(rèn)對方已經(jīng)收到了序列號起始值。
如果只是兩次握手， 至多只有客戶端的起始序列號能被確認(rèn)， 服務(wù)器端的序列號則得不到確認(rèn)。
簡述半連接隊(duì)列
TCP握手中，當(dāng)服務(wù)器處于SYN_RCVD 狀態(tài)，服務(wù)器會把此種狀態(tài)下請求連接放在一個(gè)隊(duì)列里，該隊(duì)列稱為半連接隊(duì)列。
簡述SYN攻擊
SYN攻擊即利用TCP協(xié)議缺陷，通過發(fā)送大量的半連接請求，占用半連接隊(duì)列，耗費(fèi)CPU和內(nèi)存資源。
優(yōu)化方式：
縮短SYN Timeout時(shí)間 記錄IP，若連續(xù)受到某個(gè)IP的重復(fù)SYN報(bào)文，從這個(gè)IP地址來的包會被一概丟棄。
TCP四次揮手過程
第一次揮手：客戶端發(fā)送一個(gè)FIN，用來關(guān)閉客戶端到服務(wù)端的數(shù)據(jù)傳送，客戶端進(jìn)入fin_wait_1狀態(tài)。 第二次揮手：服務(wù)端收到FIN后，發(fā)送一個(gè)ACK給客戶端，確認(rèn)序號為收到序號+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ā)完，不會立即close。
所以服務(wù)端會先將 ACK 發(fā)過去告訴客戶端我收到你的斷開請求了，但請?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ò)中消失，不會出現(xiàn)與新TCP連接報(bào)文沖突的情況。
簡述DNS協(xié)議
DNS協(xié)議是基于UDP的應(yīng)用層協(xié)議，它的功能是根據(jù)用戶輸入的域名，解析出該域名對應(yīng)的IP地址，從而給客戶端進(jìn)行訪問。
簡述DNS解析過程
1、客戶機(jī)發(fā)出查詢請求，在本地計(jì)算機(jī)緩存查找，若沒有找到，就會將請求發(fā)送給dns服務(wù)器
2、本地dns服務(wù)器會在自己的區(qū)域里面查找，找到即根據(jù)此記錄進(jìn)行解析，若沒有找到，就會在本地的緩存里面查找
3、本地服務(wù)器沒有找到客戶機(jī)查詢的信息，就會將此請求發(fā)送到根域名dns服務(wù)器
4、根域名服務(wù)器解析客戶機(jī)請求的根域部分，它把包含的下一級的dns服務(wù)器的地址返回到客戶機(jī)的dns服務(wù)器地址
5、客戶機(jī)的dns服務(wù)器根據(jù)返回的信息接著訪問下一級的dns服務(wù)器
6、這樣遞歸的方法一級一級接近查詢的目標(biāo)，最后在有目標(biāo)域名的服務(wù)器上面得到相應(yīng)的IP信息
7、客戶機(jī)的本地的dns服務(wù)器會將查詢結(jié)果返回給我們的客戶機(jī)
8、客戶機(jī)根據(jù)得到的ip信息訪問目標(biāo)主機(jī)，完成解析過程
簡述HTTP協(xié)議
http協(xié)議是超文本傳輸協(xié)議。它是基于TCP協(xié)議的應(yīng)用層傳輸協(xié)議，即客戶端和服務(wù)端進(jìn)行數(shù)據(jù)傳輸?shù)囊环N規(guī)則。該協(xié)議本身HTTP 是一種無狀態(tài)的協(xié)議。
簡述cookie
HTTP 協(xié)議本身是無狀態(tài)的，為了使其能處理更加復(fù)雜的邏輯，HTTP/1.1 引入 Cookie 來保存狀態(tài)信息。
Cookie是由服務(wù)端產(chǎn)生的，再發(fā)送給客戶端保存，當(dāng)客戶端再次訪問的時(shí)候，服務(wù)器可根據(jù)cookie辨識客戶端是哪個(gè)，以此可以做個(gè)性化推送，免賬號密碼登錄等等。
簡述session
session用于標(biāo)記特定客戶端信息，存在在服務(wù)器的一個(gè)文件里。一般客戶端帶Cookie對服務(wù)器進(jìn)行訪問，可通過cookie中的session id從整個(gè)session中查詢到服務(wù)器記錄的關(guān)于客戶端的信息。
簡述http狀態(tài)碼和對應(yīng)的信息
1XX：接收的信息正在處理
2XX：請求正常處理完畢
3XX：重定向
4XX：客戶端錯(cuò)誤
5XX：服務(wù)端錯(cuò)誤
常見錯(cuò)誤碼：301：永久重定向 302：臨時(shí)重定向 304：資源沒修改，用之前緩存就行 400：客戶端請求的報(bào)文有錯(cuò)誤 403：表示服務(wù)器禁止訪問資源 404：表示請求的資源在服務(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)址重新請求資源。用戶的地址欄url會發(fā)生改變，而且不能共享數(shù)據(jù)。
簡述http1.0
規(guī)定了請求頭和請求尾，響應(yīng)頭和響應(yīng)尾（get post）
每一個(gè)請求都是一個(gè)單獨(dú)的連接，做不到連接的復(fù)用
簡述http1.1的改進(jìn)
HTTP1.1默認(rèn)開啟長連接，在一個(gè)TCP連接上可以傳送多個(gè)HTTP請求和響應(yīng)。使用 TCP 長連接的方式改善了 HTTP/1.0 短連接造成的性能開銷。
支持管道（pipeline）網(wǎng)絡(luò)傳輸，只要第一個(gè)請求發(fā)出去了，不必等其回來，就可以發(fā)第二個(gè)請求出去，可以減少整體的響應(yīng)時(shí)間。
服務(wù)端無法主動(dòng)push
簡述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連接不會直接關(guān)閉，會根據(jù)服務(wù)器設(shè)置的保持時(shí)間保持連接，保持時(shí)間過后連接關(guān)閉。
簡述http2.0的改進(jìn)
提出多路復(fù)用。多路復(fù)用前，文件時(shí)串行傳輸?shù)模埱骯文件，b文件只能等待，并且連接數(shù)過多。引入多路復(fù)用，a文件b文件可以同時(shí)傳輸。
引入了二進(jìn)制數(shù)據(jù)幀。其中幀對數(shù)據(jù)進(jìn)行順序標(biāo)識，有了序列id，服務(wù)器就可以進(jìn)行并行傳輸數(shù)據(jù)。
http與https的區(qū)別
http所有傳輸?shù)膬?nèi)容都是明文，并且客戶端和服務(wù)器端都無法驗(yàn)證對方的身份。https具有安全性的ssl加密傳輸協(xié)議，加密采用對稱加密， https協(xié)議需要到ca申請證書，一般免費(fèi)證書很少，需要交費(fèi)。
簡述TLS/SSL, HTTP, HTTPS的關(guān)系
SSL全稱為Secure Sockets Layer即安全套接層，其繼任為TLSTransport Layer Security傳輸層安全協(xié)議，均用于在傳輸層為數(shù)據(jù)通訊提供安全支持。
可以將HTTPS協(xié)議簡單理解為HTTP協(xié)議＋TLS/SSL
https的連接過程
瀏覽器將支持的加密算法信息發(fā)給服務(wù)器 服務(wù)器選擇一套瀏覽器支持的加密算法，以證書的形式回發(fā)給瀏覽器 客戶端(SSL/TLS)解析證書驗(yàn)證證書合法性，生成對稱加密的密鑰，我們將該密鑰稱之為client key，即客戶端密鑰，用服務(wù)器的公鑰對客戶端密鑰進(jìn)行非對稱加密。 客戶端會發(fā)起HTTPS中的第二個(gè)HTTP請求，將加密之后的客戶端對稱密鑰發(fā)送給服務(wù)器 服務(wù)器接收到客戶端發(fā)來的密文之后，會用自己的私鑰對其進(jìn)行非對稱解密，解密之后的明文就是客戶端密鑰，然后用客戶端密鑰對數(shù)據(jù)進(jìn)行對稱加密，這樣數(shù)據(jù)就變成了密文。 服務(wù)器將加密后的密文發(fā)送給客戶端 客戶端收到服務(wù)器發(fā)送來的密文，用客戶端密鑰對其進(jìn)行對稱解密，得到服務(wù)器發(fā)送的數(shù)據(jù)。這樣HTTPS中的第二個(gè)HTTP請求結(jié)束，整個(gè)HTTPS傳輸完成
Get與Post區(qū)別
Get：指定資源請求數(shù)據(jù)，刷新無害，Get請求的數(shù)據(jù)會附加到URL中，傳輸數(shù)據(jù)的大小受到url的限制。
Post：向指定資源提交要被處理的數(shù)據(jù)。刷新會使數(shù)據(jù)會被重復(fù)提交。post在發(fā)送數(shù)據(jù)前會先將請求頭發(fā)送給服務(wù)器進(jìn)行確認(rèn)，然后才真正發(fā)送數(shù)據(jù)。
Get方法參數(shù)有大小限制嗎
一般HTTP協(xié)議里并不限制參數(shù)大小限制。但一般由于get請求是直接附加到地址欄里面的，由于瀏覽器地址欄有長度限制，因此使GET請求在瀏覽器實(shí)現(xiàn)層面上看會有長度限制。
了解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ù)資源的增刪改查操作：
Create ：POST Read ：GET Update ：PUT/PATCH Delete：DELETE
瀏覽器中輸入一個(gè)網(wǎng)址后，具體發(fā)生了什么
進(jìn)行DNS解析操作，根據(jù)DNS解析的結(jié)果查到服務(wù)器IP地址 通過ip尋址和arp，找到服務(wù)器，并利用三次握手建立TCP連接 瀏覽器生成HTTP報(bào)文，發(fā)送HTTP請求，等待服務(wù)器響應(yīng) 服務(wù)器處理請求，并返回給瀏覽器 根據(jù)HTTP是否開啟長連接，進(jìn)行TCP的揮手過程 瀏覽器根據(jù)收到的靜態(tài)資源進(jìn)行頁面渲染