應用層協議：HTTP

HTTP：超文本傳輸協議

1.1 HTTP報文

1.1.1 請求報文

1.1.2 響應報文

1.2 HTTP請求過程和原理

1.2.1 請求過程

1、域名（DNS）解析

2、建立TCP連接（三次握手）

3、發送HTTP請求

4、服務器處理請求

5、返回HTTP響應

6、瀏覽器渲染（客戶端側）

7、斷開TCP連接（四次揮手）

1.2.2 核心原理

1.3 HTTP的不同版本

1.3.1 HTTP1.0

1.3.2 HTTP1.1（常用）

1.3.3 HTTP2.0（常用）

1.3.4 HTTP3.0

應用層協議是網絡模型中最高層的協議，直接為用戶應用程序提供服務，定義了應用程序之間如何進行通信和數據交換的規則。

HTTP：超文本傳輸協議

功能：?HTTP 是用于在 HTTP 應用程序（Web 瀏覽器和 Web 服務器）之間傳輸超文本文檔（如 HTML 文件）的基礎協議。它定義了客戶端（瀏覽器）如何請求資源（如網頁、圖片）以及服務器如何響應這些請求。它是一種無狀態協議（服務器默認不記住之前的請求）。

無狀態：HTTP 協議本身不保留之前請求或響應的任何信息。

端口：?HTTP - 80

1.1 HTTP報文

HTTP 請求 (HTTP Request):?客戶端向服務器發送一個格式化的消息，說明它想要什么（例如，“給我 index.html 頁面” 或 “把這個表單數據提交到服務器”）。
HTTP 響應 (HTTP Response):?服務器處理請求后，向客戶端返回一個格式化的消息，包含請求的結果（例如，返回 index.html 文件的內容，或告知表單提交成功/失敗）。

1.1.1 請求報文

請求行 (Request Line):

方法 (Method)：定義要對資源執行的操作（如?GET,?POST,?PUT,?DELETE,?HEAD,?OPTIONS?等）。

請求目標 (Request Target)：通常是資源的 URL 路徑（有時包含查詢參數），例如?/index.html?或?/search?q=term。
HTTP 版本：如?HTTP/1.1。
示例：?GET /index.html HTTP/1.1

請求頭 (Request Headers):

一系列鍵值對 (Header-Name: Header-Value)，提供關于請求的額外信息。
常見頭：
- Host: 目標服務器的主機名和端口（必需，尤其在虛擬主機環境下）。
- User-Agent: 客戶端標識（瀏覽器類型、版本、操作系統等）。
- Accept: 客戶端可接受的響應內容類型（MIME 類型），如?text/html, application/json。
- Accept-Language: 客戶端接受的自然語言（如?en-US, zh-CN）。
- Accept-Encoding: 客戶端接受的內容編碼（壓縮方式），如?gzip, deflate, br。
- Connection: 控制連接選項（如?keep-alive?表示希望保持連接）。
- Cookie: 將之前服務器設置的 Cookie 發送回服務器。解決HTTP無狀態的問題。
- sec-fetch-dest ：期望獲得什么類型的資源
- sec-fetch-mode ：navigate，表示這是一個瀏覽器的頁面切換請求?
- sec-fetch-site：表示一個請求發起的來源和目標資源來源之間的關系，cross
  site ：跨域請求， same-origin ：同源請求。
- sec-fetch-user ：？ 1 表示的true。
- upgrade-insecure-requests :1,表示當前瀏覽器告訴服務器，瀏覽器是可以處理https 請求的，即使訪問的 https 請求中又包含了其他的http請求。
- user-agent：描述瀏覽器的信息
- Content-Type?(用于 POST/PUT 等)：請求體（Body）的數據類型（如?application/x-www-form-urlencoded,?multipart/form-data,?application/json）。
- Content-Length?(用于有 Body 的請求)：請求體的大小（字節數）。
- Authorization: 包含用于訪問受保護資源的憑證（如?Basic <credentials>,?Bearer <token>）。

空行 (Empty Line):

分隔頭部和請求體。

請求體 (Request Body - 可選):

包含發送給服務器的數據。主要用于?POST,?PUT,?PATCH?等方法提交表單數據、上傳文件或發送 JSON/XML 等結構化數據。
GET,?HEAD,?DELETE,?OPTIONS?等方法通常沒有請求體。

1.1.2 響應報文

狀態行 (Status Line):

HTTP 版本：如?HTTP/1.1。
狀態碼 (Status Code)：一個三位數字代碼，表示請求處理結果（如?200 OK,?404 Not Found,?500 Internal Server Error）。

1xx (信息性響應):?表示請求已被接收，需要繼續處理。

100 Continue: 客戶端應繼續發送請求體。

101 Switching Protocols: 服務器應客戶端要求切換協議（如升級到 WebSocket）。

2xx (成功):?表示請求已成功被服務器接收、理解、并接受。

200 OK:?請求成功。GET 請求返回資源，POST/PUT 請求返回操作結果。

201 Created: 請求成功并創建了新資源（通常在 POST 或 PUT 后）。

202 Accepted: 請求已接受處理，但處理尚未完成（異步操作）。

204 No Content: 請求成功，但響應沒有內容（如 DELETE 成功）。

3xx (重定向):?表示需要客戶端采取進一步的操作才能完成請求。

301 Moved Permanently: 請求的資源已永久移動到新 URL（Location 頭中）。客戶端應更新書簽。

302 Found?(曾用名?Moved Temporarily): 請求的資源臨時移動到另一個 URL（Location 頭中）。客戶端本次應訪問新 URL，但以后仍可用舊 URL。

304 Not Modified: 資源未被修改（用于緩存）。客戶端可直接使用緩存的版本。

307 Temporary Redirect: 類似于 302，但要求客戶端必須保持原請求方法不變（如 POST 重定向后必須還是 POST）。

308 Permanent Redirect: 類似于 301，但要求客戶端必須保持原請求方法不變。

4xx (客戶端錯誤):?表示請求包含語法錯誤或無法完成。

400 Bad Request: 請求語法錯誤或參數無效，服務器無法理解。

401 Unauthorized: 請求需要用戶認證（登錄）。通常伴隨?WWW-Authenticate?頭。

403 Forbidden: 服務器理解請求，但拒絕執行（權限不足）。

404 Not Found: 服務器找不到請求的資源（URL 錯誤或資源已被刪除）。

405 Method Not Allowed: 請求中使用的 HTTP 方法不被目標資源支持（如對只讀資源用 POST）。

408 Request Timeout: 服務器在等待請求發送時超時。

429 Too Many Requests: 客戶端在規定時間內發送了過多請求（限流）。

5xx (服務器錯誤):?表示服務器在處理請求時發生錯誤。

500 Internal Server Error:?服務器內部錯誤，無法完成請求（代碼崩潰、配置錯誤等）。

501 Not Implemented: 服務器不支持完成請求所需的某個功能（如請求了一個未實現的方法）。

502 Bad Gateway: 作為網關或代理的服務器，從上游服務器收到無效響應。

503 Service Unavailable: 服務器暫時過載或停機維護，無法處理請求（稍后重試）。

504 Gateway Timeout: 作為網關或代理的服務器，未能及時從上游服務器獲得響應。

狀態文本 (Reason Phrase)：對狀態碼的簡短文字描述（如?OK,?Not Found）。
示例：?HTTP/1.1 200 OK?或?HTTP/1.1 404 Not Found

響應頭 (Response Headers):

一系列鍵值對，提供關于響應的額外信息。
常見頭：
- Server: 服務器軟件信息（如?Apache/2.4.41,?nginx/1.18.0）。
- Date: 響應生成的日期和時間。
- Content-Type: 響應體的數據類型（MIME 類型），如?text/html; charset=UTF-8,?image/jpeg,?application/json。
- Content-Length: 響應體的大小（字節數）。
- Content-Encoding: 響應體使用的壓縮編碼（如?gzip），指示客戶端需要解壓。
- Connection: 連接選項（如?keep-alive）。
- Cache-Control: 指示客戶端和中間代理如何緩存此響應。
- Set-Cookie: 服務器要求客戶端存儲一個或多個 Cookie。
- Location: 在重定向響應（3xx）中，指定客戶端應跳轉的新 URL。
- WWW-Authenticate: 在 401 Unauthorized 響應中，指定服務器要求的認證方式。

空行 (Empty Line):

分隔頭部和響應體。

響應體 (Response Body - 可選):

包含服務器返回給客戶端的實際數據內容。最常見的是 HTML 文檔，但也可能是圖片、視頻、CSS、JavaScript、JSON、XML 等。
狀態碼為?204 No Content?或?304 Not Modified?的響應通常沒有響應體。

1.2 HTTP請求過程和原理

1.2.1 請求過程

1、域名（DNS）解析

瀏覽器解析URL中的域名（如?www.example.com）
查詢本地DNS緩存 → 系統Hosts文件 → 遞歸查詢DNS服務器 → 獲取目標服務器的IP地址（如?93.184.216.34）。

2、建立TCP連接（三次握手）

目的：確保雙方具備可靠數據傳輸能力。
端口：HTTP默認?80

3、發送HTTP請求

瀏覽器構建 HTTP 請求，包括請求行、請求頭和請求體；然后將請求發送到服務器。

請求報文結構：

GET /index.html HTTP/1.1          // 請求行（方法+路徑+協議版本）
Host: www.example.com             // 必需頭部
User-Agent: Mozilla/5.0           // 客戶端標識
Accept: text/html                 // 可接受的響應類型
Connection: keep-alive            // 保持連接
(空行)                             // 頭部結束標記
(可選請求體，如POST提交的數據)       // GET請求無請求體

4、服務器處理請求

Web服務器（如Nginx/Apache）接收請求
路由解析（匹配URL到具體處理程序）
應用邏輯執行（如查詢數據庫）
生成響應內容（HTML/JSON等）。

5、返回HTTP響應

響應報文結構：

