計(jì)算機(jī)網(wǎng)絡(luò)經(jīng)典 20 問(wèn)

本文目錄：

• 網(wǎng)絡(luò)分層結(jié)構(gòu)
• 三次握手
• 兩次握手可以嗎？
• 四次揮手
• 第四次揮手為什么要等待2MSL？
• 為什么是四次揮手？
• TCP有哪些特點(diǎn)？
• TCP和UDP的區(qū)別？
• HTTP協(xié)議的特點(diǎn)？
• HTTP報(bào)文格式
• HTTP狀態(tài)碼有哪些？
• HTTP1.0和HTTP1.1的區(qū)別?
• HTTP1.1和 HTTP2.0的區(qū)別？
• HTTPS與HTTP的區(qū)別？
• 什么是數(shù)字證書(shū)？
• HTTPS原理
• DNS 的解析過(guò)程？
• 瀏覽器中輸入U(xiǎn)RL返回頁(yè)面過(guò)程？
• Cookie和Session的區(qū)別？
• 什么是對(duì)稱加密和非對(duì)稱加密？

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

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

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é)向兩臺(tái)主機(jī)進(jìn)程之間的通信提供數(shù)據(jù)傳輸服務(wù)。傳輸層的協(xié)議主要有傳輸控制協(xié)議TCP和用戶數(shù)據(jù)協(xié)議UDP。
• 網(wǎng)絡(luò)層：選擇合適的路由和交換結(jié)點(diǎn)，確保數(shù)據(jù)及時(shí)傳送。主要包括IP協(xié)議。
• 數(shù)據(jù)鏈路層：在兩個(gè)相鄰節(jié)點(diǎn)之間傳送數(shù)據(jù)時(shí)，數(shù)據(jù)鏈路層將網(wǎng)絡(luò)層交下來(lái)的 IP 數(shù)據(jù)報(bào)組裝成幀，在兩個(gè)相鄰節(jié)點(diǎn)間的鏈路上傳送幀。
• 物理層：實(shí)現(xiàn)相鄰節(jié)點(diǎn)間比特流的透明傳輸，盡可能屏蔽傳輸介質(zhì)和物理設(shè)備的差異。

三次握手

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

1. 第一次握手：客戶端向服務(wù)端發(fā)起建立連接請(qǐng)求，客戶端會(huì)隨機(jī)生成一個(gè)起始序列號(hào)x，客戶端向服務(wù)端發(fā)送的字段中包含標(biāo)志位SYN=1，序列號(hào)seq=x。第一次握手前客戶端的狀態(tài)為CLOSE，第一次握手后客戶端的狀態(tài)為SYN-SENT。此時(shí)服務(wù)端的狀態(tài)為LISTEN。
2. 第二次握手：服務(wù)端在收到客戶端發(fā)來(lái)的報(bào)文后，會(huì)隨機(jī)生成一個(gè)服務(wù)端的起始序列號(hào)y，然后給客戶端回復(fù)一段報(bào)文，其中包括標(biāo)志位SYN=1，ACK=1，序列號(hào)seq=y，確認(rèn)號(hào)ack=x+1。第二次握手前服務(wù)端的狀態(tài)為LISTEN，第二次握手后服務(wù)端的狀態(tài)為SYN-RCVD，此時(shí)客戶端的狀態(tài)為SYN-SENT。（其中SYN=1表示要和客戶端建立一個(gè)連接，ACK=1表示確認(rèn)序號(hào)有效）
3. 第三次握手：客戶端收到服務(wù)端發(fā)來(lái)的報(bào)文后，會(huì)再向服務(wù)端發(fā)送報(bào)文，其中包含標(biāo)志位ACK=1，序列號(hào)seq=x+1，確認(rèn)號(hào)ack=y+1。第三次握手前客戶端的狀態(tài)為SYN-SENT，第三次握手后客戶端和服務(wù)端的狀態(tài)都為ESTABLISHED。此時(shí)連接建立完成。

