首先，需要知道 HTTP 和 HTTPS 是什么。

HTTP 是超文本傳輸協(xié)議，是一個基于請求與響應(yīng)，無狀態(tài)的，應(yīng)用層的協(xié)議，常基于 TCP/IP 協(xié)議傳輸數(shù)據(jù)，是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。

也就是說客戶端和網(wǎng)站服務(wù)器之間傳遞信息是需要使用 HTTP 協(xié)議的。但是 HTTP 協(xié)議以明文方式發(fā)送內(nèi)容，不提供任何方式的數(shù)據(jù)加密。

HTTP 是明文傳輸?shù)模捅夭豢擅獯嬖谌缦聠栴}：

• 重要數(shù)據(jù)被明文獲?。喝绻粽呓厝×丝蛻舳撕途W(wǎng)站服務(wù)器之間的傳輸報文，就可以直接讀懂其中的信息。一般獲取簡單數(shù)據(jù)用于展示的，可能無所謂以上的安全缺陷。但假如涉及類似銀行密碼的數(shù)據(jù)，就必須慎重考慮這一點了。因此，HTTP 協(xié)議不適合傳輸一些敏感信息。

• 通信雙方可能被假冒，就是第三方攻擊者會冒充客戶端向服務(wù)端請求內(nèi)容，或者冒充服務(wù)端給客戶端提供錯誤信息。這也是非常不安全的。

• 數(shù)據(jù)被篡改：再有就是通信內(nèi)容也特別容易被截獲篡改。

為了解決 HTTP 協(xié)議的這一缺陷，需要使用另一種協(xié)議：安全套接字層超文本傳輸協(xié)議，也就是 HTTPS。

HTTPS 是一種通過計算機網(wǎng)絡(luò)進行安全通信的傳輸協(xié)議。為了數(shù)據(jù)傳輸?shù)陌踩琀TTPS 在 HTTP 的基礎(chǔ)上加入了 SSL/TLS 協(xié)議。SSL 依靠證書來驗證服務(wù)器的身份，并為客戶端和服務(wù)器之間的通信加密。

所以說?HTTP + 加密 + 認證 + 完整性保護 = HTTPS

HTTPS 使用的主要目的是提供對網(wǎng)站服務(wù)器的身份認證，同時保護交換數(shù)據(jù)的隱私與完整性。

那這兩個協(xié)議的通信過程又是怎么樣的呢？

HTTP 通信過程

在 HTTP 工作開始之前，客戶端首先要通過網(wǎng)絡(luò)與服務(wù)端建立連接，該連接是通過 TCP 來完成的。連接的服務(wù)端端口號是 80。

TCP 連接要進行三次握手，通俗一點來說，就是圖中這樣的過程，客戶端先和服務(wù)端打招呼；然后服務(wù)端收到信息后就要給客戶端進行回復(fù)，并且問客戶端是否能收到自己的消息；接下來客戶端收到服務(wù)端信息后需要再告訴服務(wù)端可以收到信息，連接成功，接下來要開始發(fā)送數(shù)據(jù)了。

一旦建立了 TCP 連接客戶端就會服務(wù)端發(fā)送請求命令

例如：GET/sample/hello.jsp HTTP/1.1。

客戶端發(fā)送請求命令之后，還要以頭信息的形式服務(wù)端發(fā)送一些別的信息，之后瀏覽器發(fā)送了一空白行來通知服務(wù)器，它已經(jīng)結(jié)束了該頭信息的發(fā)送。

接下來如果有請求體的話客戶端會繼續(xù)向服務(wù)端發(fā)送請求體的信息。

客戶端向服務(wù)端發(fā)出請求后，服務(wù)端會給客戶端返回響應(yīng)。

響應(yīng)的第一部分是協(xié)議的版本號和響應(yīng)狀態(tài)碼。

接下來服務(wù)端也會發(fā)送響應(yīng)頭信息。

服務(wù)端向客戶端發(fā)送頭信息后，它會發(fā)送一個空白行來表示頭信息的發(fā)送到此為結(jié)束，接著，它就以 Content-Type 響應(yīng)頭信息所描述的格式發(fā)送用戶所請求的實際數(shù)據(jù)。

一般情況下，一旦服務(wù)端向客戶端發(fā)送了響應(yīng)數(shù)據(jù)，它就要關(guān)閉 TCP 連接。關(guān)閉時需要進行四次揮手。

