大廠必問的計(jì)算機(jī)網(wǎng)絡(luò)面試題

本文目錄：

網(wǎng)絡(luò)分層結(jié)構(gòu)

三次握手

兩次握手可以嗎？

四次揮手

第四次揮手為什么要等待2MSL？

為什么是四次揮手？

TCP有哪些特點(diǎn)？

TCP和UDP的區(qū)別？

HTTP協(xié)議的特點(diǎn)？

HTTP報(bào)文格式

HTTP狀態(tài)碼有哪些？

HTTP1.0和HTTP1.1的區(qū)別?

HTTP1.1和 HTTP2.0的區(qū)別？

HTTPS與HTTP的區(qū)別？

什么是數(shù)字證書？

HTTPS原理

DNS 的解析過程？

瀏覽器中輸入U(xiǎn)RL返回頁面過程？

Cookie和Session的區(qū)別？

什么是對稱加密和非對稱加密？

網(wǎng)絡(luò)分層結(jié)構(gòu)

計(jì)算機(jī)網(wǎng)絡(luò)體系大致分為三種，OSI七層模型、TCP/IP四層模型和五層模型。一般面試的時(shí)候考察比較多的是五層模型。

TCP/IP五層模型：應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層、物理層。

應(yīng)用層：為應(yīng)用程序提供交互服務(wù)。在互聯(lián)網(wǎng)中的應(yīng)用層協(xié)議很多，如域名系統(tǒng)DNS、HTTP協(xié)議、SMTP協(xié)議等。

傳輸層：負(fù)責(zé)向兩臺主機(jī)進(jìn)程之間的通信提供數(shù)據(jù)傳輸服務(wù)。傳輸層的協(xié)議主要有傳輸控制協(xié)議TCP和用戶數(shù)據(jù)協(xié)議UDP。

網(wǎng)絡(luò)層：選擇合適的路由和交換結(jié)點(diǎn)，確保數(shù)據(jù)及時(shí)傳送。主要包括IP協(xié)議。

數(shù)據(jù)鏈路層：在兩個(gè)相鄰節(jié)點(diǎn)之間傳送數(shù)據(jù)時(shí)，數(shù)據(jù)鏈路層將網(wǎng)絡(luò)層交下來的 IP 數(shù)據(jù)報(bào)組裝成幀，在兩個(gè)相鄰節(jié)點(diǎn)間的鏈路上傳送幀。

物理層：實(shí)現(xiàn)相鄰節(jié)點(diǎn)間比特流的透明傳輸，盡可能屏蔽傳輸介質(zhì)和物理設(shè)備的差異。

三次握手

假設(shè)發(fā)送端為客戶端，接收端為服務(wù)端。開始時(shí)客戶端和服務(wù)端的狀態(tài)都是CLOSED。

第一次握手：客戶端向服務(wù)端發(fā)起建立連接請求，客戶端會隨機(jī)生成一個(gè)起始序列號x，客戶端向服務(wù)端發(fā)送的字段中包含標(biāo)志位SYN=1，序列號seq=x。第一次握手前客戶端的狀態(tài)為CLOSE，第一次握手后客戶端的狀態(tài)為SYN-SENT。此時(shí)服務(wù)端的狀態(tài)為LISTEN。

第二次握手：服務(wù)端在收到客戶端發(fā)來的報(bào)文后，會隨機(jī)生成一個(gè)服務(wù)端的起始序列號y，然后給客戶端回復(fù)一段報(bào)文，其中包括標(biāo)志位SYN=1，ACK=1，序列號seq=y，確認(rèn)號ack=x+1。第二次握手前服務(wù)端的狀態(tài)為LISTEN，第二次握手后服務(wù)端的狀態(tài)為SYN-RCVD，此時(shí)客戶端的狀態(tài)為SYN-SENT。（其中SYN=1表示要和客戶端建立一個(gè)連接，ACK=1表示確認(rèn)序號有效）

第三次握手：客戶端收到服務(wù)端發(fā)來的報(bào)文后，會再向服務(wù)端發(fā)送報(bào)文，其中包含標(biāo)志位ACK=1，序列號seq=x+1，確認(rèn)號ack=y+1。第三次握手前客戶端的狀態(tài)為SYN-SENT，第三次握手后客戶端和服務(wù)端的狀態(tài)都為ESTABLISHED。此時(shí)連接建立完成。

兩次握手可以嗎？