兩次握手可以嗎？

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

• 比如客戶端A發(fā)出連接請(qǐng)求，可能因?yàn)榫W(wǎng)絡(luò)阻塞原因，A沒(méi)有收到確認(rèn)報(bào)文，于是A再重傳一次連接請(qǐng)求。
• 連接成功，等待數(shù)據(jù)傳輸完畢后，就釋放了連接。
• 然后A發(fā)出的第一個(gè)連接請(qǐng)求等到連接釋放以后的某個(gè)時(shí)間才到達(dá)服務(wù)端B，此時(shí)B誤認(rèn)為A又發(fā)出一次新的連接請(qǐng)求，于是就向A發(fā)出確認(rèn)報(bào)文段。
• 如果不采用三次握手，只要B發(fā)出確認(rèn)，就建立新的連接了，此時(shí)A不會(huì)響應(yīng)B的確認(rèn)且不發(fā)送數(shù)據(jù)，則B一直等待A發(fā)送數(shù)據(jù)，浪費(fèi)資源。

四次揮手

1. A的應(yīng)用進(jìn)程先向其TCP發(fā)出連接釋放報(bào)文段（FIN=1，seq=u），并停止再發(fā)送數(shù)據(jù)，主動(dòng)關(guān)閉TCP連接，進(jìn)入FIN-WAIT-1（終止等待1）狀態(tài)，等待B的確認(rèn)。
2. B收到連接釋放報(bào)文段后即發(fā)出確認(rèn)報(bào)文段（ACK=1，ack=u+1，seq=v），B進(jìn)入CLOSE-WAIT（關(guān)閉等待）狀態(tài)，此時(shí)的TCP處于半關(guān)閉狀態(tài)，A到B的連接釋放。
3. A收到B的確認(rèn)后，進(jìn)入FIN-WAIT-2（終止等待2）狀態(tài)，等待B發(fā)出的連接釋放報(bào)文段。
4. B發(fā)送完數(shù)據(jù)，就會(huì)發(fā)出連接釋放報(bào)文段（FIN=1，ACK=1，seq=w，ack=u+1），B進(jìn)入LAST-ACK（最后確認(rèn)）狀態(tài)，等待A的確認(rèn)。
5. A收到B的連接釋放報(bào)文段后，對(duì)此發(fā)出確認(rèn)報(bào)文段（ACK=1，seq=u+1，ack=w+1），A進(jìn)入TIME-WAIT（時(shí)間等待）狀態(tài)。此時(shí)TCP未釋放掉，需要經(jīng)過(guò)時(shí)間等待計(jì)時(shí)器設(shè)置的時(shí)間2MSL（最大報(bào)文段生存時(shí)間）后，A才進(jìn)入CLOSED狀態(tài)。B收到A發(fā)出的確認(rèn)報(bào)文段后關(guān)閉連接，若沒(méi)收到A發(fā)出的確認(rèn)報(bào)文段，B就會(huì)重傳連接釋放報(bào)文段。

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

• 保證A發(fā)送的最后一個(gè)ACK報(bào)文段能夠到達(dá)B。這個(gè)ACK報(bào)文段有可能丟失，B收不到這個(gè)確認(rèn)報(bào)文，就會(huì)超時(shí)重傳連接釋放報(bào)文段，然后A可以在2MSL時(shí)間內(nèi)收到這個(gè)重傳的連接釋放報(bào)文段，接著A重傳一次確認(rèn)，重新啟動(dòng)2MSL計(jì)時(shí)器，最后A和B都進(jìn)入到CLOSED狀態(tài)，若A在TIME-WAIT狀態(tài)不等待一段時(shí)間，而是發(fā)送完ACK報(bào)文段后立即釋放連接，則無(wú)法收到B重傳的連接釋放報(bào)文段，所以不會(huì)再發(fā)送一次確認(rèn)報(bào)文段，B就無(wú)法正常進(jìn)入到CLOSED狀態(tài)。
• 防止已失效的連接請(qǐng)求報(bào)文段出現(xiàn)在本連接中。A在發(fā)送完最后一個(gè)ACK報(bào)文段后，再經(jīng)過(guò)2MSL，就可以使這個(gè)連接所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失，使下一個(gè)新的連接中不會(huì)出現(xiàn)舊的連接請(qǐng)求報(bào)文段。

