本文原作者“虞大膽的嘰嘰喳喳”，原文鏈接：jianshu.com/p/8861da5734ba，感謝原作者。
1、引言
很多人一提到 HTTPS，第一反應就是安全，對于普通用戶來說這就足夠了；
但對于程序員，很有必要了解下 HTTP 到底有什么問題？以及HTTPS 是如何解決這些問題的？其背后的解決思路和方法是什么？
本文只做簡單的描述，力求簡單明了的闡明主要內(nèi)容，因為HTTPS 體系非常復雜，這么短的文字是無法做到很詳細和精準的分析。想要詳細了解HTTPS的方方面面，可以閱讀此前即時通訊網(wǎng)整理的《即時通訊安全篇（七）：如果這樣來理解HTTPS，一篇就夠了》一文。
（本文同步發(fā)布于：http://www.52im.net/thread-2027-1-1.html）
2、HTTPS相關文章
《即時通訊安全篇（七）：如果這樣來理解HTTPS，一篇就夠了》
《一文讀懂Https的安全性原理、數(shù)字證書、單項認證、雙項認證等》
《HTTPS時代已來，打算更新你的HTTP服務了嗎？》
《蘋果即將強制實施 ATS，你的APP準備好切換到HTTPS了嗎？》
3、對HTTPS性能的理解
HTTP 有典型的幾個問題，第一就是性能，HTTP 是基于 TCP 的，所以網(wǎng)絡層就不說了（快慢不是 HTTP 的問題）。
比較嚴重的問題在于 HTTP 頭是不能壓縮的，每次要傳遞很大的數(shù)據(jù)包。另外 HTTP 的請求模型是每個連接只能支持一個請求，所以會顯得很慢。
那么 HTTPS 是解決這些問題的嗎？
不是，實際上 HTTPS 是在 HTTP 協(xié)議上又加了一層，會更慢，相信未來會逐步解決的。同時 HTTPS 用到了很多加密算法，這些算法的執(zhí)行也是會影響速度的。
為什么說 HTTPS 提升了性能呢？因為只有支持了 HTTPS，才能部署 HTTP/2，而 HTTP/2 協(xié)議會提升速度，能夠有效減輕客戶端和服務器端的壓力，讓響應更快速。有關HTTP/2詳細文章可以看看《從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設計思路》、《腦殘式網(wǎng)絡編程入門(四)：快速理解HTTP/2的服務器推送(Server Push)》，這里只要知道一點：HTTP/2 能夠加快速度的主要原因在于多路復用，同一個連接能夠并行發(fā)送和接收多個請求。
4、傳統(tǒng)HTTP的安全性問題
當用戶在瀏覽器輸入一個網(wǎng)址的時候，在地址欄上看到小鎖圖標，就會安心，潛意識的認為自己的上網(wǎng)行為是安全的，當然對于小白用戶來說可能還不明白，但是未來會慢慢改善的（萬事開頭難嘛）。
那么 HTTP 到底有什么安全問題呢，看幾個例子：
1）由于互聯(lián)網(wǎng)傳輸是能夠被攔截的，所以假如你的上網(wǎng)方式被別人控制了（沒有絕對的安全），那么你的任何行為和信息攻擊者都會知道，比如我們連上一個匿名的 WIFI，當你上網(wǎng)的時候，輸入的網(wǎng)站密碼可能就已經(jīng)泄漏了；
2）當我們在上一個網(wǎng)站的時候，莫名其妙跳出一個廣告（這個廣告并不是這個網(wǎng)站的），那是因為訪問的頁面可能被運營商強制修改了（加入了他自己的內(nèi)容，比如廣告）。
HTTP 最大的問題就在于數(shù)據(jù)沒有加密，以及通信雙方?jīng)]有辦法進行身份驗證（ confidentiality and authentication），由于數(shù)據(jù)沒有加密，那么只要數(shù)據(jù)包被攻擊者劫持，信息就泄漏了。
身份驗證的意思就是服務器并不知道連接它的客戶端到底是誰，而客戶端也不確定他連接的服務器就是他想連接的服務器，雙方之間沒有辦法進行身份確認。
有關HTTP比較好的文章，可以看看：
《網(wǎng)絡編程懶人入門(七)：深入淺出，全面理解HTTP協(xié)議》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設計思路》
《腦殘式網(wǎng)絡編程入門(三)：HTTP協(xié)議必知必會的一些知識》
5、HTTPS 背后的密碼學
為了解決 HTTP 的兩個核心問題，HTTPS 出現(xiàn)了，HTTPS 包含了核心的幾個部分：TLS 協(xié)議、OpenSSL，證書。
什么是 OpenSSL 呢，它實現(xiàn)了世界上非常重要和多的密碼算法，而密碼學是解決問題最重要的一個環(huán)節(jié)。
TLS 最重要的是握手的處理方式。證書的體系也很大，但是他們背后都是基于同樣的密碼學。
1）既然 HTTP 沒有數(shù)據(jù)加密，那么我們就加密下，對稱加密算法上場了，這種算法加密和解密要使用同一個密鑰，通信雙方需要知道這個密鑰（或者每次協(xié)商一個），實際上這種方法不太可能，這涉及到密鑰保密和配送的問題，一旦被攻擊者知道了密鑰，那么傳輸?shù)臄?shù)據(jù)等同沒有加密。
2）這個時候非對稱加密算法上場了，公鑰和私鑰是分開的，客戶端保存公鑰，服務器保存私鑰（不會公開），這時候好像能夠完美解決問題了。
但實際上會存在兩個問題，第一就是非對稱加密算法運算很慢，第二就是會遇到中間人攻擊問題。
先說說中間人攻擊的問題，假如使用非對稱加密算法，對于客戶端來說它拿到的公鑰可能并不是真正服務器的公鑰，因為客戶端上網(wǎng)的時候可能不會仔細分辨某個公鑰是和某個公司綁定的，假如錯誤的拿到攻擊者的公鑰，那么他發(fā)送出去的數(shù)據(jù)包被劫持后，攻擊者用自己的私鑰就能反解了。
3）接下來如何解決公鑰認證的問題呢？證書出現(xiàn)了，證書是由 CA 機構(gòu)認證的，客戶端都充分信任它，它能夠證明你拿到的公鑰是特定機構(gòu)的，然后就能使用非對稱加密算法加密了。
證書是怎么加密的呢？實際上也是通過非對稱加密算法，但是區(qū)別在于證書是用私鑰加密，公鑰解密。
CA 機構(gòu)會用自己的私鑰加密服務器用戶的公鑰，而客戶端則用 CA 機構(gòu)的公鑰解出服務器的公鑰。聽上去有點暈，仔細體會下。這方面的知識，可以詳細閱讀：《即時通訊安全篇（七）：如果這樣來理解HTTPS，一篇就夠了》。
4）上面說了非對稱加密算法加密解密非常耗時，對于 HTTP 這樣的大數(shù)據(jù)包，速度就更慢了，這時候可以使用對稱加密算法，這個密鑰是由客戶端和服務器端協(xié)商出來，并由服務器的公鑰進行加密傳遞，所以不存在安全問題。
5）另外客戶端拿到證書后會驗證證書是否正確，它驗證的手段就是通過 Hash 摘要算法，CA 機構(gòu)會將證書信息通過 Hash 算法運算后再用私鑰加密，客戶端用 CA 的公鑰解出后，再計算證書的 Hash 摘要值，兩者一致就說明驗證身份通過。
6）HTTPS 解決的第三個問題是完整性問題，就是信息有沒有被篡改（信息能夠被反解），用的是 HMAC 算法，這個算法和 Hash 方法差不多，但是需要傳遞一個密鑰，這個密鑰就是客戶端和服務器端上面協(xié)商出來的。
附錄：更多安全方面的文章
《即時通訊安全篇（一）：正確地理解和使用Android端加密算法》
《即時通訊安全篇（二）：探討組合加密算法在IM中的應用》
《即時通訊安全篇（三）：常用加解密算法與通訊安全講解》
《即時通訊安全篇（四）：實例分析Android中密鑰硬編碼的風險》
《即時通訊安全篇（五）：對稱加密技術在Android平臺上的應用實踐》
《即時通訊安全篇（六）：非對稱加密技術的原理與應用實踐》
《傳輸層安全協(xié)議SSL/TLS的Java平臺實現(xiàn)簡介和Demo演示》
《理論聯(lián)系實際：一套典型的IM通信協(xié)議設計詳解（含安全層設計）》
《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》
《來自阿里OpenIM：打造安全可靠即時通訊服務的技術實踐分享》
《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》
《移動端安全通信的利器——端到端加密（E2EE）技術詳解》
《Web端即時通訊安全：跨站點WebSocket劫持漏洞詳解(含示例代碼)》
《通俗易懂：一篇掌握即時通訊的消息傳輸安全原理》
《IM開發(fā)基礎知識補課(四)：正確理解HTTP短連接中的Cookie、Session和Token》
《快速讀懂量子通信、量子加密技術》
《即時通訊安全篇（七）：如果這樣來理解HTTPS原理，一篇就夠了》
《一分鐘理解 HTTPS 到底解決了什么問題》
>> 更多同類文章 ……
（本文同步發(fā)布于：http://www.52im.net/thread-2027-1-1.html）