【網絡編程】HTTP(超文本傳輸協議)詳解

🦄個人主頁:修修修也

🎏所屬專欄:網絡編程

??操作環境:Visual Studio 2022

目錄

📌HTTP定義

📌HTTP工作原理

1.客戶端發起請求:

2.服務器處理請求:

3.客戶端處理響應:

📌HTTP關鍵特性

🎏HTTP請求方法

📖Get(獲取資源)

📖Post(提交消息)

📖Put(修改數據)

📖Delect(刪除數據)

🎏HTTP中Cookie、Session和Token

📖為什么需要Cookie和Session

📖Cookie

📖Session

📖Session-Cookie的典型場景

📖Token

📖小結

📌HTTP版本演進

🎏HTTP/0.9? [1991年]

🎏HTTP/1.0? [1996年]

🎏HTTP/1.1? [1997年]

🎏HTTP/2.0? [2015年]

🎏HTTP/3.0? [2022年]?

📌HTTPS

🎏核心原理

🎏TLS握手過程

結語

📌HTTP定義

??????? HTTP（HyperText Transfer Protocol）是一種應用層協議, 用于在客戶端和服務器之間傳輸超文本(如網頁, 圖片, 視頻等)。具備以下核心特性:

無狀態協議: 每次請求獨立, 服務器不保存客戶端狀態(需通過Cookie/Session擴展狀態管理)。
請求-響應模型: 客戶端發起請求(Request), 服務器返回響應(Response)。
基于TCP/IP: 默認端口80(HTTP)或443(HTTPS), 依賴TCP保證可靠傳輸。
可擴展性: 通過Header字段自定義元數據, 支持緩存, 認證, 壓縮等功能。

📌HTTP工作原理

1.客戶端發起請求:

?輸入URL, 瀏覽器解析域名并建立TCP連接。
發送HTTP請求報文, 包含方法, 路徑, 協議版本, Headers等。

2.服務器處理請求:

解析請求，定位資源，執行后端邏輯（如查詢數據庫）。
返回HTTP響應報文，包含狀態碼（如200）、Headers（如Content-Type）、Body（如HTML內容）。

3.客戶端處理響應:

瀏覽器解析響應內容(如渲染HTML), 關閉或復用TCP連接。

📌HTTP關鍵特性

🎏HTTP請求方法

📖Get(獲取資源)

?作用：獲取指定資源（通常不修改服務器數據）。
?特點：
?安全：不改變服務器狀態。
?冪等：多次請求結果相同。
無請求體, 數據通過URL參數傳遞（如?id=123）。

適用場景: 加載頁面內容, 獲取靜態資源等。

📖Post(提交消息)

作用：向服務器提交數據（通常用于創建資源或觸發操作）。
?特點：
?非安全：可能修改服務器狀態。
?非冪等：重復提交可能產生不同結果（如重復創建訂單）。
有請求體, 數據通過請求體（Body）傳輸，支持多種格式（JSON、表單等）。

適用場景: 提交表單(如用戶注冊), 上傳文件等。

📖Put(修改數據)

?作用：替換或完整更新指定資源。
?特點：
?非安全：修改服務器狀態。
?冪等：多次請求效果等同于一次（如重復更新同一資源）。
有請求體, 需提供完整的資源數據。

適用場景: 更新用戶全部信息, 替換已有文件等。

📖Delect(刪除數據)

作用：刪除指定資源。
?特點：
?非安全：修改服務器狀態。
?冪等：刪除不存在資源仍返回相同結果。

適用場景: 刪除數據庫記錄, 移除服務器上的文件。

🎏HTTP中Cookie、Session和Token

📖為什么需要Cookie和Session

????????HTTP 是無狀態協議，每個請求獨立處理，服務器默認不會記錄之前的請求信息。這導致以下挑戰：

?無法跟蹤用戶身份：用戶登錄后，服務器不知道后續請求來自同一用戶。
?無法保存用戶操作狀態：例如購物車內容、頁面偏好設置等無法跨請求保留。
?無法實現個性化服務：無法根據用戶歷史行為動態調整內容（如推薦系統）。

Cookie 和 Session 的共同目標：?在無狀態的 HTTP 協議上實現有狀態的用戶會話管理。

📖Cookie

