資料包損壞怎麼恢復

1. 網路體系

1.1 應用層

應用層（application-layer）的任務是透過應用程序間的互動來完成特定網路應用。應用層協議定義的是應用程序（程序：主機中正在執行的程式）間的通訊和互動的規則。對於不同的網路應用需要不同的應用層協議。在網際網路中應用層協議很多，如域名系統DNS，支援全球資訊網應用的 HTTP協議，支援電子郵件的 SMTP協議等等。我們把應用層互動的資料單元稱為報文。

1.1.1 域名系統

域名系統（Domain Name System縮寫 DNS，Domain Name被譯為域名）是因特網的一項核心服務，它作為可以將域名和IP地址相互對映的一個分散式資料庫，能夠使人更方便的訪問網際網路，而不用去記住能夠被機器直接讀取的IP數串。（百度百科）例如：一個公司的 Web 網站可看作是它在網上的門戶，而域名就相當於其門牌地址，通常域名都使用該公司的名稱或簡稱。例如上面提到的微軟公司的域名，類似的還有：IBM 公司的域名是 www。ibm。com、Oracle 公司的域名是 www。oracle。com、Cisco公司的域名是 www。cisco。com 等。

1.1.2 HTTP協議

超文字傳輸協議（HTTP，HyperText Transfer Protocol）是網際網路上應用最為廣泛的一種網路協議。所有的 WWW（全球資訊網） 檔案都必須遵守這個標準。設計 HTTP 最初的目的是為了提供一種釋出和接收 HTML 頁面的方法。

1.2 運輸層

運輸層（transport layer）的主要任務就是負責向兩臺主機程序之間的通訊提供通用的資料傳輸服務。應用程序利用該服務傳送應用層報文。“通用的”是指並不針對某一個特定的網路應用，而是多種應用可以使用同一個運輸層服務。由於一臺主機可同時執行多個執行緒，因此運輸層有複用和分用的功能。所謂複用就是指多個應用層程序可同時使用下面運輸層的服務，分用和複用相反，是運輸層把收到的資訊分別交付上面應用層中的相應程序。

運輸層主要使用以下兩種協議：

傳輸控制協議 TCP（Transmission Control Protocol）——提供面向連線的，可靠的資料傳輸服務。

使用者資料協議 UDP（User Datagram Protocol）——提供無連線的，盡最大努力的資料傳輸服務（不保證資料傳輸的可靠性）。

1.3 網路層

在 計算機網路中進行通訊的兩個計算機之間可能會經過很多個數據鏈路，也可能還要經過很多通訊子網。網路層的任務就是選擇合適的網間路由和交換結點， 確保資料及時傳送。 在傳送資料時，網路層把運輸層產生的報文段或使用者資料報封裝成分組和包進行傳送。在 TCP/IP 體系結構中，由於網路層使用 IP 協議，因此分組也叫 IP 資料報 ，簡稱 資料報。

這裡要注意：不要把運輸層的“使用者資料報 UDP ”和網路層的“ IP 資料報”弄混。另外，無論是哪一層的資料單元，都可籠統地用“分組”來表示。

這裡強調指出，網路層中的“網路”二字已經不是我們通常談到的具體網路，而是指計算機網路體系結構模型中第三層的名稱。

網際網路是由大量的異構（heterogeneous）網路透過路由器（router）相互連線起來的。網際網路使用的網路層協議是無連線的網際協議（Internet Protocol）和許多路由選擇協議，因此網際網路的網路層也叫做網際層或IP層。

1.4 資料鏈路層

資料鏈路層（data link layer）通常簡稱為鏈路層。兩臺主機之間的資料傳輸，總是在一段一段的鏈路上傳送的，這就需要使用專門的鏈路層的協議。 在兩個相鄰節點之間傳送資料時，資料鏈路層將網路層交下來的 IP 資料報組裝成幀，在兩個相鄰節點間的鏈路上傳送幀。每一幀包括資料和必要的控制資訊（如同步資訊，地址資訊，差錯控制等）。