第三次握手主要為了防止已失效的連接請求報(bào)文段突然又傳輸?shù)搅朔?wù)端，導(dǎo)致產(chǎn)生問題。

比如客戶端A發(fā)出連接請求，可能因?yàn)榫W(wǎng)絡(luò)阻塞原因，A沒有收到確認(rèn)報(bào)文，于是A再重傳一次連接請求。

連接成功，等待數(shù)據(jù)傳輸完畢后，就釋放了連接。

然后A發(fā)出的第一個(gè)連接請求等到連接釋放以后的某個(gè)時(shí)間才到達(dá)服務(wù)端B，此時(shí)B誤認(rèn)為A又發(fā)出一次新的連接請求，于是就向A發(fā)出確認(rèn)報(bào)文段。

如果不采用三次握手，只要B發(fā)出確認(rèn)，就建立新的連接了，此時(shí)A不會響應(yīng)B的確認(rèn)且不發(fā)送數(shù)據(jù)，則B一直等待A發(fā)送數(shù)據(jù)，浪費(fèi)資源。

四次揮手

A的應(yīng)用進(jìn)程先向其TCP發(fā)出連接釋放報(bào)文段（FIN=1，seq=u），并停止再發(fā)送數(shù)據(jù)，主動關(guān)閉TCP連接，進(jìn)入FIN-WAIT-1（終止等待1）狀態(tài)，等待B的確認(rèn)。

B收到連接釋放報(bào)文段后即發(fā)出確認(rèn)報(bào)文段（ACK=1，ack=u+1，seq=v），B進(jìn)入CLOSE-WAIT（關(guān)閉等待）狀態(tài)，此時(shí)的TCP處于半關(guān)閉狀態(tài)，A到B的連接釋放。

A收到B的確認(rèn)后，進(jìn)入FIN-WAIT-2（終止等待2）狀態(tài)，等待B發(fā)出的連接釋放報(bào)文段。

B發(fā)送完數(shù)據(jù)，就會發(fā)出連接釋放報(bào)文段（FIN=1，ACK=1，seq=w，ack=u+1），B進(jìn)入LAST-ACK（最后確認(rèn)）狀態(tài)，等待A的確認(rèn)。

A收到B的連接釋放報(bào)文段后，對此發(fā)出確認(rèn)報(bào)文段（ACK=1，seq=u+1，ack=w+1），A進(jìn)入TIME-WAIT（時(shí)間等待）狀態(tài)。此時(shí)TCP未釋放掉，需要經(jīng)過時(shí)間等待計(jì)時(shí)器設(shè)置的時(shí)間2MSL（最大報(bào)文段生存時(shí)間）后，A才進(jìn)入CLOSED狀態(tài)。B收到A發(fā)出的確認(rèn)報(bào)文段后關(guān)閉連接，若沒收到A發(fā)出的確認(rèn)報(bào)文段，B就會重傳連接釋放報(bào)文段。

第四次揮手為什么要等待2MSL？

保證A發(fā)送的最后一個(gè)ACK報(bào)文段能夠到達(dá)B。這個(gè)ACK報(bào)文段有可能丟失，B收不到這個(gè)確認(rèn)報(bào)文，就會超時(shí)重傳連接釋放報(bào)文段，然后A可以在2MSL時(shí)間內(nèi)收到這個(gè)重傳的連接釋放報(bào)文段，接著A重傳一次確認(rèn)，重新啟動2MSL計(jì)時(shí)器，最后A和B都進(jìn)入到CLOSED狀態(tài)，若A在TIME-WAIT狀態(tài)不等待一段時(shí)間，而是發(fā)送完ACK報(bào)文段后立即釋放連接，則無法收到B重傳的連接釋放報(bào)文段，所以不會再發(fā)送一次確認(rèn)報(bào)文段，B就無法正常進(jìn)入到CLOSED狀態(tài)。

防止已失效的連接請求報(bào)文段出現(xiàn)在本連接中。A在發(fā)送完最后一個(gè)ACK報(bào)文段后，再經(jīng)過2MSL，就可以使這個(gè)連接所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失，使下一個(gè)新的連接中不會出現(xiàn)舊的連接請求報(bào)文段。

為什么是四次揮手？

