本文目錄：

• 網(wǎng)絡(luò)分層結(jié)構(gòu)

• 三次握手

• 兩次握手可以嗎骇径？

• 四次揮手

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

• 為什么是四次揮手者春？

• TCP有哪些特點破衔？

• TCP和UDP的區(qū)別？

• HTTP協(xié)議的特點碧查？

• HTTP報文格式

• HTTP狀態(tài)碼有哪些运敢？

• HTTP1.0和HTTP1.1的區(qū)別?

• HTTP1.1和 HTTP2.0的區(qū)別校仑？

• HTTPS與HTTP的區(qū)別忠售？

• 什么是數(shù)字證書？

• HTTPS原理

• DNS 的解析過程迄沫？

• 瀏覽器中輸入URL返回頁面過程稻扬？

• Cookie和Session的區(qū)別？

• 什么是對稱加密和非對稱加密羊瘩？

網(wǎng)絡(luò)分層結(jié)構(gòu)

計算機(jī)網(wǎng)絡(luò)體系大致分為三種泰佳，OSI七層模型盼砍、TCP/IP四層模型和五層模型。一般面試的時候考察比較多的是五層模型逝她。

image

TCP/IP五層模型：應(yīng)用層浇坐、傳輸層、網(wǎng)絡(luò)層黔宛、數(shù)據(jù)鏈路層近刘、物理層。

• 應(yīng)用層：為應(yīng)用程序提供交互服務(wù)臀晃。在互聯(lián)網(wǎng)中的應(yīng)用層協(xié)議很多觉渴，如域名系統(tǒng)DNS、HTTP協(xié)議徽惋、SMTP協(xié)議等案淋。

• 傳輸層：負(fù)責(zé)向兩臺主機(jī)進(jìn)程之間的通信提供數(shù)據(jù)傳輸服務(wù)。傳輸層的協(xié)議主要有傳輸控制協(xié)議TCP和用戶數(shù)據(jù)協(xié)議UDP险绘。

• 網(wǎng)絡(luò)層：選擇合適的路由和交換結(jié)點踢京，確保數(shù)據(jù)及時傳送。主要包括IP協(xié)議宦棺。

• 數(shù)據(jù)鏈路層：在兩個相鄰節(jié)點之間傳送數(shù)據(jù)時漱挚，數(shù)據(jù)鏈路層將網(wǎng)絡(luò)層交下來的 IP 數(shù)據(jù)報組裝成幀，在兩個相鄰節(jié)點間的鏈路上傳送幀渺氧。

• 物理層：實現(xiàn)相鄰節(jié)點間比特流的透明傳輸旨涝，盡可能屏蔽傳輸介質(zhì)和物理設(shè)備的差異。

三次握手

假設(shè)發(fā)送端為客戶端侣背，接收端為服務(wù)端白华。開始時客戶端和服務(wù)端的狀態(tài)都是CLOSED。

image

1. 第一次握手：客戶端向服務(wù)端發(fā)起建立連接請求贩耐，客戶端會隨機(jī)生成一個起始序列號x弧腥，客戶端向服務(wù)端發(fā)送的字段中包含標(biāo)志位SYN=1，序列號seq=x潮太。第一次握手前客戶端的狀態(tài)為CLOSE管搪，第一次握手后客戶端的狀態(tài)為SYN-SENT。此時服務(wù)端的狀態(tài)為LISTEN铡买。

2. 第二次握手：服務(wù)端在收到客戶端發(fā)來的報文后更鲁，會隨機(jī)生成一個服務(wù)端的起始序列號y，然后給客戶端回復(fù)一段報文奇钞，其中包括標(biāo)志位SYN=1澡为，ACK=1，序列號seq=y景埃，確認(rèn)號ack=x+1媒至。第二次握手前服務(wù)端的狀態(tài)為LISTEN顶别，第二次握手后服務(wù)端的狀態(tài)為SYN-RCVD，此時客戶端的狀態(tài)為SYN-SENT拒啰。（其中SYN=1表示要和客戶端建立一個連接驯绎，ACK=1表示確認(rèn)序號有效）

