一文吃透 HTTP 協議：從基礎原理到深度細節
HTTP（HyperText Transfer Protocol，超文本傳輸協議）是支撐萬維網運行的核心協議，所有瀏覽器與服務器的交互、App 的接口請求、靜態資源加載，本質都是 HTTP 協議的通信過程。掌握 HTTP 不僅是開發者排查接口問題、優化性能的基礎，更是理解 Web 架構的關鍵。本文從 “基礎定義→核心組成→進階特性→實戰細節” 四個維度，全面拆解 HTTP 協議，帶你從 “會用” 到 “吃透”。
一、HTTP 基礎：協議本質與核心特性
1. 什麼是 HTTP？
HTTP 是一種基於 TCP/IP 的應用層協議，定義了客户端（如瀏覽器、App）與服務器之間的 “請求 - 響應” 通信規則 —— 客户端發送 “請求報文”，服務器接收後處理並返回 “響應報文”，以此完成數據交互（如獲取網頁、提交表單、調用接口）。
其核心定位是 “無狀態、無連接（早期）、基於文本”：
- 無狀態：協議本身不記錄客户端的歷史交互信息（如登錄狀態），每次請求都是獨立的。這一特性導致的 “狀態保存” 問題，需通過 Cookie、Session、Token 等機制解決；
- 無連接（早期 HTTP/1.0）：客户端與服務器建立 TCP 連接後，僅傳輸一次請求 - 響應便斷開連接。若需多次請求（如加載網頁中的圖片、CSS），需重複建立 TCP 連接，效率極低；
- 基於文本：請求與響應報文均為文本格式（ASCII 編碼），人類可直接閲讀（如通過 F12 開發者工具查看），但相比二進制協議（如 Protobuf）傳輸效率更低。
2. URL：HTTP 請求的 “地址標識”
HTTP 請求的目標由 URL（Uniform Resource Locator，統一資源定位符）指定，它是資源在互聯網中的唯一地址。一個完整的 URL 結構如下（以https://www.example.com:8080/path?name=test#section1為例）：
|
組成部分 |
示例值 |
作用説明 |
|
協議方案 |
https |
指定通信協議（HTTP/HTTPS/WS 等），決定數據傳輸的安全與效率特性 |
|
服務器域名 / IP |
www.example.com |
定位資源所在的服務器，通過 DNS 解析為 IP 地址（如192.168.1.1） |
|
端口號 |
8080 |
服務器上的 “應用入口”，HTTP 默認端口 80，HTTPS 默認 443，非默認需顯式指定 |
|
資源路徑 |
/path |
服務器內資源的具體路徑（如接口路徑/api/user、靜態資源路徑/static/img） |
|
查詢參數 |
name=test |
向服務器傳遞的額外參數，格式為key=value，多參數用&分隔 |
|
片段標識符 |
#section1 |
定位頁面內的具體位置（如錨點），僅在客户端生效，不發送給服務器 |
二、HTTP 核心：請求與響應的 “報文結構”
HTTP 通信的本質是 “報文交換”—— 客户端發送請求報文，服務器返回響應報文。兩者結構相似，均由 “起始行 + 頭部 + 空行 + 體部” 四部分組成，區別僅在於起始行的格式。
1. 請求報文：客户端 “要什麼”
請求報文是客户端向服務器發起請求的 “指令”，結構如下（以 “GET 請求獲取用户信息” 為例）：
# 1. 起始行（請求行）：方法 + URL路徑 + 協議版本GET /api/user?id=1 HTTP/1.1# 2. 請求頭：鍵值對格式，描述請求的附加信息（如客户端身份、數據格式）Host: www.example.com # 服務器域名（必選，用於虛擬主機配置）User-Agent: Chrome/120.0.0.1 # 客户端身份（瀏覽器/設備型號，用於適配）Accept: application/json # 客户端可接收的響應數據格式（如JSON/XML）Cookie: token=abc123 # 客户端存儲的Cookie（傳遞登錄狀態等）# 3. 空行：分隔請求頭與請求體（必須存在，即使無請求體）# 4. 請求體：可選，傳遞複雜數據（如POST請求的表單、JSON參數）# （GET請求無請求體，參數通過URL查詢串傳遞；POST請求體如下）# {"username":"test","password":"123456"}關鍵組成解析：
- HTTP 方法：定義請求的 “操作意圖”，常用方法及場景如下：
|
方法 |
核心語義 |
特點（是否冪等 / 可緩存） |
典型場景 |
|
GET |
獲取資源 |
冪等（多次請求結果一致）、可緩存 |
查詢用户信息、加載靜態資源 |
|
POST |
提交資源（創建 / 修改） |
非冪等、不可緩存 |
登錄提交、上傳文件、創建訂單 |
|
PUT |
全量更新資源 |
冪等、不可緩存 |
替換用户信息（傳所有字段） |
|
DELETE |
刪除資源 |
冪等、不可緩存 |
刪除訂單、註銷賬號 |
|
PATCH |
部分更新資源 |
非冪等、不可緩存 |
修改用户手機號（僅傳手機號） |
|
HEAD |
獲取資源頭部（無體部） |
冪等、可緩存 |
檢查文件是否存在、獲取長度 |
注：冪等性指 “多次執行同一請求，服務器狀態不變”，如 GET/PUT/DELETE 多次執行不會導致數據異常，而 POST 多次提交可能創建多個訂單。
- 請求頭：傳遞 “元數據”，除上述示例外，常用請求頭還有：
- Content-Type：請求體的數據格式（如application/json、multipart/form-data（文件上傳））；
- Authorization：身份認證（如 Bearer Token，格式Bearer abc123）；
- Referer：請求來源（如從 A 頁面跳轉到 B 頁面，Referer 為 A 頁面 URL，用於防盜鏈）。
2. 響應報文：服務器 “給什麼”
響應報文是服務器對請求的 “反饋”，結構如下（承接上述 “獲取用户信息” 請求）：
# 1. 起始行（響應行）：協議版本 + 狀態碼 + 狀態描述HTTP/1.1 200 OK# 2. 響應頭：鍵值對格式，描述響應的附加信息（如數據格式、緩存規則）Server: Nginx/1.20.0 # 服務器軟件（如Nginx/Tomcat）Content-Type: application/json # 響應體的數據格式Content-Length: 128 # 響應體的字節長度（用於解析）Set-Cookie: sessionId=def456 # 服務器向客户端設置CookieCache-Control: max-age=3600 # 響應的緩存規則（有效期1小時）# 3. 空行：分隔響應頭與響應體# 4. 響應體：服務器返回的實際數據（如JSON、HTML、圖片二進制）{"code":200,"msg":"success","data":{"id":1,"username":"test","age":20}}關鍵組成解析：
- HTTP 狀態碼：定義響應的 “結果狀態”，按首位數字分為 5 類，常用狀態碼及場景如下：
|
類別 |
含義 |
常用狀態碼 |
場景説明 |
|
1xx |
信息性響應（臨時） |
100 Continue |
服務器接收請求頭，提示客户端繼續發送體部 |
|
2xx |
成功 |
200 OK |
請求正常處理（如查詢成功、提交成功） |
|
|
|
204 No Content |
請求成功但無響應體（如刪除成功） |
|
3xx |
重定向（需進一步操作） |
301 Moved Permanently |
資源永久遷移（如域名更換，瀏覽器緩存跳轉關係） |
|
|
|
302 Found |
資源臨時遷移（如臨時維護頁面，不緩存） |
|
|
|
304 Not Modified |
協商緩存命中，服務器不返回資源體（僅返回頭） |
|
4xx |
客户端錯誤 |
400 Bad Request |
請求參數錯誤（如缺少必填字段） |
|
|
|
401 Unauthorized |
未認證（如未登錄，需先登錄） |
|
|
|
403 Forbidden |
已認證但無權限（如普通用户訪問管理員接口） |
|
|
|
404 Not Found |
資源不存在（如 URL 路徑錯誤） |
|
|
|
405 Method Not Allowed |
請求方法不支持（如用 GET 訪問僅支持 POST 的接口） |
|
5xx |
服務器錯誤 |
500 Internal Server Error |
服務器未知錯誤（如代碼 bug、數據庫異常） |
|
|
|
502 Bad Gateway |
網關錯誤（如反向代理後，後端服務未響應） |
|
|
|
503 Service Unavailable |
服務器暫時不可用（如過載、維護） |
|
|
|
504 Gateway Timeout |
網關超時（如後端服務處理超時） |
- 響應頭：除上述示例外，常用響應頭還有：
- Access-Control-Allow-Origin：解決跨域問題，指定允許訪問的客户端域名（如*表示允許所有）；
- ETag：資源的唯一標識（如文件哈希值），用於協商緩存；
- Location：配合 3xx 重定向，指定新的資源地址（如登錄成功後跳轉的首頁 URL）。
三、HTTP 進階：緩存、安全與版本演進
HTTP 緩存：提升性能的 “核心手段”
HTTP 緩存是減少重複請求、降低服務器壓力、加快頁面加載的關鍵機制，分為強緩存和協商緩存，兩者協同工作：
（1）強緩存：客户端 “自主判斷” 是否使用緩存
客户端首次請求資源後，服務器通過響應頭告知 “緩存有效期”，後續請求時，客户端先檢查緩存是否過期：
- 若未過期：直接使用本地緩存（不發送請求到服務器）；
- 若已過期：進入協商緩存流程。
控制強緩存的響應頭：
- Cache-Control: max-age=3600：緩存有效期為 3600 秒（優先級高，HTTP/1.1 及以上支持）；
- Expires: Wed, 20 Jul 2024 12:00:00 GMT：緩存過期時間（HTTP/1.0 遺留，優先級低，若與 max-age 衝突，以 max-age 為準）。
（2）協商緩存：客户端 “詢問服務器” 是否使用緩存
強緩存過期後，客户端攜帶 “緩存標識” 向服務器發起請求，服務器判斷標識是否有效：
- 若有效（資源未修改）：返回 304 Not Modified，客户端繼續使用本地緩存；
- 若無效（資源已修改）：返回 200 OK + 新資源，客户端更新緩存。
控制協商緩存的頭對：
|
服務器響應頭（首次返回） |
客户端請求頭（後續請求） |
原理説明 |
|
Last-Modified: 資源修改時間 |
If-Modified-Since: 同上 |
基於 “時間戳” 判斷，若請求時時間戳與服務器一致，説明資源未改 |
|
ETag: 資源唯一標識（如哈希） |
If-None-Match: 同上 |
基於 “資源內容哈希” 判斷，優先級高於 Last-Modified（解決時間戳精度問題） |
緩存位置：
HTTP 緩存按 “存儲位置” 分為三級，優先級從高到低：
- Memory Cache（內存緩存）：存於瀏覽器內存，關閉標籤頁失效，速度最快（如頻繁訪問的 JS/CSS）；
- Disk Cache（磁盤緩存）：存於本地磁盤，關閉瀏覽器仍有效，速度較慢（如不常變動的圖片、靜態資源）；
- Service Worker Cache：獨立於瀏覽器的緩存（PWA 應用常用），需手動配置緩存規則。
