Android 網絡編程之HTTPS詳解

前言：HTTPS涉及相關的知識，老是很難的將其概括總結起來，本文旨在帶你學習詳細的HTTPS相關知識點，看完本文後，你會了解到如下相關知識點；

• HTTPS的工做原理
• HTTPS爲何要這樣設計
• 密碼學相關原理

本文篇幅較長，建議收藏，慢慢食用，那麼接下來讓咱們開啓HTTPS的學習之旅吧！

本章目錄

• 一、HTTPS是什麼？
• 二、什麼是加密？
• 三、什麼是對稱加密？
• 四、什麼是非對稱加密？
• 五、數字證書
• 六、什麼是SSL/TSL？

本章結構圖

一、HTTPS是什麼？

1.一、HTTPS的介紹

HTTPS簡稱：超文本傳輸安全協議（英語：HyperText Transfer Protocol Secure，縮寫：HTTPS）；

HTTPS是基於HTTP上擴展出的一種安全的傳輸協議，在很早以前，HTTP的不安全爲人所詬病，而一些金融領域，涉及到敏感信息的通訊，HTTP已經遠遠不知足需求了，因此安全的傳輸協議已經迫在眉睫了；

HTTPS協議發明出來的主要目的就是保護互聯網的傳輸過程當中，保護數據的隱私和完整性，最開始是由網景公司（Netscape）在1994年首次提出的協議，後來就擴展到互聯網上了；

1.二、HTTP的痛點

HTTP協議，是咱們目前使用最多，也是最普遍的協議，幾乎咱們無時無刻不在使用着它，可是HTTP有一個致命的缺點，就是不能進行安全的傳輸；

網絡的世界是很複雜的，若是有人想要竊取或者篡改某些你要傳輸的數據，那麼在HTTP協議上是很容易出現的，好比登陸、轉帳這些極其敏感的操做，若是不使用安全的傳輸協議，那麼就很容易被不法分子所利用，致使損失慘重；

那麼安全的傳輸協議也就天然而然的誕生了，而想保證安全性，那麼加密這一塊，是必不可少的，而HTTPS就是基於這些加密算法，來保證了安全傳輸；

1.三、HTTPS是怎麼工做的？

HTTPS是基於HTTP的基礎上進行工做的，經過加密協議對通訊進行加密，該協議稱之爲傳輸層安全性（TLS），之前是被稱做爲SSL；

該協議經過協商密鑰，以及驗證身份的方式，來保證通訊的雙方數據不被獲取到，以此來保證數據傳輸的安全性；

而這其中涉及到不少算法，好比哈希算法，對稱加密算法，非對稱加密算法，數字證書等相關知識；

接下來咱們來一步步分解，深刻探索；

二、什麼是加密？

2.一、加密

將內容轉換爲沒法識別的密文，這個過程就叫作加密；

好比有一串中文：我是祖國的花朵。

那麼加密後可能就變成：HSUUI&&*768SASKD&7980%8SHOS%^$hUSHHD&6788

那麼上面的那一串密文是沒法直接讀取過來的，必需要經過解密後，才能夠看到內容；

而加密的方式有不少，這裏就先講講幾種主要使用的加密方式；

2.二、哈希

哈希算法是不可逆加密算法；

爲啥叫不可逆呢？

由於加密後的內容是沒法被轉化爲原來的內容的，那麼到這裏你是否會有疑問？

既然加密後不能轉化爲原來的內容，那麼這個加密還有什麼用呢？

不可逆加密的用途，大多都是用於數據校驗，不可逆加密算法有一個很大的特色就是，和原內容強相關，什麼意思呢？

就是說原內容，通過不可逆算法生成的值，是和原內容息息相關的，若是原內容被篡改了一個字符或者幾個字符時，生成的值就和原來的大不相同了；

因此這種特色很是適合於傳輸過程當中的數據校驗，判斷數據在傳輸過程當中是否被篡改了；

可是並不能避免數據被篡改，只是能夠洞察到這種被篡改的狀況；

三、對稱加密

3.一、什麼是對稱加密

對稱加密，簡而言之就加密和解密使用的密鑰是一致的；

也就是說使用對稱加密的雙方，都持有相同的密鑰，用於加密和解密；

下面咱們從一張圖裏能夠形象的看出對稱加密算法加密解密的流程；

對稱加密中，有幾種常見的數學算法，目的是爲了讓被加密的數據儘量的複雜，避免被很容易的po解，那麼經常使用的數學算法有哪些呢？