在接收資料時，控制資訊使接收端能夠知道一個幀從哪個位元開始和到哪個位元結束。這樣，資料鏈路層在收到一個幀後，就可從中提出資料部分，上交給網路層。 控制資訊還使接收端能夠檢測到所收到的幀中有無差錯。如果發現差錯，資料鏈路層就簡單地丟棄這個出了差錯的幀，以避免繼續在網路中傳送下去白白浪費網路資源。如果需要改正資料在鏈路層傳輸時出現差錯（這就是說，資料鏈路層不僅要檢錯，而且還要糾錯），那麼就要採用可靠性傳輸協議來糾正出現的差錯。這種方法會使鏈路層的協議複雜些。

1.5 物理層

在物理層上所傳送的資料單位是位元。

物理層（physical layer）的作用是實現相鄰計算機節點之間位元流的透明傳送，儘可能遮蔽掉具體傳輸介質和物理裝置的差異， 使其上面的資料鏈路層不必考慮網路的具體傳輸介質是什麼。“透明傳送位元流”表示經實際電路傳送後的位元流沒有發生變化，對傳送的位元流來說，這個電路好像是看不見的。

在網際網路使用的各種協中最重要和最著名的就是 TCP/IP 兩個協議。現在人們經常提到的TCP/IP並不一定單指TCP和IP這兩個具體的協議，而往往表示網際網路所使用的整個TCP/IP協議族。

2. TCP

為了準確無誤地把資料送達目標處，TCP協議採用了三次握手策略。

2.1 三次握手圖解

第一次握手：建立連線時，客戶端傳送syn包（syn=j）到伺服器，並進入SYN_SENT狀態，等待伺服器確認；SYN：同步序列編號（Synchronize Sequence Numbers）。

第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也傳送一個SYN包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；

第三次握手：客戶端收到伺服器的SYN+ACK包，向伺服器傳送確認包ACK（ack=k+1），此包傳送完畢，客戶端和伺服器進入ESTABLISHED（TCP連線成功）狀態，完成三次握手。

用自己的理解就是：

第一次握手：客戶端發起：“喂，能聽到嗎”

第二次握手：伺服器端迴應：“聽得到，你能挺到我麼”

第三次握手：客戶端：“聽得到，我們可以發起通話了”

2.2 為什麼要三次握手

三次握手的目的是建立可靠的通訊通道，說到通訊，簡單來說就是資料的傳送與接收，而三次握手最主要的目的就是雙方確認自己與對方的傳送與接收是正常的。

第一次握手：Client 什麼都不能確認；Server 確認了對方傳送正常，自己接收正常

第二次握手：Client 確認了：自己傳送、接收正常，對方傳送、接收正常；Server 確認了：對方傳送正常，自己接收正常

第三次握手：Client 確認了：自己傳送、接收正常，對方傳送、接收正常；Server 確認了：自己傳送、接收正常，對方傳送、接收正常

所以三次握手就能確認雙發收發功能都正常，缺一不可。

2.3 第二次握手中回傳了ACK，為什麼還要回傳SYN

接收端傳回傳送端所傳送的ACK是為了告訴客戶端，我接收到的資訊確實就是你所傳送的訊號了，這表明從客戶端到服務端的通訊是正常的。而回傳SYN則是為了建立並確認從服務端到客戶端的通訊。”

SYN 同步序列編號（Synchronize Sequence Numbers） 是 TCP/IP 建立連線時使用的握手訊號。在客戶機和伺服器之間建立正常的 TCP 網路連線時，客戶機首先發出一個 SYN 訊息，伺服器使用 SYN-ACK 應答表示接收到了這個訊息，最後客戶機再以 ACK（Acknowledgement）訊息響應。這樣在客戶機和伺服器之間才能建立起可靠的 TCP 連線，資料才可以在客戶機和伺服器之間傳遞。

2.4 為什麼要四次揮手

斷開一個 TCP 連線則需要“四次揮手”：

客戶端-傳送一個 FIN，用來關閉客戶端到伺服器的資料傳送

伺服器-收到這個 FIN，它發回一 個 ACK，確認序號為收到的序號加1 。和 SYN 一樣，一個 FIN 將佔用一個序號

伺服器-關閉與客戶端的連線，傳送一個FIN給客戶端

客戶端-發回 ACK 報文確認，並將確認序號設定為收到序號加1

用我自己的理解就是：

客戶端：“我打算關閉了！”