3. 第三次握手：客戶端收到服務(wù)端發(fā)來的報文后，會再向服務(wù)端發(fā)送報文谋旦，其中包含標(biāo)志位ACK=1条篷，序列號seq=x+1，確認(rèn)號ack=y+1蛤织。第三次握手前客戶端的狀態(tài)為SYN-SENT赴叹，第三次握手后客戶端和服務(wù)端的狀態(tài)都為ESTABLISHED。此時連接建立完成指蚜。

兩次握手可以嗎乞巧？

第三次握手主要為了防止已失效的連接請求報文段突然又傳輸?shù)搅朔?wù)端，導(dǎo)致產(chǎn)生問題摊鸡。

• 比如客戶端A發(fā)出連接請求绽媒，可能因為網(wǎng)絡(luò)阻塞原因，A沒有收到確認(rèn)報文免猾，于是A再重傳一次連接請求是辕。

• 連接成功，等待數(shù)據(jù)傳輸完畢后猎提，就釋放了連接获三。

• 然后A發(fā)出的第一個連接請求等到連接釋放以后的某個時間才到達(dá)服務(wù)端B，此時B誤認(rèn)為A又發(fā)出一次新的連接請求锨苏，于是就向A發(fā)出確認(rèn)報文段疙教。

• 如果不采用三次握手，只要B發(fā)出確認(rèn)伞租，就建立新的連接了贞谓，此時A不會響應(yīng)B的確認(rèn)且不發(fā)送數(shù)據(jù)，則B一直等待A發(fā)送數(shù)據(jù)葵诈，浪費資源裸弦。

四次揮手

image

1. A的應(yīng)用進(jìn)程先向其TCP發(fā)出連接釋放報文段（FIN=1，seq=u）作喘，并停止再發(fā)送數(shù)據(jù)理疙，主動關(guān)閉TCP連接，進(jìn)入FIN-WAIT-1（終止等待1）狀態(tài)徊都，等待B的確認(rèn)沪斟。

2. B收到連接釋放報文段后即發(fā)出確認(rèn)報文段（ACK=1，ack=u+1暇矫，seq=v）主之，B進(jìn)入CLOSE-WAIT（關(guān)閉等待）狀態(tài)，此時的TCP處于半關(guān)閉狀態(tài)李根，A到B的連接釋放槽奕。

3. A收到B的確認(rèn)后，進(jìn)入FIN-WAIT-2（終止等待2）狀態(tài)房轿，等待B發(fā)出的連接釋放報文段粤攒。

4. B發(fā)送完數(shù)據(jù)，就會發(fā)出連接釋放報文段（FIN=1囱持，ACK=1夯接，seq=w，ack=u+1）纷妆，B進(jìn)入LAST-ACK（最后確認(rèn)）狀態(tài)盔几，等待A的確認(rèn)。

5. A收到B的連接釋放報文段后掩幢，對此發(fā)出確認(rèn)報文段（ACK=1逊拍，seq=u+1，ack=w+1）际邻，A進(jìn)入TIME-WAIT（時間等待）狀態(tài)芯丧。此時TCP未釋放掉，需要經(jīng)過時間等待計時器設(shè)置的時間2MSL（最大報文段生存時間）后世曾，A才進(jìn)入CLOSED狀態(tài)缨恒。B收到A發(fā)出的確認(rèn)報文段后關(guān)閉連接，若沒收到A發(fā)出的確認(rèn)報文段轮听，B就會重傳連接釋放報文段肿轨。

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

• 保證A發(fā)送的最后一個ACK報文段能夠到達(dá)B蕊程。這個ACK報文段有可能丟失椒袍，B收不到這個確認(rèn)報文，就會超時重傳連接釋放報文段藻茂，然后A可以在2MSL時間內(nèi)收到這個重傳的連接釋放報文段驹暑，接著A重傳一次確認(rèn)，重新啟動2MSL計時器辨赐，最后A和B都進(jìn)入到CLOSED狀態(tài)优俘，若A在TIME-WAIT狀態(tài)不等待一段時間，而是發(fā)送完ACK報文段后立即釋放連接掀序，則無法收到B重傳的連接釋放報文段帆焕，所以不會再發(fā)送一次確認(rèn)報文段，B就無法正常進(jìn)入到CLOSED狀態(tài)。

