1. 程式人生 > 其它 >計算機網路面試知識點總結

計算機網路面試知識點總結

計算機網路面試知識點總結

一.網路分層結構

目前用的一般是5層網路模型來教學理解,實際應用中是TCP/IP的四層網路體系結構。

1.物理層

物理層考慮的是如何將位元流資料在連線計算機的傳輸媒體上進行傳輸,而不是指具體的傳輸媒體。

具體來說:

  • 確定與傳輸媒體的介面的一些特性,比如指定介面的形狀,尺寸,引線數目,電壓範圍等等

2.資料鏈路層

將網路層傳下來的IP資料報加上幀頭幀尾封裝成幀,在兩個相鄰節點的鏈路上傳送幀。

資料鏈路層所使用的通道有兩種:

  • 點對點通道
  • 廣播通道:使用一對多的廣播通訊方式

3.網路層

選擇合適的路由和交換節點,將標有目的地地址的IP資料報盡最大努力傳輸到目的主機。

需要注意的是:網路層不保證可靠傳輸,也就是說中間有丟失的IP資料報(分組)該層不做相應的處理。

4.運輸層

負責向兩臺主機程序之間的通訊提供資料傳輸服務,傳輸層的協議主要有傳輸控制協議(面向連線的)TCP和使用者資料協議(無連線的)UDP。

  • 運輸層和前面介紹的3層最大的不同是,前面三層從每一層的傳輸角度來看,在源地址和目的地址之間可能有很多個節點,而在運輸層的角度來看,它的眼裡只有源地址和目的地址主機上對應的程序,它看不到資料所經歷了哪些節點。

  • 從IP層來看,通訊的兩端是兩臺主機,從運輸層來看,通訊的兩端是主機中的程序。

  • 在一臺主機中很可能有多個應用程序同時分別與另一臺主機中的多個應用程序進行通訊,這就表明運輸層需要有一個重要功能——複用和分用。

  • 運輸層的埠

    ​ 執行在計算機中的程序是用程序識別符號來標誌的,但是不同的作業系統有不同的規定,因此必須採用統一的方法對TCP/IP體系的應用程序進行標誌,標誌的方法是

    埠用一個16位埠號進行標誌,埠號只具有本地意義,也就是說不同計算機之間相同埠號沒有聯絡。由此可見,兩個計算機中的程序要互相通訊,不僅必須知道對方的IP地址(為了找到對方的計算機),而且還要知道對方的埠號(為了找到對方計算機中的應用程序)。

  • 埠分類

    ​ 主要分為:

    服務端使用的埠號

    ​ 熟記埠0-1023、登記埠號。

    客戶端使用的埠:留給客戶端程序進行選擇並短暫適用,就是說當伺服器程序收到客戶程序的報文時,就知道了客戶程序所 使用的動態埠號。通訊結束後,這個埠號可供其他客戶程序以後使用

5.應用層

為應用程式提供互動服務。在網際網路中的應用層協議很多,如域名系統DNS、HTTP協議、SMTP協議等

二.TCP連線的建立與斷開

TCP連線的建立採用客戶-伺服器方式

客戶:主動發起連線建立的應用程序

伺服器:被動等待連線建立的應用程序叫做伺服器

1.三次握手

TCP建立連線的過程稱為握手,整個過程需要傳輸三個TCP報文

  • 第一次握手:TCP資料報首部中的同步位SYN=1,並且選擇序號位seq=x(表示一個隨機數)。同步 SYN = 1 表示這是一個連線請求連線接受報文
  • 第二次握手:客戶端的TCP在接受到連線請求後,如果同意應該傳送確認建立連線的資料報,SYN=1,ACK=1,ack=x+1,選擇序號seq為y。只有當 ACK = 1 時確認號欄位ack欄位才有效。當 ACK = 0 時,確認號無效。
  • 第三次握手:客戶接收到第二次握手報文後,向伺服器給出確認,ACK=1,seq=x+1,ack=y+1。客戶端並通知上層應用程序連線已經建立。B的TCP收到A的確認後也通知其應用程序連線已經建立。

2.四次揮手

