前言：本文只講Https實現的流程。
現在有一個場景：一個人A要其他人B,C,D交流，但是A希望的是他和B交流不會被C,D知道;自然與C的交流也不願意被B,D知道。
於是乎，人們想出了第一個方法，就是在A和B,C,D交流的時候分別都產生一個公鑰，傳送給B,C,D，雙方都根據這個公鑰加密解密對話。這樣的話，交流的時候大家就可以通過公鑰去解析對話，得到各自要說的話，但是這個想法很快就被否決了，因爲傳送公鑰的過程並不安全，可能出現中間人，在公鑰傳送過程，被攔截並被別人篡改對話，最後返回給A，這樣的A得到對話就是被篡改過了。
後來，人們想了另一個辦法，就是非對稱加密算法，簡而言之，通過非對稱加密算法生成一個私鑰和一個公鑰，只要B,C,D是用公鑰加密的數據，A這邊都能通過私鑰來做解密（對於非對稱加密算法來說,用私鑰加密的數據，都能用公鑰進行解密，而用公鑰加密的數據，只能用私鑰進行解密），這樣就可以實現B,C,D傳送到A都能安全（B->A），因爲中間人沒有私鑰就不能對傳輸數據進行解密然後重新加密給A。（注意：這個時候A->B,C，D端的傳輸是不安全的，因爲所有人都能獲得公鑰）但是這樣就有一個問題出來，還是跟第一個方法一樣，我們怎麼確保公鑰的傳輸過程是安全的呢？
這個時候，A,B,C,D商量着說：要不這樣辦吧，把E找來，他比較值得信任，他生產一個公鑰（證書）出來，並且在上面蓋章說明這個公鑰是他生成，如果上面的蓋章變了，則說明這個公鑰也不能被使用了。
因此流程就變成這樣：
A->E申請一個證書，並事前存放在A那，而B在交流前則會在本地存有一個ca蓋章庫，在B與A交流的時候，A就把ca發送給B，B收到後就開始檢查ca的內容，和檢查ca上蓋章是否和B本地上蓋章庫一致，如果一致，則B則又通過ca與自己產生隨機數（密鑰）加密得到數據發送到A，告訴A，B端確認通過；然後A端接收信息後用本地存的私鑰進行解密，若成功則告訴B端成功。至此，A-B端開始真正數據解析。
當你明白以上的流程，我們就這些轉換成https的真正的流程。此時A就是我們的服務器，B,C,D就是一個個客戶端。
最後總結：https的流程大致就是如此，在這裏需理解到利用第三方機構的證書來保證通信傳輸的安全性，但我們也需知道在開始通信的前兩步也是不安全的，直到第三步通信後。
在https雖然經過了加密，但https並不是真正的安全，比如一些大公司，通過控制入口，將請求中的證書進行替換，也就是證書劫持，將本地證書給替換掉，當你發出請求時，實際上用的是公司的證書，與外部服務器進行通信，然後再把請求返回給你。