從spring MVC角度理解HTTP協議及Request-Response模式

什么是HTTP協議？HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是一種通信規則，它定義了客戶端（如瀏覽器、手機APP）?和服務器?之間如何交換信息，是用于在萬維網（WWW）中傳輸數據的應用層協議，它定義了客戶端與服務器之間如何通信、如何請求資源如網頁、圖片、視頻,以及如何響應請求，是互聯網信息交互的通用語言。

?一、HTTP協議的核心定位：應用層的通信規則在TCP/IP協議棧（互聯網的基礎通信框架）中，HTTP屬于應用層協議，其底層依賴傳輸層的TCP協議提供可靠的數據傳輸通道。TCP負責把數據安全送到對方，確保數據不丟失、不混亂，HTTP負責定義數據的格式和交互邏輯。?

二、 HTTP的核心特點：1. 無狀態HTTP協議本身不記錄“前后請求的關聯”——服務器不會記住上一次給這個客戶端發了什么，每次請求都是獨立的、全新的。例如：你第一次訪問某購物網站，服務器不知道你是誰；第二次點擊“加入購物車”，若沒有Cookie或Token（用于身份標識的技術），服務器依然不認識你。 2. 請求-響應模式（Request-Response）通信必須由客戶端主動發起，服務器只能“被動響應”，不會主動向客戶端發送數據。流程固定為：客戶端發送請求 → 服務器處理請求 → 服務器返回響應3. 可擴展HTTP允許通過頭部字段擴展功能，比如用Accept-Encoding: gzip告訴服務器我支持壓縮數據。 4. 媒體無關HTTP可傳輸任意類型的數據（只要客戶端和服務器約定好格式，包括網頁、圖片、視頻、JSON數據等。

三、HTTP的核心交互流程：請求與響應一次完整的HTTP通信，本質是客戶端發請求、服務器回響應的過程，兩者都有固定的格式。

1. HTTP 請求（客戶端→服務器）
請求由 3 部分組成：請求行、請求頭部、請求體（可選）。

請求頭部：輔助信息，如Host（指定服務器域名）、Cookie（攜帶客戶端的身份信息，如登錄狀態）、Content-Type（POST 請求時，說明請求體的數據格式，如application/json）。
請求體：僅 POST/PUT 等請求有，用于傳遞數據（如登錄時的 “用戶名 + 密碼”、上傳的文件內容）。請求行：核心信息，決定 “要做什么”。請求方法：常用有GET（獲取資源，如打開網頁）、POST（提交數據，如登錄、上傳表單）、PUT（修改資源）、DELETE（刪除資源）。

程序如何接收前端網頁的數據？第一種方式：通過GET、POST等請求。

這種方式首先就要在方法上加上注解@RequestMapping并給定路徑("v1/car/add")而要給客戶端反饋還得加上@ResponseBody注解。同時用戶在輸入網址的時候要按照以下格式：localhost:+（本地的port）+路徑+？+給定參數賦值

@Controller
public class CarController {@RequestMapping("v1/car/add")@ResponseBodypublic String add(String brand,String color,int price){System.out.println("品牌是："+brand+"顏色是"+color+"價格是"+price);return "add";}
}

localhost:8080/v1/car/add?brand=tsl&color=black&price=100000

這種方式屬于后端，需要注意一定要先啟動程序，然后再輸入網址，順序不能反，如果有修改代碼，也一定要重新運行程序。

第二種方式：通過.html文件獲取。

所有的.html文件都屬于靜態資源，所以應該在resources中的static里面創建。完成創建后里面會有個<body>的標簽，在<body>內即可編輯頁面。比如想拿到車輛的brand、color、price等信息并添加，先設置好路徑并告訴它方法是post（post就是添加的作用）然后用<input>標簽就可以讓用戶輸入，并給placeholder提示。在打開網頁的時候一定要確保后端的代碼仍然處于運行狀態。

<!DOCTYPE html>
<html lang="en">
<head><meta charset="UTF-8"><title>Title</title>
</head>
<body>
<form action="http://localhost:8080/v1/car/add" method="post"><input type="text" name="brand" placeholder="請輸入品牌"><input type="text" name="color" placeholder="請輸入顏色"><input type="text" name="price" placeholder="請輸入價格"><input type="submit" value="添加車輛">
</form>
</body>
</html>

這就通過用.html完成了新增車輛的功能，但這屬于前端的處理方式，不再做過多的討論。