3.二、對稱加密涉及的數學計算有哪些？

（1） 移位和循環移位
移位就是數碼按照必定的順序進行移動，好比有一段數碼爲12345678，那麼其右移後變成23456781，左移後變成81234567；
（2）置換
將數碼中的數據根據置換表，進行移位，移動後的數據會變得雜亂無章； 好比一段置換表爲：2，4，1，5，3，6； 那麼123456這個數據根據這個置換表，進行置換後，數據就變成了：315246；

固然我這裏只是舉例，實際的置換表有64位，遠遠比這個複雜；

（3）擴展

將數碼中的數據擴展爲比原來更長的數據，能夠利用置換表進行擴展；

（4）壓縮

將數碼中的數據壓縮爲比原來更短的數據，同理能夠利用置換表進行壓縮；

（5）異或 爲二進制布爾代數運算

（6）迭代

進行屢次重複的運算，這在加密算法裏很常見，可讓數據變得更復雜和更難以po解；

3.三、DES算法的工做原理

下面咱們來分析一下最多見的對稱加密算法DES，以及其對應的工做原理；

（1）：DES描述

DES算法全稱爲Data Encryption Standard，即數據加密算法，是IBM公司研發出來的對稱加密算法，DES算法是典型的分組加密算法，也是應用最普遍的對稱加密算法；

（2）：DES工做原理

先來看一張流程圖：

這裏涉及太多複雜的操做，一時半會講不完，這裏就先縮略了，感興趣的能夠看看這位大佬寫的文章：算法科普：神祕的 DES 加密算法

DES非對稱加密算法是最爲常見的分組加密算法，其核心在於置換與移位的數學運算，因爲其加密算法是公開的，那麼密鑰的保密就很是的關鍵了，只要密鑰泄露了，那麼數據就會垂手可得的被po解了；

四、非對稱加密

4.一、非對稱加密是什麼？

非對稱加密，理解起來很簡單，就是加密和解密的密鑰不同，正如這個名稱所說的非對稱；

下面咱們以RSA非對稱加密來舉例；

非對稱加密有兩組密鑰，一組爲公鑰，一組爲私鑰，這裏爲啥要組來稱呼呢？ 這個與非對稱加密的原理有關，請繼續往下看！

非對稱加密的密鑰格式爲（a，b），a和b能夠爲任何整數，好比公鑰（1234，12），私鑰（1234，34）這種；固然我這裏只是舉例，這裏的公鑰和私鑰沒有關聯關係；

上面爲啥要說我這裏隨便寫的沒有關聯關係呢？由於公鑰和私鑰是一一對應的，也就是說用公鑰加密的，只能用對應的私鑰才能解開；

那麼到這裏你是否有疑問了，爲何非對稱的加密和解密的祕鑰不一致？而不和對稱加密同樣，經過算法能夠加密和解密內容；

4.二、RSA非對稱加密算法

下面咱們來說講RSA的加密和解密算法；

假設咱們加密的公鑰爲（n，e）；

加密算法：

( )

RSA的加密算法爲上面這個公式，所謂的加密，就是求這個公式的c，這裏的m表示明文；

這個公式的解讀：m的e次方除以n的餘數爲c，求c的值；

假如咱們的明文m爲12，公鑰爲（3233, 17）；

那麼代入公式後： ( )

那麼獲得的結果c爲：1730，那麼1739就是用公鑰加密後的結果；

接下來來看看解密算法；

假設咱們解密的私鑰爲（n, d）；

解密算法：

( )

RSA的解密算法爲上面這個公式，所謂的解密，就是求這個公式的m，這裏的c表示密文；

這個公式的解讀：c的d次方除以n的餘數爲m，求m的值；

這裏解密的私鑰爲（3233，2753），通過公鑰加密後的密文c爲：1730；

那麼代入公式後： ( )

那麼獲得的結果爲：12；

到這裏RSA的加密解密算法就講完了，RSA的加密解密和對稱加密算法DES還不同，沒有DES的操做那麼複雜，各類對數據進行置換，迭代，逆置換之類的，RSA的加密解密就是簡單粗暴的進行n次方計算，最後求餘數；

這裏只是舉了兩個簡單的密鑰，而實際上的密鑰不可能這麼短，目前已有公開的po解的是768位，比較安全的是1024位，超級安全的是2048位；

那麼到這裏你是否已經明白，爲何RSA非對稱加密算法相對對稱加密算法會比較耗時呢？

