目錄導航
- 前言
- Http 協定的組成
- URL（Uniform Resource Locator）
- URI(Uniform Resource Identifier)
- 方法
- HTTP 協定的特點
- 如何實作有狀态的協定
- HTTP 協定的缺陷
- HTTPS 的原理
- HTTPS 簡介
- HTTPS 的實作原理
- 後記
1.了解用戶端和服務端的請求原理
2.HTTP 協定及其組成
3.Https 互動原理分析
大家可以通過抓包工具，Fillder 或者其他去抓去一個請求，然後可以看到如下的請求資料和響應資料。分為兩部分，一個是用戶端的請求資訊，一個是服務端的響應資訊。抓去到的資訊如下
request
POST HTTP/1.1 方法 url/uri 協定的版本号 1.1
Host: re.csdn.net
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:
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) 位址用于描述一個網絡上的資源，基本格式
例如：
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 查詢字元串
#
片段辨別符（使用片段辨別符通常可标記出已
擷取資源中的子資源（文檔内的某個位置））
每個 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 協定中引入了 cookie 技術，用來解決 http 協定無狀态的問題。通
過在請求和響應封包中寫入 Cookie 資訊來控制用戶端的狀态；Cookie會根據從伺服器端發送的響應封包内的一個叫做 Set-Cookie 的首部字段資訊，通知用戶端儲存 Cookie。當下次用戶端再往該伺服器發送請求時，用戶端會自動在請求封包中加入 Cookie 值後發送出去。在基于 tomcat 這類的 jsp/servlet 容器中，會提供 session 這樣的機制來儲存服務端的對象狀态。那麼整個狀态協定的流程就是這樣的
1.通信過程中是使用明文，内容可能會被竊聽
2.不驗證通信雙方的身份
3.無法驗證封包的完整性，封包可能被篡改
由于 HTTP 協定通信的不安全性，是以人們為了防止資訊在傳輸過程中遭到洩漏或者篡改，就想出來對傳輸通道進行加密的方式 https。 https 是一種加密的超文本傳輸協定，它與 HTTP 在協定差異在于對資料傳輸的過程中，https 對資料做了完全加密。由于 http 協定或者 https 協定都是處于 TCP 傳輸層之上，同時網絡協定又是一個分層的結構，是以在 tcp 協定層之上增加了一層 SSL（Secure Socket Layer，安全層）或者 TLS（Transport Layer Security） 安全層傳輸協定組合使用用于構造加密通道；
- 用戶端發起請求(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，作為後續互動過程中的對稱密鑰