• 防止已失效的連接請求報文段出現(xiàn)在本連接中叶雹。A在發(fā)送完最后一個ACK報文段后财饥，再經(jīng)過2MSL，就可以使這個連接所產(chǎn)生的所有報文段都從網(wǎng)絡(luò)中消失折晦，使下一個新的連接中不會出現(xiàn)舊的連接請求報文段钥星。

為什么是四次揮手？

因為當(dāng)Server端收到Client端的SYN連接請求報文后满着，可以直接發(fā)送SYN+ACK報文谦炒。但是在關(guān)閉連接時，當(dāng)Server端收到Client端發(fā)出的連接釋放報文時风喇，很可能并不會立即關(guān)閉SOCKET宁改，所以Server端先回復(fù)一個ACK報文，告訴Client端我收到你的連接釋放報文了魂莫。只有等到Server端所有的報文都發(fā)送完了还蹲，這時Server端才能發(fā)送連接釋放報文，之后兩邊才會真正的斷開連接豁鲤。故需要四次揮手秽誊。

TCP有哪些特點？

• TCP是面向連接的運輸層協(xié)議琳骡。

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

• TCP提供可靠交付的服務(wù)楣号。

• TCP提供全雙工通信最易。

• 面向字節(jié)流。

TCP和UDP的區(qū)別炫狱？

1. TCP面向連接藻懒；UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接视译。

2. TCP提供可靠的服務(wù)嬉荆；UDP不保證可靠交付。

3. TCP面向字節(jié)流酷含，把數(shù)據(jù)看成一連串無結(jié)構(gòu)的字節(jié)流鄙早；UDP是面向報文的。

4. TCP有擁塞控制椅亚；UDP沒有擁塞控制限番，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會使源主機(jī)的發(fā)送速率降低（對實時應(yīng)用很有用，如實時視頻會議等）呀舔。

5. 每一條TCP連接只能是點到點的弥虐；UDP支持一對一、一對多、多對一和多對多的通信方式霜瘪。

6. TCP首部開銷20字節(jié)珠插；UDP的首部開銷小，只有8個字節(jié)粥庄。

HTTP協(xié)議的特點丧失？

1. HTTP允許傳輸任意類型的數(shù)據(jù)豺妓。傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記惜互。

2. 無狀態(tài)。對于客戶端每次發(fā)送的請求琳拭，服務(wù)器都認(rèn)為是一個新的請求训堆，上一次會話和下一次會話之間沒有聯(lián)系。

3. 支持客戶端/服務(wù)器模式白嘁。

HTTP報文格式

HTTP請求由請求行坑鱼、請求頭部、空行和請求體四個部分組成絮缅。

• 請求行：包括請求方法鲁沥，訪問的資源URL，使用的HTTP版本耕魄。GET和POST是最常見的HTTP方法画恰，除此以外還包括DELETE、HEAD吸奴、OPTIONS允扇、PUT、TRACE则奥。

• 請求頭：格式為“屬性名:屬性值”考润，服務(wù)端根據(jù)請求頭獲取客戶端的信息，主要有cookie读处、host糊治、connection、accept-language罚舱、accept-encoding井辜、user-agent。

• 請求體：用戶的請求數(shù)據(jù)如用戶名馆匿，密碼等抑胎。

請求報文示例：

<pre class="md-fences md-end-block ty-contain-cm modeLoaded" spellcheck="false" lang="java" cid="n788" mdtype="fences" style="box-sizing: border-box; overflow: visible; font-family: Monaco, Consolas, "Andale Mono", "DejaVu Sans Mono", monospace; margin-top: 0px; margin-bottom: 20px; font-size: 0.9rem; display: block; break-inside: avoid; text-align: left; white-space: normal; background: rgb(51, 51, 51); position: relative !important; padding: 10px 10px 10px 30px; width: inherit; color: rgb(184, 191, 198); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">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 請求體</pre>