這是由於RSA算法的加密解密都會進行屢次的平方，密鑰越長，那麼通過的平方也就越多，所以會致使運算變慢；

4.三、RAS非對稱加密算法的原理

上面咱們講了RSA非對稱加密和解密算法，那麼你是否會有疑問？

兩組不相同的祕鑰，經過不一樣的算法確認將明文加密後，正常解密爲原來的明文，這是怎麼作到的呢？那麼讓咱們帶着疑問繼續看下去；

在開始以前，咱們先來說講非對稱加密涉及的數學原理；

1. 互質關係

什麼是互質關係呢？

解讀：若是兩個正整數，除了1之外，沒有其餘公因子，咱們就稱這兩個數是互質關係（coprime）；

好比15和11，24和19，這個關係相信理解起來並不難；

2. 歐拉函數

什麼是歐拉函數？

請思考一個問題：給出一個正整數，求小於這個正整數的互質數有多少個？

上面這個問題的求證過程就是歐拉函數，歐拉函數是用於求小於某個數的互質數的個數，用來表示；

好比 ，表示10的互質數分別有：9，7，5，3，1，那麼加起來就爲5個；

3. 歐拉定理

歐拉定理指的是：若是有兩個整數a和b互質，那麼下面的公式就會成立；

( )

解讀：a的次方除以b的餘數爲1；就是歐拉函數；

對於歐拉定理的證實比較複雜，這麼咱們就不過多深刻了，以避免跑題；

4. 模反元素

模反元素指的是：若是兩個正整數a和b互質，那麼必定能夠找到整數k，使得 ak-1 被b整除，或者說ak被b除的餘數是1。

公式爲： ( )

歐拉定理能夠用來證實上面的公式必然成立；

如： ( )

那麼到這裏，涉及的數學知識就講完了，接下來咱們就來說講非對稱加密的公鑰和私鑰是怎麼生成的；

密鑰生成步驟：

第一步：隨機選擇兩個互質數p和q；

第二步：將這兩個質數想相乘，那麼獲得的結果爲n；

第三步：求這個結果的歐拉函數，也就是

第四步：隨機選擇一個整數e，e要大於1且小於；

第五步：計算e對於於的模反元素d，也就是求公式： ( );

最終咱們有了六個數據，分別爲：p，q，n，，e，d;

這裏將n和d封裝成公鑰(n,e)，而後將n和d封裝成私鑰(n,d)，固然這裏只是舉例，實際狀況是用ASN.1格式來表示的；

接下來咱們來看看RSA非對稱加密的安全性，由上面生成的密鑰可知，對外公佈的公鑰爲(n,e)，那麼咱們能不能在已知公鑰的狀況下，推導出私鑰呢？

已知n，要解出d的值；

根據上面的步驟五的公式， ( ) ，要求出d的值就得先知道和e的值，才能求出來;

而根據上面的步驟三的公式，，的值得先知道p和q才能求出來；

而要求出p和q的值，就得對n作因數分解，可是對於大整數的分解是極其困難的，目前公佈的被po解的RSA密鑰最長爲768位，而1024位的是比較安全的，2048位是極其安全，4096位是變態安全；

對於私鑰解密公式的證實，這裏就不過多深刻探究了，感興趣的請看這位巨佬寫的兩篇文章，超級詳細；

RSA算法原理（一）
RSA算法原理（二）

五、數字證書

5.一、什麼是數字簽名？

剛看完非對稱加密，接下來咱們來看看數字簽名；

在看下去以前，咱們來思考一個問題，在通訊的雙方，若是發生了第三方攻擊，也就是有黑客截取了主機A發送給主機B的數據，而且進行篡改後，在發送給主機B，而這時候主機B拿到的已經不是主機A發過去的原始數據了，數據已經被篡改了，那麼咱們怎麼避免這種狀況發生呢？

答案是：數字簽名

那麼這裏可能會有疑問了？我使用非對稱加密不就好了嗎，第三方就算截取了個人數據，可是仍是解密不了；

沒錯，非對稱加密雖然能夠防止被po解，可是仍是不能防止被篡改，要是攻擊者，把截取到的密文，修改了幾個字符，那麼接收者經過私鑰解密後的內容就已經不是原來的內容了，因此這種方案仍是不嚴謹；

咱們先來看一下什麼是數字簽名？

