SpringBoot項目中HTTP請求對響應體進行壓縮的方法

更新時間：2025年06月13日 08:44:36 作者：冰糖心書房

本文我們將梳理一下 Spring Boot 項目中是如何對 HTTP 請求的響應體 (Response Body) 進行壓縮,請注意：壓縮是針對服務器返回給客戶端的響應體,而不是客戶端發(fā)給服務器的請求 URL 或請求體,需要的朋友可以參考下

結論：

Spring Boot 默認開啟了對常見文本類型（如 JSON, HTML, CSS, JS）的響應體壓縮（Gzip），通常我們不需要做任何配置！只需要確保：

響應體大小超過了默認閾值 (2048 bytes)。
響應 Content-Type 是默認支持壓縮的類型之一 (如 application/json)。
客戶端在請求頭中聲明了 Accept-Encoding: gzip (目前瀏覽器和工具默認都會加)。

下面是詳細的解釋和配置方法：

1. 壓縮工作原理 (協(xié)商機制)

壓縮過程是由客戶端和服務器自動協(xié)商完成的，對Controller 代碼透明：

客戶端請求 (Request):
瀏覽器或 HTTP 客戶端發(fā)送請求時，在請求頭中攜帶 Accept-Encoding 字段，告知服務器它支持哪些壓縮算法。

 GET /api/data HTTP/1.1
 Host: example.com
 Accept: application/json
 Accept-Encoding: gzip, deflate, br

服務器響應 (Response):
Spring Boot（及其內嵌容器如 Tomcat）檢查到：

服務器開啟了壓縮功能。
客戶端 Accept-Encoding 中包含服務器支持的算法（如 gzip）。
響應的 Content-Type 在配置的 mime-types 列表中。
響應體的大小超過了配置的 min-response-size。
如果所有條件滿足，服務器將：
使用協(xié)商好的算法（如 gzip）壓縮響應體。
在響應頭中添加 Content-Encoding 字段，告知客戶端使用了何種算法。
響應頭中的 Content-Length 變?yōu)閴嚎s后的大小。
發(fā)送壓縮后的數(shù)據(jù)。

 HTTP/1.1 200 OK
 Content-Type: application/json
 Content-Encoding: gzip 
 Content-Length: 850  // <- 壓縮后的大小 (例如原始大小是 3KB)
 ...
 [壓縮后的二進制數(shù)據(jù)]

客戶端接收:
客戶端看到 Content-Encoding: gzip 后，自動對收到的響應體進行解壓，再處理原始數(shù)據(jù)。

2. Spring Boot 配置

你可以在 application.properties 或 application.yml 中進行配置和微調。

使用 application.properties:

# 1. 啟用響應壓縮 ( ? 默認值: true )
#    如果你確定前端有反向代理（如 Nginx）在做壓縮，可以在這里設為 false，避免重復壓縮。
server.compression.enabled=true 

# 2. 配置需要壓縮的內容類型 MIME types ( ? 默認值已包含常見類型)
#    只有 Content-Type 匹配這里的列表，才會被考慮壓縮。
#    默認值包括: text/html, text/xml, text/plain, text/css, text/javascript, 
#               application/javascript, application/json, application/xml 等等。
#    注意：不要添加已經壓縮過的類型，如 image/jpeg, image/png, application/zip 等，重復壓縮浪費 CPU 且效果差。
server.compression.mime-types=application/json,application/xml,text/html,text/plain,application/javascript,text/css

# 3. 觸發(fā)壓縮的最小響應體大小 ( ? 默認值: 2048 bytes，即 2KB )
#    如果響應體小于此值，即使?jié)M足其他條件也不會壓縮。
#    因為對小數(shù)據(jù)進行壓縮的 CPU 開銷可能大于節(jié)省的帶寬，得不償失。
#    單位是字節(jié)。
server.compression.min-response-size=1024 # 例如，改為 1KB

# (可選) 排除某些 User-Agent
# server.compression.excluded-user-agents=some-bad-client

使用 application.yml:

server:
 compression:
   enabled: true # 默認 true
   mime-types: # 默認包含常見類型
     - application/json
     - application/xml
     - text/html
     - text/plain
     - application/javascript
     - text/css
   min-response-size: 1024 # 默認 2048 bytes

