計算機網絡 HTTP篇常見面試題總結

HTTP各版本區別

HTTP 1.0

無狀態、無連接：每次請求都需要建立新的 TCP，處理完后立即關閉，導致開銷較大。
隊頭阻塞：每個請求必須按照順序依次處理，前面的請求未完成，后面的請求只能等待，減低了并發效率。
不支持持久連接：每個請求都建立一個新的 TCP 連接，增加了服務器的負擔

HTTP 1.1

持久連接：引入了 Keep - Alive 機制，多個請求可以復用同一個 TCP 連接，介紹了建立連接的開銷。
管道化：允許在同一個 TCP 連接上同時發送多個請求，提高了并發效率。
Host 字段：可以在同一個 IP 地址上允許多個虛擬主機。
斷點續傳：支持文件傳輸中斷后從斷點處繼續傳輸。

HTTP 2.0

二進制分幀：將 HTTP 報文分割為更小的二進制，提高了傳輸效率，并支持多路復用。
頭部壓縮：減少了 HTTP 頭部的大小，降低了網絡開銷。
服務器推送：服務器可以主動向客戶端推送資源，減少了客戶端的請求次數。
多路復用：在一個 TCP 連接上可以同時發送多個請求和響應，解決了 HTTP 1.1 的隊頭阻塞問題。

HTTP 3.0

基于 QUIC 協議：使用 UDP 協議，相較于 TCP 的可靠性，QUIC 通過自身實現可靠傳輸，減少了 RTT。
多路復用：在一個 QUIC 連接上可以同時傳輸多個請求和響應，并且支持流優先級。
更快的連接建立：減少了 TCP 的三次握手和 TLS 的握手時間。
更低的延遲：由于 QUIC 協議的特性，HTTP 3.0 具有很低的延遲。

常見HTTP狀態碼

1xx: 信息響應

100 Continue: 服務器已接收請求的初步部分，客戶端應繼續請求。
101 Switching Protocols: 服務器同意切換協議，如從 HTTP 切換到 WebSocket。

2xx: 成功

200 OK: 請求成功，服務器返回所請求的資源或數據。
201 Created: 請求成功并創建了新的資源，常用于 POST 請求。
204 No Content: 請求成功但服務器不返回任何內容，常用于刪除操作。

3xx: 重定向

301 Moved Permanently: 資源已永久移動到新的 URL，客戶端應使用新 URL 訪問。
302 Found: 資源臨時移動到新的 URL，客戶端應繼續使用原來的 URL。
304 Not Modified: 資源未修改，客戶端可以使用緩存版本。

4xx: 客戶端錯誤

400 Bad Request: 請求無效或語法錯誤，服務器無法處理。
401 Unauthorized: 請求需要身份驗證，客戶端未提供有效的憑證。
403 Forbidden: 服務器理解請求但拒絕執行，通常是權限問題。
404 Not Found: 請求的資源在服務器上未找到。

5xx: 服務器錯誤

500 Internal Server Error: 服務器內部錯誤，無法完成請求。
502 Bad Gateway: 服務器作為網關或代理，從上游服務器接收到無效響應。
503 Service Unavailable: 服務器暫時無法處理請求，通常是因為過載或維護。

HTTP請求內容組成

HTTP 請求組成：

請求行（Request Line）：包含請求方法（如 GET、POST）、請求的資源路徑（如 /index.html ）、以及 HTTP 協議版本（如 HTTP/1.1）。
請求頭（Request Headers）：包含各種鍵值對，用于傳遞客戶端環境、請求內容、認證信息等。
空行（Blank Line）：用于分隔請求頭和請求體。
請求體（Request Body）：通常在 POST、PUT 等方法中存在，包含需要發送到服務器的數據。

請求頭用于傳遞附加信息：

1.?通用頭（General Headers）

Cache-Control：控制緩存策略（如?no-cache、max-age=3600）
Connection：控制連接狀態（如?keep-alive、close）
Date：請求時間（如?Wed, 30 May 2025 12:00:00 GMT）

2.?請求頭（Request-Specific Headers）

Host：目標服務器域名（如?www.example.com）
User-Agent：客戶端信息（如瀏覽器類型、操作系統）
Accept：客戶端可接收的響應格式（如?application/json、text/html）
Accept-Language：客戶端語言偏好（如?zh-CN,en-US;q=0.8）
Accept-Encoding：客戶端支持的壓縮格式（如?gzip、deflate）
Cookie：存儲的會話信息（如?session_id=123456）
Authorization：身份驗證信息（如?Bearer token123）

