HTTPS協(xié)議是什么

????https協(xié)議比http協(xié)議多了一個(gè)s，字面意思上s=secure(安全)论巍。它跟http協(xié)議一樣都是應(yīng)用層協(xié)議，都是工作在TCP協(xié)議之上嘉汰。

????只不過(guò)https協(xié)議在傳輸過(guò)程中的數(shù)據(jù)都是經(jīng)過(guò)了加密状勤。本質(zhì)上HTTPS協(xié)議就是在TCP協(xié)議之上又加了一層SSL協(xié)議來(lái)實(shí)現(xiàn)了加密這個(gè)操作（不準(zhǔn)確的說(shuō)HTTPS就就是披著是SSL的皮的HTTP協(xié)議）

HTTPS和HTTP的區(qū)別

• HTTP協(xié)議工作在80端口，HTTPS協(xié)議工作在443端口
• HTTPS需要申請(qǐng)證書（用于驗(yàn)證服務(wù)器身份）
• HTTP在TCP三次握手建立連接之后即可開始傳輸數(shù)據(jù)持搜；HTTPS協(xié)議則需要在建立TCP連接之后客戶端與服務(wù)器在進(jìn)行SSL加密，確定對(duì)話密鑰残腌，完成加密后才開始傳輸數(shù)據(jù)。
• HTTPS協(xié)議傳輸是密文抛猫，HTTP協(xié)議傳輸是明文

大致的區(qū)別就以上4點(diǎn)，其實(shí)最主要的就是SSL協(xié)議加密對(duì)話產(chǎn)生對(duì)話密鑰的過(guò)程

在了解具體的SSL協(xié)議之前逾滥，先要了解兩個(gè)加密概念

對(duì)稱加密

????同一個(gè)密鑰可以同時(shí)用作信息的加密和解密，這種加密方法稱為對(duì)稱加密寨昙，也被叫做共享密鑰加密。這種方法在網(wǎng)絡(luò)傳輸中有個(gè)問(wèn)題毅待，就是如何把密鑰安全的交付給對(duì)方归榕，因?yàn)閔ttp協(xié)議是明文傳輸（https協(xié)議在建立ssl加密時(shí)都是明文傳輸）,所以密鑰很容易被監(jiān)聽截取，從而失去密鑰本身的意義了刹泄。

公開密鑰加密

????假設(shè)使用者為服務(wù)端，服務(wù)端有兩個(gè)密鑰特石，一個(gè)是私鑰(只能自己悄悄咪咪看的,可以比喻成鑰匙)，一個(gè)是公鑰（隨便哪個(gè)看的都行墩莫，可以比喻成鎖頭）。服務(wù)端將公鑰發(fā)給客戶端狂秦，客戶端使用公鑰對(duì)要發(fā)送的信息進(jìn)行加密推捐，然后發(fā)送給服務(wù)器(用鎖頭把數(shù)據(jù)鎖在箱子里)，由于該信息是通過(guò)服務(wù)端的公鑰進(jìn)行加密的牛柒，只有服務(wù)端使用自己的私鑰才能解析出來(lái)(用鑰匙打開鎖頭，獲取信息)皮壁。因?yàn)樗借€是一直保持在服務(wù)端，而又只有私鑰才能解析出公鑰加密的內(nèi)容蛾魄，所以通過(guò)該種方法實(shí)現(xiàn)了數(shù)據(jù)的安全傳輸协饲。

????但是由于每次都要使用私鑰去解析公鑰缴川，才能獲取到數(shù)據(jù)描馅，如果公鑰很長(zhǎng)的話，其中的運(yùn)算量會(huì)很大铭污，占用CPU性能，從而使得網(wǎng)絡(luò)延遲加大嘹狞。

HTTPS協(xié)議同時(shí)使用了這兩種方式，即先通過(guò)公開密鑰加密的方式產(chǎn)生一個(gè)對(duì)話密鑰谈截，在使用對(duì)話密鑰進(jìn)行對(duì)稱加密的方式傳輸數(shù)據(jù)。

