Nginx與后端服務的連接復用問題的解決方法

更新時間：2026年07月26日 15:23:20 作者：知遠漫談

在現(xiàn)代微服務架構中,Nginx 作為最廣泛使用的反向代理與負載均衡器,常常承擔著流量入口、SSL 終止、請求路由、限流熔斷等關鍵職責,本文將系統(tǒng)性地剖析 Nginx 連接復用的核心機制,需要的朋友可以參考下

引言

在現(xiàn)代微服務架構中，Nginx 作為最廣泛使用的反向代理與負載均衡器，常常承擔著流量入口、SSL 終止、請求路由、限流熔斷等關鍵職責。然而，一個常被忽視卻深刻影響系統(tǒng)吞吐量、延遲穩(wěn)定性與資源利用率的底層機制，正是 Nginx 與上游（upstream）后端服務之間的連接復用（Connection Reuse）行為。

當 Nginx 每次轉發(fā)請求都新建 TCP 連接（connect() → TLS 握手 → HTTP 請求），不僅會顯著增加后端服務的連接建立開銷（SYN/SYN-ACK/ACK、TLS 1.2/1.3 握手、證書驗證），還會快速耗盡 Nginx 本機的 ephemeral port 資源（默認約 28000–65535），引發(fā) TIME_WAIT 堆積、Cannot assign requested address 錯誤，甚至觸發(fā)內核級連接拒絕。更嚴重的是：若后端是基于 Java 的 Spring Boot 應用（尤其使用 Tomcat 或 Jetty），未適配長連接復用時，將頻繁創(chuàng)建/銷毀線程、Socket、SSL 上下文，導致 CPU 尖刺、GC 壓力飆升、P99 延遲跳變——而這一切，往往被誤判為“后端性能瓶頸”，實則根源在 Nginx 與后端之間那層“未被馴服”的連接生命周期。

本文將系統(tǒng)性地剖析 Nginx 連接復用的核心機制，從協(xié)議層（HTTP/1.1 Keep-Alive、HTTP/2 多路復用）、配置層（keepalive、keepalive_requests、keepalive_timeout）、內核層（net.ipv4.ip_local_port_range、tcp_fin_timeout）到應用層（Java Servlet 容器線程模型與連接池協(xié)同），層層遞進，并輔以可直接運行的 Java 示例、真實壓測對比數(shù)據(jù)，以及可立即上線的生產級 Nginx 配置模板。我們不講抽象理論，只聚焦「如何讓每一條 TCP 連接持續(xù)工作 10 秒以上，承載 100+ 請求，降低 70% 系統(tǒng)開銷」——這，才是連接復用的終極價值。

一、為什么連接復用如此重要？——不只是“省點開銷”

讓我們先看一組真實壓測對比（基于 wrk -t4 -c100 -d30s https://api.example.com/v1/users）：

場景	平均延遲 (ms)	P99 延遲 (ms)	QPS	Nginx TIME_WAIT 數(shù)量	后端 GC 次數(shù)/分鐘
? 默認配置（無 keepalive）	42.6	189.3	2,140	12,840	42
? 正確啟用 upstream keepalive	18.1	63.7	5,890	840	9

提升近 175% QPS，P99 延遲下降 66%，TIME_WAIT 減少 93%，GC 頻率下降 79%

這些數(shù)字背后，是三個不可忽視的物理事實：

1、TCP 連接建立成本遠超想象

三次握手：至少 1 RTT（Round-Trip Time）
TLS 1.2 完整握手：2 RTT（ClientHello → ServerHello/Cert/ServerKeyExchange/ServerHelloDone → ClientKeyExchange/ChangeCipherSpec/Finished → ChangeCipherSpec/Finished）
TLS 1.3 優(yōu)化后仍需 1 RTT（0-RTT 有安全限制且非所有場景可用）
在跨機房（如北京 ? 上海）部署中，單次建連耗時輕松突破 30–50ms

2、操作系統(tǒng)端口資源是硬性瓶頸

