长连接 vs 短连接？

本文目录导读：

1. 核心区别对比表
2. 短连接（Short-lived Connection）
3. 长连接（Persistent Connection）
4. 如何选择？场景分析

这是一个非常经典的计算机网络问题。长连接和短连接本质上是描述客户端与服务器之间维持TCP连接（或其他传输层连接）的时长策略。

区别在于一次数据传输完成后，这个连接是保留（长连接）还是断开（短连接）。

核心区别对比表

短连接（Short-lived Connection）

工作流程：

1. 建立连接：客户端发起TCP三次握手。
2. 传输数据：发送请求,接收响应。
3. 关闭连接：传输完毕,立即进行四次挥手断开连接。
4. 下一次请求：重复步骤1~3。

特点：

• 简单可控：服务端处理完一个请求就释放资源，不容易出现连接“挂死”或资源泄漏问题（因为每次都重新创建）。
• 系统开销大：每一次通信都包含连接建立（三次握手）和释放（四次挥手）的耗时和带宽消耗，在高并发场景下,频繁的握手会增加网络延迟和服务端CPU负载。
• 无法推送：服务器无法主动向客户端发送消息,因为连接已经关闭。

典型应用：

• HTTP/1.0：早期的Web服务器通常默认使用短连接。
• 部分RESTful API：对于低频率、无状态的后台接口调用。
• 内部微服务间的简单调用（如果使用HTTP而非gRPC）。

长连接（Persistent Connection）

工作流程：

1. 建立连接：客户端发起TCP三次握手。
2. 传输数据：发送请求,接收响应。
3. 保持连接：双方（通常通过HTTP头Connection: keep-alive或协议自身）约定不关闭连接。
4. 复用连接：继续发送下一个请求，接收下一个响应（可能在同一条TCP连接上串行或并行）。
5. 空闲超时：如果一段时间内（如60秒）没有数据传输,服务端或客户端会主动关闭连接以释放资源。

特点：

• 减少延迟：省去了频繁的握手和挥手过程,请求响应速度更快。
• 节省资源：减少了服务端创建/销毁Socket的次数，降低了CPU和内存消耗（但长期保持的连接仍需占用内存）。
• 适合推送模型：长连接是WebSocket、SSE等服务器推送技术的基础,因为连接一直是打开的。
• 管理复杂：需要心跳机制检测连接是否有效；服务端需要处理连接池（连接数量限制、复用、超时释放）；防止资源泄漏（如果客户端断线但服务端未感知，会形成“僵尸连接”）。

典型应用：

• HTTP/1.1及HTTP/2：默认就是长连接。
• 数据库连接池（如MySQL、Redis）：程序复用同一连接执行多条SQL。
• WebSocket：用于聊天、在线游戏、股票行情推送等。
• Netty、gRPC等高性能通信框架：底层通常使用长连接。

如何选择？场景分析

• 普通网页浏览

  • 假设打开一个网站，有10个资源（HTML、CSS、JS、图片）。
  • 短连接：需要10次三次握手 + 10次四次挥手，耗时约等于 10 * RTT（往返时间）,非常慢。
  • 长连接：仅1次三次握手，后续9个请求都在同一连接上完成，耗时约等于 1 * RTT + 9 * 数据传输时间。
  • 显然用长连接（HTTP keep-alive）。

• 低频率的API调用

  • 比如每30分钟上报一次设备状态。
  • 短连接：每次上报建连、传数据、断开,开销可以接受。
  • 长连接：维持30分钟的无用连接，浪费服务端内存，且需要心跳保活,反而增加复杂度。
  • 用短连接更合理。

• 即时通讯（IM）或实时游戏

  • 需要在毫秒级内接收到对方的消息。
  • 短连接：无法做到服务器主动推送，只能客户端轮询（效率极低）。
  • 长连接（如WebSocket）：连接一直保持,服务端可以随时推送消息。
  • 必须用长连接。

• 数据库访问

  • 应用服务器频繁查询数据库（每秒几百次）。
  • 短连接：每次查询都经历TCP建连、SQL执行、TCP断连，数据库服务器的CPU将大量浪费在握手、释放连接上,QPS会非常低。
  • 长连接（连接池）：创建少量连接，反复复用,通常还会配合数据库连接池进行管理。
  • 必须用长连接。

核心权衡点：

• 资源 vs 效率：长连接用保持连接的内存开销换取高频通信的效率；短连接用高频握手的网络开销换取连接资源的低占用。
• 复杂性：长连接需要处理心跳、重连、连接池超时等复杂逻辑；短连接则非常简单。

标签： 长连接 短连接