服務端回訊息：“你的訊息我收到了！但是我活還沒幹完，等我一會！”

服務端：“好了，我活幹完了！”

客戶端：“好的，我結束通話了！”——客戶端同時等待一段時間後關閉，而服務端收到訊息後立即關閉

3. TCP和UDP的區別

UDP 在傳送資料之前不需要先建立連線，遠地主機在收到 UDP 報文後，不需要給出任何確認。雖然 UDP 不提供可靠交付，但在某些情況下 UDP 確是一種最有效的工作方式（一般用於即時通訊），比如： QQ 語音、 QQ 影片 、直播等等

TCP 提供面向連線的服務。在傳送資料之前必須先建立連線，資料傳送結束後要釋放連線。 TCP 不提供廣播或多播服務。由於 TCP 要提供可靠的，面向連線的傳輸服務（TCP的可靠體現在TCP在傳遞資料之前，會有三次握手來建立連線，而且在資料傳遞時，有確認、視窗、重傳、擁塞控制機制，在資料傳完後，還會斷開連線用來節約系統資源），這一難以避免增加了許多開銷，如確認，流量控制，計時器以及連線管理等。這不僅使協議資料單元的首部增大很多，還要佔用許多處理機資源。TCP 一般用於檔案傳輸、傳送和接收郵件、遠端登入等場景。

4. TCP 如何保證可靠傳輸

應用資料被分割成 TCP 認為最適合傳送的資料塊。

TCP 給傳送的每一個包進行編號，接收方對資料包進行排序，把有序資料傳送給應用層。

校驗和： TCP 將保持它首部和資料的檢驗和。這是一個端到端的檢驗和，目的是檢測資料在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP 將丟棄這個報文段和不確認收到此報文段。

TCP 的接收端會丟棄重複的資料。

流量控制： TCP 連線的每一方都有固定大小的緩衝空間，TCP的接收端只允許傳送端傳送接收端緩衝區能接納的資料。當接收方來不及處理傳送方的資料，能提示傳送方降低傳送的速率，防止包丟失。TCP 使用的流量控制協議是可變大小的滑動視窗協議。 （TCP 利用滑動視窗實現流量控制）

擁塞控制： 當網路擁塞時，減少資料的傳送。

ARQ協議： 也是為了實現可靠傳輸的，它的基本原理就是每發完一個分組就停止傳送，等待對方確認。在收到確認後再發下一個分組。

超時重傳： 當 TCP 發出一個段後，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段。

4.1 ARQ協議

自動重傳請求（Automatic Repeat-reQuest，ARQ）是OSI模型中資料鏈路層和傳輸層的錯誤糾正協議之一。它透過使用確認和超時這兩個機制，在不可靠服務的基礎上實現可靠的資訊傳輸。如果傳送方在傳送後一段時間之內沒有收到確認幀，它通常會重新發送。ARQ包括停止等待ARQ協議和連續ARQ協議。

4.1.1 停止等待ARQ協議

停止等待協議是為了實現可靠傳輸的，它的基本原理就是每發完一個分組就停止傳送，等待對方確認（回覆ACK）。如果過了一段時間（超時時間後），還是沒有收到 ACK 確認，說明沒有傳送成功，需要重新發送，直到收到確認後再發下一個分組。

在停止等待協議中，若接收方收到重複分組，就丟棄該分組，但同時還要傳送確認。

優缺點：

優點： 簡單

缺點： 通道利用率低，等待時間長

1） 無差錯情況：

傳送方傳送分組，接收方在規定時間內收到，並且回覆確認。傳送方再次傳送。

2） 出現差錯情況（超時重傳）：

停止等待協議中超時重傳是指只要超過一段時間仍然沒有收到確認，就重傳前面傳送過的分組（認為剛才傳送過的分組丟失了）。因此每傳送完一個分組需要設定一個超時計時器，其重傳時間應比資料在分組傳輸的平均往返時間更長一些。這種自動重傳方式常稱為 自動重傳請求 ARQ 。另外在停止等待協議中若收到重複分組，就丟棄該分組，但同時還要傳送確認。連續 ARQ 協議 可提高通道利用率。傳送維持一個傳送視窗，凡位於傳送視窗內的分組可連續傳送出去，而不需要等待對方確認。接收方一般採用累積確認，對按序到達的最後一個分組傳送確認，表明到這個分組位置的所有分組都已經正確收到了。