客戶端會告訴服務(wù)端數(shù)據(jù)已經(jīng)發(fā)送完畢；服務(wù)端回復(fù)收到了客戶端的信息，并且需要確認服務(wù)端信息是否發(fā)完；確認完畢后服務(wù)端告訴客戶端信息已經(jīng)發(fā)送完畢了；接下來客戶端通知服務(wù)端收到了消息，正式斷開連接。

但是如果客戶端或者服務(wù)端在頭信息加入了

Connection:keep-alive

那么 TCP 連接在發(fā)送后將仍然保持打開狀態(tài)，于是，客戶端可以繼續(xù)通過相同的連接發(fā)送請求。保持連接節(jié)省了為每個請求建立新連接所需的時間，還節(jié)約了網(wǎng)絡(luò)帶寬。

這就是整個 HTTP 協(xié)議通信的過程

HTTPS 通信過程

前面已經(jīng)介紹過了，為了數(shù)據(jù)傳輸?shù)陌踩?，HTTPS 在 HTTP 的基礎(chǔ)上加入了 SSL/TLS 協(xié)議。那 SSL/TLS 協(xié)議要連接也是需要進行握手的，下面我們就來看一下具體過程。

• ClientHello：首先客戶端發(fā)起 HTTPS 請求，然后連接到服務(wù)端的 443 端口?？蛻舳藭?SSL/TLS 版本、客戶端的隨機數(shù)、加密組件（cipher suites）列表、支持的壓縮方法等等都一起傳給服務(wù)端。

• ServerHello：服務(wù)端表示收到信息，并且會根據(jù) ClientHello 選擇好 SSL/TLS 版本和加密組件，并且把選擇好的版本組件以及服務(wù)端的隨機數(shù)發(fā)送給客戶端。

• Certificate：接下來服務(wù)端會把包含公鑰的數(shù)字證書也發(fā)送給客戶端。采用 HTTPS 協(xié)議的服務(wù)器必須要有一套數(shù)字證書，可以自己制作，也可以向 CA 組織申請。區(qū)別就是自己頒發(fā)的證書需要客戶端驗證通過，才可以繼續(xù)訪問，而使用受信任的公司申請的證書則不會彈出提示頁面。數(shù)字證書包括了括了加密后服務(wù)器的公鑰、權(quán)威機構(gòu)的信息、服務(wù)器域名，還有經(jīng)過CA私鑰簽名之后的證書內(nèi)容，簽名計算方法以及證書對應(yīng)的域名等信息。

• ServerHelloDone：通知客戶端，最初階段的握手協(xié)商完成了。

• 驗證數(shù)字證書：客戶端的 SSL/TLS 來完成數(shù)字證書驗證，首先會驗證公鑰是否有效，比如頒發(fā)機構(gòu)，過期時間等等，如果發(fā)現(xiàn)異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那么就生成一個隨機值 pre_master。

• ClientKeyExchange：通過客戶端隨機數(shù)、服務(wù)端隨機數(shù)和剛生成的 pre_master 生成會話密鑰，這個會話密鑰是對稱加密密鑰。只要安全發(fā)送給服務(wù)端，后面就可以使用這個會話密鑰加密信息、解密信息了。要安全的發(fā)送這個會話密鑰，需要使用服務(wù)端發(fā)送過來的公開密鑰把它加密一下。

• ChangeCipherSpec：把加密過的會話密鑰發(fā)送給服務(wù)端

• Finished：告訴服務(wù)后，后面發(fā)送的信息都會使用會話密鑰加密了。如果驗證失敗，這次握手就失敗了，關(guān)閉。

• 服務(wù)端驗證會話密鑰：服務(wù)端用私鑰解密后，得到了客戶端傳過來的會話密鑰。

• ChangeCipherSpec：告訴客戶端，會話密鑰已經(jīng)收到，從現(xiàn)在起所有我發(fā)的信息都會使用會話密鑰盡心加密了！

• Finished：我的信息發(fā)送完畢了。

• HTTP request/response：接下來就可以進行加密信息的發(fā)送了。

• close_notify：最后由客戶端通知服務(wù)端進行關(guān)閉，發(fā)送 close_notify 報文。當然此時關(guān)閉的是 SSL/TLS 連接，繼續(xù)下一層 TCP 的四次揮手依舊會進行。

這就是 HTTPS 協(xié)議的通信過程。