資料傳輸結束後,雙方都可以隨時釋放連線。

  • A沒有想要跟B傳送的資料了,需要和B斷開連線,A的應用程序先向其TCP發出連線釋放報文段(FIN=1,seq=u),並停止再發送資料,主動關閉TCP連線,進入FIN-WAIT-1(終止等待1)狀態,等待B的確認
  • B發出確認,ack=u+1,設序號seq=v,B進入CLOSE-WAIT(關閉等待)狀態。並且B主機的TCP程序通知高層應用程序,A向B的單向連線斷開了。不過此時B向A的連線沒斷開,B向A發資料,A要接受。然後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就會重傳連線釋放報文段。

3.第四次揮手為什麼要等2MSL

保證A傳送的最後一個ACK報文段能夠到達B。這個ACK報文段有可能丟失,B收不到這個確認報文,就會超時重傳連線釋放報文段,然後A可以在2MSL時間內收到這個重傳的連線釋放報文段,接著A重傳一次確認,重新啟動2MSL計時器,最後A和B都進入到CLOSED狀態,若A在TIME-WAIT狀態不等待一段時間,而是傳送完ACK報文段後立即釋放連線,則無法收到B重傳的連線釋放報文段,所以不會再發送一次確認報文段,B就無法正常進入到CLOSED狀態。

防止已失效的連線請求報文段出現在本連線中。A在傳送完最後一個ACK報文段後,再經過2MSL,就可以使這個連線所產生的所有報文段都從網路中消失,使下一個新的連線中不會出現舊的連線請求報文段。如果A的最後ACK報文丟失了,且沒有等待直接開始下一次連線,B重發的斷開連線請求報文就會出現在下一個新的連線中。

4.為什麼連線是三次,斷開是四次呢

因為當Server端收到Client端的SYN連線請求報文後,可以直接傳送SYN+ACK報文。但是在關閉連線時,當Server端收到Client端發出的連線釋放報文時,很可能並不會立即關閉SOCKET,所以Server端先回復一個ACK報文,告訴Client端我收到你的連線釋放報文了。只有等到Server端所有的報文都發送完了,這時Server端才能傳送連線釋放報文,之後兩邊才會真正的斷開連線。故需要四次揮手。

5.為什麼連線是三次而不是兩次

因為如果是兩次,此時B還不能確認,B向A傳送的資料A能夠接收到。就不能正常地進行全雙工通訊。

三.TCP和UDP

1.TCP的特點以及與UDP區別

  • TCP是面向連線的,即傳送資料之前要建立一條連線,UDP是無連線的。
  • TCP提供可靠服務
  • TCP提供全雙工通訊
  • 每一條TCP連線只能是點對點的(一對一),而UDP支援一對多,一對一,多對多,多對一的通訊
  • TCP是面向位元組流的,雖然應用程式和TCP的互動是一次一個資料塊,但 TCP 把應用程式交下來的資料看成僅僅是一連串無結構的位元組流。UDP是面向報文的,不會對應用程序交下來的報文進行劃分。
  • TCP有擁塞控制,UDP沒有,因此網路出現擁塞不會使源主機的傳送速率降低(對實時應用很有用,如實時視訊會議等)。
  • TCP首部開銷20位元組;UDP的首部開銷小,只有8個位元組

2.什麼是套接字

TCP 連線的端點不是主機,不是主機的IP 地址,不是應用程序,也不是運輸層的協議埠。TCP連線的端點叫做 套接字(socket)

同一個IP地址可以有很多不同的TCP連線,同一個埠號也可以出現在不同的TCP連線中。

3.滑動視窗進行流量控制

TCP 利用滑動視窗實現流量控制。流量控制是為了控制傳送方傳送速率,保證接收方來得及接收。 TCP會話的雙方都各自維護一個傳送視窗和一個接收視窗。接收視窗大小取決於應用、系統、硬體的限制。傳送視窗則取決於對端通告的接收視窗。接收方傳送的確認報文中的rwnd欄位可以用來控制傳送方視窗大小,從而影響傳送方的傳送速率。將接收方的確認報文rwnd欄位(視窗欄位)設定為 0,則傳送方不能傳送資料。

