背景介紹
隨著 Web 應用并發量不斷攀升,長連接(keep-alive)策略已經成為提升性能和資源復用的重要手段。本文將從原理、默認值、優化實踐以及潛在風險等方面,全面剖析如何在 Node.js(Express)中正確設置和應用 keep-alive 超時時間。
例如我們是BI系統,需要做ETL處理,而ETL處理有些過程相對漫長,這個時候需要進行長連接等待。
一、長連接與 keep-alive 簡述
長連接,即 HTTP keep-alive,是指在一次 TCP 連接建立后,可以復用該連接處理多次 HTTP 請求/響應,從而避免頻繁的三次握手和四次揮手,從網絡層、系統調用層面大幅減少延遲和資源消耗。
關鍵指標:
keepAliveTimeout:空閑長連接在被銷毀之前,允許等待新請求的最長時間。
headersTimeout:在同一連接上,等待客戶端發送完整 HTTP 請求頭的最長時間,超過該時間會強制關閉連接。
二、Node.js 默認超時值
Node.js從 v13.0.0 開始,將底層 HTTP 服務器的默認參數調整為:
參數 | 默認值 | 含義 |
---|---|---|
keepAliveTimeout | 5 s (5000 ms) | 空閑長連接允許的最大等待時間 |
headersTimeout | 60 s (60000 ms) | 等待客戶端完整請求頭的最大時限 |
可以看到,默認僅保留 5 秒的空閑長連接,如果你的應用存在請求間隔較長、或需要保持連接的場景(如物聯網設備推送、長輪詢),就需要手動調整。
三、為什么要調整 keep-alive 超時
減少連接抖動:當客戶端頻繁發起短暫空閑后才真正發起請求時,5 秒可能不足以維持長連接,導致高并發場景下頻繁重建 TCP 連接。
資源復用:適當延長空閑超時,可降低操作系統的 TCP 狀態切換、內核內存分配等開銷。
提升用戶體驗:對于需要長時間保持通道通信的應用(如實時推送、游戲服務器),延長 keep-alive 可減少重連延遲。
四、在 Express 中設置超時時間
Express 底層就是基于Node.js HTTP 模塊,因此你可以通過 app.listen()
返回的 server
實例,直接修改其超時屬性。
javascript
const express = require('express');
const app = express();
const port = process.env.PORT || 3000;/**
* To set the keep-alive timeout to 30 minutes (1800 seconds) in an Express app, you need to access the underlying HTTP server and set its keepAliveTimeout property.
* Express 本身是基于 Node.js 的 HTTP 模塊,默認支持 HTTP 長連接(keep-alive)。要讓連接保持最長 30 分鐘(1800 秒),你需要設置 HTTP 服務器的 keep-alive 超時時間。
*
* In Node.js, the default keepAliveTimeout for the underlying HTTP server is 5 seconds (5000 ms) as of Node.js v13.0.0 and later.
* The default headersTimeout is 60 seconds (60000 ms).
* keepAliveTimeout: How long to keep an idle keep-alive connection open.
* headersTimeout: How long to wait for the complete HTTP headers after a connection is established.
*
* @author Moshow@https://zhengkai.blog.csdn.net/
*/
const server = app.listen(port, () => {logger.info(`My App listening on port ${port}`);
});
// Set keep-alive timeout to 1800 seconds (30 minutes)
server.keepAliveTimeout = 1800 * 1000; // milliseconds
server.headersTimeout = 1810 * 1000; // should be slightly higher than keepAliveTimeout
五、對比:默認值 vs. 自定義值
參數 | 默認值 | 示例自定義值 | 建議策略 |
---|---|---|---|
keepAliveTimeout | 5 000 ms | 1 800 000 ms | 如果應用請求間隔較長,可根據業務場景調整至分鐘級;緩存或推送類服務推薦 15–30 分鐘。 |
headersTimeout | 60 000 ms | 1 810 000 ms | 始終略高于 keepAliveTimeout,以免在等待請求頭時過早斷開連接。 |
六、設置超時時的注意事項
內存與連接數監控 延長 keep-alive 會在高并發下保持更多空閑連接,需結合指標監控(如
netstat
、lsof
、應用 APM監控)。并建立完善的鏈接釋放機制。負載均衡與代理 部署在 Nginx、HAProxy、云廠商 LB 之后,需保證下游和上游的超時配置一致,避免中間層提前斷開。
安全與資源泄露 高超時若遇到惡意客戶端維持空閑連接,可能造成資源耗盡(Slowloris 攻擊)。可借助限流、IP 白名單、防火墻規則進行防護。
更多深度優化建議:
配置?HTTP/2 多路復用,進一步提升連接利用率
使用 Redis 或MQ消息隊列、SSE做業務,而不是單純長連接
在 Kubernetes 環境下,探討 Service 和 Ingress 的超時策略如何協同