HTTPS協(xié)議的原理及其與HTTP協(xié)議的區(qū)別是什么

這篇文章給大家介紹HTTPS協(xié)議的原理及其與HTTP協(xié)議的區(qū)別是什么，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

HTTPS協(xié)議是什么

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

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

2

HTTPS和HTTP的區(qū)別

• HTTP協(xié)議工作在80端口，HTTPS協(xié)議工作在443端口

• HTTPS需要申請證書（用于驗證服務(wù)器身份）

• HTTP在TCP三次握手建立連接之后即可開始傳輸數(shù)據(jù)；HTTPS協(xié)議則需要在建立TCP連接之后客戶端與服務(wù)器在進(jìn)行SSL加密，確定對話密鑰，完成加密后才開始傳輸數(shù)據(jù)。

• HTTPS協(xié)議傳輸是密文，HTTP協(xié)議傳輸是明文

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

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

3

對稱加密

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

公開密鑰加密

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

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

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

SSL協(xié)議

• 客戶端向服務(wù)器發(fā)送請求 請求中包含

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

• 服務(wù)器接收到客戶端請求，并且向客戶端發(fā)送響應(yīng)

  響應(yīng)包括

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

• 客戶端接收到請求，對證書進(jìn)行校驗（校驗證書的頒布機構(gòu)，證書中的域名和實際域名是否一致，證書是否過期，如果不符合，瀏覽器會顯示警告）,如果通過了校驗,客戶端將會發(fā)送回應(yīng)

  請求包括

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

• 服務(wù)器接收到最后的回應(yīng)之后，使用服務(wù)器的私鑰來解析出客戶端發(fā)送過來的第三個隨機數(shù)，并且使用與客戶端約定好的加密算法將一共三個隨機數(shù)生成對話密鑰。服務(wù)器返回響應(yīng)

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

整個SSL協(xié)議的加密過程大致就是這樣，加密對話的過程都是明文傳輸?shù)模ㄒ驗镠TTPS還沒帶搭建起來的嘛）。

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

關(guān)于HTTPS協(xié)議的原理及其與HTTP協(xié)議的區(qū)別是什么就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。