分佈式專題（三）HTTPS協議

一、HTTP協議

1. HTTP協議的組成

大家可以通過抓包工具，Fillder 或者其他去抓去一個請求，然後可以看到如下的請求數據和響應數據。分爲兩部分，一個是客戶端的請求信息，一個是服務端的響應信息。抓去到的信息如下

request

response

HTTP/1.1 200 OK
協議版本號 響應狀態碼 狀態碼對應的原因
Server: openresty
Date: Sun, 27 May 2018 12:08:44 GMT
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=20
Access-Control-Allow-Origin: https://www.csdn.net
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: DNT,X�CustomHeader,Keep-Alive,User-Agent,X-Requested�With,If-Modified-Since,Cache-Control,Content�Type,body
2
ok
0

URL

URL(Uniform Resource Locator) 地址用於描述一個網絡上的資源，基本格式
例如：http://www.oracle.com/java/index.html?name=mic#head
schema://host[:port#]/path/.../?[url-params]#[ query-string]
schema ： 指定應用層使用的協議(例如：http, https, ftp)
host ： HTTP服務器的IP地址或者域名
port# ：HTTP服務器的默認端口是80，這種情況下端口號可以省略,如果使用了別的端口，必須指明，例如http://www.oracle.com:8080/
path：訪問資源的路徑
query-string： 查詢字符串
'#' ：片段標識符（使用片段標識符通常可標記出已獲取資源中的子資源（文檔內的某個位置））

URI

URI(Uniform Resource Identifier): 每個 web 服務器資源都有一個名字，這樣客戶端就可以根據這個名字來找到對應的資源，這個資源稱之爲（統一資源標識符)

方法

HTTP 發起的每個請求，都需要告訴告訴服務器要執行什麼動作，那麼這個動作就是前面報文中看到的【method】。 http協議中提供了多個方法， 不同方法的使用場景也也不一樣
GET：一般是用於客戶端發送一個URI地址去獲取服務端的資源（一般用於查詢操作）
POST：一般用戶客戶端傳輸一個實體給到服務端，讓服務端去保存（一般用於創建操作）
PUT：向服務器發送數據，一般用於更新數據的操作（一般用於更新操作）
HEAD：用於向服務端發起一個查詢請求獲取 head 信息，比如獲取index.html的有效性、最近更新時間等。
DELETE：客戶端發起一個Delete請求要求服務端把某個數據刪除（一般用於刪除操作）
OPTIONS：查詢指定URI支持的方法類型（get/post）
http1.1還支持 trace(追蹤路徑)和connect方法類型

2. HTTP 協議的特點?

HTTP 協議是無狀態的，什麼是無狀態呢？就是說 HTTP 協議本身不會對請求和響應之間的通信狀態做保存。

3. 如何實現有狀態的協議?

Http協議中引入了cookie技術，用來解決http協議無狀態的問題。
通過在請求和響應報文中寫入Cookie 信息來控制客戶端的狀態；
Cookie會根據從服務器端發送的響應報文內的一個叫做 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入 Cookie 值後發送出去。 在基於 tomcat 這類的 jsp/servlet 容器中，會提供 session 這樣的機制來保存服務端的對象狀態。

 

4. HTTP 協議的缺陷

1. 通信過程中是使用明文，內容可能會被竊聽
2. 不驗證通信雙方的身份
3. 無法驗證報文的完整性，報文可能被篡改

二、HTTPS協議

1. HTTPS 簡介

由於HTTP協議通信的不安全性，所以人們爲了防止信息在傳輸過程中遭到泄漏或者篡改，就想出來對傳輸通道進行加密的方式https。
https 是一種加密的超文本傳輸協議，它與 HTTP 在協議差異在於對數據傳輸的過程中，https對數據做了完全加密。
由於http協議或者https協議都是處於TCP傳輸層之上，同時網絡協議又是一個分層的結構，所以在tcp協議層之上增加了一層SSL（Secure Socket Layer，安全層）或者TLS（Transport Layer Security） 安全層傳輸協議組合使用用於構造加密通道。

2. HTTPS 的實現原理

 

1. 客戶端發起請求(Client Hello包)
   a) 三次握手，建立TCP連接
   b) 支持的協議版本(TLS/SSL)
   c) 客戶端生成的隨機數client.random，後續用於生成“對話密鑰”
   d) 客戶端支持的加密算法
   e) sessionid，用於保持同一個會話（如果客戶端與服務器費盡周折建立了一個HTTPS鏈接，剛建完就斷了，也太可惜）
2. 服務端收到請求，然後響應（Server Hello）
   a) 確認加密通道協議版本
   b) 服務端生成的隨機數server.random，後續用於生成“對話密鑰”
   c) 確認使用的加密算法（用於後續的握手消息進行簽名防止篡改）
   d) 服務器證書（CA機構頒發給服務端的證書）
3. 客戶端收到證書進行驗證
   a) 驗證證書是否是上級 CA 簽發的, 在驗證證書的時候，瀏覽器會調用系統的證書管理器接口對證書路徑中的所有證書一級一級的進行驗證，
   只有路徑中所有的證書都是受信的，整個驗證的結果纔是受信
   b) 服務端返回的證書中會包含證書的有效期，可以通過失效日期來驗證 證書是否過期
   c) 驗證證書是否被吊銷了
   d) 前面我們知道CA機構在簽發證書的時候，都會使用自己的私鑰對證書進行簽名證書裏的簽名算法字段 sha256RSA 表示 CA 機構使用 sha256對證書進行摘要，然後使用 RSA 算法對摘要進行私鑰簽名，而我們也知道 RSA 算法中，使用私鑰簽名之後，只有公鑰才能進行驗籤。
   e) 瀏覽器使用內置在操作系統上的CA機構的公鑰對服務器的證書進行驗籤。確定這個證書是不是由正規的機構頒發。驗籤之後得知 CA 機構使用 sha256 進行證書摘要，然後客戶端再使用 sha256 對證書內容進行一次摘要， 如果得到的值和服務端返回的證書驗籤之後的摘要相同，表示證書沒有被修改過
   f) 驗證通過後，就會顯示綠色的安全字樣
   g) 客戶端生成隨機數，驗證通過之後，客戶端會生成一個隨機數pre-master secret，客戶端根據之前的：Client.random +sever.random + pre-master生成對稱密鑰然後使用證書中的公鑰進行加密，同時利用前面協商好的加密算法，將握手消息取HASH值，然後用“隨機數加密“握手消息+握手消息HASH值（簽名）”然後傳遞給服務器端；( 在這裏之所以要取握手消息的 HASH值，主要是把握手消息做一個簽名，用於驗證握手消息在傳輸過程中沒有被篡改過。 )
4. 服務端接收隨機數
   a) 服務端收到客戶端的加密數據以後，用自己的私鑰對密文進行解密。然後得到client.random/server.random/pre-master secret. ,再用隨機數密碼 解密 握手消息與 HASH 值，並與傳過來的HASH值做對比確認是否一致。
   b) 然後用隨機密碼加密一段握手消息(握手消息+握手消息的HASH值 )給客戶端
5. 客戶端接收消息
   a) 客戶端用隨機數解密並計算握手消息的HASH，如果與服務端發來的HASH一致，此時握手過程結束
   b) 之後所有的通信數據將由之前交互過程中生成的 pre mastersecret / client.random/server.random，通過算法得出 sessionKey，作爲後續交互過程中的對稱密鑰