因此,启动终止的对等体 - 即首先调用close() - 将最终处于TIME_WAIT状态 . [...]但是,在服务器上处于TIME_WAIT状态的许多套接字可能会出现问题,因为它最终可能会阻止接受新连接 . [...]而是设计您的应用程序协议,以便始终从客户端启动连接终止 . 如果客户端总是知道它何时读取了所有剩余数据,则它可以启动终止序列 . 例如,浏览器在读取所有数据时可以从Content-Length HTTP标头中获知,并且可以启动关闭 . (我知道在HTTP 1.1中它会保持打开一段时间以便重用,然后关闭它 . )
我想使用TcpClient / TcpListener来实现它,但是不清楚如何使它正常工作 .
方法1:双方关闭
这是大多数MSDN示例所示的典型方式 - 双方都调用 Close() ,而不仅仅是客户端:
private static void AcceptLoop()
{
listener.BeginAcceptTcpClient(ar =>
{
var tcpClient = listener.EndAcceptTcpClient(ar);
ThreadPool.QueueUserWorkItem(delegate
{
var stream = tcpClient.GetStream();
ReadSomeData(stream);
WriteSomeData(stream);
tcpClient.Close();
});
AcceptLoop();
}, null);
}
private static void ExecuteClient()
{
using (var client = new TcpClient())
{
client.Connect("localhost", 8012);
using (var stream = client.GetStream())
{
WriteSomeData(stream);
ReadSomeData(stream);
}
}
}
在我用20个客户端运行之后,TCPView显示 both the client and server 中的很多套接字卡在 TIME_WAIT 中,这需要相当长的时间才能消失 .
方法2:只是客户关闭
根据上面的引用,我删除了我的监听器上的 Close() 调用,现在我只依赖客户端关闭:
var tcpClient = listener.EndAcceptTcpClient(ar);
ThreadPool.QueueUserWorkItem(delegate
{
var stream = tcpClient.GetStream();
ReadSomeData(stream);
WriteSomeData(stream);
// tcpClient.Close();
});
AcceptLoop();
现在我不再有任何 TIME_WAIT ,但我确实在 CLOSE_WAIT , FIN_WAIT 等不同阶段留下了插座,这也需要很长时间才能消失 .
方法3:给客户时间先关闭
这次我在关闭服务器连接之前添加了一个延迟:
var tcpClient = listener.EndAcceptTcpClient(ar);
ThreadPool.QueueUserWorkItem(delegate
{
var stream = tcpClient.GetStream();
ReadSomeData(stream);
WriteSomeData(stream);
Thread.Sleep(100); //
tcpClient.Close(); //
});
AcceptLoop();
这似乎更好 - 现在只有客户端套接字在 TIME_WAIT ;服务器套接字已正确关闭:
这似乎与先前链接的文章所说的一致:
因此,启动终止的对等体 - 即首先调用close() - 将最终处于TIME_WAIT状态 .
问题:
这些方法中哪一种是正确的方法,为什么? (假设我希望客户端成为'active close'方)
有没有更好的方法来实施方法3?我们希望关闭由客户端启动(以便客户端留下TIME_WAIT),但是当客户端关闭时,我们还希望关闭服务器上的连接 .
我的场景实际上与Web服务器相反;我有一个客户端连接和断开许多不同的远程机器 . 我宁愿服务器的连接卡在 TIME_WAIT 中,以释放客户端上的资源 . 在这种情况下,我应该让服务器执行主动关闭,并将睡眠/关闭放在我的客户端上吗?
自己试用的完整代码在这里:
Edit :另一个有用的资源:
对于确实 Build 出站连接以及接受入站连接的服务器,黄金法则始终确保如果需要发生TIME_WAIT,则最终在另一个对等体而不是服务器上 . 执行此操作的最佳方法是永远不要从服务器启动主动关闭,无论原因是什么 . 如果您的对等体超时,则使用RST中止连接而不是关闭它 . 如果您的对等方发送无效数据,则中止连接等 . 这个想法是,如果您的服务器永远不会启动活动关闭,它永远不会累积TIME_WAIT套接字,因此永远不会遇到它们导致的可伸缩性问题 . 虽然在发生错误情况时很容易看到如何中止连接,但正常的连接终止呢?理想情况下,您应该在协议中设计一种方法,让服务器告诉客户端它应该断开连接,而不是简单地让服务器发起主动关闭 . 因此,如果服务器需要终止连接,则服务器发送应用程序级别“我们已完成”消息,客户端将此消息作为关闭连接的理由 . 如果客户端无法在合理的时间内关闭连接,则服务器将中止连接 . 在客户端,事情稍微复杂一点,毕竟,有人必须发起一个主动关闭以干净地终止TCP连接,如果它是客户端,那么TIME_WAIT将结束 . 但是,将TIME_WAIT结束在客户端上有几个优点 . 首先,如果出于某种原因,由于TIME_WAIT中套接字的累积,客户端最终会遇到连接问题,那么它只是一个客户端 . 其他客户不会受到影响 . 其次,快速打开和关闭到同一服务器的TCP连接是低效的,因此在TIME_WAIT问题之外尝试维持连接的时间较长而不是较短的时间段是有意义的 . 不要设计客户端每分钟连接到服务器的协议,并通过打开新连接来实现 . 而是使用持久连接设计,只在重新连接时才使用连接失败,如果中间路由器拒绝在没有数据流的情况下保持连接打开,那么你可以实现应用程序级ping,使用TCP keep alive或者只是接受路由器正在重置你的连接;好处是你没有累积TIME_WAIT套接字 . 如果您在连接上所做的工作自然是短暂的,那么请考虑某种形式的“连接池”设计,从而保持连接的开放和重用 . 最后,如果您绝对必须从客户端快速打开和关闭连接到同一服务器,那么您可以设计一个可以使用的应用程序级别关闭序列,然后关闭它 . 您的客户端可以发送“我已完成”消息,然后您的服务器可以发送“再见”消息,然后客户端可以中止连接 .