TCP頭包含rwnd欄位,16bit位,它代表的是視窗的位元組容量,最大為65535。這個欄位是接收端告訴傳送端自己還有多少緩衝區可以接收資料。於是傳送端就可以根據這個接收端的處理能力來發送資料,而不會導致接收端處理不過來。從上圖可以看出接收端傳送的報文中rwnd欄位是可以根據自己的接受能力變化的。

4.TCP的擁塞控制

擁塞控制是為了避免過多的資料注入到網路中,TCP採取基於擁塞視窗(cwnd)的方法進行擁塞控制。TCP傳送方維持一個擁塞視窗cwnd(Congestion Window)。

  • 擁塞視窗的大小取決於網路的擁塞程度,並且動態地在變化。

  • 傳送端利用擁塞視窗根據網路的擁塞情況調整發送的資料量。

  • 所以,傳送視窗大小不僅取決於接收方視窗,還取決於網路的擁塞狀況,所以真正的傳送視窗值為:MIN(rwnd,cwnd)

具體的擁塞控制演算法:

  • 慢開始:

    在剛剛開始傳送報文段時,先把初始擁塞視窗cwnd設定為 1 2 個傳送方的最大報文段 SMSS。而在每收到一個對新的報文段的確認後,把擁塞視窗增加至多一個MSS的數值。每經過一個傳輸輪次,擁塞視窗 cwnd 就加倍。 為了防止擁塞視窗cwnd增長過大引起網路擁塞,還需要設定一個慢開始門限ssthresh狀態變數

    當 cwnd < ssthresh 時,使用慢開始演算法。

    當 cwnd > ssthresh 時,停止使用慢開始演算法而改用擁塞避免演算法。

    當 cwnd = ssthresh 時,既可使用慢開始演算法,也可使用擁塞控制避免演算法。

  • 擁塞避免

    ​ 讓擁塞視窗cwnd緩慢地增大,每經過一個往返時間RTT就把傳送方的擁塞視窗cwnd加1,而不是加倍。這樣擁塞視窗cwnd按線性規律緩慢增長。無論在慢開始階段還是在擁塞避免階段,只要傳送方判斷網路出現擁塞(其根據就是重傳定時器超時),就要把慢開始門限ssthresh設定為出現擁塞時的傳送 方視窗值的一半(但不能小於2)。然後把擁塞視窗cwnd重新設定為1,執行慢開始演算法。這樣做的目的就是要迅速減少主機發送到網路中的分組數,使得發生 擁塞的路由器有足夠時間把佇列中積壓的分組處理完畢。

  • 快重傳

    ​ 有時個別報文段會在網路中丟失,但實際上網路並未發生擁塞。如果傳送方遲遲收不到確認,就會產生超時,就會誤認為網路發生了擁塞。這就導致傳送方錯誤地啟動慢開始,把擁塞視窗cwnd又設定為1,因而降低了傳輸效率。快重傳演算法可以避免這個問題。快重傳演算法首先要求接收方每收到一個失序的報文段後就立即發出三次重複確認,使傳送方及早知道有報文段沒有到達對方。

    傳送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段,而不必繼續等待重傳計時器到期。由於傳送方儘早重傳未被確認的報文段,因此採用快重傳後可以使整個網路吞吐量提高約20%

  • 快恢復

    ​ 當傳送方連續收到三個重複確認,就會把慢開始門限ssthresh減半,接著把cwnd值設定為慢開始門限ssthresh減半後的數值,然後開始執行擁塞避免演算法,使擁塞視窗緩慢地線性增大。

    在採用快恢復演算法時,慢開始演算法只是在TCP連線建立時和網路出現超時時才使用。 採用這樣的擁塞控制方法使得TCP的效能有明顯的改進。

四.網路層的重要協議

1.IP地址和硬體地址

從網路層次的角度來看,硬體地址是在資料鏈路層和物理層用的地址,IP地址是在網路層及其上層所用的地址。IP地址是一種邏輯地址,可以用軟體進行劃分實現。

2.地址解析協議ARP