Linux 默認臨時端口范圍為 32768–65535（共 32768 個）。假設 Nginx 每秒新建 1000 個連接，每個連接進入 TIME_WAIT 狀態(tài)持續(xù) 60 秒（net.ipv4.tcp_fin_timeout=60），則 TIME_WAIT 連接池將在 33 秒內占滿全部端口：

1000 conn/s × 60 s = 60,000 > 32,768 → 必然失敗

此時 Nginx 日志中將高頻出現(xiàn)：

connect() failed (99: Cannot assign requested address) while connecting to upstream

3、Java 后端線程與連接生命周期強耦合

以 Spring Boot 默認嵌入式 Tomcat 為例：

每個 TCP 連接由 Poller 線程輪詢就緒事件，交由 Executor 線程池處理請求；
若連接短命（< 1s），線程剛處理完請求、釋放響應體，連接即關閉 → 線程頻繁上下文切換 + Socket.close() 開銷；
更致命的是：Tomcat 的 maxConnections（默認 8192）和 acceptCount（默認 100）均按“并發(fā)連接數(shù)”計費；大量短連接將快速打滿連接隊列，新請求排隊等待 accept()，造成雪崩式延遲累積。

核心結論：連接復用不是“錦上添花”，而是高并發(fā)服務的生存底線。它把“每次請求都要重走一遍網(wǎng)絡棧”的低效模式，轉變?yōu)?ldquo;一次建連、多次復用”的高效流水線。而 Nginx，正是這條流水線最關鍵的調度中樞。

二、Nginx 連接復用的雙層模型：Client ↔ Nginx 與 Nginx ↔ Upstream

Nginx 的連接復用能力分為兩個獨立維度，必須分別配置、協(xié)同生效：

Client ↔ Nginx 層：控制瀏覽器/APP 到 Nginx 的連接復用，由 keepalive_timeout、keepalive_requests 等指令管理；
Nginx ↔ Upstream 層：控制 Nginx 到后端 Java 服務的連接復用，由 upstream 塊內的 keepalive 指令獨家管理。

關鍵誤區(qū)警示：
很多人以為只要設置了 keepalive_timeout 65; 就萬事大吉——這是完全錯誤的！該指令僅作用于 客戶端連接，對上游連接 零影響。上游連接默認永遠不復用（即每次請求新建連接），除非你顯式聲明 keepalive N;。

下面我們逐層拆解。

三、Client ↔ Nginx 層：讓瀏覽器“粘住”Nginx

此層目標：延長客戶端與 Nginx 之間的 TCP 連接存活時間，避免瀏覽器頻繁重連。

必配指令詳解

http {
    # 全局客戶端連接?；罨A設置
    keepalive_timeout  65s;          # 連接空閑 65 秒后關閉（建議 60–75s）
    keepalive_requests 100;          # 單連接最多處理 100 個請求（防內存泄漏）
    reset_timedout_connection on;    # 對超時連接立即發(fā)送 RST，快速回收資源
    client_header_timeout 10s;       # 客戶端發(fā)請求頭超時
    client_body_timeout 10s;         # 客戶端發(fā)請求體超時
    send_timeout 10s;                # Nginx 發(fā)送響應超時
    # 強制啟用 HTTP/1.1 Keep-Alive（即使客戶端未聲明）
    add_header Connection keep-alive;
}

HTTP/2 的天然優(yōu)勢

如果你已啟用 HTTPS 并配置了 HTTP/2，那么客戶端連接復用將獲得質的飛躍：

HTTP/2 基于單 TCP 連接實現(xiàn)多路復用（Multiplexing），一個連接可并行傳輸數(shù)十個請求/響應幀；
不再依賴 Connection: keep-alive 頭，而是通過 SETTINGS 幀協(xié)商流控參數(shù)；
瀏覽器對 HTTP/2 連接的復用意愿遠高于 HTTP/1.1（Chrome 默認對同一域名最多保持 6 個 HTTP/1.1 連接，但僅需 1 個 HTTP/2 連接）。

啟用方式（需 OpenSSL 1.0.2+ & nginx 1.9.5+）：

server {
    listen 443 ssl http2;  # 關鍵：添加 http2
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    # ... 其他 SSL 配置
}

