什么是TCP长连接和短连接？别被名字骗了

刚入行时我也以为‘长’就是‘慢’，‘短’就是‘快’——结果上线后发现，一个HTTP接口每秒建立300次TCP连接，服务器SYN队列直接打满。后来才明白：TCP连接本身没有‘长短’之分，只有‘复用’与‘重建’之别。

简单说：

• 短连接：一次请求-响应就主动关闭TCP连接（FIN挥手），下次再用得重新三次握手；
• 长连接：客户端和服务端约定不立即关闭，连接空闲时保持打开，后续请求可复用同一连接。

注意，这不是TCP协议层的特性，而是应用层（比如HTTP、自定义协议）对连接生命周期的策略选择。

关键区别：不只是‘省不省握手’这么简单

很多人只盯着三次握手+四次挥手的开销（约1.5 RTT），但真正压垮系统的，往往是隐藏成本：

• 内核资源消耗：每个TCP连接占用socket、文件描述符、内核缓冲区。Linux默认单机65535个端口，短连接高频场景下极易触发TIME_WAIT堆积（尤其在NAT网关后）；
• TLS握手开销：HTTPS短连接每次都要完整TLS 1.3握手（或1.2的2-RTT），而长连接可复用会话票据（session ticket），实测QPS提升40%+；
• 连接抖动风险：移动网络下，频繁建连失败率远高于保活连接——我曾在线上看到某App在地铁进隧道瞬间，短连接错误率飙升至37%，而长连接仅掉线重连1次。

HTTP/1.1的‘默认长连接’？真相有点反直觉

HTTP/1.1确实规定Connection: keep-alive为默认行为，但服务端有权随时关闭。我们抓包发现：Nginx默认keepalive_timeout 75s，而某些CDN节点甚至设为10s。更现实的是——客户端不发请求，连接就只是‘挂着’，毫无价值。

反观HTTP/2/3，天然多路复用，一个TCP连接跑多个stream，这才是真正的‘长连接红利’。所以现在新项目，我基本不纠结HTTP/1.1的keep-alive，而是直接推HTTP/2 + TLS 1.3。

WebSocket不是长连接，而是‘长连接上的专用通道’

常有人问：WebSocket和TCP长连接啥关系？我的理解是：

WebSocket是运行在TCP长连接之上的应用层协议，它解决了HTTP长连接无法服务端主动推送的硬伤。

举个例子：你用微信发消息，服务端必须实时推送到对方手机——如果用HTTP短连接轮询，延迟高、电量爆炸；用HTTP长连接，又卡在‘只能客户端先发起请求’；而WebSocket一建立，双向通道就通了，心跳保活+消息帧传输，这才是IM的底层命脉。

高并发IM系统怎么选？看数据，不看感觉

去年帮一家教育公司重构IM服务，他们原用HTTP短连接轮询（30s间隔），峰值QPS 8000，服务器CPU常年90%+。我们做了对比测试：

方案	平均延迟	单机承载用户	故障恢复时间
HTTP短连接轮询	1.2s	≈3000	依赖客户端重试（5~30s）
TCP长连接（自研协议）	86ms	≈22000	心跳检测+自动重连（<500ms）

结论很清晰：只要客户端能稳定维持连接（iOS/Android后台保活OK），长连接是IM的唯一合理选择。不过要注意——长连接不是银弹，得配套做连接池管理、心跳探测、灰度降级（比如弱网时切回HTTP备用通道）。

性能对比怎么做？别只看吞吐量

我建议三步走：

1. 压测工具选型：用go-wrk或hey测短连接；用wstest或自研客户端测长连接（重点看连接复用率）；
2. 观测维度：除了QPS/延迟，务必监控netstat -an | grep :PORT | wc -l（连接数）、ss -i（TCP重传率）、服务端GC Pause（长连接内存泄漏高发区）；
3. 真实链路验证：在灰度环境用tcpdump抓包，确认是否真复用了连接（看源端口是否变化）。

工具链里的‘小透明’：短链接工具其实也和连接策略有关

说到这儿，你可能好奇：像趣码短链、趣码抖音卡片这类工具，和TCP连接有啥关系？其实它们更多出现在‘连接发起侧’——比如用户点击一条趣码微信卡片，前端JS发起首次HTTP请求跳转，这个环节的连接策略（短 vs 长）会影响首屏加载速度。我们做过AB测试：在卡片落地页启用HTTP/2长连接后，3G网络下首屏时间从2.1s降到1.3s。这类工具本身不处理连接复用，但作为流量入口，它的跳转链路设计值得纳入整体连接治理。

最后一点实在建议

别迷信‘长连接一定好’。我见过团队盲目上长连接，结果因心跳机制缺陷，导致百万连接假在线，把Redis撑爆。我的经验是：

• Web端优先用WebSocket（兼容性够了）；
• App端用自研TCP长连接，但必须实现分级心跳（活跃用户30s，离线用户5分钟）；
• 对外API、管理后台这类低频场景，HTTP/1.1短连接反而更轻量、更易调试；
• 所有连接策略，都要配监控告警——比如TIME_WAIT > 30000立刻通知，而不是等用户投诉。

技术没有标准答案，只有具体场景下的最优解。下次设计架构前，不妨先问一句：这个连接，到底是为了更快，还是为了更稳，抑或只是更省事？