其實疫情期間在家呆了乙個多月的時間不能出門，時間倒是挺多的，我也利用這段時間寫了幾篇新文章。但由於新寫的這些文章大都是配合著新書中的內容的，受疫情的影響我寫的新書遲遲不能出版，導致這些文章也無法發布，等得我好是焦急。希望疫情早日結束，大家都能快點恢復到正常的生活當中。
那麼今天先發布一篇和android無關的技術文章。
https這項技術現在已經應用得非常廣泛了。隨著蘋果、google等各大網際網路領頭企業紛紛在自己的作業系統、瀏覽器等主流產品中強制要求使用https，http的淘汰也正式進入了倒計時。
其實https對於客戶端開發人員來說並沒有什麼需要特別注意的地方，因為**和寫http請求時並沒有什麼兩樣。但也正是因為這個原因，導致許多客戶端開發人員對https並不了解，只知道它是安全的加密網路傳輸，對其具體的工作原理卻一無所知。
那麼客戶端開發人員到底需不需要了解https呢？我認為還是有一定必要的，掌握了https的工作原理可以幫助你更加有效地理解並解決一些工作當中遇到的問題。另外，有很多公司也喜歡在面試的時候問一些https相關的問題，如果你完全不了解的話，在這裡就很容易會被刷掉。
我自己當初在學習https的時候查閱了很多網上的資料，但是絕大多數的文章寫得都不是那麼易懂，讓不少人對https產生了一些畏懼。我認為要想理解https的工作原理，並不一定非得要知道它方方面面的細節（網上許多文章就是因為寫得太細，導致很難懂），其實只要掌握它的整體工作流程，以及搞清楚為什麼它能夠保證網路通訊的安全就可以了。因此，今天我就給大家帶來一篇最好懂的https講解。
在正式開始講解https之前我們還得先搞清楚兩個概念：什麼是對稱加密，以及什麼是非對稱加密？這兩個概念都是屬於加密學中的基礎知識，其實非常好懂。
對稱加密比較簡單，就是客戶端和伺服器共用同乙個金鑰，該金鑰可以用於加密一段內容，同時也可以用於解密這段內容。對稱加密的優點是加解密效率高，但是在安全性方面可能存在一些問題，因為金鑰存放在客戶端有被竊取的風險。對稱加密的代表演算法有：aes、des等。
而非對稱加密則要複雜一點，它將金鑰分成了兩種：公鑰和私鑰。公鑰通常存放在客戶端，私鑰通常存放在伺服器。使用公鑰加密的資料只有用私鑰才能解密，反過來使用私鑰加密的資料也只有用公鑰才能解密。非對稱加密的優點是安全性更高，因為客戶端傳送給伺服器的加密資訊只有用伺服器的私鑰才能解密，因此不用擔心被別人破解，但缺點是加解密的效率相比於對稱加密要差很多。非對稱加密的代表演算法有：rsa、elgamal等。
掌握了這兩個概念之後，我們就可以開始學習https了。這裡先提前丟擲乙個問題，同時也是面試時可能經常會問到的乙個問題：https為了保證資料傳輸的安全，使用的是對稱加密還是非對稱加密呢？
學完本篇文章之後你就能知道答案了。
首先我們來看一下，傳統的http方式在網路傳輸時存在哪些問題。
由於我們在傳輸資料時資訊都是明文的，因此很容易出現資料被監聽和竊取的情況。示意圖如下：
也就是說，使用http傳輸資料至少存在著資料被監聽以及資料被篡改這兩大風險，因此http是一種不安全的傳輸協議。
那麼解決方案大家肯定都知道是使用https，但是我們先嘗試著自己思考一下該如何保證http傳輸的安全性，進而也就能一步步地理解https的工作原理了。
既然資料以明文的形式在網路上傳輸是不安全的，那麼我們顯然要對資料進行加密才行。剛才提到了，加密方式主要有兩種，對稱加密和非對稱加密。對稱加密的優點是加解密效率高，而我們在網路上傳輸資料是非常講究效率的，因此這裡很明顯應該使用對稱加密。示意圖如下：
可以看到，由於我們在網路上傳輸的資料都是密文，所以不怕被監聽者獲取到，因為他們無法得知原文是什麼。而瀏覽器收到密文之後，只需要使用和**相同的金鑰來對資料進行解密就可以了。
這絕對是乙個計算機界的難題，瀏覽器和**要使用相同的金鑰才能正常對資料進行加解密，但是如何讓這個金鑰只讓它們倆知曉，而不被任何監聽者知曉呢？你會發現不管怎麼商定，瀏覽器和**的首次通訊過程必定是明文的。這就意味著，按照上述的工作流程，我們始終無法建立乙個安全的對稱加密金鑰。
所以，只使用對稱加密看來是永遠無法解決這個問題了，這個時候我們需要將非對稱加密引入進來，協助解決無法安全建立對稱加密金鑰的問題。
那麼為什麼非對稱加密就可以解決這個問題呢？我們還是通過示意圖的方式來理解一下：
可以看到，如果我們想要安全地建立乙個對稱加密的金鑰，可以讓瀏覽器這邊來隨機生成，但是生成出來的金鑰不能直接在網路上傳輸，而是要用**提供的公鑰對其進行非對稱加密。由於公鑰加密後的資料只能使用私鑰來解密，因此這段資料在網路上傳輸是絕對安全的。而**在收到訊息之後，只需要使用私鑰對其解密，就獲取到瀏覽器生成的金鑰了。
另外，使用這種方式，只有在瀏覽器和**首次商定金鑰的時候需要使用非對稱加密，一旦**收到了瀏覽器隨機生成的金鑰之後，雙方就可以都使用對稱加密來進行通訊了，因此工作效率是非常高的。
那麼，上述的工作機制你認為已經非常完善了嗎？其實並沒有，因為我們還是差了非常關鍵的一步，瀏覽器該怎樣才能獲取到**的公鑰呢？雖然公鑰是屬於公開的資料，在網路上傳輸不怕被別人監聽，但是如果公鑰被別人篡改了怎麼辦？示意圖如下：
也就是說，只要我們從網路上去獲取任何**的公鑰，就必然存在著公鑰被篡改的風險。而一旦你使用了假的公鑰來對資料進行加密，那麼就可以被別人以假的私鑰進行解密，後果不堪設想。
方案設計到這裡好像已經進入了死胡同，因為無論如何我們都無法安全地獲取到乙個**的公鑰，而我們顯然也不可能將世界上所有**的公鑰都預置在作業系統當中。
這個時候，就必須引入乙個新的概念來打破僵局了：ca機構。
ca機構專門用於給各個**簽發數字證書，從而保證瀏覽器可以安全地獲得各個**的公鑰。那麼ca機構是如何完成這個艱鉅的任務的呢？下面開始一步步解析。
證書製作完成後，ca機構會使用自己的私鑰對其加密，並將加密後的資料返回給我們，我們只需要將獲得的加密資料配置到**伺服器上即可。
然後，每當有瀏覽器請求我們的**時，首先會將這段加密資料返回給瀏覽器，此時瀏覽器會用ca機構的公鑰來對這段資料解密。
得到了公鑰之後，接下來的流程就和剛才示意圖中所描述的一樣了。
而如果無法解密成功，則說明此段加密資料並不是由乙個合法的ca機構使用私鑰加密而來的，有可能是被篡改了，於是會在瀏覽器上顯示乙個著名的異常介面，如下圖所示。
那麼你可能會問了，有了ca機構之後就真的安全了嗎？我們在瀏覽器端要使用ca機構的公鑰來解密資料，那麼又該如何安全地獲取到ca機構的公鑰呢？
這個問題就很好解決了，因為世界上的**是無限多的，而ca機構總共就那麼幾家。任何正版作業系統都會將所有主流ca機構的公鑰內建到作業系統當中，所以我們不用額外獲取，解密時只需遍歷系統中所有內建的ca機構的公鑰，只要有任何乙個公鑰能夠正常解密出資料，就說明它是合法的。
windows系統的內建證書如下：
但是即使使用ca機構的公鑰能夠正常解密出資料，目前的流程也還是存在問題的。因為每一家ca機構都會給成千上萬的**製作證書，假如攻擊者知道abc.com使用的是某家ca機構的證書，那麼他也可以同樣去這家ca機構申請乙個合法的證書，然後在瀏覽器請求abc.com時對返回的加密證書資料進行替換。示意圖如下：
可以看到，由於攻擊者申請的證書也是由正規ca機構製作的，因此這段加密資料當然可以成功被解密。
也正是因為這個原因，所有ca機構在製作的證書時除了**的公鑰外，還要包含許多其他資料，用來輔助進行校驗，比如說**的網域名稱就是其中一項重要的資料。
同樣是剛才的例子，如果證書中加入了**的網域名稱，那麼攻擊者就只能無功而返了。因為，即使加密資料可以被成功解密，但是最終解密出來的證書中包含的網域名稱和瀏覽器正在請求的網域名稱對不上，那麼此時瀏覽器仍然會顯示異常介面。示意圖如下：
好了，方案設計到這裡，其實我們的網路傳輸就已經做到足夠的安全了。當然，這其實也就是https的工作原理。
那麼回到一開始的問題：https使用的是對稱加密還是非對稱加密呢？答案也很明顯了，https使用的是對稱加密與非對稱加密相結合的方式。
為什麼我們要配置https？如何配置https？
https 全稱 hyper text transfer protocol over securesocket layer 是以安全為目標的 http 通道，在http的基礎上通過傳輸加密和身份認證保證了傳輸過程的安全性。https 在http 的基礎下加入ssl，https 的安全基礎是 ssl，...
https協議 什麼是HTTPS協議？
在我們平常上網的時候我經常接觸的 應該大部分都是 或者我們知道讓他是乙個超文字傳輸協議。那麼https是個什麼？雖然http和這個https兩者只差乙個s，但是本質是大不相同的，他們是兩種不同的網路傳輸協議。千萬不要搞混淆了。http協議通過請求 響應的方式，在客戶端和服務端之間進行通訊。這一切看起...
什麼是HTTPS以及如何實施HTTPS？
我在 讓我們擁抱2021年seo新趨勢吧 文章中的第6點講述了seo優化的重要性，今天就來聊聊什麼是https以及如何實施https，讓您有更深層次的認識，以及掌握實施的重點。超文字傳輸 安全協議 英語 hypertext transfer protocol secure，縮寫 https 常稱為h...