因?yàn)楫?dāng)Server端收到Client端的SYN連接請求報(bào)文后，可以直接發(fā)送SYN+ACK報(bào)文。但是在關(guān)閉連接時(shí)，當(dāng)Server端收到Client端發(fā)出的連接釋放報(bào)文時(shí)，很可能并不會立即關(guān)閉SOCKET，所以Server端先回復(fù)一個(gè)ACK報(bào)文，告訴Client端我收到你的連接釋放報(bào)文了。只有等到Server端所有的報(bào)文都發(fā)送完了，這時(shí)Server端才能發(fā)送連接釋放報(bào)文，之后兩邊才會真正的斷開連接。故需要四次揮手。

TCP有哪些特點(diǎn)？

TCP是面向連接的運(yùn)輸層協(xié)議。

點(diǎn)對點(diǎn)，每一條TCP連接只能有兩個(gè)端點(diǎn)。

TCP提供可靠交付的服務(wù)。

TCP提供全雙工通信。

面向字節(jié)流。

TCP和UDP的區(qū)別？

TCP面向連接；UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接。

TCP提供可靠的服務(wù)；UDP不保證可靠交付。

TCP面向字節(jié)流，把數(shù)據(jù)看成一連串無結(jié)構(gòu)的字節(jié)流；UDP是面向報(bào)文的。

TCP有擁塞控制；UDP沒有擁塞控制，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會使源主機(jī)的發(fā)送速率降低（對實(shí)時(shí)應(yīng)用很有用，如實(shí)時(shí)視頻會議等）。

每一條TCP連接只能是點(diǎn)到點(diǎn)的；UDP支持一對一、一對多、多對一和多對多的通信方式。

TCP首部開銷20字節(jié)；UDP的首部開銷小，只有8個(gè)字節(jié)。

HTTP協(xié)議的特點(diǎn)？

HTTP允許傳輸任意類型的數(shù)據(jù)。傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記。

無狀態(tài)。對于客戶端每次發(fā)送的請求，服務(wù)器都認(rèn)為是一個(gè)新的請求，上一次會話和下一次會話之間沒有聯(lián)系。

支持客戶端/服務(wù)器模式。

HTTP報(bào)文格式

HTTP請求由請求行、請求頭部、空行和請求體四個(gè)部分組成。

請求行：包括請求方法，訪問的資源URL，使用的HTTP版本。GET和POST是最常見的HTTP方法，除此以外還包括DELETE、HEAD、OPTIONS、PUT、TRACE。

請求頭：格式為“屬性名:屬性值”，服務(wù)端根據(jù)請求頭獲取客戶端的信息，主要有cookie、host、connection、accept-language、accept-encoding、user-agent。

請求體：用戶的請求數(shù)據(jù)如用戶名，密碼等。

請求報(bào)文示例：

POST /xxx HTTP/1.1 請求行 Accept:image/gif.image/jpeg, 請求頭部 Accept-Language:zh-cn Connection:Keep-Alive Host:localhost User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0) Accept-Encoding:gzip,deflate username=dabin 請求體

HTTP響應(yīng)也由四個(gè)部分組成，分別是：狀態(tài)行、響應(yīng)頭、空行和響應(yīng)體。

狀態(tài)行：協(xié)議版本，狀態(tài)碼及狀態(tài)描述。

響應(yīng)頭：響應(yīng)頭字段主要有connection、content-type、content-encoding、content-length、set-cookie、Last-Modified，、Cache-Control、Expires。

響應(yīng)體：服務(wù)器返回給客戶端的內(nèi)容。

響應(yīng)報(bào)文示例：

HTTP/1.1 200 OK Server:Apache Tomcat/5.0.12 Date:Mon,6Oct2003 13:23:42 GMT Content-Length:112 響應(yīng)體

HTTP狀態(tài)碼有哪些？

HTTP1.0和HTTP1.1的區(qū)別?

長連接：HTTP1.0默認(rèn)使用短連接，每次請求都需要建立新的TCP連接，連接不能復(fù)用。HTTP1.1支持長連接，復(fù)用TCP連接，允許客戶端通過同一連接發(fā)送多個(gè)請求。不過，這個(gè)優(yōu)化策略也存在問題，當(dāng)一個(gè)隊(duì)頭的請求不能收到響應(yīng)的資源時(shí)，它將會阻塞后面的請求。這就是“隊(duì)頭阻塞”問題。

斷點(diǎn)續(xù)傳：HTTP1.0 不支持?jǐn)帱c(diǎn)續(xù)傳。HTTP1.1 新增了 range 字段，用來指定數(shù)據(jù)字節(jié)位置，支持?jǐn)帱c(diǎn)續(xù)傳。

