HTTP
當你在瀏覽器輸入一個網(wǎng)址 (例如 http://nosee123.com)的時候症歇，瀏覽器發(fā)起一個 HTTP 請求猜扮，帶著請求信息 (參見HTTP協(xié)議詳解)勉吻，連接到服務器，把請求信息遞給服務器旅赢，服務器收到信息之后齿桃，解析相關的信息，然后進行處理煮盼，再返回瀏覽器請求的數(shù)據(jù)短纵。
簡單來說是這么一個流程：
小明跟瀏覽器爸爸說我想要去中關村某個店家拿一些東西 (發(fā)起請求)
瀏覽器爸爸就把小明要的東西記在一張清單上 (生成HTTP協(xié)議)
然后瀏覽器爸爸派出一個線程小弟，噌噌噌跑到中關村的店里僵控，把清單遞給店家香到，說小明要這些東西 (進行傳輸)
店家讓線程小弟稍等，然后去屋子里面拿小明的這些東西 (服務器收到請求)
店家把東西拿出來后报破，并且也打印了一份清單悠就，讓線程小弟帶著清單和東西一起拿回去 (服務器處理請求完畢)
然后線程小弟回到瀏覽器爸爸那邊，把服務器給的清單和物品交給瀏覽器爸爸充易，瀏覽器爸爸根據(jù)清單核對物品 (瀏覽器處理響應)
然后把物品打包交給了小明(瀏覽器渲染并呈現(xiàn)界面)
看圖說話：
這其中有個問題梗脾，瀏覽器爸爸和服務器都沒有驗證清單信息的有效性和對方的身份。萬一有人在中間把線程小哥攔下來蔽氨，暴揍一頓藐唠，然后把物品清單給換了怎么辦？或者有人把線程小哥在半路上暴揍一頓鹉究，拿了清單換了另外一個小哥怎么辦？
這是個很嚴肅的問題：假如服務器要把一些東西鎖在柜子里踪宠，需要小明給密碼才可以打開柜子自赔。然后小明把密碼寫在清單上讓瀏覽器爸爸交給服務器。這時候柳琢，如果這張清單被人攔截下來绍妨，不就得到了小明的密碼润脸？
簡單來說，傳輸?shù)男畔⒅邪脩裘艽a他去，被攔截了怎么辦毙驯？
HTTPS
正因為HTTP請求有這些安全性的問題，所以HTTPS誕生了灾测，致力于解決了這些安全性問題爆价，我們進行一下對比：
那么HTTPS是如何做到更安全的呢？
簡單來說媳搪，HTTPS 即是在 HTTP 下加入了一層 SSL 加密铭段，所以被稱為HTTPS。具體的加密過程則是 公匙加密法：
客戶端向服務器索要公匙秦爆，然后使用公匙加密信息
服務器收到加密后的信息序愚，用自己的私匙解密
公匙密碼和算法都是公開的，而私匙則是保密的等限。加密使用的公匙和解碼使用的密匙都是不相同的爸吮，因此這是一個非對稱加密算法。
SSL
HTTPS望门，也稱作HTTP over TLS形娇。TLS的前身是SSL，TLS 1.0通常被標示為SSL 3.1怒允，TLS 1.1為SSL 3.2埂软，TLS 1.2為SSL 3.3。
TLS協(xié)議包括TLS Record Protocol和TLS Handshake Protocol纫事。
下圖描述了在TCP/IP協(xié)議棧中TLS(各子協(xié)議）和HTTP的關系:
數(shù)字證書
提及 HTTPS 勘畔，就會聽到大家說需要證書才能部署，那么什么是證書呢丽惶？
因為互聯(lián)網(wǎng)不安全炫七，公匙也是信息的一部分，也是會有被篡改的風險的钾唬。所以引入了互聯(lián)網(wǎng)權(quán)威機構(gòu) - CA 機構(gòu)万哪，又稱為證書授權(quán) (Certificate Authority) 機構(gòu)，瀏覽器會內(nèi)置這些"受信任的根證書頒發(fā)機構(gòu)" (即 CA)抡秆。
服務端向權(quán)威的身份鑒定 CA 機構(gòu)申請數(shù)字證書奕巍，CA 機構(gòu)驗證了網(wǎng)站之后，會把網(wǎng)站錄入到內(nèi)部列表儒士，采用 Hash 把服務端的一些相關信息生成摘要的止，然后 CA 機構(gòu)用自己的私匙，把服務端的公匙和相關信息一起加密着撩，然后給申請證書的服務端頒發(fā)數(shù)字證書诅福，用于其他客戶端 (比如瀏覽器) 認證這個網(wǎng)站的公匙匾委。
客戶端通過服務端下發(fā)的證書，找到對應的 CA氓润，然后向 CA 驗證這個證書是否有效赂乐，CA 驗證通過之后，下發(fā)服務端的公匙咖气。
因為 CA 是權(quán)威并且可信的挨措，所以客戶端 (瀏覽器) 信任 CA，而 CA 又信任經(jīng)過認證的服務端 采章，所以客戶端 (瀏覽器) 也信任這個服務端运嗜，這就是信任鏈 (Chain Of Trust)。
而 CA 頒發(fā)的數(shù)字證書悯舟，一般包含這些信息：
簡單來說：為了保證公匙是安全的担租，所以通過數(shù)字證書驗證公匙。
加密通信
一條完整的HTTPS請求應該是這樣的：
客戶端 (瀏覽器) 發(fā)起 HTTP 請求抵怎，請求連接服務端奋救，發(fā)送支持的加密通信協(xié)議 (和版本)，并且生成一個隨機數(shù)反惕，后續(xù)用于生成"對話密鑰"尝艘。
服務端確認加密通信協(xié)議 (和版本)，同時也生成一個隨機數(shù)姿染，后續(xù)用于生成"對話密匙"背亥，并且將 CA 頒發(fā)的數(shù)字證書，一起發(fā)送給客戶端悬赏。
客戶端收到數(shù)字證書后狡汉，檢測內(nèi)置的"受信任的根證書頒發(fā)機構(gòu)"，查看解開數(shù)字證書的公匙是否在闽颇。
如果解開數(shù)字證書的公匙存在盾戴，則使用它解開數(shù)字證書，得到正確的服務器公匙兵多，同時再次生成一個隨機數(shù)尖啡，用于服務器公匙加密，并發(fā)送給服務器剩膘。
此時本地和服務器同時將三個隨機數(shù)衅斩，根據(jù)約定的加密方法進行加密，各自生成本次會話的所使用的同一把 "會話密匙" 怠褐。
到這里矛渴，認證階段已經(jīng)完畢，數(shù)據(jù)傳輸從非對稱加密換成了對稱加密(因為考慮到性能)惫搏，接下來所有的數(shù)據(jù)傳輸都是使用HTTP協(xié)議進行傳輸具温，只不過使用了 "會話密匙" 來加密內(nèi)容。
見下圖：
參考文獻：
linkFly的個人博客：什么是 HTTPS
MSDN博客：SSL Handshake and HTTPS Bindings on IIS
阮一峰的網(wǎng)絡日志：數(shù)字簽名是什么筐赔？铣猩、SSL/TLS協(xié)議運行機制的概述
其它網(wǎng)絡文章：What is a Digital Signature
