計算機網絡經典20問!
本文目錄:
- 網絡分層結構
- 三次握手
- 兩次握手可以嗎?
- 四次揮手
- 第四次揮手為什麼要等待2MSL?
- 為什麼是四次揮手?
- TCP有哪些特點?
- TCP和UDP的區別?
- HTTP協議的特點?
- HTTP報文格式
- HTTP狀態碼有哪些?
- HTTP1.0和HTTP1.1的區別?
- HTTP1.1和 HTTP2.0的區別?
- HTTPS與HTTP的區別?
- 什麼是數字證書?
- HTTPS原理
- DNS 的解析過程?
- 瀏覽器中輸入URL返回頁面過程?
- Cookie和Session的區別?
- 什麼是對稱加密和非對稱加密?
網絡分層結構
計算機網絡體系大致分為三種,OSI七層模型、TCP/IP四層模型和五層模型。一般面試的時候考察比較多的是五層模型。
TCP/IP五層模型:應用層、傳輸層、網絡層、數據鏈路層、物理層。
- 應用層:為應用程序提供交互服務。在互聯網中的應用層協議很多,如域名系統DNS、HTTP協議、SMTP協議等。
- 傳輸層:負責向兩台主機進程之間的通信提供數據傳輸服務。傳輸層的協議主要有傳輸控制協議TCP和用戶數據協議UDP。
- 網絡層:選擇合適的路由和交換結點,確保數據及時傳送。主要包括IP協議。
- 數據鏈路層:在兩個相鄰節點之間傳送數據時,數據鏈路層將網絡層交下來的 IP 數據報組裝成幀,在兩個相鄰節點間的鏈路上傳送幀。
- 物理層:實現相鄰節點間比特流的透明傳輸,儘可能屏蔽傳輸介質和物理設備的差異。
三次握手
假設發送端為客戶端,接收端為服務端。開始時客戶端和服務端的狀態都是CLOSED
。
- 第一次握手:客戶端向服務端發起建立連接請求,客戶端會隨機生成一個起始序列號x,客戶端向服務端發送的字段中包含標誌位
SYN=1
,序列號seq=x
。第一次握手前客戶端的狀態為CLOSE
,第一次握手後客戶端的狀態為SYN-SENT
。此時服務端的狀態為LISTEN
。 - 第二次握手:服務端在收到客戶端發來的報文後,會隨機生成一個服務端的起始序列號y,然後給客戶端回復一段報文,其中包括標誌位
SYN=1
,ACK=1
,序列號seq=y
,確認號ack=x+1
。第二次握手前服務端的狀態為LISTEN
,第二次握手後服務端的狀態為SYN-RCVD
,此時客戶端的狀態為SYN-SENT
。(其中SYN=1
表示要和客戶端建立一個連接,ACK=1
表示確認序號有效) - 第三次握手:客戶端收到服務端發來的報文後,會再向服務端發送報文,其中包含標誌位
ACK=1
,序列號seq=x+1
,確認號ack=y+1
。第三次握手前客戶端的狀態為SYN-SENT
,第三次握手後客戶端和服務端的狀態都為ESTABLISHED
。此時連接建立完成。
兩次握手可以嗎?
第三次握手主要為了防止已失效的連接請求報文段突然又傳輸到了服務端,導致產生問題。
- 比如客戶端A發出連接請求,可能因為網絡阻塞原因,A沒有收到確認報文,於是A再重傳一次連接請求。
- 連接成功,等待數據傳輸完畢後,就釋放了連接。
- 然後A發出的第一個連接請求等到連接釋放以後的某個時間才到達服務端B,此時B誤認為A又發出一次新的連接請求,於是就向A發出確認報文段。
- 如果不採用三次握手,只要B發出確認,就建立新的連接了,此時A不會響應B的確認且不發送數據,則B一直等待A發送數據,浪費資源。
四次揮手
- A的應用進程先向其TCP發出連接釋放報文段(
FIN=1,seq=u
),並停止再發送數據,主動關閉TCP連接,進入FIN-WAIT-1
(終止等待1)狀態,等待B的確認。 - B收到連接釋放報文段後即發出確認報文段(
ACK=1,ack=u+1,seq=v
),B進入CLOSE-WAIT
(關閉等待)狀態,此時的TCP處於半關閉狀態,A到B的連接釋放。 - A收到B的確認後,進入
FIN-WAIT-2
(終止等待2)狀態,等待B發出的連接釋放報文段。 - B發送完數據,就會發出連接釋放報文段(
FIN=1,ACK=1,seq=w,ack=u+1
),B進入LAST-ACK
(最後確認)狀態,等待A的確認。 - A收到B的連接釋放報文段後,對此發出確認報文段(
ACK=1,seq=u+1,ack=w+1
),A進入TIME-WAIT
(時間等待)狀態。此時TCP未釋放掉,需要經過時間等待計時器設置的時間2MSL
(最大報文段生存時間)後,A才進入CLOSED
狀態。B收到A發出的確認報文段後關閉連接,若沒收到A發出的確認報文段,B就會重傳連接釋放報文段。
第四次揮手為什麼要等待2MSL?
- 保證A發送的最後一個ACK報文段能夠到達B。這個
ACK
報文段有可能丟失,B收不到這個確認報文,就會超時重傳連接釋放報文段,然後A可以在2MSL
時間內收到這個重傳的連接釋放報文段,接着A重傳一次確認,重新啟動2MSL計時器,最後A和B都進入到CLOSED
狀態,若A在TIME-WAIT
狀態不等待一段時間,而是發送完ACK報文段後立即釋放連接,則無法收到B重傳的連接釋放報文段,所以不會再發送一次確認報文段,B就無法正常進入到CLOSED
狀態。 - 防止已失效的連接請求報文段出現在本連接中。A在發送完最後一個
ACK
報文段後,再經過2MSL,就可以使這個連接所產生的所有報文段都從網絡中消失,使下一個新的連接中不會出現舊的連接請求報文段。
為什麼是四次揮手?
因為當Server端收到Client端的SYN
連接請求報文後,可以直接發送SYN+ACK
報文。但是在關閉連接時,當Server端收到Client端發出的連接釋放報文時,很可能並不會立即關閉SOCKET,所以Server端先回復一個ACK
報文,告訴Client端我收到你的連接釋放報文了。只有等到Server端所有的報文都發送完了,這時Server端才能發送連接釋放報文,之後兩邊才會真正的斷開連接。故需要四次揮手。
TCP有哪些特點?
- TCP是面向連接的運輸層協議。
- 點對點,每一條TCP連接只能有兩個端點。
- TCP提供可靠交付的服務。
- TCP提供全雙工通信。
- 面向位元組流。
TCP和UDP的區別?
- TCP面向連接;UDP是無連接的,即發送數據之前不需要建立連接。
- TCP提供可靠的服務;UDP不保證可靠交付。
- TCP面向位元組流,把數據看成一連串無結構的位元組流;UDP是面向報文的。
- TCP有擁塞控制;UDP沒有擁塞控制,因此網絡出現擁塞不會使源主機的發送速率降低(對實時應用很有用,如實時視頻會議等)。
- 每一條TCP連接只能是點到點的;UDP支持一對一、一對多、多對一和多對多的通信方式。
- TCP首部開銷20位元組;UDP的首部開銷小,只有8個位元組。
HTTP協議的特點?
- HTTP允許傳輸任意類型的數據。傳輸的類型由Content-Type加以標記。
- 無狀態。對於客戶端每次發送的請求,服務器都認為是一個新的請求,上一次會話和下一次會話之間沒有聯繫。
- 支持客戶端/服務器模式。
HTTP報文格式
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 請求體
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>
HTTP狀態碼有哪些?
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信息。
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允許服務器向客戶端推送資源,無需客戶端發送請求到服務器獲取。
HTTPS與HTTP的區別?
- HTTP是超文本傳輸協議,信息是明文傳輸;HTTPS則是具有安全性的ssl加密傳輸協議。
- HTTP和HTTPS用的端口不一樣,HTTP端口是80,HTTPS是443。
- HTTPS協議需要到CA機構申請證書,一般需要一定的費用。
- HTTP運行在TCP協議之上;HTTPS運行在SSL協議之上,SSL運行在TCP協議之上。
什麼是數字證書?
服務端可以向證書頒發機構CA申請證書,以避免中間人攻擊(防止證書被篡改)。證書包含三部分內容:證書內容、證書籤名算法和簽名,簽名是為了驗證身份。
服務端把證書傳輸給瀏覽器,瀏覽器從證書里取公鑰。證書可以證明該公鑰對應本網站。
數字簽名的製作過程:
- CA使用證書籤名算法對證書內容進行hash運算。
- 對hash後的值用CA的私鑰加密,得到數字簽名。
瀏覽器驗證過程:
- 獲取證書,得到證書內容、證書籤名算法和數字簽名。
- 用CA機構的公鑰對數字簽名解密(由於是瀏覽器信任的機構,所以瀏覽器會保存它的公鑰)。
- 用證書里的簽名算法對證書內容進行hash運算。
- 比較解密後的數字簽名和對證書內容做hash運算後得到的哈希值,相等則表明證書可信。
HTTPS原理
首先是TCP三次握手,然後客戶端發起一個HTTPS連接建立請求,客戶端先發一個Client Hello
的包,然後服務端響應Server Hello
,接着再給客戶端發送它的證書,然後雙方經過密鑰交換,最後使用交換的密鑰加解密數據。
-
協商加密算法 。在
Client Hello
裏面客戶端會告知服務端自己當前的一些信息,包括客戶端要使用的TLS版本,支持的加密算法,要訪問的域名,給服務端生成的一個隨機數(Nonce)等。需要提前告知服務器想要訪問的域名以便服務器發送相應的域名的證書過來。 -
服務端響應
Server Hello
,告訴客戶端服務端選中的加密算法。 -
接着服務端給客戶端發來了2個證書。第二個證書是第一個證書的簽發機構(CA)的證書。
-
客戶端使用證書的認證機構CA公開發佈的RSA公鑰對該證書進行驗證,下圖表明證書認證成功。
-
驗證通過之後,瀏覽器和服務器通過密鑰交換算法產生共享的對稱密鑰。
-
開始傳輸數據,使用同一個對稱密鑰來加解密。
DNS 的解析過程?
- 瀏覽器搜索自己的DNS緩存
- 若沒有,則搜索操作系統中的DNS緩存和hosts文件
- 若沒有,則操作系統將域名發送至本地域名服務器,本地域名服務器查詢自己的DNS緩存,查找成功則返回結果,否則依次向根域名服務器、頂級域名服務器、權限域名服務器發起查詢請求,最終返回IP地址給本地域名服務器
- 本地域名服務器將得到的IP地址返回給操作系統,同時自己也將IP地址緩存起來
- 操作系統將 IP 地址返回給瀏覽器,同時自己也將IP地址緩存起來
- 瀏覽器得到域名對應的IP地址
瀏覽器中輸入URL返回頁面過程?
- 解析域名,找到主機 IP。
- 瀏覽器利用 IP 直接與網站主機通信,三次握手,建立 TCP 連接。瀏覽器會以一個隨機端口向服務端的 web 程序 80 端口發起 TCP 的連接。
- 建立 TCP 連接後,瀏覽器向主機發起一個HTTP請求。
- 服務器響應請求,返迴響應數據。
- 瀏覽器解析響應內容,進行渲染,呈現給用戶。
Cookie和Session的區別?
- 作用範圍不同,Cookie 保存在客戶端,Session 保存在服務器端。
- 有效期不同,Cookie 可設置為長時間保持,比如我們經常使用的默認登錄功能,Session 一般失效時間較短,客戶端關閉或者 Session 超時都會失效。
- 隱私策略不同,Cookie 存儲在客戶端,容易被竊取;Session 存儲在服務端,安全性相對 Cookie 要好一些。
- 存儲大小不同, 單個 Cookie 保存的數據不能超過 4K;對於 Session 來說存儲沒有上限,但出於對服務器的性能考慮,Session 內不要存放過多的數據,並且需要設置 Session 刪除機制。
什麼是對稱加密和非對稱加密?
對稱加密:通信雙方使用相同的密鑰進行加密。特點是加密速度快,但是缺點是密鑰泄露會導緻密文數據被破解。常見的對稱加密有AES
和DES
算法。
非對稱加密:它需要生成兩個密鑰,公鑰和私鑰。公鑰是公開的,任何人都可以獲得,而私鑰是私人保管的。公鑰負責加密,私鑰負責解密;或者私鑰負責加密,公鑰負責解密。這種加密算法安全性更高,但是計算量相比對稱加密大很多,加密和解密都很慢。常見的非對稱算法有RSA
和DSA
。
碼字不易,如果覺得對你有幫助,可以點個贊鼓勵一下!
我是程序員大彬 ,專註Java後端硬核知識分享,歡迎大家關注~