首先我們來解釋一下HTTP協(xié)議的功能和工作原理

HTTP（超文本傳輸協(xié)議）
它是基于TCP / IP 協(xié)議的應(yīng)用層傳輸協(xié)議，簡(jiǎn)單來說就是客戶端和服務(wù)端進(jìn)行數(shù)據(jù)傳輸?shù)囊环N規(guī)則。HTTP底層協(xié)議是TCP協(xié)議.

HTTP工作原理
HTTP協(xié)議定義Web客戶端如何從Web服務(wù)器請(qǐng)求Web頁面，以及服務(wù)器如何把Web頁面?zhèn)魉徒o客戶端。

HTTP 用 TCP要實(shí)現(xiàn)的兩個(gè)基本功能：

• 發(fā)數(shù)據(jù)；
• 收數(shù)據(jù)。
• HTTP不關(guān)心其他的細(xì)節(jié)問題。

HTTP的任務(wù)：

• 請(qǐng)求資源（從對(duì)方服務(wù)器將資源拿到）；
• 提交信息（處理數(shù)據(jù)），從客戶端把數(shù)據(jù)推送到服務(wù)器。

image.png

HTTP 請(qǐng)求 / 響應(yīng)的步驟

1.客戶端連接到Web服務(wù)器

一個(gè)HTTP客戶端，通常是瀏覽器，與Web服務(wù)器的HTTP
端口（默認(rèn)為80）建立一個(gè)TCP套接字連接。例如，
http://www.oakcms.cn

2、發(fā)送HTTP請(qǐng)求
報(bào)文結(jié)構(gòu)：

• request:請(qǐng)求行（方法 + url + 協(xié)議）請(qǐng)求頭部、請(qǐng)求正文
• response:狀態(tài)行（狀態(tài)碼 + 原因+ 協(xié)議）響應(yīng)頭部、響應(yīng)正文

通過TCP套接字，客戶端向Web服務(wù)器發(fā)送一個(gè)文本的請(qǐng)
求報(bào)文，一個(gè)請(qǐng)求報(bào)文由請(qǐng)求行、請(qǐng)求頭部、空行和請(qǐng)求
數(shù)據(jù)4部分組成。
如下圖所示：
- Host ：請(qǐng)求的資源在哪個(gè)主機(jī)的端口上
- Connection：該請(qǐng)求支持長(zhǎng)連接（heep_alive）
- Content-Length：正文內(nèi)容長(zhǎng)度
- Content-Type：數(shù)據(jù)類型
- User-Agent：聲明用戶的操作系統(tǒng)和瀏覽器版本信息
- Accent：發(fā)起了請(qǐng)求
- Referer：當(dāng)前頁面是從哪個(gè)頁面跳轉(zhuǎn)過來的
- Accept-Encoding：接受的編碼
- Accept-Language：接受的語言類型
- Cookie：用于在客戶端存儲(chǔ)少量信息，通常用于實(shí)現(xiàn)會(huì)話（session）功能

image.png

3、服務(wù)器接受請(qǐng)求并返回HTTP響應(yīng)

• Web服務(wù)器解析請(qǐng)求，定位請(qǐng)求資源。服務(wù)器將資源復(fù)本
  寫到TCP套接字，由客戶端讀取。一個(gè)響應(yīng)由狀態(tài)行、響
  應(yīng)頭部、空行和響應(yīng)數(shù)據(jù)4部分組成。

HTTP響應(yīng)：

• GET：獲取資源
• POST：傳輸實(shí)體主體
• PUT：傳輸文件
• HEAD：獲得報(bào)文首部（相當(dāng)于GET方法獲得的資源去掉正文）
• DELETE：刪除文件
• OPTIONS：詢問支持的方法（客戶端問服務(wù)器）
• TRACE：追蹤路徑
• OCONNECT：要求用隧道協(xié)議連接代理
• LINK：建立與資源之間的聯(lián)系
• UNLINE：斷開連接關(guān)系

image.png

image.png

GET 方法和 POST 方法核心點(diǎn)：

• 傳參的數(shù)據(jù)量不一樣，一個(gè)通過 url，一個(gè)通過正文，所以 POST 能傳更多的數(shù)據(jù)；
• GET 方法和 POST 方法傳參位置上，可靠性問題。

4、釋放連接TCP連接

• 若connection 模式為close，則服務(wù)器主動(dòng)關(guān)閉TCP連接，
  客戶端被動(dòng)關(guān)閉連接，釋放TCP連接;若connection 模式為
  keepalive，則該連接會(huì)保持一段時(shí)間，在該時(shí)間內(nèi)可以繼
  續(xù)接收請(qǐng)求;

5、客戶端瀏覽器解析HTML內(nèi)容

• 客戶端瀏覽器首先解析狀態(tài)行，查看表明請(qǐng)求是否成功的
  狀態(tài)代碼。然后解析每一個(gè)響應(yīng)頭，響應(yīng)頭告知以下為若
  干字節(jié)的HTML文檔和文檔的字符集?？蛻舳藶g覽器讀取響
  應(yīng)數(shù)據(jù)HTML，根據(jù)HTML的語法對(duì)其進(jìn)行格式化，并在瀏
  覽器窗口中顯示。

比較HTTP與HTTPS 特定比較：

HTTP特點(diǎn)：

• 無狀態(tài)：協(xié)議對(duì)客戶端沒有狀態(tài)存儲(chǔ)，比如訪問一個(gè)網(wǎng)站需要反復(fù)進(jìn)行登錄操作
• 無連接：HTTP/1.1之前，由于無狀態(tài)特點(diǎn)，每次請(qǐng)求需要通過TCP三次握手四次揮手，和服務(wù)器重新建立連接。

