文章目錄
- 計算機網絡
- 網絡模型
- 網絡OSI
- TCP/IP
- 應用層
- 常用協議
- HTTP報文
- HTTP狀態碼
- HTTP請求類型
- HTTP握手過程
- HTTP連接
- HTTP斷點續傳
- HTTPS
- HTTPS握手過程
計算機網絡
網絡模型
為了解決多種設備能夠通過網絡相互通信，解決網絡互聯兼容性問題。
網絡模型是計算機網絡中用于理解和設計網絡通信的分層架構
主要分OSI模型和TCP/IP模型
網絡OSI
-
物理層
傳輸原始比特流，定義物理介質（電纜、光纖等）的電氣、機械特性。
數據單元：比特（Bit）
-
數據鏈路層
數據封幀，在直接相連的節點間可靠傳輸數據幀，MAC地址尋址，錯誤檢測。
數據單元：幀
-
網絡層
負責數據的路由轉發分片,IP地址尋址。
數據單元：數據包
-
傳輸層
端到端通信，確保可靠傳輸（TCP）或快速傳輸（UDP）。
數據單元：TCP,UDP
-
會話層
建立、管理和終止會話，同步數據交換。
-
表示層
數據格式轉換、加密/解密（如SSL/TLS）、壓縮（如JPEG、MPEG）。
-
應用層
提供用戶統一的接口，支持應用程序通信。
TCP/IP
-
網絡接口層
處理物理連接和本地網絡數據傳輸。
-
網絡層
IP尋址、路由。
-
傳輸層
處理主機到主機的通信（TCP、UDP）。
-
應用層
支持 HTTP、SMTP 等最終用戶進程。
應用層
- 提供應用程序與網絡之間的交互接口（如瀏覽器、郵件客戶端）。
- 用戶通過應用層協議訪問網絡服務（如訪問網頁、發送郵件）。
常用協議
HTTP,HTTPS,CDN,DNS等。
默認端口：
HTTP：80
HTTPS: 443
HTTP報文
無論是請求報文還是回應報文，均有3部分組成
|-----------------------|
| 起始行 | → 請求方法/狀態碼等
|-----------------------|
| 頭部字段 | → 元數據（鍵值對）
|-----------------------|
| 空行 | → 分隔頭部和正文
|-----------------------|
| 消息體 | → 實際傳輸的數據（可選）
|-----------------------|
-
請求報文
[起始行]：方法/請求URL/HTTP版本
[頭部字段]：包含關于請求的附加信息，如Host、User-Agent、Content-Type等。
[空行]
[消息體]：用于傳遞數據（如POST請求的表單或JSON數據）。POST /login HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 Content-Type: application/x-www-form-urlencoded Content-Length: 27username=admin&password=123 -
響應報文
[起始行] :包含HTTP版本/狀態碼/狀態信息。
[頭部字段] :包含關于響應的附加信息，響應數據類型,數據類型，cookie等
[空行]
[消息體] :包含響應的數據，通常是服務器返回的HTML、JSON等內容HTTP/1.1 200 OK Content-Type: text/html Content-Length: 137 Date: Wed, 21 Oct 2023 07:28:00 GMT<html><body><h1>Welcome to Example.com</h1></body> </html>
HTTP狀態碼
| 分類 | 描述 | 常見狀態碼 |
|---|---|---|
| 1xx | 信息類（請求已被接收，繼續處理） | 100, 101 |
| 2xx | 成功類（請求被成功處理） | 200, 201, 204 |
| 3xx | 重定向類（需進一步操作以完成請求） | 301, 302, 304 |
| 4xx | 客戶端錯誤類（請求有誤，服務器無法處理） | 400, 401, 403, 404 |
| 5xx | 服務器錯誤類（服務器處理請求失敗） | 500, 502, 503 |
其中常用的狀態碼：
- 200：請求被成功處理
- 301：資源已永久遷移到新URL（網站更換域名，舊鏈接跳轉到新地址）
- 302：資源臨時從其他URL返回，客戶端后續應繼續請求原地址（未登錄用戶訪問受限頁面，臨時跳轉到登錄頁）
- 404：請求的資源不存在
- 500：服務器內部錯誤，無法完成請求（后端代碼拋出未捕獲的異常，如數據庫連接失敗）
HTTP請求類型
-
GET
-
用途：獲取資源（從服務器讀取數據）。
-
特點：
- 安全且冪等。(冪等：多次重復請求與單次請求效果相同)
- 參數通過 URL 傳遞（如
/users?id=1）。 - 通常無請求體（但技術上允許）。
-
示例：
GET /api/users/1 HTTP/1.1 Host: example.com
-
-
POST
-
用途：提交資源（向服務器發送數據，可能創建新資源）。
-
特點：
- 非安全、非冪等（非冪等：多次請求可能產生不同結果）。
- 數據通過請求體傳輸（如 JSON、表單）。
- 常用于創建新資源或觸發復雜操作。
-
示例：
POST /api/users HTTP/1.1 Content-Type: application/json{"name": "Alice", "age": 25}
-
-
PUT
-
用途：全量更新資源（替換目標資源的全部內容）。
-
特點：
- 冪等。
- 需指定完整資源數據，用于覆蓋已有內容。
- 若資源不存在，可能創建新資源（取決于實現）。
-
示例：
PUT /api/users/1 HTTP/1.1 Content-Type: application/json{"name": "Bob", "age": 30}
-
-
DELETE
-
用途：刪除資源。
-
特點：
- 冪等。
- 通常無請求體。
-
示例：
DELETE /api/users/1 HTTP/1.1 Host: example.com
-
-
HEAD
-
用途：獲取資源的元數據（與
GET類似，但無響應體）。 -
特點：
- 安全且冪等。
- 常用于檢查資源是否存在或驗證緩存。
-
示例：
HEAD /api/users/1 HTTP/1.1 Host: example.com
-
HTTP握手過程
HTTP 本身無握手過程，其通信依賴 TCP 三次握手建立連接。
整個過程如下:
1.TCP三次握手
客戶端 服務器| || ---- SYN（seq=x） ----------> || || <--- SYN-ACK（seq=y, ack=x+1）-|| || ---- ACK（ack=y+1） --------->|| |
-
步驟解釋：
-
SYN：客戶端發送同步報文，攜帶初始序列號
seq=x。 -
SYN-ACK：服務器回應同步確認，攜帶自己的序列號
seq=y和對客戶端的確認號ack=x+1。 -
ACK：客戶端確認服務器的響應，連接建立。
-
2.HTTP請求/響應
TCP 連接建立后，客戶端直接發送 HTTP 請求：
GET /index.html HTTP/1.1
Host: example.com
服務器返回 HTTP 響應：
HTTP/1.1 200 OK
Content-Type: text/html<html>...</html>
3.連接關閉
通信完成后，通過四次揮手關閉連接：
客戶端 服務器| || ---- FIN -------------------> || <---- ACK ------------------- || || <---- FIN ------------------- || ---- ACK -------------------> || |
HTTP連接
HTTP是基于 TCP 傳輸協議實現的，客戶端與服務端要進行 HTTP 通信前，需要先建立 TCP 連接,然后客戶端發送 HTTP 請求，服務端收到后就返回響應。
- 短連接
這樣的連接就是短連接，一次連接只能請求一次資源。
-
長連接
HTTP 的 Keep-Alive 就是實現了這個功能，可以使用同一個 TCP 連接來發送和接收多個 HTTP 請求/應答，只要任意一端沒有明確提出斷開連接，則保持 TCP 連接狀態，避免了連接建立和釋放的開銷，這個方法稱為 HTTP 長連接。
HTTP斷點續傳
斷點續傳允許客戶端只請求資源的一部分，而不是整個文件。這對于大文件下載非常有用，特別是當下載中斷時，可以從中斷的地方繼續，而不必重新開始
舉個例子，大文件下載中斷后恢復的流程如下：
假設文件總大小為2GB(2,147,483,648 字節)，已經下載了500MB(即 524,288,000 字節)后中斷了，剩余1.5GB未下載。
-
客戶端首次下載（0~500MB）
客戶端未指定
Range頭部，嘗試完整下載：GET /large-video.mp4 HTTP/1.1 Host: example.com -
服務器響應
服務器返回完整文件（若支持斷點續傳，會包含
Accept-Ranges: bytes）：HTTP/1.1 200 OK Accept-Ranges: bytes Content-Length: 2147483648 Content-Type: video/mp4[視頻文件的前 524,288,000 字節...（下載中途網絡斷開）] -
客戶端發送 HEAD 請求
確認服務器是否支持范圍請求：
HEAD /large-video.mp4 HTTP/1.1 Host: example.com -
服務器響應：
返回
Accept-Ranges: bytes表示支持：HTTP/1.1 200 OK Accept-Ranges: bytes Content-Length: 2147483648 Content-Type: video/mp4 Last-Modified: Wed, 21 Oct 2023 00:00:00 GMT ETag: "abc123xyz" -
客戶端發起續傳請求：
通過
Range頭部指定從已下載位置繼續請求：GET /large-video.mp4 HTTP/1.1 Host: example.com Range: bytes=524288000- # 請求 500MB 之后的所有數據 If-Range: "abc123xyz" # 使用 ETag 校驗文件未修改-
Range: bytes=524288000-：表示請求從第 500MB 到文件末尾。 -
If-Range：若文件未修改（ETag 匹配），服務器返回剩余部分；若已修改，返回完整文件。
-
-
服務器處理請求：
-
文件未修改：返回
206 Partial Content和剩余數據：HTTP/1.1 206 Partial Content Content-Range: bytes 524288000-2147483647/2147483648 Content-Length: 1623195648 # 剩余 1.5GB 的長度（2147483648 - 524288000=1623195648） Content-Type: video/mp4 ETag: "abc123xyz"[視頻文件的 500MB ~ 2GB 數據] -
文件已修改：返回
200 OK和完整文件（需重新下載）。
-
-
客戶端合并文件：
客戶端將已下載的
500MB數據與續傳的1.5GB數據按字節順序拼接，得到完整文件。
HTTPS
HTTP和 HTTPS（HTTP Secure）是 Web 通信的核心協議，HTTPS 本質是 HTTP 的安全版本，通過加密和身份驗證保障數據傳輸的安全性。
HTTP為什么不安全？
核心原因在于其明文傳輸、缺乏身份驗證和完整性保護
-
明文傳輸
HTTP協議在傳輸過程中不加密數據，所有內容（如密碼、銀行卡號、聊天記錄）均以明文形式在網絡中傳輸。
-
無身份驗證
HTTP協議不驗證服務器身份，用戶無法確認自己連接的是真實服務器還是攻擊者的偽造站點。
-
數據無完整性保護
HTTP傳輸的數據無完整性校驗機制，攻擊者可隨意修改傳輸內容。
所以就需要用到HTTPS進行安全管理：
那么HTTPS是如何保證安全性的呢？
- 在 TCP 和 HTTP 網絡層之間加入了 SSL/TLS 安全協議，使得報文能夠加密傳輸。
- HTTPS 在 TCP 三次握手之后，還需進行 SSL/TLS 的握手過程，才可進入加密報文傳輸。
- HTTPS 協議需要向 CA（證書權威機構）申請數字證書，來保證服務器的身份是可信的。
HTTPS握手過程
HTTPS 在 TCP 連接基礎上增加了 TLS/SSL 握手，用于協商加密參數、驗證身份并生成會話密鑰。
1.TCP 三次握手
與 HTTP 相同，首先建立 TCP 連接。
2.TLS握手
客戶端 服務器| || ---- Client Hello（支持的加密套件等）-----> || || <---- Server Hello（選定加密套件）--------- || <---- Certificate（服務器證書）----------- || <---- Server Key Exchange（可選）--------- || <---- Server Hello Done ---------------- || || ---- Client Key Exchange（預主密鑰）------> || ---- Change Cipher Spec（準備加密）-------> || ---- Finished（加密驗證）----------------> || || <---- Change Cipher Spec（準備加密）------- || <---- Finished（加密驗證）---------------- || |
-
第一次握手
客戶端向服務器發起加密通信請求，也就是 ClientHello 請求。
- TLS 版本：支持的 TLS 版本。
- 隨機數1：32 字節的隨機數，用于生成會話密鑰。
- 加密套件列表：支持的加密算法組合
-
第二次握手
服務器收到客戶端請求后，向客戶端發出響應，也就是 SeverHello。
- TLS 版本：雙方協商后的版本。
- 隨機數2：32 字節的隨機數，也用于生成會話密鑰。
- 選定的加密套件：從客戶端列表中選擇的加密套件
- 證書鏈：服務器公鑰證書（由 CA 簽發）
-
第三次握手
Client Key Exchange。
客戶端收到服務器的回應之后，首先通過瀏覽器或者操作系統中的 CA 公鑰，確認服務器的數字證書的真實性。
如果證書沒有問題，客戶端會從數字證書中取出服務器的公鑰，然后使用它加密報文，向服務器發送如下信息：
- 隨機數3：該隨機數會被服務器公鑰加密。
- 加密通信算法改變通知，通知服務器后續消息將加密。
- 客戶端握手結束通知。
密鑰生成過程：
- 客戶端使用3個隨機數生成 主密鑰（Master Secret）。
- 主密鑰進一步生成 會話密鑰（Session Key）
-
第四次握手
- 服務器 → 客戶端
服務器確認加密參數：- Change Cipher Spec：通知客戶端后續消息加密。
- Finished：發送加密的驗證消息，確認握手完整性。
- 服務器 → 客戶端
3.加密的HTTP通信
握手完成后，所有 HTTP 數據通過會話密鑰加密傳輸：
客戶端 服務器| || ---- Encrypted HTTP Request -----------> || <---- Encrypted HTTP Response ---------- || |
4.連接關閉
先關閉 TLS 連接，再關閉 TCP 連接。
不斷學習中，結合小林Coding整理了些筆記，感謝大家的觀看>W<