Cookie解決客戶端狀態存儲, 主要解決用戶偏好（如語言、主題）或臨時數據（如未登錄時的購物車）需長期或短期保存的問題。
解決方案: Cookie 將數據存儲在客戶端（瀏覽器），每次請求自動攜帶。
Cookie解決服務器需要識別同一用戶的多次請求的問題。
解決方案: Cookie 存儲 Session ID，作為用戶身份的唯一標識。

📖Session

Session解決用戶的敏感信息（如登錄憑證、權限角色）不能暴露在客戶端的問題。
解決方案:Session 數據存儲在服務器（內存、數據庫或緩存如 Redis），僅通過 Cookie 傳遞安全的 Session ID。
Session解決Cookie 有大小限制（約 4KB），無法存儲復雜數據的問題。
解決方案: Session 在服務端存儲用戶完整數據（如購物車商品列表、多步驟表單填寫內容）。
Session解決客戶端數據易被篡改（如用戶偽造身份提升權限）的問題。
解決方案: Session ID 通過 HttpOnly 和 Secure Cookie 傳輸，防止 XSS 和中間人攻擊。服務端驗證 Session ID 合法性，綁定 IP 或設備指紋防止盜用。

??????? 下面介紹一下用戶登錄時Cookie和Session的協同工作場景

1.登錄請求(http請求信息):
POST /login HTTP/1.1
Content-Type: application/json{"username": "alice", "password": "123456"}
2.服務器驗證：生成 Session 數據并返回 Session ID 到 Cookie。
HTTP/1.1 200 OK
Set-Cookie: session_id=xyz789; HttpOnly; Secure; Path=/
3.后續請求：瀏覽器自動攜帶 Session ID，服務器查詢 Session 數據識別用戶。
GET /dashboard HTTP/1.1
Cookie: session_id=xyz789

📖Token

??????? 由于服務器可能會有繁忙需要將部分用戶轉移給別的服務器分擔壓力的情況, 那保存在A服務器的Session_id就要一起轉交給B服務器, 否則用戶發新的請求就還需要重新登陸驗證, 這樣非常麻煩, 如果把Session_id都統一存放在數據庫里呢, 又怕數據庫過載不安全, 于是為了解決這個問題, 又引入了新的解決方案, 就是Token。

????????Token?（令牌）是一種用于身份驗證和授權的憑證，通常由服務器生成并返回給客戶端。客戶端在后續請求中攜帶 Token，供服務器驗證身份。

核心特點：

?無狀態：服務器無需存儲 Token，驗證基于簽名或加密。
?自包含：Token 可攜帶用戶信息（如用戶ID、權限）。
?跨域友好：適合前后端分離、微服務架構。

常見類型：

?JWT（JSON Web Token）?：標準化、自包含的 Token 格式。
?OAuth Token：用于第三方授權（如使用微信登錄）。
?Access Token/Refresh Token：短效令牌與長效刷新令牌組合。

📖小結

??????? Session是誕生并保存在服務器里的, 由服務器主導一切, 而Cookie則是一種數據載體, 把Session放入Cookie中送到客戶端那邊, Cookie跟隨每個HTTP請求發送出去, 以便服務器識別用戶身份。

??????? Token是誕生在服務器, 但是保存在瀏覽器這邊的, 由客戶端主導一切, 可以放在Cookie或者Storage里面, 持有Token就像持有"令牌"一樣可以允許訪問服務器。

📌HTTP版本演進

🎏HTTP/0.9? [1991年]

特點：

?極簡設計：僅支持?GET?方法，無請求頭（Header）和狀態碼。
?純文本傳輸：直接返回 HTML 內容，無圖片、CSS 等資源支持。

局限：

無錯誤處理，無法擴展。

🎏HTTP/1.0? [1996年]

核心改進：
?引入請求頭/響應頭：支持元數據（如?Content-Type、User-Agent）。
?狀態碼：如?200 OK、404 Not Found。
?多方法支持：新增?POST、HEAD?方法。
?版本標識：請求中需聲明?HTTP/1.0。

?問題：
?短連接：每個請求需新建 TCP 連接（三次握手開銷大）。
?無 Host 頭：無法支持虛擬主機（單 IP 多域名）。

🎏HTTP/1.1? [1997年]

