最新必會的計算機網絡大廠面試必問20個問題

目錄

• 1、網絡分層結構
• 2、三次握手
• 3、四次揮手
• 4、第四次揮手為什么要等待2MSL？
• 5、為什么是四次揮手？
• 6、TCP和UDP的區別
• 7、TCP有哪些特點？
• 8、HTTP協會的特點
• 9、HTTP報文格式
  • • 1、HTTP由請求行、請求頭部、空行、請求體四部分組成
    • 2、HTTP響應也由四個部分組成，分別是：狀態行、響應頭、空行和響應體。
• 10、HTTP狀態碼有哪些
• 11、HTTP1.0和HTTP1.1的區別?
• 12、HTTP1.1和 HTTP2.0的區別？
• 13、HTTPS和HTTP的區別
• 14、什么是數字證書？
• 15、HTTPS原理
• 16、DNS 的解析過程？
• 17、瀏覽器中輸入URL返回頁面過程？
• 18、Cookie和Session的區別？
• 19、什么是對稱加密和非對稱加密？
• 20、http GET 和 POST 請求的優缺

1、網絡分層結構

計算機網絡體系大致分為三種，OSI七層模型、TCP/IP四層模型和五層模型。一般面試的時候考察比較多的是五層模型。

TCP/IP五層模型：應用層、傳輸層、網絡層、數據鏈路層、物理層。

• 物理層：實現相鄰節點間比特流的透明傳輸，盡可能屏蔽傳輸介質和物理設備的差異。

• 數據鏈路層：在兩個相鄰節點之間傳送數據時，數據鏈路層將網絡層交下來的 IP 數據報組裝成幀，在兩個相鄰節點間的鏈路上傳送幀。

• 網絡層：選擇合適的路由和交換結點，確保數據及時傳送。主要包括IP協議

• 傳輸層：負責向兩台主機進程之間的通信提供數據傳輸服務。傳輸層的協議主要有傳輸控制協議TCP和用戶數據協議UDP。

• 應用層：為應用程序提供交互服務。在互聯網中的應用層協議很多，如域名系統DNS、HTTP協議、SMTP協議等。

2、三次握手

疑問一，圖中傳遞過程中出現的幾個字符（SYN,ACK,FIN,seq,ack）各代表什么意思

SYN，ACK，FIN存放在TCP的標志位，一共有6個字符，這里就介紹這三個：

SYN：代表請求創建連接，所以在三次握手中前兩次要SYN=1，表示這兩次用於建立連接，至於第三次什么用，在疑問三里解答。

FIN：表示請求關閉連接，在四次分手時，我們發現FIN發了兩遍。這是因為TCP的連接是雙向的，所以一次FIN只能關閉一個方向。

ACK：代表確認接受，從上面可以發現，不管是三次握手還是四次分手，在回應的時候都會加上ACK=1，表示消息接收到了，並且在建立連接以后的發送數據時，都需加上ACK=1,來表示數據接收成功。

seq:序列號，什么意思呢？當發送一個數據時，數據是被拆成多個數據包來發送，序列號就是對每個數據包進行編號，這樣接受方才能對數據包進行再次拼接。

初始序列號是隨機生成的，這樣不一樣的數據拆包解包就不會連接錯了。（例如：兩個數據都被拆成1，2，3和一個數據是1，2，3一個是101，102，103，很明顯后者不會連接錯誤）

ack:這個代表下一個數據包的編號，這也就是為什么第二請求時，ack是seq+1，

假設發送端為客戶端，接收端為服務端。開始時客戶端和服務端的狀態都是

CLOSED。

1、第一次握手：客戶端向服務端發起建立連接請求，客戶端會隨機生成一個起始序列號x，客戶端向服務端發送的字段中包含標志位SYN=1，序列號seq=x。第一次握手前客戶端的狀態為CLOSE，第一次握手后客戶端的狀態為SYN-SEND。此時服務端的狀態為LISTEN

• 2、第二次握手：服務端在收到客戶端發來的報文后，會隨機生成一個服務端的起始序列號y，然后給客戶端回復一段報文，其中包括標志位SYN=1，ACK=1，序列號seq=y，確認號ack=x+1。第二次握手前服務端的狀態為LISTEN，第二次握手后服務端的狀態為SYN-RCVD，此時客戶端的狀態為SYN-SENT。（其中SYN=1表示要和客戶端建立一個連接，ACK=1表示確認序號有效）

• 3、第三次握手：客戶端收到服務端發來的報文后，會再向服務端發送報文，其中包含標志位ACK=1，序列號seq=x+1，確認號ack=y+1。第三次握手前客戶端的狀態為SYN-SENT，第三次握手后客戶端和服務端的狀態都為ESTABLISHED。此時連接建立完成。