HTTP響應(yīng)也由四個部分組成，分別是：狀態(tài)行渐北、響應(yīng)頭阿逃、空行和響應(yīng)體。

• 狀態(tài)行：協(xié)議版本，狀態(tài)碼及狀態(tài)描述恃锉。

• 響應(yīng)頭：響應(yīng)頭字段主要有connection搀菩、content-type、content-encoding破托、content-length肪跋、set-cookie、Last-Modified土砂，州既、Cache-Control、Expires萝映。

• 響應(yīng)體：服務(wù)器返回給客戶端的內(nèi)容吴叶。

響應(yīng)報文示例：

<pre class="md-fences md-end-block ty-contain-cm modeLoaded" spellcheck="false" lang="html" cid="n798" mdtype="fences" style="box-sizing: border-box; overflow: visible; font-family: Monaco, Consolas, "Andale Mono", "DejaVu Sans Mono", monospace; margin-top: 0px; margin-bottom: 20px; font-size: 0.9rem; display: block; break-inside: avoid; text-align: left; white-space: normal; background: rgb(51, 51, 51); position: relative !important; padding: 10px 10px 10px 30px; width: inherit; color: rgb(184, 191, 198); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112

<html>
<body>響應(yīng)體</body>
</html></pre>

HTTP狀態(tài)碼有哪些？

image

HTTP1.0和HTTP1.1的區(qū)別?

• 長連接：HTTP1.0默認(rèn)使用短連接序臂，每次請求都需要建立新的TCP連接蚌卤，連接不能復(fù)用。HTTP1.1支持長連接奥秆，復(fù)用TCP連接逊彭，允許客戶端通過同一連接發(fā)送多個請求。不過构订，這個優(yōu)化策略也存在問題侮叮，當(dāng)一個隊頭的請求不能收到響應(yīng)的資源時，它將會阻塞后面的請求鲫咽。這就是“隊頭阻塞”問題签赃。

• 斷點續(xù)傳：HTTP1.0 不支持?jǐn)帱c續(xù)傳。HTTP1.1 新增了 range 字段分尸，用來指定數(shù)據(jù)字節(jié)位置锦聊，支持?jǐn)帱c續(xù)傳。

• 錯誤狀態(tài)響應(yīng)碼：在HTTP1.1中新增了24個錯誤狀態(tài)響應(yīng)碼箩绍，如409（Conflict）表示請求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突孔庭、410（Gone）表示服務(wù)器上的某個資源被永久性的刪除。

• Host頭處理：在HTTP1.0中認(rèn)為每臺服務(wù)器都綁定一個唯一的IP地址材蛛，因此圆到，請求消息中的URL并沒有傳遞主機(jī)名。到了HTTP1.1時代卑吭，虛擬主機(jī)技術(shù)發(fā)展迅速芽淡，在一臺物理服務(wù)器上可以存在多個虛擬主機(jī)，并且它們共享一個IP地址豆赏，故HTTP1.1增加了HOST信息挣菲。

HTTP1.1和 HTTP2.0的區(qū)別富稻？

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

• 新的二進(jìn)制格式：HTTP1.1 基于文本格式傳輸數(shù)據(jù)；HTTP2.0采用二進(jìn)制格式傳輸數(shù)據(jù)白胀，解析更高效椭赋。

• 多路復(fù)用：在一個連接里，允許同時發(fā)送多個請求或響應(yīng)或杠，并且這些請求或響應(yīng)能夠并行的傳輸而不被阻塞哪怔，避免 HTTP1.1 出現(xiàn)的”隊頭堵塞”問題。

• 頭部壓縮向抢，HTTP1.1的header帶有大量信息认境，而且每次都要重復(fù)發(fā)送；HTTP2.0 把header從數(shù)據(jù)中分離笋额，并封裝成頭幀和數(shù)據(jù)幀元暴，使用特定算法壓縮頭幀篷扩，有效減少頭信息大小兄猩。并且HTTP2.0在客戶端和服務(wù)器端記錄了之前發(fā)送的鍵值對，對于相同的數(shù)據(jù)鉴未，不會重復(fù)發(fā)送枢冤。比如請求a發(fā)送了所有的頭信息字段，請求b則只需要發(fā)送差異數(shù)據(jù)铜秆，這樣可以減少冗余數(shù)據(jù)淹真，降低開銷。