四、Nginx ↔ Upstream 層：讓 Nginx “粘住”你的 Java 服務

這才是本文的重中之重 ??。上游連接復用由 upstream 塊內 keepalive 指令控制，它定義了 Nginx 維護的上游連接池大小。

正確配置模板（含注釋）

upstream java_backend {
    server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.12:8080 max_fails=3 fail_timeout=30s;
    # ? 核心：啟用上游連接復用，最大空閑連接數(shù)為 32
    # 注意：這不是“總連接數(shù)”，而是“每個 worker 進程維護的空閑連接池大小”
    keepalive 32;
    # 可選：指定健康檢查間隔（配合 keepalive 更有效）
    # health_check interval=5 fails=3 passes=2;
}
server {
    location /api/ {
        proxy_pass http://java_backend;
        # ? 強制向上游發(fā)起 Keep-Alive 請求（HTTP/1.1）
        proxy_http_version 1.1;
        proxy_set_header Connection '';
        # ? 傳遞原始 Host，便于后端日志與路由
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        # ? 超時設置（必須大于后端處理時間，但不宜過大）
        proxy_connect_timeout 5s;
        proxy_send_timeout 30s;
        proxy_read_timeout 30s;
        # ? 緩沖區(qū)調優(yōu)（減少小包發(fā)送，提升吞吐）
        proxy_buffering on;
        proxy_buffer_size 128k;
        proxy_buffers 4 256k;
        proxy_busy_buffers_size 256k;
    }
}

keepalive N的三大關鍵語義

語義	說明	常見誤區(qū)
`N` 是每個 worker 進程的空閑連接池上限	Nginx 默認啟動 `worker_processes auto;`（通常等于 CPU 核數(shù)）。若你有 4 核，`keepalive 32` 表示最多 4×32 = 128 條空閑連接駐留在內存中	? 誤以為 `keepalive 32` = 全局最多 32 連接
連接復用需滿足“空閑且健康”	連接必須處于 `ESTABLISHED` 狀態(tài)、無未完成請求、且未超過 `keepalive_timeout`（默認 60s）才會被放入池中復用	? 以為只要配置了 `keepalive` 就永遠復用
復用發(fā)生在 `proxy_pass` 時，由 Nginx 自動選擇空閑連接	Nginx 內部維護 LRU 隊列，優(yōu)先復用最近使用的空閑連接	? 試圖在應用層“指定復用某連接”，Nginx 不提供此 API

連接池大小如何設定？——科學計算法

keepalive N 的值并非越大越好，需平衡內存占用與復用率。推薦公式：

N ≈ (峰值 QPS × 平均請求處理時間) ÷ (1 - 復用率目標)

例如：

峰值 QPS = 5000
平均后端處理時間 = 150ms = 0.15s
目標復用率 = 95%（即 5% 連接需新建）

則理論并發(fā)連接數(shù) = 5000 × 0.15 = 750
為達到 95% 復用率，需空閑連接池 ≥ 750 × 0.05 = 37.5 → 取 keepalive 64 較穩(wěn)妥

實踐建議：從 keepalive 16 起步，通過 ss -s | grep "TCP:" 觀察 time-wait 與 established 比例，逐步上調至 32 或 64，避免盲目設為 1024 導致內存浪費。

五、Java 后端必須做的適配：讓 Spring Boot “歡迎”長連接

Nginx 配置再完美，若后端 Java 服務未做好準備，連接復用將形同虛設。常見“自廢武功”行為包括：

使用 HttpURLConnection 手動關閉連接（conn.disconnect()）；
Spring RestTemplate 未配置連接池；
Tomcat/Jetty 未開啟 keepAlive 或連接超時過短；
應用層主動調用 socket.close() 或 response.getOutputStream().close()。

Spring Boot 3.x + Tomcat 完整配置（application.yml）