注意：兩次握手可以嗎？

第三次握手主要為了防止已失效的連接請求報文段突然又傳輸到了服務端，導致產生問題。

• 比如客戶端A發出連接請求，可能因為網絡阻塞原因，A沒有收到確認報文，於是A再重傳一次連接請求。

• 連接成功，等待數據傳輸完畢后，就釋放了連接。

• 然后A發出的第一個連接請求等到連接釋放以后的某個時間才到達服務端B，此時B誤認為A又發出一次新的連接請求，於是就向A發出確認報文段。

• 如果不采用三次握手，只要B發出確認，就建立新的連接了，此時A不會響應B的確認且不發送數據，則B一直等待A發送數據，浪費資源。

3、四次揮手

• 1、A的應用進程先向其TCP發出連接釋放報文段（FIN=1，seq=u），並停止再發送數據，主動關閉TCP連接，進入FIN-WAIT-1（終止等待1）狀態，等待B的確認。

• 2、B收到連接釋放報文段后即發出確認報文段（ACK=1，ack=u+1，seq=v），B進入CLOSE-WAIT（關閉等待）狀態，此時的TCP處於半關閉狀態，A到B的連接釋放。

A收到B的確認后，進入FIN-WAIT-2（終止等待2）狀態，等待B發出的連接釋放報文段。

• 3、B發送完數據，就會發出連接釋放報文段（FIN=1，ACK=1，seq=w，ack=u+1），B進入LAST-ACK（最后確認）狀態，等待A的確認。

• 4、A收到B的連接釋放報文段后，對此發出確認報文段（ACK=1，seq=u+1，ack=w+1），A進入TIME-WAIT（時間等待）狀態。此時TCP未釋放掉，需要經過時間等待計時器設置的時間2MSL（最大報文段生存時間）后，A才進入CLOSED狀態。B收到A發出的確認報文段后關閉連接，若沒收到A發出的確認報文段，B就會重傳連接釋放報文段。

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

• 保證A發送的最后一個ACK報文段能夠到達B。這個

ACK報文段有可能丟失，B收不到這個確認報文，就會超時重傳連接釋放報文段，然后A可以在

2MSL時間內收到這個重傳的連接釋放報文段，接着A重傳一次確認，重新啟動2MSL計時器，最后A和B都進入到CLOSED狀態，若A在TIME-WAIT狀態不等待一段時間，而是發送完ACK報文段后立即釋放連接，則無法收到B重傳的連接釋放報文段，所以不會再發送一次確認報文段，B就無法正常進入到CLOSED狀態。

• 防止已失效的連接請求報文段出現在本連接中。A在發送完最后一個

ACK報文段后，再經過2MSL，就可以使這個連接所產生的所有報文段都從網絡中消失，使下一個新的連接中不會出現舊的連接請求報文段。

5、為什么是四次揮手？

因為當Server端收到Client端的

SYN連接請求報文后，可以直接發送

SYN+ACK報文。但是在關閉連接時，當Server端收到Client端發出的連接釋放報文時，很可能並不會立即關閉SOCKET，所以Server端先回復一個

ACK報文，告訴Client端我收到你的連接釋放報文了。只有等到Server端所有的報文都發送完了，這時Server端才能發送連接釋放報文，之后兩邊才會真正的斷開連接。故需要四次揮手。

6、TCP和UDP的區別

• 1、TCP面向連接；UDP是無連接的，即發送數據之前不需要建立連接。

• 2、TCP提供可靠傳輸；UDP不保證可靠交付

• 3、TCP面向字節流。將數據看成一串無結構的字節流；UDP是面向報文的

• 4、TCP有擁塞控制；UDP沒有擁塞控制，因此網絡出現擁塞不會使源主機的發送速率降低（對實時應用很有用，如實時視頻會議）

• 5、每一條TCP連接只能是點對點的；UDP是一對一。一對多，多對多的通信方式

• 6、TCP首部開銷是20字節；UDP的首部開銷小，只有8字節

7、TCP有哪些特點？

• TCP是面向連接的運輸層協議。

• 點對點，每一條TCP連接只能有兩個端點。

• TCP提供可靠交付的服務。

• TCP提供全雙工通信。

• 面向字節流。

8、HTTP協會的特點

1. HTTP允許傳輸任意類型的數據。傳輸的類型由Content-Type加以標記。
2. 無狀態。對於客戶端每次發送的請求，服務器都認為是一個新的請求，上一次會話和下一次會話之間沒有聯系。
3. 支持客戶端/服務器模式。

9、HTTP報文格式

1、HTTP由請求行、請求頭部、空行、請求體四部分組成

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

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

