http，https協議
Http 協議的組成
http請求分為兩部分， 一個是客戶端的請求資訊，一個是服務端的響應資訊。
Request
POST https://mp.csdn.net/mdeditor# HTTP/1.1
方法 url/uri 協議的版本號 1.1
Response
HTTP/1.1 200 OK
協議版本號 響應狀態碼 狀態碼對應的原因
URL（Uniform Resource Locator）
URL 地址用於描述一個網路 上的資源，基本格式：
schema://host[:port#]/path/…/?[urlparams]#[ query-string]
scheme 指定應用層使用的協議(例如：http, https, ftp)
host ： HTTP伺服器的IP地址或者域名
port# ： HTTP伺服器的預設埠是80，這 種情況下埠號可以省略。如果使用了別的埠，必須指 明
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 的實現原理
1.客戶端發起請求
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 master secret / client.random/server.random通過 演算法得出 session Key，作為後續互動過程中的對稱金鑰。