錯(cuò)誤狀態(tài)響應(yīng)碼：在HTTP1.1中新增了24個(gè)錯(cuò)誤狀態(tài)響應(yīng)碼，如409（Conflict）表示請求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突、410（Gone）表示服務(wù)器上的某個(gè)資源被永久性的刪除。

Host頭處理：在HTTP1.0中認(rèn)為每臺服務(wù)器都綁定一個(gè)唯一的IP地址，因此，請求消息中的URL并沒有傳遞主機(jī)名。到了HTTP1.1時(shí)代，虛擬主機(jī)技術(shù)發(fā)展迅速，在一臺物理服務(wù)器上可以存在多個(gè)虛擬主機(jī)，并且它們共享一個(gè)IP地址，故HTTP1.1增加了HOST信息。

HTTP1.1和 HTTP2.0的區(qū)別？

HTTP2.0相比HTTP1.1支持的特性：

新的二進(jìn)制格式：HTTP1.1 基于文本格式傳輸數(shù)據(jù)；HTTP2.0采用二進(jìn)制格式傳輸數(shù)據(jù)，解析更高效。

多路復(fù)用：在一個(gè)連接里，允許同時(shí)發(fā)送多個(gè)請求或響應(yīng)，并且這些請求或響應(yīng)能夠并行的傳輸而不被阻塞，避免 HTTP1.1 出現(xiàn)的”隊(duì)頭堵塞”問題。

頭部壓縮，HTTP1.1的header帶有大量信息，而且每次都要重復(fù)發(fā)送；HTTP2.0 把header從數(shù)據(jù)中分離，并封裝成頭幀和數(shù)據(jù)幀，使用特定算法壓縮頭幀，有效減少頭信息大小。并且HTTP2.0在客戶端和服務(wù)器端記錄了之前發(fā)送的鍵值對，對于相同的數(shù)據(jù)，不會重復(fù)發(fā)送。比如請求a發(fā)送了所有的頭信息字段，請求b則只需要發(fā)送差異數(shù)據(jù)，這樣可以減少冗余數(shù)據(jù)，降低開銷。

服務(wù)端推送：HTTP2.0允許服務(wù)器向客戶端推送資源，無需客戶端發(fā)送請求到服務(wù)器獲取。

HTTPS與HTTP的區(qū)別？

HTTP是超文本傳輸協(xié)議，信息是明文傳輸；HTTPS則是具有安全性的ssl加密傳輸協(xié)議。

HTTP和HTTPS用的端口不一樣，HTTP端口是80，HTTPS是443。

HTTPS協(xié)議需要到CA機(jī)構(gòu)申請證書，一般需要一定的費(fèi)用。

HTTP運(yùn)行在TCP協(xié)議之上；HTTPS運(yùn)行在SSL協(xié)議之上，SSL運(yùn)行在TCP協(xié)議之上。

什么是數(shù)字證書？

服務(wù)端可以向證書頒發(fā)機(jī)構(gòu)CA申請證書，以避免中間人攻擊（防止證書被篡改）。證書包含三部分內(nèi)容：證書內(nèi)容、證書簽名算法和簽名，簽名是為了驗(yàn)證身份。

服務(wù)端把證書傳輸給瀏覽器，瀏覽器從證書里取公鑰。證書可以證明該公鑰對應(yīng)本網(wǎng)站。

數(shù)字簽名的制作過程：

CA使用證書簽名算法對證書內(nèi)容進(jìn)行hash運(yùn)算。

對hash后的值用CA的私鑰加密，得到數(shù)字簽名。

瀏覽器驗(yàn)證過程：

獲取證書，得到證書內(nèi)容、證書簽名算法和數(shù)字簽名。

用CA機(jī)構(gòu)的公鑰對數(shù)字簽名解密（由于是瀏覽器信任的機(jī)構(gòu)，所以瀏覽器會保存它的公鑰）。

用證書里的簽名算法對證書內(nèi)容進(jìn)行hash運(yùn)算。

比較解密后的數(shù)字簽名和對證書內(nèi)容做hash運(yùn)算后得到的哈希值，相等則表明證書可信。

HTTPS原理

首先是TCP三次握手，然后客戶端發(fā)起一個(gè)HTTPS連接建立請求，客戶端先發(fā)一個(gè)Client Hello的包，然后服務(wù)端響應(yīng)Server Hello，接著再給客戶端發(fā)送它的證書，然后雙方經(jīng)過密鑰交換，最后使用交換的密鑰加解密數(shù)據(jù)。