• 請求體：用戶的請求數據如用戶名，密碼等。

請求報文示例：

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 請求體

2、HTTP響應也由四個部分組成，分別是：狀態行、響應頭、空行和響應體。

• 狀態行：協議版本，狀態碼及狀態描述。

• 響應頭：響應頭字段主要有

connection、content-type、content-encoding、content-length、set-cookie、Last-Modified，、Cache-Control、Expires。

• 響應體：服務器返回給客戶端的內容。

響應報文示例：

HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112

<html>
    <body>響應體</body>
</html>

10、HTTP狀態碼有哪些

11、HTTP1.0和HTTP1.1的區別?

• 長連接：HTTP1.0默認使用短連接，每次請求都需要建立新的TCP連接，連接不能復用。HTTP1.1支持長連接，復用TCP連接，允許客戶端通過同一連接發送多個請求。不過，這個優化策略也存在問題，當一個隊頭的請求不能收到響應的資源時，它將會阻塞后面的請求。這就是“隊頭阻塞”問題。
• 斷點續傳：HTTP1.0 不支持斷點續傳。HTTP1.1 新增了 range字段，用來指定數據字節位置，支持斷點續傳
• 錯誤狀態響應碼：在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生沖突、410（Gone）表示服務器上的某個資源被永久性的刪除。
• Host頭處理：在HTTP1.0中認為每台服務器都綁定一個唯一的IP地址，因此，請求消息中的URL並沒有傳遞主機名。到了HTTP1.1時代，虛擬主機技術發展迅速，在一台物理服務器上可以存在多個虛擬主機，並且它們共享一個IP地址，故HTTP1.1增加了HOST信息。

12、HTTP1.1和 HTTP2.0的區別？

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

• 新的二進制格式：HTTP1.1 基於文本格式傳輸數據；HTTP2.0采用二進制格式傳輸數據，解析更高效。
• 多路復用：在一個連接里，允許同時發送多個請求或響應，並且這些請求或響應能夠並行的傳輸而不被阻塞，避免 HTTP1.1 出現的”隊頭堵塞”問題。
• 頭部壓縮，HTTP1.1的header帶有大量信息，而且每次都要重復發送；HTTP2.0 把header從數據中分離，並封裝成頭幀和數據幀，使用特定算法壓縮頭幀，有效減少頭信息大小。並且HTTP2.0在客戶端和服務器端記錄了之前發送的鍵值對，對於相同的數據，不會重復發送。\比如請求a發送了所有的頭信息字段，請求b則\只需要發送差異數據，這樣可以減少冗余數據，降低開銷。
• 服務端推送：HTTP2.0允許服務器向客戶端推送資源，無需客戶端發送請求到服務器獲取。

13、HTTPS和HTTP的區別

• 1、HTTP是超文本傳輸協議、信息是明文傳輸；HTTPS則是具有安全性的SSL加密傳輸協議

• 2、HTTP和HTTPS用的端口不一樣，HTTP是80，HTTPS是443

• HTTPS協議需要到CA機構申請證書，一般需要一定的費用

• 3、HTTP運行在TCP協議之上；HTTPS運行在SSL協議之上，SSL運行在TCP協議之上

14、什么是數字證書？

服務端可以向證書頒發機構CA申請證書，以避免中間人攻擊（防止證書被篡改）。證書包含三部分內容：證書內容、證書簽名算法和簽名，簽名是為了驗證身份。

服務端把證書傳輸給瀏覽器，瀏覽器從證書里取公鑰。證書可以證明該公鑰對應本網站。

數字簽名的制作過程：

1. CA使用證書簽名算法對證書內容進行hash運算。
2. 對hash后的值用CA的私鑰加密，得到數字簽名。

瀏覽器驗證過程：

1. 獲取證書，得到證書內容、證書簽名算法和數字簽名。
2. 用CA機構的公鑰對數字簽名解密（由於是瀏覽器信任的機構，所以瀏覽器會保存它的公鑰）。
3. 用證書里的簽名算法對證書內容進行hash運算。
4. 比較解密后的數字簽名和對證書內容做hash運算后得到的哈希值，相等則表明證書可信。

15、HTTPS原理

• 1、客戶端發起一個http請求

• 2.、服務端把自己的信息以數字證書的形式返回給客戶端（證書內容包括密鑰私鑰、網站地址、證書頒發機構、失效日期）。證書中有一個公鑰用來加密信息，私鑰由服務器持有。

• 3、驗證證書的合法性

  • 客戶端收到服務器的響應后會驗證證書的合法性（證書中包含的地址是否和正在訪問的地址是否一致，證書的是否過期）

