长连接复用：握手与慢启动的成本摊薄手册

先把成本账算清

一次全新的 HTTPS 请求 vs 复用连接，差距全在首字节之前：

短连接（每次请求新建）：
  TCP 握手 1 RTT + TLS1.3 1 RTT + 请求 1 RTT ≈ 3 RTT 起步
  外加：慢启动从 10 MSS 重新爬、服务端 accept 压力、TIME_WAIT 堆积

复用连接（keepalive）：
  0 RTT 建连开销，cwnd 已在高位，直接全速传输

// RTT 50ms、QPS 1000 的场景：
// 短连接每天白烧 50ms × 8640 万次握手 —— 50 天的纯等待
// 这就是为什么所有高性能组件都是长连接

keepalive 必须全链路打通

很多人开了浏览器到 Nginx 的 keepalive 就以为完事了——Nginx 到后端应用默认每请求新开一条连接，最贵的一段（应用 accept、FD）根本没省到：

upstream app_server {
    server 10.0.0.1:8080;
    keepalive 64;              ← upstream 连接池：每 worker 缓存 64 条空闲连接
}
server {
    location / {
        proxy_http_version 1.1;                    ← 必须 1.1 才有 keepalive
        proxy_set_header Connection "";            ← 清掉 close，允许复用
        proxy_pass http://app_server;
    }
}
# 三处缺一不可：keepalive 池、http_version 1.1、清 Connection 头
# 效果：Nginx→应用 的 TIME_WAIT 直接消失，应用 QPS 上限抬升

同理还有数据库连接池（HikariCP、Druid）、RPC 长连接（Dubbo、gRPC）、Redis 客户端池——凡是“每次调用新建连接”的写法，在高 QPS 下都会先撞 FD 上限，再撞端口耗尽。

连接池参数：三个数定生死

最后一行是经典事故来源：池里一条连接空闲太久，被中间的 LB 或数据库悄悄关了，业务拿来就用，偶发 connection reset。解法是让 idleTimeout 比链路上最短的空闲超时更短，或开借出前探活。

TCP keepalive ≠ HTTP keepalive

两个名字一样的东西完全是两回事：HTTP keepalive 是应用层约定“连接用完别关”；TCP keepalive 是内核的保活探针——连接空闲超过 tcp_keepalive_time（默认 7200 秒）才发探测包，判断对端死没死。真正负责空闲连接回收的是应用层的 idle timeout（Nginx keepalive_timeout、连接池 idleTimeout、网关的 60 秒）。IM、推送这类长连接还要靠应用层心跳（mqtt ping、websocket ping/pong），别指望 TCP 探针救你。下一篇进入实战段：tcpdump——线上网络问题，抓包见真章。