SSL協(xié)議

1. 客戶端向服務(wù)器發(fā)送請(qǐng)求
   
   請(qǐng)求中包含

    支持的SSL協(xié)議版本
    客戶端生成的隨機(jī)數(shù)（第一個(gè)隨機(jī)數(shù)）
    支持的加密方法
    支持的壓縮方法
   

2. 服務(wù)器接收到客戶端請(qǐng)求簸喂，并且向客戶端發(fā)送響應(yīng)
   響應(yīng)包括

   確認(rèn)協(xié)議版本
   服務(wù)器生產(chǎn)的隨機(jī)數(shù)（第二個(gè)隨機(jī)數(shù)）
   確定加密的方法
   服務(wù)器的證書（服務(wù)器的公鑰在里面）
   

3. 客戶端接收到請(qǐng)求燎潮，對(duì)證書進(jìn)行校驗(yàn)（校驗(yàn)證書的頒布機(jī)構(gòu)，證書中的域名和實(shí)際域名是否一致确封，證書是否過(guò)期，如果不符合爪喘，瀏覽器會(huì)顯示警告）,如果通過(guò)了校驗(yàn),客戶端將會(huì)發(fā)送回應(yīng)
   請(qǐng)求包括

   客戶端生成一個(gè)隨機(jī)數(shù)，并且該隨機(jī)數(shù)通過(guò)服務(wù)器的公鑰進(jìn)行加密（第三個(gè)隨機(jī)數(shù)）
   編碼改變通知（表示之后的通信都會(huì)通過(guò)雙方商定的加密算法進(jìn)行通信）
   客戶端握手結(jié)束通知泛啸，表示客戶端的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值候址，用來(lái)供服務(wù)器校驗(yàn)种柑。
   

4. 服務(wù)器接收到最后的回應(yīng)之后，使用服務(wù)器的私鑰來(lái)解析出客戶端發(fā)送過(guò)來(lái)的第三個(gè)隨機(jī)數(shù)聚请，并且使用與客戶端約定好的加密算法將一共三個(gè)隨機(jī)數(shù)生成對(duì)話密鑰稳其。服務(wù)器返回響應(yīng)

   編碼改變通知（表示之后的通信都會(huì)通過(guò)雙方商定的加密算法進(jìn)行通信）
   服務(wù)器握手結(jié)束通知炸卑，表示服務(wù)器的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值盖文，用來(lái)供客戶端校驗(yàn)。
   

????整個(gè)SSL協(xié)議的加密過(guò)程大致就是這樣五续，加密對(duì)話的過(guò)程都是明文傳輸?shù)模ㄒ驗(yàn)镠TTPS還沒(méi)帶搭建起來(lái)的嘛）洒敏。

????整個(gè)加密過(guò)程的核心就是客戶端與服務(wù)器產(chǎn)生的三個(gè)隨機(jī)數(shù)凶伙，這三個(gè)隨機(jī)數(shù)是用于產(chǎn)生后續(xù)數(shù)據(jù)傳輸?shù)募用苊荑€的。從上面的過(guò)程可以看出函荣，這三個(gè)隨機(jī)數(shù)都是可以別竊取的，但是由于第三個(gè)隨機(jī)數(shù)使用了服務(wù)器的公鑰進(jìn)行了公開密鑰加密傳輸偏竟，理論上只有使用服務(wù)器的私鑰才能解析出第三個(gè)隨機(jī)數(shù)敞峭。所以最后使用這三個(gè)隨機(jī)數(shù)生成的對(duì)話私鑰是安全的，之后的數(shù)據(jù)傳輸都會(huì)使用這個(gè)對(duì)話私鑰進(jìn)行加密（對(duì)稱加密）旋讹，從而保證了傳輸?shù)陌踩杂直ＷC了數(shù)據(jù)傳輸?shù)男省?/p>