3） 確認丟失和確認遲到

確認丟失 ：確認訊息在傳輸過程丟失。當A傳送M1訊息，B收到後，B向A傳送了一個M1確認訊息，但卻在傳輸過程中丟失。而A並不知道，在超時計時過後，A重傳M1訊息，B再次收到該訊息後採取以下兩點措施：1。 丟棄這個重複的M1訊息，不向上層交付。 2。 向A傳送確認訊息。（不會認為已經發送過了，就不再發送。A能重傳，就證明B的確認訊息丟失）。

確認遲到 ：確認訊息在傳輸過程中遲到。A傳送M1訊息，B收到併發送確認。在超時時間內沒有收到確認訊息，A重傳M1訊息，B仍然收到並繼續傳送確認訊息（B收到了2份M1）。此時A收到了B第二次傳送的確認訊息。接著傳送其他資料。過了一會，A收到了B第一次傳送的對M1的確認訊息（A也收到了2份確認訊息）。處理如下：1。 A收到重複的確認後，直接丟棄。2。 B收到重複的M1後，也直接丟棄重複的M1。

4.1.2 連續ARQ協議

連續 ARQ 協議可提高通道利用率。傳送方維持一個傳送視窗，凡位於傳送視窗內的分組可以連續傳送出去，而不需要等待對方確認。接收方一般採用累計確認，對按序到達的最後一個分組傳送確認，表明到這個分組為止的所有分組都已經正確收到了。

優缺點：

優點： 通道利用率高，容易實現，即使確認丟失，也不必重傳。

缺點： 不能向傳送方反映出接收方已經正確收到的所有分組的資訊。 比如：傳送方傳送了 5條 訊息，中間第三條丟失（3號），這時接收方只能對前兩個傳送確認。傳送方無法知道後三個分組的下落，而只好把後三個全部重傳一次。這也叫 Go-Back-N（回退 N），表示需要退回來重傳已經發送過的 N 個訊息。

4.2 滑動視窗和流量控制

TCP 利用滑動視窗實現流量控制。流量控制是為了控制傳送方傳送速率，保證接收方來得及接收。 接收方傳送的確認報文中的視窗欄位可以用來控制傳送方視窗大小，從而影響傳送方的傳送速率。將視窗欄位設定為 0，則傳送方不能傳送資料。

4.3 擁塞控制

在某段時間，若對網路中某一資源的需求超過了該資源所能提供的可用部分，網路的效能就要變壞。這種情況就叫擁塞。擁塞控制就是為了防止過多的資料注入到網路中，這樣就可以使網路中的路由器或鏈路不致過載。擁塞控制所要做的都有一個前提，就是網路能夠承受現有的網路負荷。擁塞控制是一個全域性性的過程，涉及到所有的主機，所有的路由器，以及與降低網路傳輸效能有關的所有因素。相反，流量控制往往是點對點通訊量的控制，是個端到端的問題。流量控制所要做到的就是抑制傳送端傳送資料的速率，以便使接收端來得及接收。

為了進行擁塞控制，TCP 傳送方要維持一個 擁塞視窗（cwnd） 的狀態變數。擁塞控制視窗的大小取決於網路的擁塞程度，並且動態變化。傳送方讓自己的傳送視窗取為擁塞視窗和接收方的接受視窗中較小的一個。

TCP的擁塞控制採用了四種演算法，即 慢開始 、 擁塞避免 、快重傳 和 快恢復。在網路層也可以使路由器採用適當的分組丟棄策略（如主動佇列管理 AQM），以減少網路擁塞的發生。

慢開始： 慢開始演算法的思路是當主機開始傳送資料時，如果立即把大量資料位元組注入到網路，那麼可能會引起網路阻塞，因為現在還不知道網路的符合情況。經驗表明，較好的方法是先探測一下，即由小到大逐漸增大發送視窗，也就是由小到大逐漸增大擁塞視窗數值。cwnd初始值為1，每經過一個傳播輪次，cwnd加倍。