為什么是四次揮手？

因?yàn)楫?dāng)Server端收到Client端的SYN連接請(qǐng)求報(bào)文后，可以直接發(fā)送SYN+ACK報(bào)文。但是在關(guān)閉連接時(shí)，當(dāng)Server端收到Client端發(fā)出的連接釋放報(bào)文時(shí)，很可能并不會(huì)立即關(guān)閉SOCKET，所以Server端先回復(fù)一個(gè)ACK報(bào)文，告訴Client端我收到你的連接釋放報(bào)文了。只有等到Server端所有的報(bào)文都發(fā)送完了，這時(shí)Server端才能發(fā)送連接釋放報(bào)文，之后兩邊才會(huì)真正的斷開(kāi)連接。故需要四次揮手。

TCP有哪些特點(diǎn)？

• TCP是面向連接的運(yùn)輸層協(xié)議。
• 點(diǎn)對(duì)點(diǎn)，每一條TCP連接只能有兩個(gè)端點(diǎn)。
• TCP提供可靠交付的服務(wù)。
• TCP提供全雙工通信。
• 面向字節(jié)流。

TCP和UDP的區(qū)別？

1. TCP面向連接；UDP是無(wú)連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接。
2. TCP提供可靠的服務(wù)；UDP不保證可靠交付。
3. TCP面向字節(jié)流，把數(shù)據(jù)看成一連串無(wú)結(jié)構(gòu)的字節(jié)流；UDP是面向報(bào)文的。
4. TCP有擁塞控制；UDP沒(méi)有擁塞控制，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會(huì)使源主機(jī)的發(fā)送速率降低（對(duì)實(shí)時(shí)應(yīng)用很有用，如實(shí)時(shí)視頻會(huì)議等）。
5. 每一條TCP連接只能是點(diǎn)到點(diǎn)的；UDP支持一對(duì)一、一對(duì)多、多對(duì)一和多對(duì)多的通信方式。
6. TCP首部開(kāi)銷(xiāo)20字節(jié)；UDP的首部開(kāi)銷(xiāo)小，只有8個(gè)字節(jié)。

HTTP協(xié)議的特點(diǎn)？

1. HTTP允許傳輸任意類(lèi)型的數(shù)據(jù)。傳輸?shù)念?lèi)型由Content-Type加以標(biāo)記。
2. 無(wú)狀態(tài)。對(duì)于客戶端每次發(fā)送的請(qǐng)求，服務(wù)器都認(rèn)為是一個(gè)新的請(qǐng)求，上一次會(huì)話和下一次會(huì)話之間沒(méi)有聯(lián)系。
3. 支持客戶端/服務(wù)器模式。

HTTP報(bào)文格式

HTTP請(qǐng)求由請(qǐng)求行、請(qǐng)求頭部、空行和請(qǐng)求體四個(gè)部分組成。

• 請(qǐng)求行：包括請(qǐng)求方法，訪問(wèn)的資源URL，使用的HTTP版本。GET和POST是最常見(jiàn)的HTTP方法，除此以外還包括DELETE、HEAD、OPTIONS、PUT、TRACE。
• 請(qǐng)求頭：格式為“屬性名:屬性值”，服務(wù)端根據(jù)請(qǐng)求頭獲取客戶端的信息，主要有cookie、host、connection、accept-language、accept-encoding、user-agent。
• 請(qǐng)求體：用戶的請(qǐng)求數(shù)據(jù)如用戶名，密碼等。

請(qǐng)求報(bào)文示例：

