我終於徹底理解了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，網站訪問速度要稍微降低一些的，畢竟有個加密解密的過程嘛！
知識在於分享傳播，在分享傳播的過程中，會逐步進行凝練和升華！