3. Controller 代碼示例

你的 Controller 代碼無需做任何修改！Spring Boot / 內嵌服務器會自動處理。

 import org.springframework.web.bind.annotation.GetMapping;
 import org.springframework.web.bind.annotation.PostMapping;
 import org.springframework.web.bind.annotation.RequestBody;
 import org.springframework.web.bind.annotation.RestController;
 import java.util.List;
 import java.util.stream.Collectors;
 import java.util.stream.IntStream;

 @RestController
 public class MyController {

     // 模擬一個返回較大數(shù)據(jù)，用于測試 GET 請求的響應壓縮
     @GetMapping("/api/users")
     public List<String> getUsers() {
        // 生成一個較大的列表，確保 JSON 序列化后大小超過 server.compression.min-response-size
         return IntStream.range(0, 1000)
                 .mapToObj(i -> "User Name - " + i + " with some description text here.")
                 .collect(Collectors.toList());
     }
     
      // 模擬一個 POST 請求，它的響應體同樣會被壓縮
      @PostMapping("/api/users/filter")
     public List<String> filterUsers(@RequestBody String filter) {
          // 假設過濾后仍然返回一個大數(shù)據(jù)
          return IntStream.range(0, 800)
                 .mapToObj(i -> "Filtered User Name - " + i + " for filter " + filter)
                 .collect(Collectors.toList());
     }
 }

當客戶端（帶上Accept-Encoding: gzip）請求 /api/users 或 /api/users/filter 時，如果返回的 JSON 大小超過了 min-response-size，Spring Boot 就會自動返回 Content-Encoding: gzip 的壓縮響應。

4. 如何驗證？

使用瀏覽器的開發(fā)者工具 (F12) -> 網絡 (Network) 面板：

刷新頁面或觸發(fā) API 請求。
找到你的 API 請求記錄。
點擊該請求，查看 “標頭” (Headers) -> “響應標頭” (Response Headers)。
- 如果看到 Content-Encoding: gzip (或 br, deflate)，則表示壓縮成功。
在請求列表的大小 (Size) 列，Chrome 等瀏覽器會顯示兩個值：
- 上面的小數(shù)字：網絡傳輸?shù)?strong>壓縮后大小。
- 下面的大數(shù)字：解壓后的原始大小。
- 兩者有顯著差異就說明壓縮生效了。

或者使用 curl 命令：

# -v 顯示詳細信息（包含頭）
# --compressed 告訴 curl 自動請求并解壓 (它會自動加上 Accept-Encoding: gzip, deflate 并根據(jù) Content-Encoding 解壓)
# -o /dev/null 不輸出內容到屏幕
curl -v --compressed http://localhost:8080/api/users -o /dev/null

在 curl 的輸出中查找 Response Headers 是否包含 Content-Encoding: gzip。

5. 注意事項

反向代理 (Reverse Proxy): 在生產環(huán)境中，Spring Boot 應用前端經常會有 Nginx, Apache 或負載均衡器。這些反向代理通常也具備非常高效的壓縮能力。最佳實踐通常是在反向代理層（如 Nginx）統(tǒng)一處理壓縮，而在 Spring Boot 中關閉壓縮 (server.compression.enabled=false)，以避免重復壓縮和減輕應用服務器的 CPU 負擔。
CPU 開銷: 壓縮會消耗服務器 CPU 資源。
不要壓縮已壓縮內容: 確保 mime-types 里不包含圖片 (jpg, png, gif)、視頻、zip 包等，它們本身就是壓縮格式，再次壓縮基本無效甚至可能增大體積，且浪費 CPU。
Streaming 響應: 對于流式響應（例如 StreamingResponseBody 或 WebFlux 的 Flux），壓縮機制依然有效，但實現(xiàn)方式略有不同（邊生成邊壓縮邊發(fā)送）。

總的來說，Spring Boot 提供了開箱即用的響應體壓縮功能，通過簡單的 server.compression.* 屬性即可配置，無需修改業(yè)務代碼。

以上就是SpringBoot項目中HTTP請求對響應體進行壓縮的方法的詳細內容，更多關于SpringBoot HTTP響應體壓縮的資料請關注腳本之家其它相關文章！

您可能感興趣的文章: