最新必會的計算機網路大廠面試必問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

標籤：Java

上一篇：甲骨文嚴查Java授權，換openJDK要避坑

下一篇：BigDecimal 設定小數位數、小數比例轉換整數