ARP主要用於解決同一個區域網上的主機或路由器IP和MAC地址的解析,已知IP地址如何解析出MAC地址。

  • 一個主機都設有一個ARP快取記憶體,裡面有所有的區域網上的主機和路由器的IP地址到硬體地址的對映表

  • 當源主機需要將一個數據包要傳送到目的主機時,會首先檢查自己 ARP列表中是否存在該 IP地址對應的MAC地址,如果有,就直接將資料包傳送到這個MAC地址;如果沒有,就向本地網段(所在的區域網)發起一個ARP請求的廣播包,查詢此目的主機對應的MAC地址。此ARP請求資料包裡包括源主機的IP地址、硬體地址、以及目的主機的IP地址。

  • 區域網絡中所有的主機收到這個ARP請求後,會檢查資料包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此資料包;如果相同,該主機首先將傳送端的MAC地址和IP地址新增到自己的ARP列表中,如果ARP表中已經存在該IP的資訊,則將其覆蓋,然後給源主機發送一個 ARP響應資料包,告訴對方自己是它需要查詢的MAC地址。

  • 源主機收到這個ARP響應資料包後,將得到的目的主機的IP地址和MAC地址新增到自己的ARP列表中,並利用此資訊開始資料的傳輸。如果源主機一直沒有收到ARP響應資料包,表示ARP查詢失敗。

  • 需要注意的是如果要找的主機和源主機不在一個區域網中,就要用ARP找到一個位於本區域網中某個路由器的硬體地址,然後把ARP請求分組發給該路由器,剩下的工作就由其他網路來做。

3.路由器分組轉發演算法

4.路由資訊協議RIP

RIP 是一種分散式的基於距離向量的路由選擇協議。RIP 協議要求網路中的每一個路由器都要維護從它自己到其他每一個目的網路的距離記錄。(從一個路由器到直接相連的網路的距離為1,距離也稱為跳數,每經過一個路由器跳數就加一)

RIP協議的三個特點:

  • 僅和相鄰路由器交換資訊,所交換的資訊是是各自的路由表
  • 按固定時間間隔交換資訊,例如每隔30s,當網路拓撲發生變化時,路由器也及時向相鄰路由器通告拓撲變化後的路由資訊

五.應用層的重要協議

1.域名的解析過程

  • 瀏覽器搜尋自己的DNS快取

  • 若沒有,則搜尋作業系統中的DNS快取和hosts檔案

  • 若沒有,則作業系統將域名傳送至本地域名伺服器,本地域名伺服器查詢自己的DNS快取,查詢成功則返回結果,否則依次向根域名伺服器、頂級域名伺服器、許可權域名伺服器發起查詢請求,最終返回IP地址給本地域名伺服器

  • 本地域名伺服器將得到的IP地址返回給作業系統,同時自己也將IP地址快取起來

  • 作業系統將 IP 地址返回給瀏覽器,同時自己也將IP地址快取起來

  • 瀏覽器得到域名對應的IP地址

2.瀏覽器中輸入URL地址得到頁面的過程

  • 解析域名,找到主機 IP。

  • 瀏覽器利用 IP 直接與網站主機通訊,三次握手,建立 TCP 連線。(瀏覽器會以一個隨機埠服務端的 web 程式 80 埠發起 TCP 的連線。 )

  • 建立 TCP 連線後,瀏覽器向主機發起一個HTTP請求。

  • 伺服器響應請求,返回響應資料。

  • 瀏覽器解析響應內容,進行渲染,呈現給使用者。

3.什麼是cookie

由於HTTP協議是無狀態的協議,它把每一次http請求看做是獨立的,因此需要用某種機制來識具體的請求者的身份,用來跟蹤使用者的整個會話。常用的會話跟蹤技術是cookie與session

cookie就是由伺服器發給客戶端的特殊資訊,而這些資訊以文字檔案的方式存放在客戶端,然後客戶端每次向伺服器傳送請求的時候都會帶上這些特殊的資訊。說得更具體一些:當用戶使用瀏覽器訪問一個支援cookie的網站的時候,使用者會提供包括使用者名稱在內的個人資訊並且提交至伺服器;接著,伺服器在向客戶端回傳相應的超文字的同時也會發回這些個人資訊,當然這些資訊並不是存放在HTTP響應體中的,而是存放於HTTP響應頭;當客戶端瀏覽器接收到來自伺服器的響應之後,瀏覽器會將這些資訊存放在一個統一的位置。 自此,客戶端再向伺服器傳送請求的時候,都會把相應的cookie存放在HTTP請求頭再次發回至伺服器。伺服器在接收到來自客戶端瀏覽器的請求之後,就能夠通過分析存放於請求頭的cookie得到客戶端特有的資訊,從而動態生成與該客戶端相對應的內容。網站的登入介面中“請記住我”這樣的選項,就是通過cookie實現的。

