服务端 TCP 连接的 TIME_WAIT 过多问题的分析与解决

发布网友 发布时间：12小时前

我来回答

共1个回答

热心网友 时间：12小时前

文章标题：服务端 TCP 连接的 TIME_WAIT 过多问题的分析与解决

解决思路：分析 TIME_WAIT 状态的 TCP 连接过多问题，提供有效方法，帮助读者解决常见问题。

问题描述：高并发场景下，出现批量 TIME_WAIT 状态的 TCP 连接。短时间内这些连接消失，端口恢复正常。这种现象在高并发场景中是正常的。

线上思考：大量 TIME_WAIT 状态连接有何影响？

Nginx 反向代理时，大量短链接可能导致 TIME_WAIT 状态，影响性能。

统计 TCP 连接状态：本地端口数量上限为 65535，因为 TCP 头部使用 16 bit 存储端口号。

问题分析：大量 TIME_WAIT 状态连接的根本原因。

解决办法：客户端与服务器端的调整方法。

1. 客户端：设置 HTTP 请求头部，connection 为 keep-alive，保持连接。

2. 服务器端：允许 socket 被重用，缩短 time_wait 时间至 1 MSL（2 mins）。

核心要点包括影响、现实场景、解决办法。

附录：查询 TCP 连接状态、MSL 时间、TCP 三次握手与四次挥手。

查询 TCP 连接状态：Mac 下使用的具体命令。

MSL 时间：IP 报文最长存在时间，TCP 报文的存活时间，实际应用中常设置为 30 秒、1 分钟或 2 分钟。

2MSL：TCP TIME_WAIT 状态，等待 2 MSL 时间后可重用端口。

TCP 三次握手与四次挥手：建立与释放连接的完整过程。

疑问解答：time_wait 状态与主动断开连接的关系。

答案：在 HTTP1.1 协议中，客户端或服务端根据 Connection 头决定是否保持连接。默认关闭连接，服务端产生 TIME_WAIT 多的情况常见。

正确理解 Connection 头的设置，调整参数减少 TIME_WAIT 状态。

关注公众号 Linux 码农，获取更多技术干货。