• 4、生成隨機密碼

  • 如果驗證通過、或用戶接受不受信任的證書，瀏覽器會生成一個隨機的對稱密鑰（Session Key）並用於公鑰加密，讓服務器私鑰解密，解密后就用這個對稱密鑰進行傳輸了，並且能夠說明服務器確是私鑰的持有者

• 5、生成對稱加密算法

  • 驗證完服務端身份后，客戶端生成一個對稱加密的算法和對應密鑰。以公鑰加密后發送給服務端。此時被黑客截獲也是沒有用的，因為只有服務器端的私鑰才能對其解密。之后客戶端與服務端可以用這個對稱加密算法加密和解密通信內容。

16、DNS 的解析過程？

域名到IP地址的解析過程的要點如下：

當某一個應用需要把主機名解析為IP地址時，該應用進程就調用解析程序，並稱為DNS的一個客戶，把待解析的域名放在DNS請求報文中，以UDP用戶數據報方式發給本地域名服務器。本地域名服務器在查找域名后，把對應的IP地址放在回答報文中返回。應用程序獲得目的主機的IP地址后即可進行通信。

若本地域名服務器不能回答該請求，則此域名服務器就暫時稱為DNS的另一個客戶，並向其他域名服務器發出查詢請求（發給其他根域名服務器，若根域名服務器叫去指定的其他頂級域名服務器查詢請求）。這種過程直至找到能夠回答該請求的域名服務器為止。此過程在后面作進一步討論。

17、瀏覽器中輸入URL返回頁面過程？

• 1、解析域名，找到主機IP

• 2、瀏覽器利用 IP 直接與網站主機通信，三次握手，建立 TCP 連接。瀏覽器會以一個隨機端口向服務端的 web 程序 80 端口發起 TCP 的連接。

• 3、建立TCP連接后，瀏覽器向服務器主機發送一個HTTP請求

• 4、服務器響應請求，發送響應數據

• 5、瀏覽器解析響應內容，進行渲染，呈現給用戶
  

18、Cookie和Session的區別？

• 作用范圍不同：Cookie保存在客戶端，Session保存在服務器端

• 有效期不同：Cookie可設置長時間的保持，比如我們常常使用的默認登陸功能，Session一般失效時間比較短，客戶端關閉或者Session超時就會失效

• 隱私策略不同：Cookie保存在客戶端，容易被竊取；Session存儲在Session存儲在服務端，安全性相對較高點

• 存儲大小不一樣：單個 Cookie 保存的數據不能超過 4K；對於 Session 來說存儲沒有上限，但出於對服務器的性能考慮，Session 內不要存放過多的數據，並且需要設置 Session 刪除機制。

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

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

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

20、http GET 和 POST 請求的優缺

此問答案來源鏈接：https://blog.csdn.net/zzk220106/article/details/78595108

• 區別
  （1）post更安全（不會作為url的一部分，不會被緩存、保存在服務器日志、以及瀏覽器瀏覽記錄中）
  （2）post發送的數據更大（get有url長度限制）
  （3）post能發送更多的數據類型（get只能發送ASCII字符）
  （4）post比get慢
  （5）post用於修改和寫入數據，get一般用於搜索排序和篩選之類的操作
  （6）get請求的是靜態資源，則會緩存，如果是數據，則不會緩存

• 為什么get比post更快
  1.post請求包含更多的請求頭
  因為post需要在請求的body部分包含數據，所以會多了幾個數據描述部分的首部字段（如：content-type）,這其實是微乎其微的。
  2.最重要的一條，post在真正接收數據之前會先將請求頭發送給服務器進行確認，然后才真正發送數據

• post請求的過程：
  （1）瀏覽器請求tcp連接（第一次握手）
  （2）服務器答應進行tcp連接（第二次握手）
  （3）瀏覽器確認，並發送post請求頭（第三次握手，這個報文比較小，所以http會在此時進行第一次數據發送）
  （4）服務器返回100 Continue響應
  （5）瀏覽器發送數據
  （6）服務器返回200 OK響應

• get請求的過程：
  （1）瀏覽器請求tcp連接（第一次握手）
  （2）服務器答應進行tcp連接（第二次握手）
  （3）瀏覽器確認，並發送get請求頭和數據（第三次握手，這個報文比較小，所以http會在此時進行第一次數據發送）
  （4）服務器返回200 OK響應
  也就是說，目測get的總耗是post的2/3左右，這個口說無憑，網上已經有網友進行過測試。

• get傳參最大長度的理解誤區
  （1）http協議並未規定get和post的長度限制
  （2）get的最大長度限制是因為瀏覽器和web服務器限制了URL的長度
  （3）不同的瀏覽器和web服務器，限制的最大長度不一樣
  （4）要支持IE，則最大長度為2083byte，若支持Chrome，則最大長度8182byte