協(xié)商加密算法 。在Client Hello里面客戶端會告知服務(wù)端自己當(dāng)前的一些信息，包括客戶端要使用的TLS版本，支持的加密算法，要訪問的域名，給服務(wù)端生成的一個(gè)隨機(jī)數(shù)（Nonce）等。需要提前告知服務(wù)器想要訪問的域名以便服務(wù)器發(fā)送相應(yīng)的域名的證書過來。

服務(wù)端響應(yīng)Server Hello，告訴客戶端服務(wù)端選中的加密算法。

接著服務(wù)端給客戶端發(fā)來了2個(gè)證書。第二個(gè)證書是第一個(gè)證書的簽發(fā)機(jī)構(gòu)（CA）的證書。

客戶端使用證書的認(rèn)證機(jī)構(gòu)CA公開發(fā)布的RSA公鑰對該證書進(jìn)行驗(yàn)證，下圖表明證書認(rèn)證成功。

驗(yàn)證通過之后，瀏覽器和服務(wù)器通過密鑰交換算法產(chǎn)生共享的對稱密鑰。

開始傳輸數(shù)據(jù)，使用同一個(gè)對稱密鑰來加解密。

DNS 的解析過程？

瀏覽器搜索自己的DNS緩存

若沒有，則搜索操作系統(tǒng)中的DNS緩存和hosts文件

若沒有，則操作系統(tǒng)將域名發(fā)送至本地域名服務(wù)器，本地域名服務(wù)器查詢自己的DNS緩存，查找成功則返回結(jié)果，否則依次向根域名服務(wù)器、頂級域名服務(wù)器、權(quán)限域名服務(wù)器發(fā)起查詢請求，最終返回IP地址給本地域名服務(wù)器

本地域名服務(wù)器將得到的IP地址返回給操作系統(tǒng)，同時(shí)自己也將IP地址緩存起來

操作系統(tǒng)將 IP 地址返回給瀏覽器，同時(shí)自己也將IP地址緩存起來

瀏覽器得到域名對應(yīng)的IP地址

瀏覽器中輸入U(xiǎn)RL返回頁面過程？

解析域名，找到主機(jī) IP。

瀏覽器利用 IP 直接與網(wǎng)站主機(jī)通信，三次握手，建立 TCP 連接。瀏覽器會以一個(gè)隨機(jī)端口向服務(wù)端的 web 程序 80 端口發(fā)起 TCP 的連接。

建立 TCP 連接后，瀏覽器向主機(jī)發(fā)起一個(gè)HTTP請求。

服務(wù)器響應(yīng)請求，返回響應(yīng)數(shù)據(jù)。

瀏覽器解析響應(yīng)內(nèi)容，進(jìn)行渲染，呈現(xiàn)給用戶。

Cookie和Session的區(qū)別？

作用范圍不同，Cookie 保存在客戶端，Session 保存在服務(wù)器端。

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

隱私策略不同，Cookie 存儲在客戶端，容易被竊取；Session 存儲在服務(wù)端，安全性相對 Cookie 要好一些。

存儲大小不同， 單個(gè) Cookie 保存的數(shù)據(jù)不能超過 4K；對于 Session 來說存儲沒有上限，但出于對服務(wù)器的性能考慮，Session 內(nèi)不要存放過多的數(shù)據(jù)，并且需要設(shè)置 Session 刪除機(jī)制。

什么是對稱加密和非對稱加密？

對稱加密：通信雙方使用相同的密鑰進(jìn)行加密。特點(diǎn)是加密速度快，但是缺點(diǎn)是密鑰泄露會導(dǎo)致密文數(shù)據(jù)被破解。常見的對稱加密有AES和DES算法。

非對稱加密：它需要生成兩個(gè)密鑰，公鑰和私鑰。公鑰是公開的，任何人都可以獲得，而私鑰是私人保管的。公鑰負(fù)責(zé)加密，私鑰負(fù)責(zé)解密；或者私鑰負(fù)責(zé)加密，公鑰負(fù)責(zé)解密。這種加密算法安全性更高，但是計(jì)算量相比對稱加密大很多，加密和解密都很慢。常見的非對稱算法有RSA和DSA。

碼字不易，如果覺得對你有幫助，可以點(diǎn)個(gè)贊鼓勵(lì)一下！

我是程序員大彬 ，專注Java后端硬核知識分享，歡迎大家關(guān)注~

Java

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。