比如某個(gè)客戶機(jī)在短時(shí)間多次請(qǐng)求同一個(gè)資源，服務(wù)器并不能區(qū)別是
否已經(jīng)響應(yīng)過用戶的請(qǐng)求，所以每次需要重新響應(yīng)請(qǐng)求，需要耗費(fèi)時(shí)
間和流量。

• 基于請(qǐng)求和響應(yīng)：基本的特性，由客戶端發(fā)起請(qǐng)求，服務(wù)端響應(yīng)
• 通信使用明文、請(qǐng)求和響應(yīng)不會(huì)對(duì)通信方進(jìn)行確認(rèn)、無法保護(hù)數(shù)據(jù)的完整性,網(wǎng)絡(luò)完全性極差，后面的HTTPS彌補(bǔ)了這個(gè)缺點(diǎn)。

HTTPS特點(diǎn)：

HTTPS和HTTP通信協(xié)議發(fā)送報(bào)文的區(qū)別

• 1. 傳統(tǒng)的HTTP協(xié)議通信：
  傳統(tǒng)的HTTP報(bào)文是直接將報(bào)文信息傳輸?shù)絋CP然后TCP再通過TCP套接字發(fā)送給目的主機(jī)上。

• 2. HTTPS協(xié)議通信：
  HTTPS是HTTP報(bào)文直接將報(bào)文信息傳輸給SSL套接字進(jìn)行加密，SSL加密后將加密后的報(bào)文發(fā)送給TCP套接字，然后TCP套接字再將加密后的報(bào)文發(fā)送給目的主機(jī)，目的主機(jī)將通過TCP套接字獲取加密后的報(bào)文給SSL套接字，SSL解密后交給對(duì)應(yīng)進(jìn)程。

• 3. 加入了很多密碼學(xué)中的協(xié)議
• 基于HTTP協(xié)議，通過SSL或TLS提供加密處理數(shù)據(jù)、驗(yàn)證對(duì)方身份以及數(shù)據(jù)完整性保護(hù)

image.png

HTTP與HTTPS安全性比較

HTTPS： 采用 對(duì)稱加密 和 非對(duì)稱加密 結(jié)合的方式來保護(hù)瀏覽器和服務(wù)端之間的通信安全。
HTTPS (security) = 對(duì)稱加密算法加密數(shù)據(jù) + 非對(duì)稱加密算法交換密鑰 + 數(shù)字證書驗(yàn)證身份

HTTPS加密具體過程

• ① 驗(yàn)證身份：

  1. 客戶端向服務(wù)端發(fā)起握手請(qǐng)求，以明文傳輸請(qǐng)求信息，包含版本信息，加密-套件候選列表，壓縮算法候選列表，隨機(jī)數(shù)，擴(kuò)展字段等信息。

  2. 服務(wù)端發(fā)送證書 [這套證書就是一對(duì)公私鑰對(duì)(PK,SK)] ,給客戶端

  3. 客戶端檢查證書，確認(rèn)是否由可信任CA機(jī)構(gòu)簽發(fā)，獲取服務(wù)端公鑰。 如果不是，由用戶決定是否繼續(xù)通訊；如果檢查無誤或用戶選擇繼續(xù)，則客戶端認(rèn)可服務(wù)端的身份.

  4. 服務(wù)端要求客戶端發(fā)送證書，并檢查是否通過驗(yàn)證。失敗則關(guān)閉連接，認(rèn)證成功則從客戶端證書中獲得客戶端公鑰（PK）

  5. 至此，服務(wù)器客戶端雙方的身份認(rèn)證結(jié)束，雙方確保身份都是真實(shí)可靠的

• ② 傳輸加密：抵擋中間人攻擊

  1. 客戶端和服務(wù)端在開始傳輸數(shù)據(jù)之前，先協(xié)商傳輸過程需要使用的加密算法。 客戶端發(fā)送協(xié)商請(qǐng)求給服務(wù)端, 其中包含自己支持的非對(duì)稱加密的密鑰交換算法 (RSA)、數(shù)據(jù)簽名算法 (SHA/MD5)、對(duì)稱加密算法 (DES)、加密密鑰的長(zhǎng)度*

  2. 服務(wù)端收到消息后，選擇安全性最高的算法，發(fā)還給客戶端，完成協(xié)商

  3. 采用混合加密的方式，對(duì)稱加密和非對(duì)稱加密相結(jié)合。客戶端使用對(duì)稱加密生成 Key Pairs (pk,sk),對(duì)傳輸數(shù)據(jù)進(jìn)行加密，然后使用非對(duì)稱加密的公鑰PK對(duì)密鑰進(jìn)行加密，發(fā)送給服務(wù)端。

  4. 服務(wù)端收到后使用自己的SK解密得到密鑰key，再用密鑰key解密密文得到明文。

  5. 因此，網(wǎng)上傳輸?shù)臄?shù)據(jù)時(shí)被秘鑰加密的密文和用公鑰PK加密后的秘鑰，即使被劫持抓包，沒有私鑰SK，無法獲得加密明文的秘鑰，無法獲得明文數(shù)據(jù)。

• 數(shù)字摘要：
  將任意長(zhǎng)度消息變成固定長(zhǎng)度的短消息，常用的加密算法包括
  HASH（SHA256）,HMAC(Hmac_SHA256)

• ③ 保護(hù)數(shù)據(jù)完整性：
  防止傳輸?shù)膬?nèi)容被中間人冒充或者篡改

image.png