我们的服务器应用程序正在侦听一个端口，一段时间后它不再接受传入的连接。 （虽然我很想解决这个问题，但这不是我在这里要问的；）
奇怪的是，当我们的应用停止接受端口 44044 上的连接时，IIS（端口 8080）也停止接受。杀死我们的应用程序可以解决所有问题 - IIS 再次开始响应。
所以问题是，一个应用程序会弄乱整个 TCP/IP 堆栈吗？或者，应用程序如何做到这一点？
毫无意义的细节：我们的应用是在 XP/SP2 上的 .Net 2.0 下用 C# 编写的。
澄清：IIS 没有“拒绝”尝试的连接。它永远不会看到它们。客户端收到“服务器未及时响应”消息（使用 .Net TCP 客户端。）
【问题讨论】：
你很可能会饿死堆栈。在每秒高打开/关闭事务的环境中很容易耗尽，例如服务于大量未合并请求的网络服务器。
默认的 TIME-WAIT 延迟会加剧这种情况 - 套接字在被回收之前必须关闭的时间默认为 90 秒（如果我没记错的话）
有很多可以调整的注册表键 - 建议至少创建/编辑以下键
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
TcpTimedWaitDelay = 30
MaxUserPort = 65534
MaxHashTableSize = 65536
MaxFreeTcbs = 16000
MSDN 和 Technet 上有大量关于这些键功能的文档。
【讨论】：
您还没有用尽可用的端口句柄吗？netstat -a
当应用打开和关闭端口（但实际上并没有正确关闭它们）时，我看到了类似的情况。
【讨论】：
发生这种情况时，使用 netstat -a 查看活动连接。也许，您的服务器应用程序没有关闭/处理“关闭”连接。
【讨论】：
大家的好建议，感谢您的帮助。
所以这就是发生的事情： 事实证明，我们有多个服务竞争同一个端口，并且大多数时候“正确的”服务会获得该端口。有时，第二个服务会抢走端口，而第一个服务会尝试打开另一个端口。从那时起，服务将在每次处理请求时不断获取新端口（因为它们没有使用首选端口），最终我们将耗尽所有可用端口。
当然，实际的问题是：“一个应用程序能搞乱整个 TCP/IP 堆栈吗？”，这个问题的答案是：是的。一种方法是监听一大堆端口。
【讨论】：
我猜 RichS 的端口号注释是正确的。
除此之外，TCP/IP 堆栈只是您操作系统中的一个模块，因此，可能存在可能导致应用程序杀死它的错误。它不会是第一个被程序杀死的司机。
（向 Andrew Tanenbaum 致敬，他坚持认为操作系统应该是模块化的，而不是单一的。）
【讨论】：
我自己也遇到过一些类似的情况。一个好的故障排除步骤是尝试从受影响的机器连接到当时没有遇到任何连接问题的已知目的地。如果连接尝试失败，您很可能会在错误消息/代码中获得更多有趣的细节。例如，它可以说没有足够的句柄或内存。
【讨论】：
从支持和系统管理员的角度来看，我只在极少数情况下（不止一次）看到过这种情况，但它肯定会发生。
在诊断问题时，应仔细排除可能的原因，而不是一出现问题就盲目重启系统。我之所以这么说，是因为与我合作的许多客户都想这样做。
【讨论】：