大量同步请求下TCP连接持续开启（含TIME_WAIT状态）的原因咨询

这其实是TCP协议本身的设计机制导致的，咱们一步步拆解来看：

1. 这些连接其实处于TIME_WAIT状态 #

你用netstat看到的TIME_WAIT是TCP连接生命周期里的一个正常阶段。当客户端（这里是curl）主动关闭连接后，会进入这个状态，核心目的有两个：

• 确保对方（Python服务器）确实收到了最后一个ACK报文，避免因为网络丢包导致连接异常残留
• 防止旧的TCP报文段在网络中延迟到达，干扰新建立的同名连接（源IP、源端口、目标IP、目标端口完全相同的连接）

2. 为什么会积累大量这类连接？ #

你在循环里执行了1000次curl，每次执行都是一个独立的curl进程——每个进程都会和服务器建立全新的TCP连接，请求完成后curl主动关闭连接，这个连接就会进入TIME_WAIT状态。短时间内发起上千次独立请求，自然就会有大量连接排队等待度过TIME_WAIT周期。

补充一句：Python的http.server默认是单线程处理请求（Python 3.7+可通过--threads参数开启多线程），但这只会影响请求处理的速度，不会改变连接关闭后的TIME_WAIT行为。

3. 为什么TIME_WAIT会持续2分钟？ #

这个时长是TCP标准定义的，等于2倍的MSL（最长报文段寿命）。MSL是一个报文在网络中能存活的最长时间，通常被设为60秒，所以2*MSL就是120秒（2分钟）。Windows系统的默认TIME_WAIT时长就是120秒，这是协议层面的规范，不是程序能随意绕过的（当然可以通过系统注册表修改，但不建议随便调整，可能引发其他网络问题）。

4. 为什么修改TTL没用？ #

你提到修改TTL没改变时长，这很正常——因为TTL（Time To Live）是IP层的参数，用来限制报文在网络中转发的跳数；而TIME_WAIT是TCP层的状态，两者属于完全不同的协议层级，没有任何关联。修改TTL根本不会影响TCP连接的TIME_WAIT时长。

如果想减少这类连接的积累，可以试试这些思路：

• 让curl复用连接：比如用curl --keepalive-time 60，或者把多个请求放到同一个curl会话里（比如用脚本批量处理，而非循环启动独立进程）
• 谨慎调整系统的TIME_WAIT相关参数（比如Windows里修改TcpTimedWaitDelay注册表项），操作前一定要明确修改的后果

内容的提问来源于stack exchange，提问作者user3704544