我有一个服务器应用程序，它使用 W2k8 现在使用的 IANA 建议范围 ~49000-65000 内的永久连接的传入端口。（由于遗留原因，改变这一点极其困难，所以我必须改变窗口的范围来避开我的范围，但这不是问题）。
我一直在研究如何避免与 Windows 2008 Server 中的临时端口发生冲突，但找不到有关选择临时端口的 Windows 算法。
当 Windows 网络层为传出的 TCP/IP 连接的响应分配一个“随机”临时端口时，它是否测试建议的端口看看它是否已被使用？
（Linux 内核似乎做了 check_established 测试但仍然可以重新使用一些使用过的连接，所以我想知道 Windows 会做出什么决定来从另一个进程中移除看似未使用或空闲的端口……）
也就是说，如果我的服务器在其所有端口上打开 winsocks，并将它们保持在监听状态，Windows 是否会因为它们正在使用而尊重并跳过它们？还是会忽略它们正在使用的事实，并将它们分配给其他进程以供短暂使用，从而导致冲突？
我发现有时我的服务器启动时无法分配一些端口，因为其他进程正在随机使用这些端口 - 这是有道理的，我理解这一点。但我还无法证明它最初设法打开的端口是否随后被“盗用”用于短暂用途（由于范围大且性质随机，因此很难测试或强制执行）。
正如我所说的，无论如何我都会重新配置 Windows 以避开我的服务器，所以这个问题更多的是出于好奇，并为了更清楚地解释最近的行为（以排除/排除其他可能的错误！）
提前致谢
答案1
我的回答是；
对于您使用 winsock API 编写的程序，它会以那种方式处理；http://support.microsoft.com/kb/173619。
当您关闭套接字句柄时，客户端和服务器之间会进行一些额外的协商。套接字将等待最多两倍于 Windows 等待从关闭端口的套接字另一端接收确认的最大时间。默认情况下，此选项设置为两分钟。因此，Windows 可能需要等待最多四分钟才能实际释放端口。这使得该特定端口在实际释放之前不可用。
对于 Windows RPC 服务；
*本文未指定哪些服务依赖其他服务进行网络通信。例如，许多服务依赖 Microsoft Windows 中的远程过程调用 (RPC) 或 DCOM 功能来为其分配动态 TCP 端口。远程过程调用服务协调使用 RPC 或 DCOM 与客户端计算机通信的其他系统服务的请求。许多其他服务依赖于网络基本输入/输出系统 (NetBIOS) 或 SMB，这些协议由服务器服务提供。其他服务依赖于 HTTP 或超文本传输协议安全 (HTTPS)。这些协议由 Internet 信息服务 (IIS) 提供。对 Windows 操作系统体系结构的完整讨论超出了本文的范围。但是，Microsoft TechNet 和 Microsoft Developer Network (MSDN) 网站上提供了有关此主题的详细文档。尽管许多服务可能依赖特定的 TCP 或 UDP 端口，但一次只有一个服务或进程可以侦听该端口。
当您使用 RPC 和 TCP/IP 或 UDP/IP 作为传输方式时，传入端口通常会根据需要动态分配给系统服务；使用高于端口 1024 的 TCP/IP 和 UDP/IP 端口。这些端口也被非正式地称为随机 RPC 端口。在这些情况下，RPC 客户端依靠 RPC 终结点映射器来告诉它们已将哪个或哪些动态端口分配给服务器。对于某些基于 RPC 的服务，您可以配置特定端口，而不是让 RPC 动态分配端口。您还可以将 RPC 动态分配的端口范围限制为一个较小的范围，而不管服务是什么。有关此主题的更多信息，请参阅“参考”部分。*