3.?實體頭（Entity Headers）

Content-Type：請求體的媒體類型（如?application/json、multipart/form-data）
Content-Length：請求體的長度（如?128）
Content-Encoding：請求體的編碼方式（如?gzip）

請求體的類型由?`Content-Type`?頭決定，常見類型如下：

1.?無請求體（No Body）

適用方法：GET、HEAD、DELETE、OPTIONS

示例：

GET /api/users HTTP/1.1
Host: www.example.com

2.?表單數據（Form Data）

Content-Type：application/x-www-form-urlencoded
格式：鍵值對（key1=value1&key2=value2）

示例：

POST /login HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 27username=admin&password=123456

3.?多部分表單數據（Multipart Form Data）

Content-Type：multipart/form-data; boundary=----WebKitFormBoundary123456
用途：上傳文件或復雜表單

示例：

POST /upload HTTP/1.1
Host: www.example.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary123456------WebKitFormBoundary123456
Content-Disposition: form-data; name="username"admin
------WebKitFormBoundary123456
Content-Disposition: form-data; name="avatar"; filename="photo.jpg"
Content-Type: image/jpeg[二進制文件內容]
------WebKitFormBoundary123456--

4.?JSON 數據

Content-Type：application/json
格式：JSON 對象

示例：

POST /api/users HTTP/1.1
Host: www.example.com
Content-Type: application/json
Content-Length: 27{"name": "John", "age": 30}

5.?XML 數據

Content-Type：application/xml?或?text/xml
格式：XML 文檔

示例：

POST /api/users HTTP/1.1
Host: www.example.com
Content-Type: application/xml
Content-Length: 81<user><name>John</name><age>30</age>
</user>

6.?原始數據（Raw Data）

Content-Type：text/plain、application/javascript?等
用途：傳輸任意格式文本

示例：

POST /api/script HTTP/1.1
Host: www.example.com
Content-Type: text/plain
Content-Length: 10Hello World

HTTP中GET和POST區別

從 HTTP 的定義來看：

GET：用于獲取資源，通常用于請求數據而不改變服務器狀態。
POST：用于提交數據到服務器，通常會改變服務器的狀態或產生副作用（如創建或更新資源）。

由于 HTTP 和瀏覽器等規定，它們在應用過程中會出現一些區別：

參數傳遞方式：

GET：參數通過 URL 拼接傳遞，暴露在請求 URL 中，具有可見性，長度有限（取決于瀏覽器和服務器）。
POST：參數放在請求體中，通常不可見且長度理論上沒有限制，更適合傳遞大量數據（但是注意，POST 也可以在 URL 上放參數！）。

安全性：

GET：參數可見，數據容易暴露在瀏覽器歷史記錄、日志和緩存中，不適合傳遞敏感信息。
POST：數據放在請求體中，相對安全，但需要 HTTPS 才能保證數據加密傳輸。

冪等性：

GET：冪等（重復請求不會改變服務器狀態）。
POST：非冪等（多次請求可能導致重復創建資源或執行多次相同操作）。

GET 和 POST 的數據傳輸方式與限制

URL 長度限制：GET 請求中的參數通過 URL 傳遞，受 URL 長度限制。不同瀏覽器和服務器對 URL 長度限制不同，一般為 2048 字節左右，因此不適合大數據傳輸。
POST 請求體限制：POST 請求的數據放在請求體中，理論上無長度限制，適合傳輸較多的數據。但實際中服務器對請求體長度有配置限制，如 Nginx 默認限制為 1MB，可根據需求調整。

GET 和 POST 的數據安全性差異

GET 請求暴露數據：由于 GET 請求的參數出現在 URL 中，可能被瀏覽器緩存、日志記錄或歷史記錄保存，增加了信息泄露的風險，不適合傳輸敏感信息，如用戶名、密碼等。
POST 請求相對安全：POST 請求數據位于請求體中，盡管這并不提供加密保護，但比 URL 中傳遞更隱蔽。配合 HTTPS 加密傳輸可進一步確保數據安全。

緩存機制的不同