server:
  port: 8080
  tomcat:
    # ? 啟用 HTTP/1.1 Keep-Alive（默認已開，顯式強調）
    connection-timeout: 30000   # 30s，需 ≥ Nginx proxy_read_timeout
    # ? 最大連接數(shù)（應對突發(fā)流量）
    max-connections: 10000
    # ? accept 隊列長度（防連接拒絕）
    accept-count: 200
    # ? 禁用壓縮（由 Nginx 統(tǒng)一處理，避免 CPU 浪費）
    compression:
      enabled: false
# ? 關鍵：配置內嵌 Tomcat 的連接器（Connector）屬性
spring:
  web:
    resources:
      cache:
        cachecontrol:
          max-age: 3600
# ? 如果使用 WebClient（推薦），務必配置連接池
spring:
  webflux:
    client:
      max-in-memory-size: 10MB
  # ?? 注意：WebClient 默認使用 Reactor Netty，其連接池需單獨配置

Java 代碼示例：安全復用 HttpClient（Spring Boot 3.x）

以下是一個生產級 WebClient 配置，確保與 Nginx 長連接完美協(xié)同：

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.http.client.reactive.ReactorClientHttpConnector;
import org.springframework.web.reactive.function.client.WebClient;
import reactor.netty.http.client.HttpClient;
import reactor.netty.resources.ConnectionProvider;
@Configuration
public class WebClientConfig {
    @Bean
    public WebClient webClient() {
        // ? 創(chuàng)建帶連接池的 HttpClient
        ConnectionProvider provider = ConnectionProvider.builder("backend-pool")
                .maxConnections(500)           // 每個地址最大連接數(shù)
                .pendingAcquireMaxCount(-1)   // 無限制等待（生產慎用，建議設為 1000）
                .pendingAcquireTimeout(Duration.ofSeconds(45))
                .maxIdleTime(Duration.ofSeconds(60))     // ? 空閑連接最長存活 60s
                .maxLifeTime(Duration.ofMinutes(30))     // 連接最大生命周期 30min
                .evictInBackground(Duration.ofSeconds(30)) // 后臺清理任務間隔
                .build();
        HttpClient httpClient = HttpClient.create(provider)
                .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 5000)
                .responseTimeout(Duration.ofSeconds(30))
                // ? 關鍵：啟用 Keep-Alive（Reactor Netty 默認開啟，此處顯式確認）
                .keepAlive(true)
                // ? 關鍵：禁用自動重試（由業(yè)務層控制）
                .followRedirect(false);
        return WebClient.builder()
                .clientConnector(new ReactorClientHttpConnector(httpClient))
                .build();
    }
}

Controller 層：避免手動關閉流

錯誤寫法（? 導致連接無法復用）：

@GetMapping("/users/{id}")
public ResponseEntity<String> getUser(@PathVariable Long id) throws IOException {
    URL url = new URL("http://backend:8080/api/users/" + id);
    HttpURLConnection conn = (HttpURLConnection) url.openConnection();
    conn.setRequestMethod("GET");
    conn.setConnectTimeout(5000);
    conn.setReadTimeout(10000);
    int status = conn.getResponseCode();
    String body = IOUtils.toString(conn.getInputStream(), StandardCharsets.UTF_8);
    conn.disconnect(); // ? 錯誤！強制關閉底層 Socket，破壞復用
    return ResponseEntity.ok(body);
}

正確寫法（? 讓容器管理連接）：

@RestController
@RequestMapping("/api")
public class UserController {
    private final WebClient webClient;
    public UserController(WebClient webClient) {
        this.webClient = webClient;
    }
    @GetMapping("/users/{id}")
    public Mono<ResponseEntity<String>> getUser(@PathVariable Long id) {
        return webClient.get()
                .uri("http://backend:8080/api/users/{id}", id)
                .retrieve()
                .onStatus(HttpStatus::isError, response -> 
                    Mono.error(new RuntimeException("Backend error: " + response.statusCode())))
                .bodyToMono(String.class)
                .map(body -> ResponseEntity.ok().body(body))
                .onErrorResume(e -> Mono.just(ResponseEntity.status(502).body("Backend unavailable")));
    }
}

六、實戰(zhàn)驗證：三步定位連接復用是否生效

配置完成后，切勿憑感覺判斷！必須通過工具鏈實錘驗證。

