分佈式協議基礎http協議

Http 協議的組成

• 抓包工具，Fillder
• request

response

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，這種狀況下端口號能夠省略；若是使用了別的端口， 必須指明
    • path 訪問資源的路徑
    • query-string 查詢字符串
    • # 片斷標識符
      • 使用片斷標識符一般可標記出已獲取資源中的子資源（文檔內的某個位置））

URI(Uniform Resource Identifier)

• 每一個web 服務器資源都有一個名字，這樣客戶端就能夠根據這個名字來找到對應的資源，這個資源稱之爲（統一資源標識符）
• URI 是用一個字符串來表示互聯網上的某一個資源。
• 而URL表示資源的地點（互聯網所在的位置）

方法

• TTP 發起的每一個請求，都須要告訴告訴服務器要執行什麼動做，
• 那麼這個動做就是前面報文中看到的【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。
• https 是一種加密的超文本傳輸協議，它與HTTP 在協議差別在於對數據傳輸的過程當中，https 對數據作了徹底加密。
• 在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機構的公鑰對服務器的證書進行驗籤
  • 肯定這個證書是否是由正規的機構頒發。
  • 若是獲得的值和服務端返回的證書驗籤以後的摘要相同，表示證書沒有被修改過
• 驗證經過後，就會顯示綠色的安全字樣
• 客戶端生成隨機數，驗證經過以後，客戶端會生成一個隨機數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 mastersecret / client.random/server.random 經過算法得出sessionKey，做爲後續交互過程當中的對稱密鑰