數字簽名其實就至關於人類的簽名，數字簽名就是通訊的時候對數據進行簽名，簽名的做用就是通訊的雙方能夠辨識該數據的身份，以避免被僞造身份；

那麼數字簽名是怎麼實現的呢？

假如正在通訊的主機A和主機B，主機A持有私鑰，主機B持有主機A的公鑰；

首先，主機A使用Hash算法對數據生成一段摘要值，而後再用私鑰對這個摘要值加密，並將這個摘要值附在數據後面，發送給主機B；

主機B接收到數據後，使用公鑰對這個摘要進行解密，而後再使用Hash算法對數據生成摘要值，將生成的摘要值，和解密後的摘要值進行比較，若是一致，那麼則認爲該數據持有的人是對的人，而不是被假冒的第三方；

第一種狀況，使用公鑰加密，私鑰解密：

第二種狀況，使用私鑰加密，公鑰解密：

看到這裏，你是否會有疑惑，這兩種狀況是否還存在風險呢？

假如第一種狀況，公鑰被別人盜取了，那麼別人就能夠用這個公鑰來假冒身份進行通訊，而通訊的對方識別不出來；

第二種狀況，私鑰泄露了，那麼同理別人也能夠用這個私鑰來假冒身份進行通訊；

那麼怎麼解決以上這兩種問題呢？

那麼就輪到咱們的主角登場了，那就是：數字證書；

5.二、數字證書

數字證書是什麼？

說的通俗易懂的，數字證書其實就至關於身份證，用於證實你是你，而不是被別人冒充的你，而數字證書的做用，用於在服務器出示證書驗證身份用的；

做用就是爲了不第三方攻擊，也就是別人冒充你去和對方進行通訊，在通訊的時候起到鑑別身份的做用；

數字證書是怎麼起到鑑別身份的做用呢？

數字證書是由一個權威機構頒發的，這個權威機構叫CA，英文全稱：certificate authority，又被稱爲證書中心；

這個CA中心，相似於公安局那種權威機構，給咱們辦理的身份證就是權威的，其餘機構可信任的；

而CA中心就是這種原理，頒發的證書，能夠被瀏覽器和客戶端所信任；

接下來咱們來看看證書都包含着哪些內容？

其實有一個很簡單的方法，打開瀏覽器，輸入百度的地址，而後點擊左上角的鎖頭就能看到百度網站使用的證書，如圖：

從上圖能夠看出，證書主要包含的主要內容有：

下面咱們來看看數字證書是怎麼驗證身份的；

假設瀏覽器和服務器正在進行HTTPS通訊：

首先，服務器會先把他的數字證書發送給瀏覽器，也就是上面圖片這個，可是這個證書的相關內容是被CA的私鑰加密過的；

瀏覽器持有CA內嵌的證書，包含有CA的公鑰，而這個內嵌的證書叫作根證書，瀏覽器收到服務器發送過來的數字證書，那麼就用CA的公鑰對這個證書進行解密，解密成功，則表示該證書可信任，那麼就認爲服務器的身份正常；

而後瀏覽器將驗證解密後的數字證書，會驗證證書的有效期，還有服務器的地址是否正確（避免釣魚網站），提取證書裏服務器的公鑰驗證簽名，若是都驗證經過了，那麼纔會進行正常的通訊，若是驗證不過，那麼就會創建鏈接失敗，或者是提示用戶，該網站不可信，請謹慎訪問，給用戶選擇權；

那麼到這裏你是否會有疑問了？黑客照着這個證書仿照一個不行嗎？這樣不就能夠騙過瀏覽器了？

黑客拿不到CA機構的私鑰，因此無法僞造證書，所以這個問題不成立；

那麼你是否又會有疑問了，黑客去權威機構申請一個證書不就好了嗎？

答案是不行的，爲啥呢? 由於證書的申請須要認證身份的，黑客無法假冒身份去申請證書；

假設瀏覽器和服務器經過非對稱算法來加密數據，那麼下面咱們經過流程圖來看看瀏覽器和服務器是怎麼經過數字證書來校驗身份的；

六、SSL/TSL

6.一、什麼是SSL？

SSL簡稱安全套接字協議，SSL協議是HTTPS的保障，HTTPS等於HTTP+SSL；

SSL協議位於應用層和傳輸層之間，用於保障通訊雙方的安全傳輸；

如圖所示：

而TSL是SSL的升級版，雖然咱們大多數時候稱呼安全協議爲SSL，可是大部分使用的都是TSL的協議；