里程碑改進：
?持久連接（Keep-Alive）?：默認復用 TCP 連接，通過?Connection: keep-alive?管理。
?管道化（Pipelining）?：允許連續發送多個請求（但響應必須按序返回，存在隊頭阻塞）。
?Host 頭：支持單服務器托管多域名。
?緩存控制：引入?Cache-Control、ETag?等頭字段。
?分塊傳輸：通過?Transfer-Encoding: chunked?支持流式傳輸。

?遺留問題：
?隊頭阻塞（Head-of-Line Blocking）?：管道化未完全解決請求/響應隊列阻塞。
?頭部冗余：重復頭部字段（如?Cookie）浪費帶寬。

🎏HTTP/2.0? [2015年]

核心優化：
?二進制分幀（Binary Framing）?：將數據拆分為更小的二進制幀，提升傳輸效率。
?多路復用（Multiplexing）?：單連接并行處理多個請求/響應，徹底解決隊頭阻塞。
?頭部壓縮（HPACK）?：減少頭部大小（如靜態表、動態表編碼）。
?服務器推送（Server Push）?：主動推送客戶端可能需要的資源（如 CSS/JS 文件）。
?流優先級：允許客戶端指定資源加載優先級。

?示例：
一個 TCP 連接同時傳輸 HTML、CSS、圖片，無需等待前序請求完成。

?局限：
?TCP 層隊頭阻塞：若單個 TCP 包丟失，所有流需等待重傳。

🎏HTTP/3.0? [2022年]?

革命性變革：
?基于 QUIC 協議：棄用 TCP，改用 UDP 實現可靠傳輸，內置加密（TLS 1.3）。
?解決 TCP 隊頭阻塞：每個流獨立傳輸，丟包僅影響單個流。
?0-RTT 連接：首次連接即可發送數據（復用之前會話的加密信息）。
?連接遷移：網絡切換（如 Wi-Fi → 4G）時無需重建連接。

?優勢場景：
高延遲網絡（如衛星通信）、移動網絡（頻繁切換基站）。

?挑戰：
運營商對 UDP 的支持策略可能影響普及。

📌HTTPS

?????????HTTPS（HyperText ?Transfer ?Protocol ?Secure）是 HTTP 的安全版本，通過在 HTTP 和 TCP 層之間引入 ?SSL/TLS 加密層，解決 HTTP 明文傳輸的安全隱患，保護數據隱私和完整性。默認端口: 443。

🎏核心原理

?加密通信

?混合加密機制：
?非對稱加密：用于密鑰交換（如 RSA、ECDHE），確保初始握手安全。
?對稱加密：用于數據傳輸（如 AES、ChaCha20），提高加密效率。

?示例：客戶端生成臨時密鑰（Pre-Master Secret），用服務器公鑰加密后傳輸，雙方基于此生成對稱加密密鑰。

?身份驗證

?數字證書：由受信任的證書頒發機構（CA）簽發，包含服務器公鑰和域名信息。
?驗證流程：
客戶端驗證證書是否過期、域名匹配、簽發機構可信。
檢查證書鏈是否完整（根證書 → 中間證書 → 服務器證書）。

?數據完整性

?MAC（消息認證碼）??或 ?HMAC：防止數據在傳輸中被篡改。
?TLS 記錄協議：對每個數據塊計算哈希值，接收方驗證一致性。

🎏TLS握手過程

一次完整的 HTTPS 連接需經歷以下步驟（以 TLS 1.3 為例）：

?Client Hello
客戶端發送支持的 TLS 版本、加密套件列表、隨機數（Client Random）。

?Server Hello
服務器選擇加密套件，發送隨機數（Server Random）、證書、公鑰。
TLS 1.3 優化：省略不必要的協商步驟（如密鑰交換參數）。

?密鑰交換
客戶端生成 Pre-Master Secret，用服務器公鑰加密后發送。
雙方基于 Client Random、Server Random 和 Pre-Master Secret 生成會話密鑰。

?完成握手
雙方發送加密的 Finished 消息，確認握手成功，后續數據均加密傳輸。

握手耗時優化：

?Session Resumption：復用之前會話的密鑰（通過 Session ID 或 Session Ticket）。
?0-RTT（TLS 1.3）?：首次連接即可發送加密數據，降低延遲。