簡單的總結一下就是:

  • 某個使用者通過瀏覽器訪問某個網路伺服器時,伺服器在回覆這個請求時,將cookie資訊存放於響應頭中
  • 瀏覽器得到該響應獲取其中的cookie資料,並儲存在瀏覽器中
  • 下次該使用者再次通過這個瀏覽器訪問這個伺服器時,瀏覽器將自動攜帶cookie資料傳送給伺服器

4.什麼是session

首先瀏覽器請求伺服器訪問web站點時,伺服器首先會檢查這個客戶端請求是否已經包含了一個session標識、稱為SESSIONID,如果已經包含了一個sessionid則說明以前已經為此客戶端建立過session,伺服器就按照sessionid把這個session檢索出來使用,如果客戶端請求不包含session id,則伺服器為此客戶端建立一個session,並且生成一個與此session相關聯的獨一無二的sessionid存放到cookie中,這個sessionid將在本次響應中返回到客戶端儲存,這樣在互動的過程中,瀏覽器端每次請求時,都會帶著這個sessionid,伺服器根據這個sessionid就可以找得到對應的session。以此來達到共享資料的目的。 這裡需要注意的是,session不會隨著瀏覽器的關閉而死亡,而是等待超時時間。

5.對稱加密和非對稱加密

對稱加密:通訊雙方使用相同的金鑰進行加密。特點是加密速度快,但是缺點是金鑰洩露會導致密文資料被破解。常見的對稱加密有AESDES演算法

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

  • 對稱加密加密與解密使用的是同樣的金鑰,所以速度快,但由於需要將金鑰在網路傳輸,所以安全性不高。

  • 非對稱加密使用了一對金鑰,公鑰與私鑰,所以安全性高,但加密與解密速度慢。

  • 解決的辦法是將對稱加密的金鑰使用非對稱加密的公鑰進行加密,然後傳送出去,接收方使用私鑰進行解密得到對稱加密的金鑰,然後雙方可以使用對稱加密來進行溝通。

6.HTTP協議特點

  • HTTP允許傳輸任意型別的資料。傳輸的型別由Content-Type加以標記。

  • HTTP1.0是無狀態。對於客戶端每次傳送的請求,伺服器都認為是一個新的請求,上一次會話和下一次會話之間沒有聯絡。

  • 支援客戶端/伺服器模式

  • 協議本身是無連線的,雖然在傳輸層使用了面向連線的TCP協議(保證了資料的可靠傳輸)。

7.HTTP報文

  • 請求報文:由請求行,請求頭,請求體組成

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

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

    • 請求體:使用者的請求資料如使用者名稱,密碼等

  • 響應報文:響應行,響應頭,響應體

    • 響應行:協議版本,狀態碼及狀態描述

    • 響應頭:響應頭欄位主要有connection、content-type、content-encoding、content-length、set-cookie、Last-Modified,、Cache-Control、Expires

    • 響應體,主要是返回的頁面的內容

8.HTTP常用狀態碼

9.POST和GET的區別

  • GET請求引數通過URL傳遞,POST的引數放在請求體中。

  • GET產生一個TCP資料包;POST產生兩個TCP資料包。對於GET方式的請求,瀏覽器會把請求頭和請求體一併傳送出去;而對於POST,瀏覽器先發送請求頭,伺服器響應100 continue,瀏覽器再發送請求體。

  • GET請求會被瀏覽器主動快取,而POST不會,除非手動設定。

  • GET請求引數會被完整保留在瀏覽器歷史記錄裡,而POST中的引數不會被保留。

10.HTTP長連線和短連線

HTTP1.0預設使用的是短連線。瀏覽器和伺服器每進行一次HTTP操作,就建立一次連線,任務結束就中斷連線。

HTTP/1.1起,預設使用長連線。要使用長連線,客戶端和伺服器的HTTP首部的Connection都要設定為keep-alive,才能支援長連線。