POST?/xxx?HTTP/1.1?請(qǐng)求行
Accept:image/gif.image/jpeg,?請(qǐng)求頭部
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?請(qǐng)求體

HTTP響應(yīng)也由四個(gè)部分組成，分別是：狀態(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)報(bào)文示例：

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>

HTTP狀態(tài)碼有哪些？HTTP1.0和HTTP1.1的區(qū)別?

• 長(zhǎng)連接：HTTP1.0默認(rèn)使用短連接，每次請(qǐng)求都需要建立新的TCP連接，連接不能復(fù)用。HTTP1.1支持長(zhǎng)連接，復(fù)用TCP連接，允許客戶端通過(guò)同一連接發(fā)送多個(gè)請(qǐng)求。不過(guò)，這個(gè)優(yōu)化策略也存在問(wèn)題，當(dāng)一個(gè)隊(duì)頭的請(qǐng)求不能收到響應(yīng)的資源時(shí)，它將會(huì)阻塞后面的請(qǐng)求。這就是“隊(duì)頭阻塞”問(wèn)題。

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

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

• Host頭處理：在HTTP1.0中認(rèn)為每臺(tái)服務(wù)器都綁定一個(gè)唯一的IP地址，因此，請(qǐng)求消息中的URL并沒(méi)有傳遞主機(jī)名。到了HTTP1.1時(shí)代，虛擬主機(jī)技術(shù)發(fā)展迅速，在一臺(tái)物理服務(wù)器上可以存在多個(gè)虛擬主機(jī)，并且它們共享一個(gè)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ù)用：在一個(gè)連接里，允許同時(shí)發(fā)送多個(gè)請(qǐng)求或響應(yīng)，并且這些請(qǐng)求或響應(yīng)能夠并行的傳輸而不被阻塞，避免 HTTP1.1 出現(xiàn)的”隊(duì)頭堵塞”問(wèn)題。

• 頭部壓縮，HTTP1.1的header帶有大量信息，而且每次都要重復(fù)發(fā)送；HTTP2.0 把header從數(shù)據(jù)中分離，并封裝成頭幀和數(shù)據(jù)幀，使用特定算法壓縮頭幀，有效減少頭信息大小。并且HTTP2.0在客戶端和服務(wù)器端記錄了之前發(fā)送的鍵值對(duì)，對(duì)于相同的數(shù)據(jù)，不會(huì)重復(fù)發(fā)送。比如請(qǐng)求a發(fā)送了所有的頭信息字段，請(qǐng)求b則只需要發(fā)送差異數(shù)據(jù)，這樣可以減少冗余數(shù)據(jù)，降低開(kāi)銷(xiāo)。

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

HTTPS與HTTP的區(qū)別？

1. HTTP是超文本傳輸協(xié)議，信息是明文傳輸；HTTPS則是具有安全性的ssl加密傳輸協(xié)議。
2. HTTP和HTTPS用的端口不一樣，HTTP端口是80，HTTPS是443。
3. HTTPS協(xié)議需要到CA機(jī)構(gòu)申請(qǐng)證書(shū)，一般需要一定的費(fèi)用。
4. HTTP運(yùn)行在TCP協(xié)議之上；HTTPS運(yùn)行在SSL協(xié)議之上，SSL運(yùn)行在TCP協(xié)議之上。

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

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

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

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

1. CA使用證書(shū)簽名算法對(duì)證書(shū)內(nèi)容進(jìn)行hash運(yùn)算。
2. 對(duì)hash后的值用CA的私鑰加密，得到數(shù)字簽名。

瀏覽器驗(yàn)證過(guò)程：

1. 獲取證書(shū)，得到證書(shū)內(nèi)容、證書(shū)簽名算法和數(shù)字簽名。
2. 用CA機(jī)構(gòu)的公鑰對(duì)數(shù)字簽名解密（由于是瀏覽器信任的機(jī)構(gòu)，所以瀏覽器會(huì)保存它的公鑰）。
3. 用證書(shū)里的簽名算法對(duì)證書(shū)內(nèi)容進(jìn)行hash運(yùn)算。
4. 比較解密后的數(shù)字簽名和對(duì)證書(shū)內(nèi)容做hash運(yùn)算后得到的哈希值，相等則表明證書(shū)可信。

