连接管理的三种形态，用时间线对比最直观：

• 短连接：建连 → 请求 → 响应 → 断开，再建连 → 请求 → 响应 → 断开。每个请求都要付一次 TCP 三次握手（约 1 个 RTT）和四次挥手的代价，HTTPS 还要加 TLS 握手。HTTP/1.0 默认就是这样，要复用得显式发 Connection: keep-alive。
• 长连接（持久连接）：建连一次，后面的请求排着队用同一条连接，最后空闲超时或主动 Connection: close 再断开。HTTP/1.1 默认就是长连接。
• 多路复用：HTTP/2 把请求拆成带编号的帧，在一条连接上交错发送，谁先好谁先回，应用层不再排队。

长连接的边界有三点：

1. 服务器要控制连接数量和寿命。Nginx 里 keepalive_timeout 控制空闲多久断开（默认 75s），keepalive_requests 控制一条连接最多处理多少个请求（1.19.10 之后默认 1000，之前是 100）。
2. 队头阻塞没解决。HTTP/1.1 管线化（pipelining）理论上允许连发多个请求，但响应必须按顺序回，主流浏览器都没默认启用。所以浏览器对同一个域名最多开 6 条连接，资源多了就排队。
3. HTTP/2 解决了应用层的队头阻塞，但所有请求挤在一条 TCP 连接上，丢一个包整条连接都要等重传。HTTP/3 换成基于 UDP 的 QUIC，每个流独立重传，连 TCP 层的阻塞也绕开了。

在 Node 里可以直观看到连接复用：

const http = require('http')
const agent = new http.Agent({ keepAlive: true }) // 开启连接复用
http.get({ host: 'example.com', agent }, res => {
  res.resume()
  res.on('end', () => {
    // 第二个请求会复用刚才那条 socket，不再握手
    http.get({ host: 'example.com', agent }, r => console.log(r.statusCode))
  })
})

Node 19 起全局默认的 http.globalAgent 已经开启了 keepAlive，老版本要像上面这样手动传 agent。

HTTP 协议最初（0.9/1.0）是个非常简单的协议，通信过程也采用了简单的“请求 - 应答”方式。

它底层的数据传输基于 TCP/IP，每次发送请求前需要先与服务器建立连接，收到响应报文后会立即关闭连接。

因为客户端与服务器的整个连接过程很短暂，不会与服务器保持长时间的连接状态，所以就被称为“短连接”（short-lived connections）。早期的 HTTP 协议也被称为是“无连接”的协议。

短连接的缺点相当严重，因为在 TCP协议里，建立连接和关闭连接都是非常“昂贵”的操作。TCP 建立连接要有“三次握手”，发送 3 个数据包，需要 1 个 RTT；关闭连接是“四次挥手”，4 个数据包需要 2 个 RTT。

而 HTTP 的一次简单“请求 - 响应”通常只需要 4 个包，如果不算服务器内部的处理时间，最多是 2 个 RTT。这么算下来，浪费的时间就是“3÷5=60%”，有三分之二的时间被浪费掉了，传输效率低得惊人

单纯地从理论上讲，TCP 协议你可能还不太好理解，我就拿打卡考勤机来做个形象的比喻吧。

假设你的公司买了一台打卡机，放在前台，因为这台机器比较贵，所以专门做了一个保护罩盖着它，公司要求每次上下班打卡时都要先打开盖子，打卡后再盖上盖子。

可是偏偏这个盖子非常牢固，打开关闭要费很大力气，打卡可能只要 1 秒钟，而开关盖子却需要四五秒钟，大部分时间都浪费在了毫无意义的开关盖子操作上了。

可想而知，平常还好说，一到上下班的点在打卡机前就会排起长队，每个人都要重复“开盖 - 打卡 - 关盖”的三个步骤，你说着急不着急。

在这个比喻里，打卡机就相当于服务器，盖子的开关就是 TCP 的连接与关闭，而每个打卡的人就是 HTTP 请求，很显然，短连接的缺点严重制约了服务器的服务能力，导致它无法处理更多的请求。