咱們上面講的方案是使用非對稱加密來進行安全傳輸的，而事實是非對稱加密使用的算法比較耗時，那麼咱們真正商用的時候，不可能使用這種非對稱算法來進行數據的加解密；

那麼怎麼解決這種缺陷呢？

既然非對稱加密算法比較耗時，而對稱加密算法則不會很耗時，可是對稱加密算法的密鑰不安全，那麼咱們能夠結合這兩種加密算法來進行安全傳輸；

如圖所示：

1，使用對稱加密來加密數據；
2，使用非對稱加密來加密對稱加密的密鑰；

那麼SSL協議具體是怎麼實現的呢？

SSL協議的具體實現並不像上面這種簡單的實現，實際狀況是，經過幾回握手來進行密鑰的協商，最終協商出通訊雙方使用的對稱加密的密鑰；

6.二、SSL協議

SSL協議的具體劃分：

SSL體系分爲SSL握手協議層和SSL記錄協議層；

SSL握手協議層包含SSL握手協議，SSL密碼變化協議，SSL警告協議，主要用於SSL的信息交換，協商加密算法以及密鑰生成等操做；

SSL記錄協議層主要針對應用層協議HTTP協議進行特別的設計，使HTTP協議可以在SSL協議層正常運行，主要用於加密解密，以及MAC校驗等安全操做；

說了這麼多，那麼SSL協議是怎麼來保證安全傳輸的呢？

別急，且聽我細細道來；

6.三、SSL協議層是怎麼創建鏈接的？

在上一篇文章，我講了TCP鏈接是經過握手來創建鏈接的；

Android 網絡編程之TCP、UDP詳解

而SSL協議，促使通訊的雙方，經過SSL握手來創建通訊的安全通道，那麼SSL是怎麼讓HTTP達到安全傳輸的目的的呢？

在開始講以前，咱們來思考幾個問題；

（1）SSL握手總共有幾回？
（2）SSL握手是怎麼協商密鑰的？
（3）SSL安全通道是否可複用？

接下來，讓咱們帶着這幾個問題，來學習SSL握手吧；

咱們先來看一下SSL握手的流程圖：

假設咱們經過客戶端訪問百度網站，客戶端向服務器發起請求，此時雙方尚未創建起安全通訊；

第一次握手：

客戶端向服務器發送ClientHello消息，這個消息包含一個隨機數 Random1（用於後續生成密鑰使用），客戶端支持哪一種加密的相關信息（加密套件），SSL版本等信息；

服務器收到消息後，那麼就會回客戶端一個ServerHello消息，包含一個隨機數Random2，以及服務器使用哪一種加密的相關信息（加密套件），那麼這時候客戶端和服務器都有了兩個隨機數：Random1 + Random2；

從上面能夠看出，第一次握手的主要做用的溝通協商通訊雙方支持的加密信息，以及生成隨機數；

第二次握手：

第二次握手由服務器發起，服務器向客戶端發送Certificate消息，消息包含數字證書，而後客戶端驗證服務器發送過來的證書，驗證完畢後，取出證書中公鑰，這裏客戶端是怎麼經過數字證書驗證身份的，上面已經講過了，這裏就再也不多說；

從上面能夠看出第二次握手主要做用是校驗身份，這裏主要是客戶端校驗了服務器的身份，若是服務器要求客戶端也要校驗身份，那麼客戶端也須要將數字證書發送給服務端；

第三次握手：

第三次握手由客戶端發起，客戶端向服務器發送Client Key exchange消息，客戶端生成一個隨機數Random3，而後使用服務器的公鑰加密這個隨機數Random3，生成pre-master，而後將這個加密後的pre-master發送給服務器；

服務器接收到這個使用公鑰加密後的pre-master，而後服務器使用私鑰解密這個pre-master，獲得Random3，那麼這時候服務器和客戶端都持有Random1 + Random2 + Random3；

那麼這個東西是用來幹嗎的呢？

答案是：對稱機密

服務端和客戶端使用這一串隨機數，使用相同的算法生成對稱加密的密鑰，用於通訊的雙方的數據加密；

而這一串隨機數的生成，避免了對稱加密的密鑰泄露的問題；

第四次握手：

第四次握手客戶端向服務器發送一個加密後的消息，使用對稱密鑰加密消息，使用非對稱密鑰加密對稱加密的密鑰，而後使用非對稱密鑰進行簽名，這個上面已經講過了，這裏就再也不多說；