• 服務(wù)端推送：HTTP2.0允許服務(wù)器向客戶端推送資源连茧，無需客戶端發(fā)送請求到服務(wù)器獲取核蘸。

HTTPS與HTTP的區(qū)別？

1. HTTP是超文本傳輸協(xié)議啸驯，信息是明文傳輸客扎；HTTPS則是具有安全性的ssl加密傳輸協(xié)議。

2. HTTP和HTTPS用的端口不一樣罚斗，HTTP端口是80徙鱼，HTTPS是443。

3. HTTPS協(xié)議需要到CA機(jī)構(gòu)申請證書针姿，一般需要一定的費用袱吆。

4. HTTP運行在TCP協(xié)議之上；HTTPS運行在SSL協(xié)議之上距淫，SSL運行在TCP協(xié)議之上绞绒。

什么是數(shù)字證書？

服務(wù)端可以向證書頒發(fā)機(jī)構(gòu)CA申請證書榕暇，以避免中間人攻擊（防止證書被篡改）蓬衡。證書包含三部分內(nèi)容：證書內(nèi)容饲趋、證書簽名算法和簽名，簽名是為了驗證身份撤蟆。

image

服務(wù)端把證書傳輸給瀏覽器奕塑，瀏覽器從證書里取公鑰。證書可以證明該公鑰對應(yīng)本網(wǎng)站家肯。

數(shù)字簽名的制作過程：

1. CA使用證書簽名算法對證書內(nèi)容進(jìn)行hash運算龄砰。

2. 對hash后的值用CA的私鑰加密，得到數(shù)字簽名讨衣。

瀏覽器驗證過程：

1. 獲取證書换棚，得到證書內(nèi)容、證書簽名算法和數(shù)字簽名反镇。

2. 用CA機(jī)構(gòu)的公鑰對數(shù)字簽名解密（由于是瀏覽器信任的機(jī)構(gòu)固蚤，所以瀏覽器會保存它的公鑰）。

3. 用證書里的簽名算法對證書內(nèi)容進(jìn)行hash運算歹茶。

4. 比較解密后的數(shù)字簽名和對證書內(nèi)容做hash運算后得到的哈希值夕玩，相等則表明證書可信。

HTTPS原理

首先是TCP三次握手惊豺，然后客戶端發(fā)起一個HTTPS連接建立請求燎孟，客戶端先發(fā)一個Client Hello的包，然后服務(wù)端響應(yīng)Server Hello尸昧，接著再給客戶端發(fā)送它的證書揩页，然后雙方經(jīng)過密鑰交換，最后使用交換的密鑰加解密數(shù)據(jù)烹俗。

1. 協(xié)商加密算法 爆侣。在Client Hello里面客戶端會告知服務(wù)端自己當(dāng)前的一些信息，包括客戶端要使用的TLS版本幢妄，支持的加密算法兔仰，要訪問的域名，給服務(wù)端生成的一個隨機(jī)數(shù)（Nonce）等磁浇。需要提前告知服務(wù)器想要訪問的域名以便服務(wù)器發(fā)送相應(yīng)的域名的證書過來斋陪。

   image

2. 服務(wù)端響應(yīng)Server Hello，告訴客戶端服務(wù)端選中的加密算法置吓。

   image

3. 接著服務(wù)端給客戶端發(fā)來了2個證書无虚。第二個證書是第一個證書的簽發(fā)機(jī)構(gòu)（CA）的證書。

   image

4. 客戶端使用證書的認(rèn)證機(jī)構(gòu)CA公開發(fā)布的RSA公鑰對該證書進(jìn)行驗證衍锚，下圖表明證書認(rèn)證成功友题。

   image

