HTTPS
HTTPS即加密的HTTP，HTTPS并不是一個新協(xié)議明也，而是HTTP+SSL（TLS）宣虾。原本HTTP先和TCP（假定傳輸層是TCP協(xié)議）直接通信，而加了SSL后温数，就變成HTTP先和SSL通信绣硝，再由SSL和TCP通信，相當于SSL被嵌在了HTTP和TCP之間撑刺。
我們首先了解幾個基本概念鹉胖。
共享密鑰加密（對稱密鑰加密）：加密和解密同用一個密鑰。加密時就必須將密鑰傳送給對方够傍，那么如何安全的傳輸呢甫菠？
公開密鑰加密（非對稱密鑰加密）：公開密鑰加密使用一對非對稱的密鑰。一把叫做私有密鑰冕屯，一把叫做公開密鑰寂诱。私有密鑰不能讓其他任何人知道，而公開密鑰則可以隨意發(fā)布愕撰，任何人都可以獲得刹衫。使用此加密方式醋寝，發(fā)送密文的一方使用公開密鑰進行加密處理，對方收到被加密的信息后带迟，再使用自己的私有密鑰進行解密音羞。利用這種方式，不需要發(fā)送用來解密的私有密鑰仓犬，也不必擔心密鑰被攻擊者竊聽盜走嗅绰。
但由于公開密鑰比共享密鑰要慢，所以我們就需要綜合一下他們兩者的優(yōu)缺點搀继，使他們共同使用窘面，而這也是HTTPS采用的加密方式。在交換密鑰階段使用公開密鑰加密方式叽躯，之后建立通信交換報文階段則使用共享密鑰加密方式财边。
這里就有一個問題，如何證明公開密鑰本省是貨真價實的公開密鑰点骑。如酣难，正準備和某臺服務(wù)器建立公開密鑰加密方式下的通信時，如何證明收到的公開密鑰就是原本預(yù)想的那臺服務(wù)器發(fā)行的公開密鑰黑滴『┠迹或許在公開密鑰傳輸過程中，真正的公開密鑰已經(jīng)被攻擊者替換掉了袁辈。為了解決這個問題菜谣，可以使用由數(shù)字證書認證機構(gòu)（CA，Certificate Authority）和其他相關(guān)機關(guān)頒發(fā)的公開密鑰證書晚缩。
下圖是https通信步驟圖：
下面是詳細步驟：
步驟 1： 客戶端通過發(fā)送 Client Hello 報文開始 SSL 通信尾膊。報文中包
含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所
使用的加密算法及密鑰長度等）荞彼。
步驟 2： 服務(wù)器可進行 SSL 通信時眯停，會以 Server Hello 報文作為應(yīng)
答。和客戶端一樣卿泽，在報文中包含 SSL 版本以及加密組件。服務(wù)器的
加密組件內(nèi)容是從接收到的客戶端加密組件內(nèi)篩選出來的滋觉。
步驟 3： 之后服務(wù)器發(fā)送 Certificate 報文签夭。報文中包含公開密鑰證
書。
步驟 4： 最后服務(wù)器發(fā)送 Server Hello Done 報文通知客戶端椎侠，最初階
段的 SSL 握手協(xié)商部分結(jié)束第租。
步驟 5： SSL 第一次握手結(jié)束之后，客戶端以 Client Key Exchange 報
文作為回應(yīng)我纪。報文中包含通信加密中使用的一種被稱為 Pre-master
secret 的隨機密碼串慎宾。該報文已用步驟 3 中的公開密鑰進行加密丐吓。
步驟 6： 接著客戶端繼續(xù)發(fā)送 Change Cipher Spec 報文。該報文會提
示服務(wù)器趟据，在此報文之后的通信會采用 Pre-master secret 密鑰加密券犁。
步驟 7： 客戶端發(fā)送 Finished 報文。該報文包含連接至今全部報文的
整體校驗值汹碱。這次握手協(xié)商是否能夠成功粘衬，要以服務(wù)器是否能夠正確
解密該報文作為判定標準。
步驟 8： 服務(wù)器同樣發(fā)送 Change Cipher Spec 報文咳促。
步驟 9： 服務(wù)器同樣發(fā)送 Finished 報文稚新。
步驟 10： 服務(wù)器和客戶端的 Finished 報文交換完畢之后，SSL 連接
就算建立完成跪腹。當然褂删，通信會受到 SSL 的保護。從此處開始進行應(yīng)用
層協(xié)議的通信冲茸，即發(fā)送 HTTP 請求屯阀。
步驟 11： 應(yīng)用層協(xié)議通信，即發(fā)送 HTTP 響應(yīng)噪裕。
步驟 12： 最后由客戶端斷開連接蹲盘。斷開連接時，發(fā)送 close_notify 報
文膳音。上圖做了一些省略召衔，這步之后再發(fā)送 TCP FIN 報文來關(guān)閉與 TCP
的通信。
在以上流程中祭陷，應(yīng)用層發(fā)送數(shù)據(jù)時會附加一種叫做MAC（Message Authentication Cods）的報文摘要苍凛。MAC能夠查知報文是否遭到篡改從，從而保護報文的完整性兵志。
