HTTP與HTTPS有什麼區別？
HTTP協議傳輸的數據都是未加密的，也就是明文的，因此使用HTTP協議傳輸隱私信息非常不安全，爲了保證這些隱私數據能加密傳輸，於是網景公司設計了SSL（Secure Sockets Layer）協議用於對HTTP協議傳輸的數據進行加密，從而就誕生了HTTPS。簡單來說，HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全。
HTTPS和HTTP的區別主要如下：
1、https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
2、http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議。
3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，後者是443。
4、http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。
http切換到HTTPS
如果需要將網站從http切換到https到底該如何實現呢？
這裏需要將頁面中所有的鏈接，例如js，css，圖片等等鏈接都由http改爲https。例如：http://www.baidu.com改爲https://www.baidu.com
BTW，這裏雖然將http切換爲了https，還是建議保留http。所以我們在切換的時候可以做http和https的兼容，具體實現方式是，去掉頁面鏈接中的http頭部，這樣可以自動匹配http頭和https頭。例如：將http://www.baidu.com改爲//www.baidu.com。然後當用戶從http的入口進入訪問頁面時，頁面就是http，如果用戶是從https的入口進入訪問頁面，頁面即是https的。
1：在使用HTTPS是需要保證服務端配置正確了對應的安全證書
2：客戶端發送請求到服務端
3：服務端返回公鑰和證書到客戶端
4：客戶端接收後會驗證證書的安全性,如果通過則會隨機生成一個隨機數,用公鑰對其加密,發送到服務端
5：服務端接受到這個加密後的隨機數後會用私鑰對其解密得到真正的隨機數,隨後用這個隨機數當做私鑰對需要發送的數據進行對稱加密
6：客戶端在接收到加密後的數據使用私鑰(即生成的隨機值)對數據進行解密並且解析數據呈現結果給客戶
7：SSL加密建立
數字證書：
一個證書包含下面的具體內容：
證書的發佈機構
證書的有效期
公鑰
證書所有者（Subject）
簽名所使用的算法
指紋以及指紋算法
數字證書可以保證數字證書裏的公鑰確實是這個證書的所有者(Subject)的，或者證書可以用來確認對方的身份。
也就是說，我們拿到一個數字證書，我們可以判斷出這個數字證書到底是誰的。
https://wetest.qq.com/lab/view/110.html
1、http爲什麼不安全？
http協議屬於明文傳輸協議，交互過程以及數據傳輸都沒有進行加密，通信雙方也沒有進行任何認證，通信過程非常容易遭遇劫持、監聽、篡改，嚴重情況下，會造成惡意的流量劫持等問題，甚至造成個人隱私泄露（比如銀行卡卡號和密碼泄露）等嚴重的安全問題。
可以把http通信比喻成寄送信件一樣，A給B寄信，信件在寄送過程中，會經過很多的郵遞員之手，他們可以拆開信讀取裏面的內容（因爲http是明文傳輸的）。A的信件裏面的任何內容（包括各類賬號和密碼）都會被輕易竊取。除此之外，郵遞員們還可以僞造或者修改信件的內容，導致B接收到的信件內容是假的。
比如常見的，在http通信過程中，“中間人”將廣告鏈接嵌入到服務器發給用戶的http報文裏，導致用戶界面出現很多不良鏈接； 或者是修改用戶的請求頭URL，導致用戶的請求被劫持到另外一個網站，用戶的請求永遠到不了真正的服務器。這些都會導致用戶得不到正確的服務，甚至是損失慘重。
2、https如何保證安全？
要解決http帶來的問題，就要引入加密以及身份驗證機制。
如果Server（以後簡稱服務器）給Client（以後簡稱 客戶端）的消息是密文的，只有服務器和客戶端才能讀懂，就可以保證數據的保密性。同時，在交換數據之前，驗證一下對方的合法身份，就可以保證通信雙方的安全。那麼，問題來了，服務器把數據加密後，客戶端如何讀懂這些數據呢？這時服務器必須要把加密的密鑰（對稱密鑰，後面會詳細說明）告訴客戶端，客戶端才能利用對稱密鑰解開密文的內容。但是，服務器如果將這個對稱密鑰以明文的方式給客戶端，還是會被中間人截獲，中間人也會知道對稱密鑰，依然無法保證通信的保密性。但是，如果服務器以密文的方式將對稱密鑰發給客戶端，客戶端又如何解開這個密文，得到其中的對稱密鑰呢？
說到這裏，大家是不是有點兒糊塗了？一會兒密鑰，一會兒對稱密鑰，都有點兒被搞暈的節奏。在這裏，提前給大家普及一下，這裏的密鑰，指的是非對稱加解密的密鑰，是用於TLS握手階段的； 對稱密鑰，指的是對稱加解密的密鑰，是用於後續傳輸數據加解密的。下面將詳細說明。
這時，我們引入了非對稱加解密的概念。在非對稱加解密算法裏，公鑰加密的數據，有且只有唯一的私鑰才能夠解密，所以服務器只要把公鑰發給客戶端，客戶端就可以用這個公鑰來加密進行數據傳輸的對稱密鑰。客戶端利用公鑰將對稱密鑰發給服務器時，即使中間人截取了信息，也無法解密，因爲私鑰只部署在服務器，其他任何人都沒有私鑰，因此，只有服務器才能夠解密。服務器拿到客戶端的信息並用私鑰解密之後，就可以拿到加解密數據用的對稱密鑰，通過這個對稱密鑰來進行後續通信的數據加解密。除此之外，非對稱加密可以很好的管理對稱密鑰，保證每次數據加密的對稱密鑰都是不相同的，這樣子的話，即使客戶端病毒拉取到通信緩存信息，也無法竊取正常通信內容。
上述通信過程，可以畫成以下交互圖：
但是這樣似乎還不夠，如果通信過程中，在三次握手或者客戶端發起HTTP請求過程中，客戶端的請求被中間人劫持，那麼中間人就可以僞裝成“假冒客戶端”和服務器通信；中間人又可以僞裝成“假冒服務器”和客戶端通信。接下來，我們詳細闡述中間人獲取對稱密鑰的過程：
中間人在收到服務器發送給客戶端的公鑰（這裏是“正確的公鑰”）後，並沒有發給客戶端，而是中間人將自己的公鑰（這裏中間人也會有一對公鑰和私鑰，這裏稱呼爲“僞造公鑰”）發給客戶端。之後，客戶端把對稱密鑰用這個“僞造公鑰”加密後，發送過程中經過了中間人，中間人就可以用自己的私鑰解密數據並拿到對稱密鑰，此時中間人再把對稱密鑰用“正確的公鑰”加密發回給服務器。此時，客戶端、中間人、服務器都擁有了一樣的對稱密鑰，後續客戶端和服務器的所有加密數據，中間人都可以通過對稱密鑰解密出來。
中間人獲取對稱密鑰的過程如下：
爲了解決此問題，我們引入了數字證書的概念。服務器首先生成公私鑰，將公鑰提供給相關機構（CA），CA將公鑰放入數字證書並將數字證書頒佈給服務器，此時服務器就不是簡單的把公鑰給客戶端，而是給客戶端一個數字證書，數字證書中加入了一些數字簽名的機制，保證了數字證書一定是服務器給客戶端的。中間人發送的僞造證書，不能夠獲得CA的認證，此時，客戶端和服務器就知道通信被劫持了。加入了CA數字簽名認證的SSL會話過程如下所示：
所以綜合以上三點：非對稱加密算法（公鑰和私鑰）交換對稱密鑰+數字證書驗證身份（驗證公鑰是否是僞造的）+利用對稱密鑰加解密後續傳輸的數據=安全
對稱加密算法
對稱加密是指：加密和解密使用相同密鑰的算法。它要求發送方和接收方在安全通信之前，商定一個對稱密鑰。對稱算法的安全性完全依賴於密鑰，密鑰泄漏就意味着任何人都可以對他們發送或接收的消息解密，所以密鑰的保密性對通信至關重要。
有DES、3DES、AES。其中DES是比較老的加密算法，現在已經被證明不安全。而3DES是一個過渡的加密算法，相當於在DES基礎上進行三重運算來提高安全性，但其本質上還是和DES算法一致。而AES是DES算法的替代算法，是現在最安全的對稱加密算法之一。
非對稱加密算法
在非對稱密鑰交換算法出現以前，對稱加密的最主要缺陷就是不知道如何在通信雙方之間傳輸對稱密鑰，而又不讓中間人竊取。非對稱密鑰交換算法誕生之後，專門針對對稱密鑰傳輸做加解密，使得對稱密鑰的交互傳輸變得非常安全了。
其中加密使用的密鑰和解密使用的密鑰是不相同的。
最經典也是最常用的是RSA算法。
1：非對稱加密相比對稱加密更加安全，但也存在兩個致命的缺點：
（1）CPU計算資源消耗非常大。一次完全TLS握手，密鑰交換時的非對稱解密計算量佔整個握手過程的90%以上。而對稱加密的計算量只相當於非對稱加密的0.1%。如果後續的應用層數據傳輸過程也使用非對稱加解密，那麼CPU性能開銷太龐大，服務器是根本無法承受的。賽門特克給出的實驗數據顯示，加解密同等數量的文件，非對稱算法消耗的CPU資源是對稱算法的1000倍以上。
（2）非對稱加密算法對加密內容的長度有限制，不能超過公鑰長度。比如現在常用的公鑰長度是2048位，意味着待加密內容不能超過256個字節。
所以非對稱加解密（極端消耗CPU資源）目前只能用來作對稱密鑰交換或者CA簽名，不適合用來做應用層內容傳輸的加解密。
2：身份認證
https協議中身份認證的部分是由CA數字證書完成的，證書由公鑰、證書主體、數字簽名等內容組成。在客戶端發起SSL請求後，服務端會將數字證書發給客戶端，客戶端會對證書進行驗證（驗證這張證書是否是僞造的？也就是公鑰是否是僞造的），如果證書不是僞造的，客戶端就獲取用於對稱密鑰交換的非對稱密鑰（獲取公鑰）。
3：數字證書有三個作用：
1、身份授權。確保瀏覽器訪問的網站是經過CA驗證的可信任的網站。
2、分發公鑰。每個數字證書都包含了註冊者生成的公鑰（驗證確保是合法的，非僞造的公鑰）。在SSL握手時會通過certificate消息傳輸給客戶端。
3、驗證證書合法性。客戶端接收到數字證書後，會對證書合法性進行驗證。只有驗證通過後的證書，才能夠進行後續通信過程。
https改變了通信方式，它由以前的http—–>tcp，改爲http——>SSL—–>tcp；