ASPX页面中如何通过代码缩短Socket的TIME_WAIT/CLOSE_WAIT时长？

首先咱们先拆解你的问题：ASPX页面中Socket首次绑定正常，二次访问报错端口被占用，同时怀疑清理步骤有遗漏，还想知道能不能通过代码缩短TIME_WAIT/CLOSE_WAIT时长。下面分两部分给你梳理：

一、Socket清理步骤的遗漏点 #

你的清理代码看起来覆盖了基础操作，但有几个细节没处理到位，可能导致资源残留：

• 阻塞Accept的致命问题：你在ASPX页面里用了s1.Accept()——这是阻塞调用！ASPX是请求响应模型，线程会一直挂在这个方法上直到有连接进来，不仅会占满线程池资源，还会导致后续的清理代码根本没机会执行，这大概率是你出现CLOSE_WAIT的核心原因！
• 冗余操作与顺序问题：监听Sockets1本身没有活跃连接时，调用Disconnect(true)是多余的；另外Close()方法内部已经会调用Dispose()，不需要重复执行两者。
• Session引用未清空：清理后没把Session里的Socket引用设为null，可能导致GC无法及时回收资源。

修正后的清理代码可以参考：

Socket s1 = Session["s1"] as Socket;
Socket s2 = Session["s2"] as Socket;

// 先处理客户端连接Socket s2
try
{
    if (s2 != null && s2.Connected)
    {
        s2.Shutdown(SocketShutdown.Both); // 先通知对方关闭连接
        s2.Close();
    }
}
catch (Exception ex)
{
    // 捕获异常，避免影响监听Socket的清理
}
finally
{
    s2?.Dispose();
    Session["s2"] = null; // 清空Session引用
}

// 处理监听Socket s1
try
{
    if (s1 != null)
    {
        s1.Close(); // 强制中断阻塞的Accept操作
    }
}
catch (Exception ex)
{
    // 捕获异常
}
finally
{
    s1?.Dispose();
    Session["s1"] = null; // 清空Session引用
}

二、代码层面处理TIME_WAIT/CLOSE_WAIT #

关于TIME_WAIT #

TIME_WAIT是TCP协议的保护机制，默认时长是2个MSL（通常1-4分钟），代码层面无法直接修改单个Socket的TIME_WAIT时长，但可以通过ReuseAddress选项让新Socket绑定到处于TIME_WAIT状态的端口上，注意必须在Bind之前设置：

IPAddress ipAddress = IPAddress.Parse(ip); 
Socket s1 = new Socket(ipAddress.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
// 启用端口复用，必须在Bind之前设置
s1.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);
IPEndPoint ep = new IPEndPoint(ipAddress, port); 
try { 
    s1.Bind(ep); 
} catch(Exception ex) { 
    HttpContext.Current.Response.Write("[Exception in bind: "+ ex + "\n"); 
    return; 
}

关于CLOSE_WAIT #

CLOSE_WAIT状态表示你的Socket已经收到对方的FIN包，但自己还没主动关闭连接。结合你的场景，主要原因是：

1. 阻塞的Accept()导致清理代码没执行；
2. 客户端连接断开后，你的代码没及时检测到并清理。

解决办法：

• 立刻换掉阻塞的Accept()，改用异步方式（BeginAccept/EndAccept），或者把Socket监听逻辑放到后台服务（比如Windows服务）中，ASPX页面只负责和后台服务通信，不要直接监听端口——Web页面的请求模型和Socket监听完全不兼容！
• 使用Socket时及时检测连接状态，比如：

// 检测连接是否已断开
if (!s2.Connected || s2.Poll(1000, SelectMode.SelectRead) && s2.Available == 0)
{
    // 提前执行清理逻辑
}

总结 #

1. 优先解决阻塞Accept()的问题，这是你资源泄漏的根源；
2. 修正清理代码，确保Socket资源被彻底释放且Session引用清空；
3. 用ReuseAddress绕过TIME_WAIT的端口占用限制；
4. CLOSE_WAIT的核心是确保清理代码被执行，同时及时检测连接状态。

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