寫一篇最好懂的HTTPS講解

你們早上好，有段時間沒更新文章了。

其實疫情期間在家呆了一個多月的時間不能出門，時間卻是挺多的，我也利用這段時間寫了幾篇新文章。但因爲新寫的這些文章大都是配合着新書中的內容的，受疫情的影響我寫的新書遲遲不能出版，致使這些文章也沒法發佈，等得我好是焦急。但願疫情早日結束，你們都能快點恢復到正常的生活當中。

那麼今天先發布一篇和Android無關的技術文章。

https這項技術如今已經應用得很是普遍了。隨着蘋果、Google等各大互聯網領頭企業紛紛在本身的操做系統、瀏覽器等主流產品中強制要求使用https，http的淘汰也正式進入了倒計時。

其實https對於客戶端開發人員來講並無什麼須要特別注意的地方，由於代碼和寫http請求時並無什麼兩樣。但也正是由於這個緣由，致使許多客戶端開發人員對https並不瞭解，只知道它是安全的加密網絡傳輸，對其具體的工做原理卻一無所知。

那麼客戶端開發人員到底需不須要了解https呢？我認爲仍是有必定必要的，掌握了https的工做原理能夠幫助你更加有效地理解並解決一些工做當中遇到的問題。另外，有不少公司也喜歡在面試的時候問一些https相關的問題，若是你徹底不瞭解的話，在這裏就很容易會被刷掉。

https://plsshjz.edublogs.org

我本身當初在學習https的時候查閱了不少網上的資料，可是絕大多數的文章寫得都不是那麼易懂，讓很多人對https產生了一些畏懼。我認爲要想理解https的工做原理，並不必定非得要知道它方方面面的細節（網上許多文章就是由於寫得太細，致使很難懂），其實只要掌握它的總體工做流程，以及搞清楚爲何它可以保證網絡通訊的安全就能夠了。所以，今天我就給你們帶來一篇最好懂的https講解。

在正式開始講解https以前咱們還得先搞清楚兩個概念：什麼是對稱加密，以及什麼是非對稱加密？這兩個概念都是屬於加密學中的基礎知識，其實很是好懂。

 

對稱加密比較簡單，就是客戶端和服務器共用同一個密鑰，該密鑰能夠用於加密一段內容，同時也能夠用於解密這段內容。對稱加密的優勢是加解密效率高，可是在安全性方面可能存在一些問題，由於密鑰存放在客戶端有被竊取的風險。對稱加密的表明算法有：AES、DES等。

http://plsshjz.wikidot.com

而非對稱加密則要複雜一點，它將密鑰分紅了兩種：公鑰和私鑰。公鑰一般存放在客戶端，私鑰一般存放在服務器。使用公鑰加密的數據只有用私鑰才能解密，反過來使用私鑰加密的數據也只有用公鑰才能解密。非對稱加密的優勢是安全性更高，由於客戶端發送給服務器的加密信息只有用服務器的私鑰才能解密，所以不用擔憂被別人破解，但缺點是加解密的效率相比於對稱加密要差不少。非對稱加密的表明算法有：RSA、ElGamal等。

掌握了這兩個概念以後，咱們就能夠開始學習https了。這裏先提早拋出一個問題，同時也是面試時可能常常會問到的一個問題：https爲了保證數據傳輸的安全，使用的是對稱加密仍是非對稱加密呢？

學完本篇文章以後你就能知道答案了。

 

首先咱們來看一下，傳統的http方式在網絡傳輸時存在哪些問題。

因爲咱們在傳輸數據時信息都是明文的，所以很容易出現數據被監聽和竊取的狀況。

另外，傳輸的數據還有可能被一些別有用心的人篡改，致使瀏覽器與網站收發的內容不一致。示意圖以下：

也就是說，使用http傳輸數據至少存在着數據被監聽以及數據被篡改這兩大風險，所以http是一種不安全的傳輸協議。

那麼解決方案你們確定都知道是使用https，可是咱們先嚐試着本身思考一下該如何保證http傳輸的安全性，進而也就能一步步地理解https的工做原理了。

既然數據以明文的形式在網絡上傳輸是不安全的，那麼咱們顯然要對數據進行加密才行。剛纔提到了，加密方式主要有兩種，對稱加密和非對稱加密。對稱加密的優勢是加解密效率高，而咱們在網絡上傳輸數據是很是講究效率的，所以這裏很明顯應該使用對稱加密。

因爲咱們在網絡上傳輸的數據都是密文，因此不怕被監聽者獲取到，由於他們沒法得知原文是什麼。而瀏覽器收到密文以後，只須要使用和網站相同的密鑰來對數據進行解密就能夠了。