GET 請求可緩存：GET 請求可以被瀏覽器和 CDN 緩存，當請求同一個 URL 時可以直接返回緩存內容，減少服務器負載。適用于不頻繁變動的資源，比如圖片、靜態頁面。
POST 請求默認不緩存：大部分瀏覽器和緩存服務器不緩存 POST 請求，主要因為 POST 請求通常會對服務器數據產生影響（如創建、修改數據），需要確保請求每次都傳遞到服務器。

HTTP和HTTPS區別

數據傳輸安全性：

HTTP：數據以明文傳輸，容易被竊聽、篡改。
HTTPS：通過 SSL/TLS 協議對數據進行加密傳輸，提供數據機密性和完整性保障。

端口號：

HTTP：默認使用端口 80。
HTTPS：默認使用端口 443。

性能：

HTTP：無加密過程，連接建立速度稍快。
HTTPS：基于 HTTP 上又加了 SSL（Secure Sockets Layer）或 TLS（Transport Layer Security）協議來實現的加密傳輸，加解密過程增加了計算開銷，握手時間較長，但現代硬件和協議優化已使性能差距減小。

SEO 影響：

HTTP：搜索引擎一般會降低未加密站點的排名。
HTTPS：搜索引擎更傾向于優先展示 HTTPS 網站。

HTTPS握手過程

TLS 握手過程概述

TLS 握手是客戶端與服務器建立安全連接的關鍵步驟，主要目的是：

驗證雙方身份（通常驗證服務器身份）。
協商加密算法和密鑰（對稱密鑰和非對稱密鑰）。
確保通信內容的機密性和完整性。

基于 RSA 算法的 TLS 握手流程

核心流程（簡化版）：

客戶端發起請求（ClientHello）
- 客戶端發送支持的 TLS 版本、加密算法列表（如 RSA 相關套件）、隨機數（Client Random）等信息。
服務器響應（ServerHello）
- 服務器選擇 TLS 版本、加密算法（如 RSA）、隨機數（Server Random），并發送服務器證書（含 RSA 公鑰）。
客戶端驗證服務器證書
- 客戶端通過信任的 CA 驗證服務器證書的合法性，提取服務器公鑰。
客戶端生成預主密鑰（Pre-Master Secret）
- 客戶端生成一個隨機數作為預主密鑰，用服務器公鑰加密后發送給服務器（RSA 加密過程）。
服務器解密預主密鑰
- 服務器用私鑰解密獲取預主密鑰，結合雙方隨機數（Client Random?和?Server Random）生成?主密鑰（Master Secret）。
生成對稱密鑰
- 客戶端和服務器分別根據主密鑰生成用于加密通信的對稱密鑰（如 AES 密鑰）。
驗證握手完整性
- 雙方發送握手結束消息，使用新生成的密鑰對消息進行加密和校驗，確保握手過程未被篡改。

基于 ECDHE 算法的 TLS 握手流程

核心流程（簡化版）：

客戶端發起請求（ClientHello）
- 類似 RSA 流程，但支持的加密算法包含 ECDHE 相關套件（如 ECDHE-ECDSA-AES256-GCM-SHA384）。
服務器響應（ServerHello）
- 選擇 ECDHE 算法，發送服務器證書（含 ECDSA 公鑰或 RSA 公鑰，取決于簽名算法）、橢圓曲線參數、服務器端生成的橢圓曲線私鑰對應的公鑰（Server PubKey）。
客戶端驗證服務器證書
- 驗證證書合法性，提取服務器公鑰。
客戶端生成橢圓曲線密鑰對
- 客戶端生成臨時橢圓曲線密鑰對（Client PrivKey?和?Client PubKey），發送?Client PubKey?給服務器。
協商共享密鑰（ECDHE 密鑰交換）
- 客戶端和服務器分別用對方的公鑰與自己的私鑰計算出?共享秘密（Shared Secret）：
  - 客戶端：用?Server PubKey?和?Client PrivKey?計算共享秘密。
  - 服務器：用?Client PubKey?和?Server PrivKey?計算共享秘密。
- 雙方得到的共享秘密相同，結合隨機數生成?預主密鑰?和?主密鑰。
生成對稱密鑰
- 與 RSA 流程類似，基于主密鑰生成對稱加密密鑰。
驗證握手完整性
- 流程與 RSA 一致。