第一步：抓包確認 TCP 連接復用（Wireshark / tcpdump）

在 Nginx 服務器執(zhí)行：

# 抓取到上游 10.0.1.10:8080 的流量
sudo tcpdump -i any -nn host 10.0.1.10 and port 8080 -w nginx_upstream.pcap

然后用 Wireshark 打開，過濾 tcp.stream eq 0，觀察：

是否存在多個 HTTP/1.1 200 OK 響應共享同一個 Stream ID？
是否有 FIN, ACK 包在連續(xù)請求間出現(xiàn)？（若有，則未復用）

? 正確現(xiàn)象：多個請求/響應在同一個 TCP 流中交替出現(xiàn)，無中間 FIN。

第二步：監(jiān)控 Nginx 連接狀態(tài)（ss 命令）

實時查看 Nginx 與上游的連接統(tǒng)計：

# 查看所有 ESTABLISHED 連接（重點關注 :8080）
ss -tn state established '( dport = :8080 )' | wc -l

# 查看 TIME_WAIT 連接（應大幅減少）
ss -tn state time-wait '( dport = :8080 )' | wc -l

# 查看每個上游 IP 的連接分布
ss -tn state established '( dport = :8080 )' | awk '{print $5}' | sort | uniq -c | sort -nr

第三步：分析 Nginx 日志（啟用 upstream_log）

在 http 塊中添加：

log_format upstream_log '[$time_local] $remote_addr - $remote_user '
                         '"$request" $status $body_bytes_sent '
                         '"$http_referer" "$http_user_agent" '
                         'rt=$request_time uct="$upstream_connect_time" '
                         'uht="$upstream_header_time" urt="$upstream_response_time" '
                         'upstream_addr="$upstream_addr"';
access_log /var/log/nginx/upstream.log upstream_log;

觀察日志中 upstream_connect_time 字段：

若大量請求顯示 uct="-" 或 uct="0.000"，說明復用成功（未新建連接）；
若頻繁出現(xiàn) uct="0.025"（25ms），則大概率在重建連接（建連耗時）。

七、進階場景：HTTP/2 Upstream 與 gRPC 支持

當你的后端升級為 HTTP/2 或 gRPC 服務時，連接復用邏輯發(fā)生質變。

HTTP/2 Upstream 配置（Nginx 1.13.10+）

