linux - TCPv4 源端口和目标端口是否可以相互冲突？还是源端口和目标端口位于它们自己的地址空间中？

Question

让我用一个例子更具体地说明我的问题:假设我有很多小型服务器，它们都使用 TCPv4 在不同的端口上启动。当然，这些端口将成为目标端口。让我们进一步假设这些小型服务器不像典型服务器那样在启动时启动，而是根据需求动态变化。它们会在需要时启动，并可能会自行关闭一段时间，然后再次启动。

现在假设在同一台计算机上，我们还有许多客户端进程通过 TCPv4 向其他计算机上的服务器进程发出请求。当客户端发出此类请求时，操作系统会为其分配一个源端口。

为了这个例子，我们假设一个客户端进程向在不同计算机上运行的 RESTful 服务器发出 Web 请求。假设操作系统分配给这个请求的源端口是端口 7777。

对于这个例子，我们还假设当上述请求仍在发生时，我们的一个小服务器想要启动，并且它想要在目标端口 7777 上启动。

我的问题是这会引起冲突吗？即，服务器是否会因为端口 7777 已被使用而出错？还是一切都会好起来，因为这两种不同类型的端口位于不同的地址空间，不会相互冲突？

我担心这里可能发生冲突的一个原因是，我看到网页说“临时源端口选择”通常是在从相对较高的数字开始的端口号范围内完成的。这是这样一个网页:

https://www.cymru.com/jtk/misc/ephemeralports.html

为什么源端口从高数字开始，而不是仅仅从 1 开始，一个自然的假设是避免与服务器进程使用的目标端口发生冲突。虽然我还没有看到任何明确表示是这样的。

附言当然，TCPv4 协议(protocol)规范在这个问题上必须说明的内容与操作系统实际执行的操作之间存在潜在区别。例如，也许协议(protocol)是不可知的，但操作系统往往只使用一个地址空间？或者可能不同的操作系统以不同的方式处理这个问题？

就我个人而言，目前我最感兴趣的是 Linux 会做什么。

Answer 1

TCP 规范说连接由元组标识:

{local addr, local port, remote addr, remote port}

基于此，理论上在现有连接中使用的本地端口与尝试绑定(bind)同一端口供服务器监听之间不应该存在冲突，因为监听套接字没有远程地址/端口(这些在规范中表示为通配符)。

然而，大多数 TCP 实现，包括 Unix 套接字 API，都比这更严格。如果本地端口已在任何现有套接字中使用，您将无法绑定(bind)它，您将收到错误 EADDRINUSE。如果现有套接字都处于 TIME_WAIT 状态并且新套接字具有 SO_REUSEADDR 套接字选项，则会产生一个特殊的异常(exception)；这用于允许服务器在前一个进程遗留的套接字仍在等待超时时重新启动。

因此，端口范围一般分为不同用途的范围。当套接字没有绑定(bind)本地端口时(因为它只是调用了 connect() 而没有调用 bind()，或者通过指定 IPPORT_ANY作为 bind() 中的端口)，该端口是从 ephemeral 范围中选择的，通常是编号非常高的端口。另一方面，服务器应该绑定(bind)到低编号端口。如果网络应用程序遵循此约定，则不应遇到冲突。