HTTP長連線,指的是複用TCP連線。多個HTTP請求可以複用同一個TCP連線,這就節省了TCP連線建立和斷開的消耗。

11.HTTP1.0和2.0的區別

  • 新的二進位制格式:HTTP1.1 基於文字格式傳輸資料;HTTP2.0採用二進位制格式傳輸資料,解析更高效。

  • 多路複用:在一個連線裡,允許同時傳送多個請求或響應,並且這些請求或響應能夠並行的傳輸而不被阻塞,避免 HTTP1.1 出現的”隊頭堵塞”問題。

  • 頭部壓縮,HTTP1.1的header帶有大量資訊,而且每次都要重複傳送;HTTP2.0 把header從資料中分離,並封裝成頭幀和資料幀,使用特定演算法壓縮頭幀,有效減少頭資訊大小。並且HTTP2.0在客戶端和伺服器端記錄了之前傳送的鍵值對,對於相同的資料,不會重複傳送。比如請求a傳送了所有的頭資訊欄位,請求b則只需要傳送差異資料,這樣可以減少冗餘資料,降低開銷。

  • 服務端推送:HTTP2.0允許伺服器向客戶端推送資源,無需客戶端傳送請求到伺服器獲取。

12.HTTP和HTTPS的區別

  • HTTP是超文字傳輸協議,資訊是明文傳輸;HTTPS則是具有安全性的ssl加密傳輸協議。

  • HTTP和HTTPS用的埠不一樣,HTTP埠是80,HTTPS是443。

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

  • HTTP執行在TCP協議之上;HTTPS執行在SSL協議之上,SSL執行在TCP協議之上

13.什麼是HTTPS所用到的數字證書

服務端可以向證書頒發機構CA申請證書,以避免中間人攻擊(防止證書被篡改)。證書包含三部分內容:證書內容、證書籤名演算法和簽名,簽名是為了驗證身份。服務端把證書傳輸給瀏覽器,瀏覽器從證書裡取公鑰。證書可以證明該公鑰對應本網站

14.數字簽名的製作過程

  • CA機構使用證書籤名演算法對證書內容進行hash運算

  • 對hash後的值用CA的私鑰加密,得到數字簽名。

15.瀏覽器驗證數字證書有效的過程

  • 獲取證書,得到證書內容、證書籤名演算法和數字簽名。

  • 用CA機構的公鑰對數字簽名解密(由於是瀏覽器信任的機構,所以瀏覽器會儲存它的公鑰)。

  • 用證書裡的簽名演算法對證書內容進行hash運算

  • 比較解密後的數字簽名和對證書內容做hash運算後得到的雜湊值,相等則表明證書可信。

16.HTTPS的原理

整體流程:首先是TCP三次握手,然後客戶端發起一個HTTPS連線建立請求(TCP先建立連線),客戶端先發一個Client Hello的包,然後服務端響應Server Hello,接著再給客戶端傳送它的證書,然後雙方經過金鑰交換,最後使用交換的金鑰加解密資料。

  • 客戶端傳送Client Hello來協商加密的演算法

    Client Hello裡面客戶端會告知服務端自己當前的一些資訊,包括客戶端要使用的TLS版本,支援的加密演算法要訪問的域名,給服務端生成的一個隨機數(Nonce)等。需要提前告知伺服器想要訪問的域名以便伺服器傳送相應的域名的證書過來。TLS(安全傳輸層協議):為兩個通訊應用程式之間提供保密性和資料完整性,在SSL的協議上改進來的。

  • 服務端響應Server Hello,告訴客戶端服務端選中的加密演算法

  • 接著服務端給客戶端發來了2個證書。第二個證書是第一個證書的簽發機構(CA)的證書

  • 客戶端使用證書的認證機構CA公開發布的RSA公鑰對該證書進行驗證

  • 驗證通過之後,瀏覽器和伺服器通過金鑰交換演算法產生共享的對稱金鑰

    注意這裡服務端將對稱祕鑰傳給客戶端是先進行非對稱加密的,結合了對稱加密和非對稱加密兩種方式。

  • 開始傳輸資料,使用同一個對稱金鑰來加解密

六.參考連結

  1. 計算機網路面試題總結_筆經面經_牛客網 (nowcoder.com)