我終於徹底理解了https原理！！！激動之下，寫一篇部落格，搞一波分享！！！
本篇部落格比較精彩的地方：
思維方式：也是借鑑一位大佬的，寫得很棒。https://blog.csdn.net/guolin_blog/article/details/104546558
圖文並茂，簡單明瞭，化繁為簡。
關於https原理，有非常非常多的部落格，然而其中很多博主都不一定完全理解，只是單純地為了寫部落格而寫部落格。
基礎知識鋪墊
雖然我們不一定是專門搞密碼學的，但多多少少還是要知道一點的。不然的話，接下來的知識可能無法理解。
1、對稱加密演算法：加密和解密使用相同的金鑰。
2、非對稱加密演算法：加密和解密使用不同的金鑰，一個成為公鑰，另一個則是私鑰，兩者是成對的。公鑰用來加密，私鑰用來解密。
備註：https原理中，這兩種演算法都用到了。至於其他加密演算法，我們就不多說了。
http傳輸原理
（其實呢，瀏覽器和伺服器之間資訊傳輸並不是直接的，中間還會有個中間路由。）
解釋一下http到底不安全在哪裡
正如圖中所看到的，如果有人通過中間路由惡意篡改傳輸的資訊，那會怎樣？瀏覽器接收到的資訊都被篡改了，後果不堪設想。
https因此誕生。在http基礎上加上了SSL/TLS協議。就是為了防止以上的這種情況。
思維風暴：
試想，如果是我們，我們會怎麼處理這種情況呢？跟著這個思維走下去，你便會提現到這種思維的魅力
首先，我們很自然地會想到，資訊在傳輸期間進行加密，瀏覽器和伺服器那邊再進行解密。這樣的話，即使監聽者得到了這些資訊，他也無法進行解密。這樣便安全了。
那又有問題了，以上這種加密便是採用的對稱加密，那金鑰怎麼得到呢？
我們知道，瀏覽器一開始是向伺服器傳送請求的，那金鑰必定是瀏覽器發給伺服器的。這樣的話，監聽者還是可以通過中間路由得到這個金鑰，然後通過金鑰進行解密，治標不治本。或者直接隨便惡意篡改這個金鑰，後果可想而知。那怎麼辦呢？
我們可能也很自然地想到，如果把瀏覽器發給伺服器的金鑰進行加密，不就可以了嗎？這樣的話，的確解決了問題。
把瀏覽器發給伺服器的金鑰進行加密，我們很自然地會想到，使用非對稱加密演算法便可以實現。那怎麼做到這一點呢？
這也是個計算機屆的難題，卡在這兒，走不下去了。
某一天，某個天才突然想到了，瀏覽器給伺服器傳送一個請求。打破常規，如果請求兩次呢？第一次只請求公鑰，得到公鑰後，瀏覽器生成一個金鑰（這裡稱作瀏覽器金鑰），使用公鑰進行加密，第二次請求附帶上使用公鑰進行加密的瀏覽器金鑰，伺服器接收後，使用私鑰進行解密不就得到了瀏覽器金鑰嗎？接下來，傳輸資訊，只需通過瀏覽器金鑰進行加密解密不就成了。這樣的話，問題不就解決了嗎？的確如此。
最後一個問題，伺服器端的公鑰和私鑰怎麼來的呢？
這便誕生出了CA機構。
CA機構專門給網站伺服器端新增公鑰和私鑰（就是所謂的數字簽名證書），當然還有一些其他的資訊，比如網站域名、證書有效期等。
還有一點要說明一下，瀏覽器是如何驗證公鑰的？
瀏覽器得到伺服器傳送的公鑰後，會和系統內建的證書進行比對便可驗證真假了。
總結：
https原理：
1、瀏覽器給伺服器傳送一個http請求，得到公鑰。
2、將公鑰和系統內建證書進行對比，並驗證有效期，然後生成一個隨機瀏覽器金鑰並使用公鑰加密，接著再傳送一個http請求。
3、伺服器接收到用公鑰加密的瀏覽器金鑰後，使用私鑰進行解密。
4、接下來傳輸便通過瀏覽器金鑰進行加密解密。即使監聽者通過中間路由接收到了資訊，也無法解密，惡意篡改的話，瀏覽器和伺服器端會識別到，中斷連線。這樣的話，便安全了。
怎麼升級到https？
將http升級到https，比較簡單，購買SSL證書，然後將證書安裝到網站伺服器端即可。一般而言，購買SSL證書的話，第一年是免費的，然後每年差不多要4k左右。（還挺貴的。。。）當然了，http升級到https，網站訪問速度要稍微降低一些的，畢竟有個加密解密的過程嘛！
知識在於分享傳播，在分享傳播的過程中，會逐步進行凝練和昇華！