擁塞避免： 擁塞避免演算法的思路是讓擁塞視窗cwnd緩慢增大，即每經過一個往返時間RTT就把傳送放的cwnd加1。

快重傳與快恢復： 在 TCP/IP 中，快速重傳和恢復（fast retransmit and recovery，FRR）是一種擁塞控制演算法，它能快速恢復丟失的資料包。沒有 FRR，如果資料包丟失了，TCP 將會使用定時器來要求傳輸暫停。在暫停的這段時間內，沒有新的或複製的資料包被髮送。有了 FRR，如果接收機接收到一個不按順序的資料段，它會立即給傳送機傳送一個重複確認。如果傳送機接收到三個重複確認，它會假定確認件指出的資料段丟失了，並立即重傳這些丟失的資料段。有了 FRR，就不會因為重傳時要求的暫停被耽誤。 當有單獨的資料包丟失時，快速重傳和恢復（FRR）能最有效地工作。當有多個數據信息包在某一段很短的時間內丟失時，它則不能很有效地工作。

5. 在瀏覽器中輸入url地址 ->> 顯示主頁的過程

上圖有一個錯誤，請注意，是OSPF不是OPSF。 OSPF（Open Shortest Path First，ospf）開放最短路徑優先協議，是由Internet工程任務組開發的路由選擇協議

總體來說分為以下幾個過程：

DNS解析

TCP連線

傳送HTTP請求

伺服器處理請求並返回HTTP報文

瀏覽器解析渲染頁面

連線結束

6. 狀態碼

7. 各種協議與http協議之間的關係

8. http 長連線和短連線

在HTTP/1。0中預設使用短連線。也就是說，客戶端和伺服器每進行一次HTTP操作，就建立一次連線，任務結束就中斷連線。當客戶端瀏覽器訪問的某個HTML或其他型別的Web頁中包含有其他的Web資源（如JavaScript檔案、影象檔案、CSS檔案等），每遇到這樣一個Web資源，瀏覽器就會重新建立一個HTTP會話。

而從HTTP/1。1起，預設使用長連線，用以保持連線特性。使用長連線的HTTP協議，會在響應頭加入這行程式碼：

Connection：keep-alive

在使用長連線的情況下，當一個網頁開啟完成後，客戶端和伺服器之間用於傳輸HTTP資料的TCP連線不會關閉，客戶端再次訪問這個伺服器時，會繼續使用這一條已經建立的連線。Keep-Alive不會永久保持連線，它有一個保持時間，可以在不同的伺服器軟體（如Apache）中設定這個時間。實現長連線需要客戶端和服務端都支援長連線。

HTTP協議的長連線和短連線，實質上是TCP協議的長連線和短連線。

9. HTTP是不儲存狀態的協議,如何儲存使用者狀態?

HTTP 是一種不儲存狀態，即無狀態（stateless）協議。也就是說 HTTP 協議自身不對請求和響應之間的通訊狀態進行儲存。那麼我們儲存使用者狀態呢？Session 機制的存在就是為了解決這個問題，Session 的主要作用就是透過服務端記錄使用者的狀態。典型的場景是購物車，當你要新增商品到購物車的時候，系統不知道是哪個使用者操作的，因為 HTTP 協議是無狀態的。服務端給特定的使用者建立特定的 Session 之後就可以標識這個使用者並且跟蹤這個使用者了（一般情況下，伺服器會在一定時間內儲存這個 Session，過了時間限制，就會銷燬這個Session）。

在服務端儲存 Session 的方法很多，最常用的就是記憶體和資料庫（比如是使用記憶體資料庫redis儲存）。既然 Session 存放在伺服器端，那麼我們如何實現 Session 跟蹤呢？大部分情況下，我們都是透過在 Cookie 中附加一個 Session ID 來方式來跟蹤。

Cookie 被禁用怎麼辦？

最常用的就是利用 URL 重寫把 Session ID 直接附加在URL路徑的後面。

10. cookie 和 session

Cookie 和 Session都是用來跟蹤瀏覽器使用者身份的會話方式，但是兩者的應用場景不太一樣。

Cookie 一般用來儲存使用者資訊

①比如我們在 Cookie 中儲存已經登入過得使用者資訊，下次訪問網站的時候頁面可以自動幫你登入的一些基本資訊給填了；