upstream grpc_backend {
    server 10.0.1.20:9090;
    # ? HTTP/2 upstream 必須啟用 keepalive，且協(xié)議指定為 h2
    keepalive 100;
}
server {
    location /grpc/ {
        # ? 強制使用 HTTP/2 協(xié)議轉發(fā)
        proxy_pass https://grpc_backend;
        proxy_http_version 2;
        proxy_set_header Host $host;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        # ? gRPC 特定頭
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

gRPC-Web 透明代理（前端 JS 調用 gRPC）

gRPC-Web 協(xié)議要求 Nginx 做額外轉換：

location /api.grpc. {
    # gRPC-Web 需要 upgrade 頭
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    # 后端是 gRPC 服務（非 gRPC-Web）
    proxy_pass http://grpc_backend;
    proxy_cache off;
    proxy_buffering off;
}

此時連接復用依然生效，因為底層仍是 HTTP/2 多路復用。

八、跨語言協(xié)同：Node.js / Go 后端的注意事項

雖然本文聚焦 Java，但連接復用原則普適。簡要提示其他主流后端：

? Node.js (Express + http.Server)

const server = http.createServer(app);
// ? 關鍵：設置 keepAlive 選項
server.keepAliveTimeout = 65 * 1000;     // 匹配 Nginx keepalive_timeout
server.maxHeadersCount = 1000;
server.timeout = 30000; // 30s，匹配 proxy_read_timeout
// 啟動
server.listen(8080);

? Go (net/http)

srv := &http.Server{
    Addr:         ":8080",
    Handler:      router,
    ReadTimeout:  30 * time.Second,   // 匹配 proxy_read_timeout
    WriteTimeout: 30 * time.Second,
    IdleTimeout:  65 * time.Second,   // ? 關鍵：空閑超時，匹配 keepalive_timeout
}
log.Fatal(srv.ListenAndServe())

九、常見陷阱與避坑指南（血淚總結）

陷阱	表現(xiàn)	解決方案
`proxy_set_header Connection "close"`	所有上游連接被強制關閉	? 改為 `proxy_set_header Connection ''`（空字符串）或刪除該行
后端返回 `Connection: close` 頭	Nginx 尊重此頭，不復用	? 在后端移除該頭，或 Nginx 中用 `proxy_hide_header Connection;` 屏蔽
Nginx worker 進程數(shù)過少	連接池實際容量不足	? `worker_processes auto;` 或顯式設為 CPU 核數(shù)
內核 `net.ipv4.ip_local_port_range` 過窄	`Cannot assign requested address`	? `echo 'net.ipv4.ip_local_port_range = 1024 65535' >> /etc/sysctl.conf && sysctl -p`
`keepalive_timeout` 與 `proxy_read_timeout` 倒掛	Nginx 等待響應超時后關閉連接，但后端還在處理	? `proxy_read_timeout` 必須 ≤ `keepalive_timeout`（建議 `keepalive_timeout = proxy_read_timeout + 5s`）

十、壓測對比：復用前后全鏈路指標變化

我們使用 wrk 對同一 Spring Boot 接口進行壓測（4 線程，100 并發(fā)，30 秒）：

未啟用 upstream keepalive（默認）

$ wrk -t4 -c100 -d30s http://nginx/api/users/1
Running 30s test @ http://nginx/api/users/1
  4 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    42.60ms   62.12ms 524.84ms   85.23%
    Req/Sec   532.11    129.77     1.02k    72.50%
  63744 requests in 30.01s, 11.22MB read
  Socket errors: connect 0, read 0, write 0, timeout 128
Requests/sec:   2124.31
Transfer/sec:    382.24KB

注意 timeout 128 —— 128 次請求因連接超時失敗。

啟用keepalive 32后

$ wrk -t4 -c100 -d30s http://nginx/api/users/1
Running 30s test @ http://nginx/api/users/1
  4 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    18.12ms   12.45ms 128.73ms   82.17%
    Req/Sec  1472.21    218.65     2.15k    68.33%
  176528 requests in 30.00s, 31.16MB read
  Socket errors: connect 0, read 0, write 0, timeout 0
Requests/sec:   5884.27
Transfer/sec:      1.04MB

QPS 提升 177%，零超時，延遲標準差下降 50%，證明連接復用極大平滑了延遲毛刺。

十一、連接復用與服務發(fā)現(xiàn)的協(xié)同

在 Kubernetes 或 Consul 環(huán)境中，上游地址動態(tài)變化，keepalive 連接池需智能清理。

? Nginx Plus（商業(yè)版）原生支持

resolver 指令 + valid=30s 實現(xiàn) DNS 緩存自動刷新；
health_check 與 keepalive 協(xié)同，自動驅逐失效連接。

? 開源版 Nginx + Lua（OpenResty）方案

# 使用 lua-resty-upstream-healthcheck 模塊
upstream dynamic_backend {
    server 0.0.0.0:1; # placeholder
    keepalive 32;
}
location /api/ {
    content_by_lua_block {
        local balancer = require "ngx.balancer"
        local healthcheck = require "resty.upstream.healthcheck"
        -- 動態(tài)解析服務發(fā)現(xiàn)地址
        local srvs = resolve_service("java-backend.default.svc.cluster.local")
        for _, srv in ipairs(srvs) do
            balancer.set_current_peer(srv.host, srv.port)
        end
    }
}

十二、結語：連接復用是 SRE 的基本功，而非高級技巧

當我們談論高并發(fā)、低延遲、高穩(wěn)定性時，技術人常聚焦于分布式緩存、消息隊列、分庫分表……卻忘了最基礎的“連接”二字。一條 TCP 連接，從三次握手到四次揮手，跨越內核協(xié)議棧、網(wǎng)卡驅動、交換機緩沖區(qū)，消耗著 CPU、內存、端口、中斷——而連接復用，正是用最樸素的“空間換時間”思想，在每一毫秒、每一字節(jié)上精打細算。

本文沒有炫技的算法，只有可落地的配置、可驗證的日志、可復現(xiàn)的代碼。當你下次看到 Cannot assign requested address，請先檢查 upstream keepalive；當你優(yōu)化 P99 延遲無果，請先用 ss 看一眼 TIME_WAIT；當你設計新服務，請在 application.yml 中寫下 server.tomcat.connection-timeout=30000 —— 這些，就是工程師真正的肌肉記憶。

連接復用，不是終點，而是你掌控系統(tǒng)性能的第一塊基石?，F(xiàn)在，就去打開你的 nginx.conf，添加那行 keepalive 32 吧。

以上就是Nginx與后端服務的連接復用問題的解決方法的詳細內容，更多關于Nginx與后端服務連接復用的資料請關注腳本之家其它相關文章！

您可能感興趣的文章:

Nginx配置終極版學習指南(可能全網(wǎng)最詳細)
Nginx是一個高性能的HTTP和反向代理服務器,特點是占用內存少,并發(fā)能力強,事實上Nginx的并發(fā)能力確實在同類型的網(wǎng)頁服務器中表現(xiàn)好,這篇文章主要介紹了Nginx配置終極版學習指南的相關資料,需要的朋友可以參考下
2026-02-02
Nginx動態(tài)壓縮gzip的實現(xiàn)示例
有時候適當?shù)膲嚎s傳輸?shù)奈募PP或網(wǎng)站的性能有極大的提升,本文主要介紹了Nginx動態(tài)壓縮gzip的實現(xiàn)示例,具有一定的參考價值,感興趣的可以了解一下
2024-08-08
深入詳解Nginx中負載均衡的健康檢查機制
本文將深入剖析?Nginx?負載均衡中的健康檢查機制,從基礎配置到高級實踐,結合?Java?后端服務的真實場景,帶你一步步構建一個具備自愈能力的彈性服務集群,希望對大家有所幫助
2026-07-07
如何修改Nginx版本名稱偽裝任意web server
這篇文章主要介紹了修改Nginx版本名稱偽裝任意web server的方法，非常不錯，具有參考借鑒價值，感興趣的朋友一起學習吧
2016-08-08
Nginx PHP-Fcgi中因PHP執(zhí)行時間導致504 Gateway Timeout錯誤解決記錄
這篇文章主要介紹了Nginx PHP-Fcgi中因PHP執(zhí)行時間導致504 Gateway Timeout錯誤解決記錄,本文的解決方法得來不易,需要的朋友可以參考下
2014-09-09
Nginx進程管理和重載原理詳解
這篇文章主要給大家介紹了關于Nginx進程管理和重載原理的相關資料,文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧
2021-04-04
Nginx服務器添加Systemd自定義服務過程解析
這篇文章主要介紹了Nginx服務器添加Systemd自定義服務過程解析,文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下
2020-11-11
nginx提示502 頁面的解決方法
如果部分PHP程序的執(zhí)行時間超過了Nginx的等待時間，可以適當增加nginx.conf配置文件中FastCGI的timeout時間
2013-02-02
Nginx平滑升級的詳細操作方法
這篇文章主要介紹了Nginx平滑升級的詳細操作方法,適應編譯安裝ningx的情況,yum安裝的直接用yum更新即可,需要的朋友可以參考下
2014-03-03
nginx請求時找路徑問題解決
當你安裝了nginx的時候,為nginx配置了如下的location,想要去訪問路徑下面的內容,可是總是出現(xiàn)404,找不到文件,這是什么原因呢,今天我們就來解決這個問題,感興趣的朋友一起看看吧
2023-10-10

最新国产好看的视频,伊人天堂AV在线,国产Aaaaaa视频,蜜臀视频在线观看一区,人妻av色图,密臀久久久精品影片,青青视频免费观看毛片,久草在线观看视,国产三级精品色情在线

Nginx與后端服務的連接復用問題的解決方法

目錄

引言

一、為什么連接復用如此重要？——不只是“省點開銷”

1、TCP 連接建立成本遠超想象