HTTP/1.1 200 OK                     // 狀態行（協議版本+狀態碼）
Content-Type: text/html; charset=utf-8  // 響應數據類型
Content-Length: 1024                // 數據長度
Set-Cookie: session_id=abc123       // 會話管理
(空行)                               // 頭部結束標記
<!DOCTYPE html>                      // 響應體（實際數據）
<html>...</html>

6、瀏覽器渲染（客戶端側）

解析HTML → 構建DOM樹
加載CSS/JS → 渲染頁面
執行JavaScript邏輯。

7、斷開TCP連接（四次揮手）

HTTP/1.1 默認?keep-alive（復用連接）
超時或顯式關閉時觸發?TCP四次揮手：

1.2.2 核心原理

1、無狀態協議

每次請求獨立，服務器不保存客戶端狀態
解決方案：Cookies/Session/JWT Token 維持會話狀態。

Cookies：服務器通過 Set-Cookie 響應頭將狀態信息存儲在客戶端，客戶端在后續請求中發送該 Cookie 以維持狀態。
Session：服務器生成一個唯一的會話 ID，存儲在 Cookie 中，并在服務器端維護與該會話 ID 關聯的狀態信息。
Token：使用 JWT（JSON Web Token）等機制在客戶端存儲狀態信息，客戶端在每次請求中發送該 Token。

2、持久連接（HTTP/1.1 Keep-Alive）

單TCP連接處理多個請求/響應，減少握手開銷
對比HTTP/1.0（每個請求新建連接）。

3、管道化技術（Pipelining）

客戶端連續發送多個請求而不等響應
實際因隊頭阻塞問題被棄用（必須按照請求相同的順序回送HTTP響應） → HTTP/2 多路復用解決。

1.3 HTTP的不同版本

1.3.1 HTTP1.0

非持久連接：默認情況下，每個 HTTP 請求/響應對之后，連接會被關閉，屬于短連接。這意味著對于同一個網站的每個資源請求，如 HTML 頁面上的圖片和腳本，都需要建立一個新的 TCP 連接。可以設置Connection: keep-alive?強制開啟長連接。

1.3.2 HTTP1.1（常用）

持久連接：HTTP 1.1 引入了持久連接（也稱為 HTTP keep-alive），默認情況下不會立即關閉連接，可以在一個連接上發送多個請求和響應。極大減輕了 TCP 連接的開銷。

持久連接的超時時間：

HTTP/1.1 規范本身沒有定義默認的 keep-alive 超時時間。

實際的默認超時時間取決于使用的具體 Web 服務器軟件和 HTTP 客戶端庫/應用程序的配置。

常見 Web 服務器的典型默認值范圍在 5 秒到 120 秒之間（例如 Nginx 默認為 75 秒）。

客戶端（如瀏覽器）通常也有自己的默認值（可能幾分鐘）。

服務器和客戶端可以通過?Keep-Alive: timeout=?頭部進行協商，最終超時通常由服務器決定或配置。

管道化處理：HTTP 1.1 支持客戶端在前一個請求的響應到達之前發送下一個請求，以提高傳輸效率。有隊頭阻塞問題（必須按照請求相同的順序回送HTTP響應）

1.3.3 HTTP2.0（常用）

二進制分幀：將所有傳輸的信息分割為更小的消息和幀,并對它們采用二進制格式的編碼，其中HTTP1.x的首部信息會被封裝到Headers幀，而我們的request body則封裝到Data幀里面。幀是數據傳輸的最小單位，以二進制傳輸代替原本的明文傳輸。這些幀可以亂序發送，然后再根據每個幀首部的流標識符重新組裝。

多路復用：一個 TCP 連接上可以同時進行多個 HTTP 請求/響應，解決了 HTTP 1.x 的隊頭阻塞問題。盡管從邏輯上來說，不同的流之間相互獨立，不會相互影響，但在實際傳輸的過程中，數據還是要一幀一幀的發送和接收，一旦某一個流的數據有丟包，仍然會阻塞在它之后傳輸的流數據。

頭部壓縮：HTTP 協議不帶狀態，所以每次請求都必須附上所有信息。HTTP 2.0 引入了頭部壓縮機制，可以使用 gzip 或 compress 壓縮后再發送，減少了冗余頭部信息的帶寬消耗。

服務端推送：服務器可以主動向客戶端推送資源，而不需要客戶端明確請求。

1.3.4 HTTP3.0

基于QUIC協議（UDP）：HTTP/2.0 基于 TCP 協議，而 HTTP/3.0 則基于 QUIC 協議，Quick UDP Connections，直譯為快速 UDP 網絡連接。基于 UDP 的 QUIC 協議，讓不同的流之間真正的實現相互獨立傳輸，互不干擾。

版本	核心改進	解決的問題
HTTP/1.0	支持Header、多種請求方法	基礎標準化
HTTP/1.1	持久連接、分塊傳輸	TCP連接復用
HTTP/2	二進制分幀、多路復用、頭部壓縮	隊頭阻塞、性能優化
HTTP/3	基于QUIC協議（UDP）、0-RTT握手	TCP隊頭阻塞、延遲更低