HTTPS原理

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

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

   

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

   

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

   

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

   

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

   

6. 開(kāi)始傳輸數(shù)據(jù)，使用同一個(gè)對(duì)稱密鑰來(lái)加解密。

   

DNS 的解析過(guò)程？

1. 瀏覽器搜索自己的DNS緩存
2. 若沒(méi)有，則搜索操作系統(tǒng)中的DNS緩存和hosts文件
3. 若沒(méi)有，則操作系統(tǒng)將域名發(fā)送至本地域名服務(wù)器，本地域名服務(wù)器查詢自己的DNS緩存，查找成功則返回結(jié)果，否則依次向根域名服務(wù)器、頂級(jí)域名服務(wù)器、權(quán)限域名服務(wù)器發(fā)起查詢請(qǐng)求，最終返回IP地址給本地域名服務(wù)器
4. 本地域名服務(wù)器將得到的IP地址返回給操作系統(tǒng)，同時(shí)自己也將IP地址緩存起來(lái)
5. 操作系統(tǒng)將 IP 地址返回給瀏覽器，同時(shí)自己也將IP地址緩存起來(lái)
6. 瀏覽器得到域名對(duì)應(yīng)的IP地址

瀏覽器中輸入U(xiǎn)RL返回頁(yè)面過(guò)程？

1. 解析域名，找到主機(jī) IP。
2. 瀏覽器利用 IP 直接與網(wǎng)站主機(jī)通信，三次握手，建立 TCP 連接。瀏覽器會(huì)以一個(gè)隨機(jī)端口向服務(wù)端的 web 程序 80 端口發(fā)起 TCP 的連接。
3. 建立 TCP 連接后，瀏覽器向主機(jī)發(fā)起一個(gè)HTTP請(qǐng)求。
4. 服務(wù)器響應(yīng)請(qǐng)求，返回響應(yīng)數(shù)據(jù)。
5. 瀏覽器解析響應(yīng)內(nèi)容，進(jìn)行渲染，呈現(xiàn)給用戶。

Cookie和Session的區(qū)別？

• 作用范圍不同，Cookie 保存在客戶端，Session 保存在服務(wù)器端。
• 有效期不同，Cookie 可設(shè)置為長(zhǎng)時(shí)間保持，比如我們經(jīng)常使用的默認(rèn)登錄功能，Session 一般失效時(shí)間較短，客戶端關(guān)閉或者 Session 超時(shí)都會(huì)失效。
• 隱私策略不同，Cookie 存儲(chǔ)在客戶端，容易被竊取；Session 存儲(chǔ)在服務(wù)端，安全性相對(duì) Cookie 要好一些。
• 存儲(chǔ)大小不同， 單個(gè) Cookie 保存的數(shù)據(jù)不能超過(guò) 4K；對(duì)于 Session 來(lái)說(shuō)存儲(chǔ)沒(méi)有上限，但出于對(duì)服務(wù)器的性能考慮，Session 內(nèi)不要存放過(guò)多的數(shù)據(jù)，并且需要設(shè)置 Session 刪除機(jī)制。

什么是對(duì)稱加密和非對(duì)稱加密？

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

非對(duì)稱加密：它需要生成兩個(gè)密鑰，公鑰和私鑰。公鑰是公開(kāi)的，任何人都可以獲得，而私鑰是私人保管的。公鑰負(fù)責(zé)加密，私鑰負(fù)責(zé)解密；或者私鑰負(fù)責(zé)加密，公鑰負(fù)責(zé)解密。這種加密算法安全性更高，但是計(jì)算量相比對(duì)稱加密大很多，加密和解密都很慢。常見(jiàn)的非對(duì)稱算法有RSA和DSA。