②一般的網站都會有保持登入也就是說下次你再訪問網站的時候就不需要重新登入了，這是因為使用者登入的時候我們可以存放了一個 Token 在 Cookie 中，下次登入的時候只需要根據 Token 值來查詢使用者即可（為了安全考慮，重新登入一般要將 Token 重寫）；

③登入一次網站後訪問網站其他頁面不需要重新登入。

Session 的主要作用就是透過服務端記錄使用者的狀態。

典型的場景是購物車，當你要新增商品到購物車的時候，系統不知道是哪個使用者操作的，因為 HTTP 協議是無狀態的。服務端給特定的使用者建立特定的 Session 之後就可以標識這個使用者並且跟蹤這個使用者了。

Cookie 儲存在客戶端（瀏覽器端）中，而Session儲存在伺服器上，相對來說 Session 安全性更高。如果要在 Cookie 中儲存一些敏感資訊，不要直接寫入 Cookie 中，最好能將 Cookie 資訊加密然後使用到的時候再去伺服器端解密。

11. http1.0和1.1 有什麼區別

長連線 ： 在HTTP/1。0中，預設使用的是短連線，也就是說每次請求都要重新建立一次連線。HTTP 是基於TCP/IP協議的，每一次建立或者斷開連線都需要三次握手四次揮手的開銷，如果每次請求都要這樣的話，開銷會比較大。因此最好能維持一個長連線，可以用個長連線來發多個請求。HTTP 1。1起，預設使用長連線 ，預設開啟Connection： keep-alive。 HTTP/1。1的持續連線有非流水線方式和流水線方式 。流水線方式是客戶在收到HTTP的響應報文之前就能接著傳送新的請求報文。與之相對應的非流水線方式是客戶在收到前一個響應後才能傳送下一個請求。

錯誤狀態響應碼 ：在HTTP1。1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突；410（Gone）表示伺服器上的某個資源被永久性的刪除。

快取處理 ：在HTTP1。0中主要使用header裡的If-Modified-Since，Expires來做為快取判斷的標準，HTTP1。1則引入了更多的快取控制策略例如Entity tag，If-Unmodified-Since， If-Match， If-None-Match等更多可供選擇的快取頭來控制快取策略。

頻寬最佳化及網路連線的使用 ：HTTP1。0中，存在一些浪費頻寬的現象，例如客戶端只是需要某個物件的一部分，而伺服器卻將整個物件送過來了，並且不支援斷點續傳功能，HTTP1。1則在請求頭引入了range頭域，它允許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用頻寬和連線。

12. URI和URL

URI（Uniform Resource Identifier） 是統一資源標誌符，可以唯一標識一個資源。

URL（Uniform Resource Location） 是統一資源定位符，可以提供該資源的路徑。它是一種具體的 URI，即 URL 可以用來標識一個資源，而且還指明瞭如何 locate 這個資源。

URI的作用像身份證號一樣，URL的作用更像家庭住址一樣。URL是一種具體的URI，它不僅唯一標識資源，而且還提供了定位該資源的資訊。

13. HTTP和HTTPS

埠 ：HTTP的URL由“http：//”起始且預設使用埠80，而HTTPS的URL由“https：//”起始且預設使用埠443。

安全性和資源消耗： HTTP協議執行在TCP之上，所有傳輸的內容都是明文，客戶端和伺服器端都無法驗證對方的身份。HTTPS是執行在SSL/TLS之上的HTTP協議，SSL/TLS 執行在TCP之上。所有傳輸的內容都經過加密，加密採用對稱加密，但對稱加密的金鑰用伺服器方的證書進行了非對稱加密。所以說，HTTP 安全性沒有 HTTPS高，但是 HTTPS 比HTTP耗費更多伺服器資源。

對稱加密：金鑰只有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密演算法有DES、AES等；

小知識點：

對稱加密：金鑰只有一個，加密的解密都是用的同一個金鑰，加密解密的速度快，典型的對稱加密有AES。

非對稱加密：金鑰成對出現，一般加密用是私鑰，解密用的是公鑰，透過私鑰是無法推算出公鑰的，公鑰也無法推算出私鑰，加解密的速度相對對稱加密來說慢，典型的非對稱有RSA。