而服務器也使用一樣的操做向客戶端發送一個加密後的消息；

第四次握手的主要做用是用於檢驗通訊的雙方協商的密鑰是否有效；

下面請看具體的流程圖：

固然，實際的握手比這個還要複雜，由於涉及到太多計算機專業術語，這裏不打算講太多，容易把人繞暈，能理解過程就能夠了；

若是有想要深刻了解的小夥伴，能夠看看這篇文章，講的很詳細：

SSL/TLS協議詳解

6.四、SSL協議優化

那麼看到這裏，你是否會有疑問，若是客戶端和服務端每次進行HTTPS通訊的時候，都須要進行四次握手來創建安全通道，那麼這樣會形成很大的開銷，而HTTPS做爲商用的通訊機制，那麼確定是已經考慮過這個問題了，那麼究竟是怎麼解決的呢？

答案是：SSL會話複用；

會話複用，說白了就是已經創建過一次HTTPS鏈接的雙方，當再次通訊時，能夠複用以前已經創建好的通道；

那麼究竟是怎麼作到複用的呢？

有兩種方案：

第一種方案：session ID機制；

1，首先，若是客戶端和服務器已經成功創建鏈接，那麼服務器就會返回一個session ID給客戶端，服務器會保存這個session ID相關的通訊信息；

2，當客戶端再次發起HTTPS請求時，會將這個session ID傳給服務器；

3，服務器接收到session ID後，經過session ID獲取本地的緩存，判斷緩存是否過時，若是沒有過時，那麼則繼續複用該session ID對應的通訊信息，因而直接跳過了前三次握手，直接進去第四次握手；

4，若是第四次握手雙方驗證數據成功後，那麼就表示第四次握手成功，雙方能夠進行通訊了；

看到這裏你是否發現了一個問題，若是每一個服務器將每一個客戶端的session ID相關信息都保存到服務器的話，那麼就會面臨佔用資源過大的問題，若是客戶端較少，那麼該問題不存在，可是現實是客戶端的數量是巨大的，服務器得考慮性能問題；

那麼這個問題要怎麼解決呢？ 請看第二種方案；

第二種方案：session ticket;

1，若是客戶端和服務端已經創建起鏈接了，那麼服務器會將使用公鑰加密後的session ticket發送給客戶端，由客戶端來保存；

2，若是客戶端須要和服務端再次創建鏈接，那麼就會將session ticket相關的加密信息發送給服務端；

3，若是服務器能夠正常解密這個session ticket，那麼表示該session ticket有效，那麼服務器就會進入第四次握手，若是解密失敗，那麼按正常的握手流程走；

4，若是客戶端解密服務器的數據成功後，那麼第四次握手成功；

方案二與方案一不一樣的地方，在於將對應的通訊信息，放到客戶端來保存，由非對稱密鑰來保證安全性，大大的下降了服務器的壓力；

很高興再次見到你！

上面咱們講了一堆東西，Hash，對稱加密，非對稱加密，數字證書，SSL等相關知識，那麼HTTPS具體是怎麼實現的呢？

那麼請看下面最後的總結

總結

HTTPS的實現原理

HTTPS的實現，等於HTTP+SSL，而SSL協議作的主要工做是，幫助通訊的雙方，創建起通訊的安全通道，經過四次握手，進行身份驗證，密鑰協商等操做，讓服務器與客戶端經過對稱加密算法進行數據的加密，而後經過非對稱加密算法來進行數據的簽名，保證數據的完整性，以此來達到安全傳輸的目的；

請看最後總結的流程圖：

從這裏能夠看出，最重要的一步，就是SSL協議，是HTTPS的基石；

那麼到這裏HTTPS相關的知識就已經講完了，若是你有更好的觀點，或者文中有哪些不合理的，均可以在評論區留言；

參考&感謝

算法科普：神祕的 DES 加密算法
RSA算法原理（一）
RSA算法原理（二）
通俗理解數字簽名，數字證書和https 證書頒發機構 SSL/TLS協議詳解
SSL/TLS 握手過程詳解
HTTPS系列乾貨（一）：HTTPS 原理詳解
SSL/TLS 握手過程詳解

其餘

Android 你不得不學的HTTP相關知識
Android 網絡編程之TCP、UDP詳解

關於我

兄dei，若是個人文章對你有幫助的話，請幫我點個贊吧️，也能夠關注一下個人Github和博客;

本文使用 mdnice 排版