5. 驗證通過之后，瀏覽器和服務(wù)器通過密鑰交換算法產(chǎn)生共享的對稱密鑰戴质。

   image
   image

6. 開始傳輸數(shù)據(jù)度宦，使用同一個對稱密鑰來加解密踢匣。

   image

DNS 的解析過程？

1. 瀏覽器搜索自己的DNS緩存

2. 若沒有戈抄，則搜索操作系統(tǒng)中的DNS緩存和hosts文件

3. 若沒有离唬，則操作系統(tǒng)將域名發(fā)送至本地域名服務(wù)器，本地域名服務(wù)器查詢自己的DNS緩存划鸽，查找成功則返回結(jié)果输莺，否則依次向根域名服務(wù)器、頂級域名服務(wù)器裸诽、權(quán)限域名服務(wù)器發(fā)起查詢請求嫂用，最終返回IP地址給本地域名服務(wù)器

4. 本地域名服務(wù)器將得到的IP地址返回給操作系統(tǒng)，同時自己也將IP地址緩存起來

5. 操作系統(tǒng)將 IP 地址返回給瀏覽器丈冬，同時自己也將IP地址緩存起來

6. 瀏覽器得到域名對應(yīng)的IP地址

瀏覽器中輸入URL返回頁面過程嘱函？

1. 解析域名，找到主機(jī) IP埂蕊。

2. 瀏覽器利用 IP 直接與網(wǎng)站主機(jī)通信往弓，三次握手，建立 TCP 連接粒梦。瀏覽器會以一個隨機(jī)端口向服務(wù)端的 web 程序 80 端口發(fā)起 TCP 的連接亮航。

3. 建立 TCP 連接后，瀏覽器向主機(jī)發(fā)起一個HTTP請求匀们。

4. 服務(wù)器響應(yīng)請求，返回響應(yīng)數(shù)據(jù)准给。

5. 瀏覽器解析響應(yīng)內(nèi)容泄朴，進(jìn)行渲染，呈現(xiàn)給用戶露氮。

image

Cookie和Session的區(qū)別祖灰？

• 作用范圍不同，Cookie 保存在客戶端畔规，Session 保存在服務(wù)器端局扶。

• 有效期不同，Cookie 可設(shè)置為長時間保持叁扫，比如我們經(jīng)常使用的默認(rèn)登錄功能三妈，Session 一般失效時間較短，客戶端關(guān)閉或者 Session 超時都會失效莫绣。

• 隱私策略不同畴蒲，Cookie 存儲在客戶端，容易被竊榷允摇模燥；Session 存儲在服務(wù)端咖祭，安全性相對 Cookie 要好一些。

• 存儲大小不同蔫骂， 單個 Cookie 保存的數(shù)據(jù)不能超過 4K么翰；對于 Session 來說存儲沒有上限，但出于對服務(wù)器的性能考慮辽旋，Session 內(nèi)不要存放過多的數(shù)據(jù)硬鞍，并且需要設(shè)置 Session 刪除機(jī)制。

什么是對稱加密和非對稱加密戴已？

對稱加密：通信雙方使用相同的密鑰進(jìn)行加密固该。特點是加密速度快，但是缺點是密鑰泄露會導(dǎo)致密文數(shù)據(jù)被破解糖儡。常見的對稱加密有AES和DES算法伐坏。

非對稱加密：它需要生成兩個密鑰娜谊，公鑰和私鑰稚伍。公鑰是公開的篡悟，任何人都可以獲得毁欣，而私鑰是私人保管的陨帆。公鑰負(fù)責(zé)加密隧饼，私鑰負(fù)責(zé)解密欠窒；或者私鑰負(fù)責(zé)加密辰斋，公鑰負(fù)責(zé)解密代芜。這種加密算法安全性更高埠褪，但是計算量相比對稱加密大很多，加密和解密都很慢挤庇。常見的非對稱算法有RSA和DSA钞速。

碼字不易，如果覺得對你有幫助嫡秕，可以點個贊鼓勵一下渴语！
我是程序員大彬 ，專注Java后端硬核知識分享昆咽，歡迎大家關(guān)注~