我们的服务器应用程序正在侦听端口，一段时间后它不再接受传入连接。 （虽然我很乐意解决这个问题，但这不是我在这里问的问题;）
奇怪的是，当我们的应用程序停止接受端口44044上的连接时，IIS（端口8080）也是如此。杀死我们的应用程序修复了所有内容 - IIS再次开始响应。
所以问题是，应用程序可以搞乱整个TCP / IP堆栈吗？或许，应用程序如何做到这一点？
无意识的细节：我们的应用程序是用C＃编写的，在.Net 2.0下，在XP / SP2上。
澄清：IIS不会“拒绝”尝试连接。它永远不会看到它们。客户端正在获取“服务器未及时响应”消息（使用.Net TCP客户端。）
答案 0 :(得分：5)
你很可能正在挨饿。在每秒高的开/关交易环境中很容易流失，例如网络服务器提供大量未发送的请求。
这可以通过默认的TIME-WAIT延迟来实现 - 在回收之前必须关闭套接字的时间默认为90秒（如果我没记错的话）
有一堆可以调整的注册表项 - 建议至少创建/编辑以下键
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
TcpTimedWaitDelay = 30
MaxUserPort = 65534
MaxHashTableSize = 65536
MaxFreeTcbs = 16000
MSDN上的大量文档＆amp; Technet关于这些密钥的功能。
答案 1 :(得分：4)
你有没有最大限度地使用可用的端口句柄？
netstat -a
当应用程序打开和关闭端口时，我看到类似的东西（但实际上没有正确关闭它们）。
答案 2 :(得分：1)
使用netstat -a查看发生这种情况时的活动连接。也许，您的服务器应用程序没有关闭/处置“已关闭”的连接。
答案 3 :(得分：1)
大家的好建议，感谢您的帮助。
所以这是发生了什么： 事实证明，我们有几个服务竞争相同的端口，并且大多数时候“适当的”服务将获得端口。偶尔第二个服务会抓住端口，第一个服务会尝试打开另一个端口。从那时起，服务将在每次服务请求时继续抓取新端口（因为他们没有使用他们的首选端口），最终我们将耗尽所有可用端口。
当然，实际的问题是：“应用程序可以搞乱整个TCP / IP堆栈吗？”，这个问题的答案是：是的。一种方法是收听一大堆端口。
答案 4 :(得分：0)
我想RichS的端口号评论是正确的。
除此之外，TCP / IP堆栈只是操作系统中的一个模块，因此可能存在可能允许应用程序终止它的错误。它不会是第一个被程序杀死的驱动程序。
（对于Andrew Tanenbaum的一个提示，坚持认为操作系统应该是模块化而不是整体的。）
答案 5 :(得分：0)
我自己也遇到过几种类似的情况。一个很好的故障排除步骤是尝试从受影响的计算机连接到目前尚未遇到任何连接问题的知名目标。如果连接尝试失败，您很可能会在错误消息/代码中获得更多有趣的详细信息。例如，可以说没有足够的句柄或内存。
答案 6 :(得分：0)
从支持和系统管理员的角度来看，我只在极少数情况下（不止一次）看到过这种情况，但肯定会发生这种情况。
在诊断问题时，应该仔细消除可能的原因，而不是在出现问题时立即重新启动系统。我之所以这么说，是因为与我合作的很多客户都很想这样做。