目錄導航
前言
1.瞭解客戶端和服務端的請求原理
2.HTTP 協議及其組成
3.Https 交互原理分析
Http 協議的組成
大家可以通過抓包工具，Fillder 或者其他去抓去一個請求，然後可以看到如下的請求數據和響應數據。分爲兩部分，一個是客戶端的請求信息，一個是服務端的響應信息。抓去到的信息如下
request
POST https://re.csdn.net/csdnbi HTTP/1.1 方法 url/uri 協議的版本號 1.1
Host: re.csdn.net
Connection: keep-alive
Content-Length: 167
Accept: */*
Origin: https://www.csdn.net User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.23 Safari/537.36 Content-Type: text/plain;charset=UTF-8 Referer: https://www.csdn.net/ Accept-Encoding: gzip, deflate, br Accept-Language: zh-CN,zh;q=0.9
Cookie: uuid_tt_dd=10_19119862890-1514946902631-
786149;
__utma=17226283.1502834598.1514952032.1514952032.
1514952032.1;
__utmz=17226283.1514952032.1.1.utmcsr=(direct)|ut
mccn=(direct)|utmcmd=(none); kd_user_id=accb9177-
52d8-41f3-b69e-54bb338ffb23; UN=q331464542;
UM_distinctid=1610314af5bb3a-012f62bad56aa5-
71103742-1fa400-1610314af5ca34;
Hm_ct_6bcd52f51e9b3dce32bec4a3997715ac=1788*1*PC_
VC; BT=1523867282719;
smidV2=20180517165125ad3024b867497a0fbd79f81ef81c
dd4400ceee13dc5e27d30;
dc_session_id=10_1527227855207.688716;
Hm_lvt_6bcd52f51e9b3dce32bec4a3997715ac=152741308
2,1527413263,1527413731,1527415074;
Hm_lpvt_6bcd52f51e9b3dce32bec4a3997715ac=15274229
24; dc_tos=p9dz2k
--------------
[{"headers":{"component":"enterprise","datatype": "re","version":"v1"},"body":"{\"re\":\"ref=-&mtp=4&mod=ad_popu_131&con=ad_content_2961%2Cad_o rder_731&uid=-&ck=-\"}"}]
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（Uniform Resource Locator）
URL(Uniform Resource Locator) 地址用於描述一個網絡上的資源，基本格式
例如：
http://www.gupaoedu.com:80/java/index.html?name=mic#head schema://host[:port#]/path/…/?[url-params]#[ query-string]
scheme 指定應用層使用的協議(例如：http, https, ftp)
host HTTP 服務器的 IP 地址或者域名
port# HTTP 服務器的默認端口是 80，這種情況下端
口 號 可 以 省 略 。 如 果 使 用 了 別 的 端 口 ， 必 須 指 明 ， 例 如 http://www.gupaoedu.com:8080/
path 訪問資源的路徑
query-string 查詢字符串
# 片段標識符（使用片段標識符通常可標記出已
獲取資源中的子資源（文檔內的某個位置））
URI(Uniform Resource Identifier)
每個 web 服務器資源都有一個名字，這樣客戶端就可以根據這個名字來找到對應的資源，這個資源稱之爲（統一資源標識符）
總的來說：URI 是用一個字符串來表示互聯網上的某一個資源。而 URL 表示資源的地點（互聯網所在的位置）
方法
HTTP 發起的每個請求，都需要告訴告訴服務器要執行什麼動作，那麼
這個動作就是前面報文中看到的【method】。http 協議中提供了多個方
法，不同方法的使用場景也也不一樣
GET：一般是用於客戶端發送一個 URI 地址去獲取服務端的資源（一般
用於查詢操作）
POST：一般用戶客戶端傳輸一個實體給到服務端，讓服務端去保存（一
般用於創建操作）
PUT：向服務器發送數據，一般用於更新數據的操作
HEAD：用於向服務端發起一個查詢請求獲取 head 信息，比如獲取
index.html 的有效性、最近更新時間等。
DELETE：客戶端發起一個 Delete 請求要求服務端把某個數據刪除（一般用於刪除操作）
OPTIONS：查詢指定 URI 支持的方法類型（get/post）
http1.1 還支持 trace(追蹤路徑)和 connect 方法類型
HTTP 協議的特點
HTTP 協議是無狀態的，什麼是無狀態呢？就是說 HTTP 協議本身不會對請求和響應之間的通信狀態做保存。
如何實現有狀態的協議
Http 協議中引入了 cookie 技術，用來解決 http 協議無狀態的問題。通
過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態；Cookie會根據從服務器端發送的響應報文內的一個叫做 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入 Cookie 值後發送出去。在基於 tomcat 這類的 jsp/servlet 容器中，會提供 session 這樣的機制來保存服務端的對象狀態。那麼整個狀態協議的流程就是這樣的
HTTP 協議的缺陷
1.通信過程中是使用明文，內容可能會被竊聽
2.不驗證通信雙方的身份
3.無法驗證報文的完整性，報文可能被篡改
HTTPS 的原理
HTTPS 簡介
由於 HTTP 協議通信的不安全性，所以人們爲了防止信息在傳輸過程中遭到泄漏或者篡改，就想出來對傳輸通道進行加密的方式 https。 https 是一種加密的超文本傳輸協議，它與 HTTP 在協議差異在於對數據傳輸的過程中，https 對數據做了完全加密。由於 http 協議或者 https 協議都是處於 TCP 傳輸層之上，同時網絡協議又是一個分層的結構，所以在 tcp 協議層之上增加了一層 SSL（Secure Socket Layer，安全層）或者 TLS（Transport Layer Security） 安全層傳輸協議組合使用用於構造加密通道；
HTTPS 的實現原理
- 客戶端發起請求(Client Hello 包)
- 三次握手，建立 TCP 連接
- 支持的協議版本(TLS/SSL)
- 客戶端生成的隨機數 client.random，後續用於生成“對話密鑰”
- 客戶端支持的加密算法
- sessionid，用於保持同一個會話（如果客戶端與服務器費盡周折建立了一個 HTTPS 鏈接，剛建完就斷了，也太可惜）
- 服務端收到請求，然後響應（Server Hello）
- 確認加密通道協議版本
- 服務端生成的隨機數 server.random，後續用於生成“對話密鑰”
- 確認使用的加密算法（用於後續的握手消息進行簽名防止篡改）
- 服務器證書（CA 機構頒發給服務端的證書）
- 客戶端收到證書進行驗證
- 驗證證書是否是上級 CA 簽發的, 在驗證證書的時候，瀏覽器會調用系統的證書管理器接口對證書路徑中的所有證書一級一級的進行驗證，只有路徑中所有的證書都是受信的，整個驗證的結果纔是受信
- 服務端返回的證書中會包含證書的有效期，可以通過失效日期來驗證 證書是否過期
- 驗證證書是否被吊銷了
- 前面我們知道 CA 機構在簽發證書的時候，都會使用自己的私鑰對證書進行簽名，證書裏的簽名算法字段 sha256RSA 表示 CA 機構使用 sha256
對證書進行摘要，然後使用 RSA 算法對摘要進行私鑰簽名，而我們也知道 RSA 算法中，使用私鑰簽名之後，只有公鑰才能進行驗籤。 - 瀏覽器使用內置在操作系統上的 CA 機構的公鑰對服務器的證書進行驗籤。確定這個證書是不是由正規的機構頒發。驗籤之後得知 CA 機構使用 sha256 進行證書摘要，然後客戶端再使用sha256 對證書內容進行一次摘要，如果得到的值和服務端返回的證書驗籤之後的摘要相同，表示證書沒有被修改過
- 驗證通過後，就會顯示綠色的安全字樣
- 客戶端生成隨機數，驗證通過之後，客戶端會生成一個隨機數
pre-master secret ，客戶端根據之前的： Client.random + sever.random + pre-master 生成對稱密鑰然後使用證書中的公鑰進行加密，同時利用前面協商好的加密算法，將握手消息取 HASH 值，然後用“隨機數加密“握手消息+握手消息 HASH 值（簽名）”然後傳遞給服務器端；(在這裏之所以要取握手消息的 HASH 值，主要是把握手消息做一個簽名，用於驗證握手消息在傳輸過程中沒有被篡改過。)
- 服務端接收隨機數
- 服務端收到客戶端的加密數據以後，用自己的私鑰對密文進行解密。然後得到 client.random/server.random/pre-master secret. ,再用隨機數密碼 解密 握手消息與 HASH 值，並與傳過來的 HASH 值做對比確認是否一致。
- 然後用隨機密碼加密一段握手消息 (握手消息 +握手消息的HASH 值 )給客戶端
- 客戶端接收消息
- 客戶端用隨機數解密並計算握手消息的 HASH，如果與服務端發來的 HASH 一致，此時握手過程結束，
- 之後所有的通信數據將由之前交互過程中生成的 pre master secret / client.random/server.random 通過算法得出 session Key，作爲後續交互過程中的對稱密鑰
後記
鏈接：推薦PDF