這里只有三個參數需要給，但實際中可能會有很多參數，而一旦只要有一個字母打錯了就可能導致整個程序沒法收到客戶端的請求。那么就可以將客戶端提供的數據先保存到一個AddCarDTO類中并定義必要的參數，加上tostring/get/set方法，這個DTO類可以放到一個pojo包里面，那么程序就會根據這個類來得到客戶端輸入的數據。

    @RequestMapping("/v1/car/add2")@ResponseBodypublic String add2(AddCarDTO addCarDTO){System.out.println(addCarDTO);return "add";}

localhost:8080/v1/car/add2

localhost:8080/v1/car/add2?brand=byd&color=white&price=300000

可以看到，分別給了沒值和有值的，就算不輸入必要的信息，它也會給默認值而不會獲取失敗，這樣既能方便用戶輸入，也減少了輸入錯誤的可能。

接下來在當前工程實現一個功能：BMI身體質量指數測試 BMIController。客戶端將用戶的身高height和體重weight 傳遞給服務端，服務端接收參數并計算用戶的身體健康指數。計算公式：bmi = 體重kg/(身高m*身高)<18.5 偏瘦 <24 正常 <27 微胖 >=27 該減肥了

先在pojo里面創建一個BmiDTO類，接收網頁數據時就是用這個類，同時加上get/set/tostring方法。然后在Controller中創建BMIController類，用于計算bmi，屬于后端的業務。根據接收的BmiDTO類的對象，獲取其中的高度和重量，完成計算后根據bmi所在的范圍給客戶端反饋。

public class BmiDTO {private double weight;private double height;@Overridepublic String toString() {return "BmiDTO{" +"weight=" + weight +", height=" + height +'}';}public double getWeight() {return weight;}public void setWeight(double weight) {this.weight = weight;}public double getHeight() {return height;}public void setHeight(double height) {this.height = height;}
}

@Controller
public class BMIController {@RequestMapping("/v1/bmi/func")@ResponseBodypublic String func(BmiDTO bmi){double high=bmi.getHeight();double weight=bmi.getWeight();double res=weight/(high*high);if(res<18.5)return "偏瘦";else if(res<24)return "正常";else if(res<27)return "微胖";elsereturn "該減肥了";}
}

2. HTTP 響應（服務器→客戶端）
響應同樣由 3 部分組成：狀態行、響應頭部、響應體（可選）。
狀態行：核心是狀態碼，用數字表示請求的處理結果（常見狀態碼如下表）。
響應頭部：輔助信息，如Content-Type（標識響應體的類型）、Set-Cookie（服務器向客戶端寫入 Cookie，如登錄后的身份令牌）、Cache-Control（控制資源的緩存策略，如 “緩存 1 小時”）。
響應體：服務器返回的實際數據，如 HTML 網頁、JSON 數據、圖片二進制流等（若狀態碼是 404，響應體可能是 “404 頁面找不到” 的提示內容）。

常見 HTTP 狀態碼分類
狀態碼以 “第一位數字” 區分含義，核心常用碼如下：

??????? 1xx（信息性）：臨時響應，告知客戶端 “請求已收到，正在處理”（極少用，如100 Continue）。
??????? 2xx（成功）：請求已正常處理，最常用：
??????? 200 OK：通用成功（如網頁加載、API 調用成功）；
??????? 201 Created：資源創建成功（如 POST 請求新增用戶、上傳文件成功）。
??????? 3xx（重定向）：請求需要進一步操作（客戶端需跳轉）：
??????? 301 Moved Permanently：永久重定向（如舊域名跳轉新域名，搜索引擎會更新地址）；
??????? 302 Found：臨時重定向（如登錄后跳轉首頁，下次訪問仍走原地址）；
??????? 304 Not Modified：緩存命中（客戶端本地有最新緩存，無需重新下載資源）。
??????? 4xx（客戶端錯誤）：請求本身有問題，服務器無法處理：
??????? 400 Bad Request：請求參數錯誤（如 JSON 格式錯誤、必填字段缺失）；
??????? 401 Unauthorized：未授權（需要登錄或令牌失效）；
??????? 403 Forbidden：權限不足（已登錄，但無操作權限，如普通用戶刪管理員數據）；
??????? 404 Not Found：資源不存在（如訪問不存在的網頁、API 路徑錯誤）。
??????? 5xx（服務器錯誤）：服務器處理請求時出錯（客戶端無錯）：
??????? 500 Internal Server Error：通用服務器錯誤（如代碼 bug、數據庫連接失敗）；
??????? 502 Bad Gateway：網關錯誤（服務器作為網關時，上游服務器無響應，如反向代理后端掛了）；
??????? 503 Service Unavailable：服務暫時不可用（如服務器維護、負載過高）；
??????? 504 Gateway Timeout：網關超時（上游服務器響應太慢，網關等不及）。

