面試軟件測試，經(jīng)常被問到的計算機(jī)網(wǎng)絡(luò)題，看這篇就夠
來源：湖北國菱計算機(jī)科技有限公司-湖北國聯(lián)計算機(jī)科技有限公司-荊州網(wǎng)站建設(shè)-荊州軟件開發(fā)-政府網(wǎng)站建設(shè)公司
時間：2025-03-10
進(jìn)行軟件測試面試時，相信大家或多或少都會被問到一些關(guān)于計算機(jī)網(wǎng)絡(luò)的問題，今天這篇文章就目前反饋比較多的計算機(jī)網(wǎng)絡(luò)面試題及答案做了一個整理，在找工作的你，趕緊看過來~
1. 說一下你理解的七層網(wǎng)絡(luò)模型？
答案：
應(yīng)用層：網(wǎng)絡(luò)服務(wù)與最終用戶的一個接口。協(xié)議有：HTTP FTP TFTP DNS協(xié)議等；
表示層：數(shù)據(jù)的表示、安全、壓縮的格式；
會話層：建立、管理、終止會話。對應(yīng)主機(jī)進(jìn)程，指本地主機(jī)與遠(yuǎn)程主機(jī)正在進(jìn)行的會話
傳輸層：定義傳輸數(shù)據(jù)的協(xié)議端口號，以及流控和差錯校驗。協(xié)議有：TCP UDP協(xié)議。
網(wǎng)絡(luò)層：進(jìn)行邏輯地址尋址，實現(xiàn)不同網(wǎng)絡(luò)之間的路徑選擇。協(xié)議有：ICMP IP（IPV4 IPV6）
數(shù)據(jù)鏈路層：建立邏輯連接、進(jìn)行硬件地址尋址功能。將比特組合成字節(jié)進(jìn)而組合成幀，用MAC地址訪問介質(zhì)，錯誤發(fā)現(xiàn)但不能糾正。
物理層：建立、維護(hù)、斷開物理連接。
2. TCP協(xié)議的三次握手過程？
答案：
TCP協(xié)議要建立連接的時候，需要經(jīng)歷三次握手的過程：
第一次握手：是客戶端向服務(wù)器發(fā)起的，用來申請建立連接的，這個報文中的SYN標(biāo)志位標(biāo)記為1，所以我們也叫作SYN包；
第二次握手：是服務(wù)器回復(fù)客戶端的，用來確認(rèn)并接受連接請求的，這個報文中的SYN位和ACK位都標(biāo)記為1，所以叫做SYN-ACK報文；
第三次握手：仍然是客戶端發(fā)給服務(wù)器的，用來確認(rèn)服務(wù)器的回復(fù)消息，這個報文中的ACK標(biāo)志位標(biāo)記為1，所以我們也叫作ACK包。
這就是TCP協(xié)議的三次握手過程。
3. 有了解TCP握手是握幾次嗎？為什么要握三次手？
答案：
3次。
客戶端發(fā)送請求建立連接的數(shù)據(jù)包可能會滯留在網(wǎng)絡(luò)中，等到后續(xù)這個連接斷開之后再次到達(dá)服務(wù)器，那么服務(wù)器會發(fā)送消息告訴客戶端可以發(fā)送消息，但是客戶端不會理會服務(wù)器也不會發(fā)送消息，服務(wù)器端處于等待狀態(tài)，會造成資源浪費(fèi)
4. TCP協(xié)議的4次揮手？
答案：
TCP協(xié)議完成了數(shù)據(jù)發(fā)送之后，就會斷開連接，此時就需要經(jīng)歷四次揮手的過程：
第一次揮手：是客戶端向服務(wù)器發(fā)起的，用來申請斷開連接的，這個報文中的FIN標(biāo)志位標(biāo)記為1，所以我們也叫作FIN包；
第二次揮手：是服務(wù)器回復(fù)客戶端的，用來確認(rèn)客戶端的上一個斷開連接請求的，所以是一個ACK報文；
第三次揮手：仍然是服務(wù)器發(fā)給客戶端的，用來告知客戶端服務(wù)器的數(shù)據(jù)發(fā)送完畢了，需要斷開連接；這個報文中的FIN標(biāo)志位標(biāo)記為1，所以也是一個FIN包。
第四次揮手：是客戶端回復(fù)服務(wù)器的，確認(rèn)服務(wù)器的上一個斷開連接請求，所以也是一個ACK報文；
這就是TCP協(xié)議的四次揮手過程。
5. 為什么握手需要三次，揮手卻需要四次呢？
答案：
三次握手是TCP協(xié)議建立連接的過程，建立連接，我只需要確認(rèn)一下你在我也在就好了啊，三次握手夠了；
但是四次揮手是TCP協(xié)議是為了斷開連接的，所以需要確保我既結(jié)束發(fā)送數(shù)據(jù)，也結(jié)束接收數(shù)據(jù)；開始客戶端先結(jié)束發(fā)送并告知服務(wù)器，服務(wù)器確認(rèn)后就結(jié)束接收了；這兩次揮手完成后，客戶端還在接收數(shù)據(jù)哦，服務(wù)器也還在發(fā)送；所以需要服務(wù)器也發(fā)送一次FIN包，告知我也結(jié)束數(shù)據(jù)發(fā)送了，客戶端確認(rèn)后，才雙方都關(guān)閉發(fā)送和接收數(shù)據(jù)通道，所以必須要四次~
6. tcp和udp的區(qū)別？
答案：
TCP協(xié)議和UDP協(xié)議都是傳輸層的兩個協(xié)議： 它們的區(qū)別主要有如下3個方面：
第一：TCP是面向連接，就像打電話要先撥號建立連接一樣，而UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接。
第二：TCP可以提供可靠的服務(wù)，能保證數(shù)據(jù)傳輸無差錯，不丟失，不重復(fù)，且按序到達(dá)；而UDP協(xié)議只是盡最大努力交付，即不保證可靠交付。
第三：因為TCP以上兩個特點，所以對應(yīng)傳輸效率相對較低，而UDP效率高，所以一些注重速度而不在乎的丟包的場景，會選擇用UDP協(xié)議，比如IP電話，流媒體等。
7. 你了解http協(xié)議有哪些響應(yīng)狀態(tài)碼？
答案：
狀態(tài)碼有如下幾種：
a. 1xx（臨時響應(yīng)）：表示臨時響應(yīng)并需要請求者繼續(xù)執(zhí)行操作的狀態(tài)代碼。
b. 2xx （成功）：表示成功處理了請求的狀態(tài)代碼。
c. 3xx （重定向）：表示要完成請求，需要進(jìn)一步操作。 通常，這些狀態(tài)代碼用來重定向。
d. 4xx（請求錯誤）：這些狀態(tài)代碼表示請求可能出錯，妨礙了服務(wù)器的處理。
e. 5xx（服務(wù)器錯誤）：這些狀態(tài)代碼表示服務(wù)器在嘗試處理請求時發(fā)生內(nèi)部錯誤。 這些錯誤可能是服務(wù)器本身的錯誤，而不是請求出錯。
8. HTTP和HTTPS的區(qū)別？
答案：
從安全性來說：http明文傳輸，易受攻擊，無法確認(rèn)雙方身份，也無法保證數(shù)據(jù)的完整性；https使用ssl加密傳輸協(xié)議，信息是密文，可以認(rèn)證雙方身份，防止信息被截取篡改，安全性相比http要高
從端口來看：http默認(rèn)端口80，https默認(rèn)端口443
靈活性上：http簡單快速，使用靈活；https技術(shù)門檻較高，多數(shù)個人或私人網(wǎng)站難以支撐
訪問速度：http協(xié)議簡單，http服務(wù)器的程序規(guī)模小，因而通信速度很快；https加重了服務(wù)端負(fù)擔(dān)，需要更多的資源來支撐，降低了用戶的訪問速度
經(jīng)濟(jì)適用度：http沒有額外的費(fèi)用要求，https協(xié)議CA機(jī)構(gòu)頒發(fā)的證書都是需年費(fèi)的，此外對接https協(xié)議也需要額外的技術(shù)支持
9、https協(xié)議比http安全，是如何實現(xiàn)的呢？
答案：
https協(xié)議通過SSL協(xié)議外殼來實現(xiàn)它的安全性，主要體現(xiàn)在三個方面：
第一：數(shù)據(jù)是加密的，SSL協(xié)議通過非對稱秘鑰分發(fā)的方式完成秘鑰的協(xié)商，然后通過對稱秘鑰的加密方式完成數(shù)據(jù)的加密；
第二：會驗證對方身份。服務(wù)端和客戶端雙方會需要向CA機(jī)構(gòu)申請證書，再SSL握手階段會驗證雙方證書是否可信，從而驗證雙方的身份，防止第三方冒充；
第三：保證數(shù)據(jù)的完整性。每次的數(shù)據(jù)都會加上MAC摘要并簽名，接收的數(shù)據(jù)和發(fā)送的數(shù)據(jù)這個摘要信息一致的，就表示數(shù)據(jù)沒有被篡改過。
10、當(dāng)一個用戶在瀏覽器輸入url打開一個網(wǎng)頁的時候，從輸入到加載完整個過程經(jīng)歷了什么?
答案：
a. 首先它會進(jìn)行DNS的域名解析；
b. 建立TCP連接；發(fā)起tcp的三次握手
c. 發(fā)送一個HTTP的請求；
d. 服務(wù)器處理相關(guān)的請求并返回處理后的結(jié)果；
e. 關(guān)閉TCP連接；
f. 瀏覽器接收到服務(wù)器給到的html代碼，開始解析；
g. 瀏覽器將解析后的資源(如js、css、圖片等)進(jìn)行請求，并對頁面進(jìn)行渲染呈現(xiàn)給用戶。
（轉(zhuǎn)載自：CSDN, 版權(quán)聲明：本文為博主原創(chuàng)文章，遵循 CC 4.0 BY-SA 版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接和本聲明原文鏈接：
鄂公網(wǎng)安備 42100202000212號