HTTPS和TCP協議三次握手設計

1. 咱們的TCP 三次握手大概是長這樣

 

 

2.那麼爲何 TCP 要採起三次握手，而不是兩次或其餘

　　首先咱們要知道握手的目的：

• 爲了保證通信雙方創建的鏈接是可靠的。
• 同時，爲了保證性能，握手的次數要求儘量少。

　　那麼什麼纔算是鏈接可靠？

• 通信雙方創建的鏈接可靠」就是要確保雙方的發送和接收功能都正常。

　　如下圖爲例，在握手前，雙方的發送和接收能力還沒有確認。

 

　　第一次握手：

　　客戶端向服務端發送信息。當服務端接收到信息後，服務端能夠明確接收功能是正常的。

 

 

　　第二次握手：

　　服務端向客戶端發送信息做爲應答。當客戶端接收到信息後，客戶端能夠明確發送和接受功能都正常。

 

　　第三次握手：

　　客戶端向服務端發送信息，當服務端接收到信息後，服務端能夠明確發送功能是正常的。

 　　經過三次握手，就能明確雙方的收發功能均正常，也就是說，保證了創建的鏈接是可靠的。並且，由上可見，三次是確保鏈接可靠的最少次數，再就多餘。

 

3.都知道HTTPS是比HTTP更安全的鏈接方式，但爲何HTTPS會更安全？

• 由於HTTPS加入了SSL因此更安全，但爲何是SSL？

 

3.1咱們先了解一下什麼事對稱加密，給你們講一個故事。

古時候有兩我的，一直經過寫信相互聯繫

 

但他們總以爲郵差的樣子很賊，懼怕本身信件被偷看。

因而一次見面的時候，找來一個帶鎖的盒子和兩把鑰匙，商定每次寄信前都先鎖上信件。

 

經過這種方式，他們以爲通訊已經足夠安全了。

直到有一天，其中一我的把鑰匙弄丟了。

他想要發信通知另外一人拷貝一把鑰匙發回來，但深想，他無法將「拷貝一把新鑰匙給我」這番話進行加密，也無法保證中途鑰匙會不會被盜竊啊。

換言之，要繼續維持原來的通訊方式，只能約對方出來見面再拿新的鑰匙了。

若是將這個問題放到當今的互聯網，通信前都要求兩我的先見面取鑰匙，那顯然是不可能的。

因而有了非對稱加密

 

3.2非對稱加密

針對於上述鑰匙交換的問題，人們想出了非對稱加密的方式，簡單來講，非對稱加密有公鑰和密鑰，公鑰能夠公開由任何人持有，而私鑰由本身持有。公鑰加密的信息只能由對應的私密解密，一樣，私鑰加密的信息只能由對應的公鑰解密。

利用這個特性，回到上面的例子，能夠進行下面的通訊方式：

1. 先將公鑰交給郵差發送給對方

 

2. 對方使用公鑰將信息加密以後將信息返回

 

3. 收到信件後，利用私鑰對信息進行解密

 

這樣就能保證信件的保密傳遞了。

而因爲公鑰是容許任何人知道的，若是用私鑰將信息加密，被別人竊取後，能夠經過公開的公鑰來獲取信息，因此通訊前必定是先獲取對方的公鑰，只傳遞公鑰加密後的信息。

這樣足夠安全了嗎？並不。

若是有人截取通訊，假裝成其中一方，發送僞造方的公鑰，就能竊取通信信息了。

 

認證機構和數字證書

爲了保證通訊者獲取的公鑰並無被惡意替換，能夠經過第三方認證機構來確認公鑰是否可信。

那麼這個認證和檢驗的過程是怎樣實現的呢？

首先，通訊的一方須要先向認證機構認證本身的身份。將本身的通信公鑰和一些我的信息發送給認證結構，而後認證機構利用本身的私鑰來對這些信息加密，生成一份數字證書，這份證書就是用來證實這我的的身份的。

 

在瀏覽器中，系統默認就會裝有一些認證機構的公鑰，稱之爲頂級證書。

在通信的時候，先發送數字證書，而後接收方利用頂級證書對這份數字證書進行解密，得到通信的另外一方的公鑰，同時利用解密出來的信息進行比對，從而檢驗出解析出來的公鑰是否屬於通信方。

流程以下：

 

這樣，若是頂級證書沒有被惡意替換，整個通信流程就能夠認爲是安全的。

 

3.3優化通信性能

再回顧上面的流程，

對稱加密的弊端是難以安全地傳遞密鑰。

非對稱加密的弊端是加密和解密的花費時間長，若是通信中全部數據都使用非對稱加密，將會引發性能問題。

若是結合二者，使用機構認證和非對稱加密的方式解決密鑰傳遞的問題，使用對稱加密的方式來解決加解密費時問題，就能達到性能優化的目的。

若是通信雙方分別是瀏覽器和服務器，通信流程將以下：

1. 服務器先從認證機構申請數字證書

 

2. 瀏覽器訪問網站，服務器返回數字證書

 

3.1. 瀏覽器利用內置的頂級證書解析服務器返回的數字證書獲得服務器的公鑰。

3.2. 而後瀏覽器生成一個對稱加密的密鑰。

3.3. 再利用服務器的公鑰進行加密。

 

瀏覽器將加密後的密鑰發送給服務器，服務器利用本身的私鑰將其解密獲得對稱加密的密鑰，雙方將使用該對稱加密的密鑰進行通信。

 

 

以上~