在瀏覽器中輸入www.360buy.com打開的卻是京東頁面

背后核心是域名重定向機制，對應的 HTTP 狀態碼主要是 3xx 系列重定向狀態碼，最常見的是 301 永久重定向或 302 臨時重定向，其中京東對該域名的配置更可能是 301 永久重定向。
為什么會跳轉？—— 域名歷史與重定向邏輯
360buy.com 本身是京東早期使用的域名（京東曾用名 “360buy 京東”），后來為了品牌統一，將主域名切換為 jd.com。為了避免老用戶因記憶舊域名無法訪問，京東會通過服務器配置，讓所有訪問 www.360buy.com 的請求自動跳轉到 www.jd.com（或京東主站其他地址），這個過程就是 “HTTP 重定向”。
核心狀態碼：301 和?302 的區別
重定向的核心是通過 HTTP 響應頭中的 Location 字段指定新地址，同時用 3xx 狀態碼告訴瀏覽器 “該地址已變更，請訪問新地址”。其中京東對 360buy.com 的配置更可能是 301 永久重定向

四、HTTP與HTTPS的核心區別

我們常說的 “HTTP 不安全”，本質是它傳輸數據時不加密，數據在網絡中可能被攔截、篡改（如 “中間人攻擊”）。而 HTTPS（HTTP Secure）是 “HTTP+SSL/TLS 加密協議” 的組合，解決了安全問題：

HTTP 協議（HyperText Transfer Protocol，超文本傳輸協議）和 HTTPS 協議（HyperText Transfer Protocol Secure，超文本傳輸安全協議）是互聯網中用于客戶端（如瀏覽器）與服務器之間數據傳輸的核心協議，二者的核心區別在于安全性，但在傳輸原理、端口、應用場景等維度也存在顯著差異。以下從 7 個關鍵維度進行詳細對比，并補充核心原理說明：

1.安全性：明文 vs 加密（核心區別）
HTTP 的安全隱患：HTTP 傳輸的數據是 “明文”—— 比如在網頁上輸入的賬號密碼、支付信息，會以 “原始文本” 的形式在網絡中傳輸。如果數據被 “中間人”（如黑客通過公共 WiFi 攔截、路由器劫持）捕獲，可直接讀取內容，甚至篡改數據，完全無安全保障。
HTTPS 的安全機制：HTTPS 通過SSL/TLS 協議解決了 HTTP 的安全問題，核心依賴兩種加密技術和證書驗證,混合加密（對稱加密 + 非對稱加密）,通過?TLS/SSL 協議對 HTTP 協議的傳輸過程進行加密和認證，從而解決 HTTP 協議原生存在的明文傳輸、身份不可信、數據易篡改三大安全問題。
服務器需安裝權威 CA 機構頒發的證書，證書中包含服務器的公鑰和身份信息。客戶端（瀏覽器）會驗證證書的合法性 —— 若證書無效，瀏覽器會彈出 “不安全” 警告，避免用戶連接到偽裝的釣魚網站。

2. 傳輸流程：簡單 vs 多握手步驟
HTTP 傳輸流程：客戶端通過 TCP 協議與服務器的 80 端口建立連接；客戶端發送 HTTP 請求；服務器返回 HTTP 響應；連接關閉（或保持長連接）。整個過程無額外安全步驟，流程簡單。
HTTPS 傳輸流程：在 HTTP 流程基礎上，增加了SSL/TLS 握手階段（約 3-4 次 TCP 交互）：客戶端與服務器的 443 端口建立 TCP 連接；SSL/TLS 握手：客戶端發送 “支持的加密算法列表”“隨機數 A”；服務器返回 “選定的加密算法”“隨機數 B”“服務器 SSL 證書”；客戶端驗證證書合法性，生成 “預主密鑰”，用服務器公鑰加密后發送給服務器；客戶端和服務器分別用 “隨機數 A + 隨機數 B + 預主密鑰” 生成相同的 “對稱加密密鑰”；后續的 HTTP 請求 / 響應，均用 “對稱加密密鑰” 加密后傳輸；連接關閉（或保持長連接）。握手階段是 HTTPS 比 HTTP 慢的主要原因，但現代瀏覽器和服務器會通過會話復用等技術減少重復握手，降低性能損耗。

在網絡通信中優先使用https，它從根本上解決了 HTTP 協議的安全缺陷，能保護數據傳輸的完整性、機密性和身份真實性，同時滿足現代網絡環境對安全、合規和用戶信任的核心需求。