今天接到個活兒，讓我科普 https 。講 http 我都「方」，想要通俗易懂的說完 https， 我有點「圓」。在講什麼是 https 之前，我們先來看個漫畫。
△ **於阮一峰的網路日誌
漫畫中其實就是 https 的握手過程，但是我相信大段的英文你看著也不怎麼流暢，下面就由我簡單講解下吧。https 是在 http 的基礎上增加了 ssl 或 tls 安全協議，這些協議有眾多的套件，這些套件則是由加密演算法和雜湊演算法組成，而這些演算法最後則涉及到了數學。數學是我上學時期最頭痛的學科，還記得上數學課時，我傳紙條給坐在我後面的班花……咦，好像有點跑偏了，拉回來，坐好了，開始我們的 https 之旅。
https 是為了安全的使用 http ，縮寫展開：hyper text transfer protocol over secure socket layer 。從英文釋義可以看出，https 就是 http + ssl 或者 http + tls 。
「我讀書少，你可不要騙我，上面的英文縮寫不是 http over ssl 嗎？」呃...是這樣的，https 最初使用的加密協議的確是 ssl，ssl 最近的三個版本是：ssl 1.0 、ssl 2.0 、ssl 3.0 ，不過隨著加密演算法的發展和人們對傳輸安全性要求的提高，截止目前已經長江後浪推前浪依次推出了 tls 的四個版本，分別是：tls 1.0 、tls 1.1 、tls 1.2 以及前不久剛推出的 tls 1.3 。實際上，業內也有人把 tls 1.0 叫做 ssl 3.1 ，事實上，tls 是在 ssl 的基礎上發展起來的更安全的加密協議。
這個問題要從為什麼逐漸的拋棄 http 說起。http 從 1991 年的 http/0.9 一直發展到 1999 年的 http/1.1 ，雖然功能不斷增加，效能也不斷提高，但是隨著網際網路技術和網路裝置的迅速普及，導致資訊大**，眾多的網民們對網路傳輸的速度和安全性有了越來越高的要求。2012 年，谷歌推出了 spdy 方案，優化了 http/1.x 的請求延遲和安全性問題，進一步普及了 https，截止到 2015 年，http/2 已經成為標準，更是進一步推動了全網 https 的程序。
全網 https 是大勢所趨，那麼為什麼拋棄 http 呢？最重要的原因就是安全問題，因為 http 是明文傳輸的，這對於目前從娃娃就開始玩智慧型手機，學習 python 程式設計的新一代來說，抓個包估計是不在話下，更別提浸淫網路多年的「黑客」了。是時候跑步進入 https 加密時代的了。
上文已經有提到，https 就是 http + ssl or tls ，除了 https 傳輸標準嚴格和規範外，主要是 ssl 或者 tls 對傳輸的資訊有一整套的加解密和校驗方案。這套方案主要從下面三個方面確保傳輸的安全。
1. 身份認證
傳輸之前首先通過數字證書來確認身份，各大 ca 廠商幹的就是這個事情。這裡涉及到乙個名詞：數字證書。數字證書分為公鑰和私鑰，ca 廠商會用自己的私鑰來給證書申請者簽發一套包含私鑰和公鑰的客戶證書，客戶的公鑰證書誰都可以獲取，裡面包含了客戶站點和證書的基本資訊，用來確保訪問者訪問的就是他想要訪問的站點。
這個證書不可以偽造嗎？答案是真的不可以。
原因一：系統早已內建了各大 ca 廠商的公鑰來校驗證書是否是對應的站點的證書，如果不是，就會給出證書不匹配的提示，除非你給別人的裝置強行植入假的 ca 公鑰。
原因二：這個證書是 ca 廠商通過雜湊並加密得到的，基本無法逆向破解並偽造乙個新的，除非是你黑進 ca 獲取了 ca 的私鑰，那這家 ca 也基本可以倒閉了。
2. 資料保密
資料保密包括對話秘鑰傳輸時候的保密和資料的加密傳送。
對話秘鑰：以 tls 1.2 使用的套件之一 dhe-rsa-aes256-sha256 為例：該套件是以 dhe 、rsa 作為秘鑰交換演算法，這兩種秘鑰交換演算法都是使用的非對稱加密，數學原理分別依賴於計算離散對數的難度和大數分解的難度。也就是在建立 https 鏈結的過程中，剛開始是有一些明文出現的，不過想要根據這些已知的明文推算出「對話秘鑰」卻非常困難。
對話加密：客戶端和和服務端協商並成功獲取到對話秘鑰後就開始用對話秘鑰進行對稱加密會話，上面的套件我們可以看到使用的是 aes256 加密演算法。
那麼為什麼「對話秘鑰」的交換使用非對稱加密，正式對話資料的傳輸使用對稱加密？因為非對稱加密雖然安全性比較高，但是它的效率比較低，速度比較慢，所以我們一般只使用它們來交換一下對話秘鑰，後面的對話加密則使用速度更快，效率更高的對稱加密。
3. 資料完整
身份認證成功後，到了資料加密傳輸的階段，所有資料都以明文（http）收發，只不過收發的是加密後的明文。這時候也遇到了乙個問題，雖然中間人很難破解加密後的資料，但是如果他對資料進行了篡改，那該怎麼辦？此時加密套件驗證資料一致性的雜湊演算法就派上用場了，雜湊演算法有多種，比如 md5 ，sha1 或者 sha2 等，上面舉例的加密套件使用的是 sha2 中的 sha256 來對資料進行雜湊計算。這樣就使得任何的資料更改都會導致通訊雙方在校驗時發現問題，進而發出警報並採取相應的措施。
以上主要從使用 https 的必要性及 https 能安全傳輸的原理進行了簡單的闡述，https 的實現不僅僅是網路技術的集中應用，底層還涉及到了大量的演算法以及密碼學的眾多知識，小編也無法一下子概述完整（笑哭）。另外，不論是 pfs，或是國際網際網路組織正在推行的 hsts 安全傳輸協議，他們的主要目的就是避免中間人攻擊，使資訊在傳輸過程中更安全，更快速。想要更詳細的了解 https 相關知識，我們在推薦閱讀裡準備了大量的 https 乾貨，歡迎查閱。
彩蛋：你是不是想吐槽一下標題說讀這篇就夠了，哈哈，你得允許我皮一下嘛~
推薦閱讀：
不是 https 拖慢**速度，而是優化做的不夠優秀
科普 tls 1.3 — 新特性與開啟方式
從 http 到 https 再到 hsts
vue開發看這篇文章就夠了
每個月，我們幫助 1000 萬的開發者解決各種各樣的技術問題。並助力他們在技術能力 職業生涯 影響力上獲得提公升。一二三 16 小時前發布 庫，本質上是一些函式的集合。每次呼叫函式，實現乙個特定的功能，接著把控制權交給使用者框架，是一套完整的解決方案，使用框架的時候，需要把你的 放到框架合適的地方，...
Redis入門，有這篇文章就夠了
hash list setzset 展示 redis它是key value兼職對的nosql資料庫，它與其他的關係型資料庫不同的是，它是將資料儲存到記憶體，這樣很大程度上了提高讀寫速度。提供了string,hash,list.set,zset多種資料結構，所以它可以應用於不同的場景 而且它將記憶體上...
想了解MQ，讀這篇就夠了
mq全稱為message queue 訊息佇列，是一種應用程式對應用程式的訊息通訊，一端只管往佇列不斷發布資訊，另一端只管往佇列中讀取訊息，發布者不需要關心讀取訊息的誰，讀取訊息者不需要關心發布訊息的是誰，各幹各的互不干擾。市場上現在常用的訊息佇列有 rabbitmq rocketmq kafka，...