本文目錄:
- 網路分層結構
- 三次握手
- 兩次握手可以嗎?
- 四次揮手
- 第四次揮手為什麼要等待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後端硬核知識分享,歡迎大家關注~