linux - SO_REUSEADDR(setsockopt 选项)的含义是什么 - Linux？

Question

这个问题在这里已经有了答案:





How do SO_REUSEADDR and SO_REUSEPORT differ?

(2 个回答)


7年前关闭。




从手册页:

SO_REUSEADDR Specifies that the rules used in validating addresses supplied to bind() should allow reuse of local addresses, if this is supported by the protocol. This option takes an int value. This is a Boolean option

我应该什么时候使用它？为什么“重用本地地址”会给出？

Answer 1

TCP 的主要设计目标是在面对数据包丢失、数据包重新排序以及 — 此处的关键 — 数据包重复时允许可靠的数据通信。

当连接建立时，TCP/IP 网络堆栈如何处理所有这些是相当明显的，但是在连接关闭之后会发生边缘情况。如果在对话结束时发送的数据包被复制和延迟会发生什么，例如 the 4-way shutdown数据包在延迟数据包之前到达接收器？堆栈尽职尽责地关闭其连接。然后，延迟的重复数据包出现了。堆栈应该做什么？

更重要的是，如果一个在给定 IP 地址 + TCP 端口组合上打开套接字的程序关闭它的套接字，然后在短时间内，一个程序出现并想要监听相同的 IP 地址和 TCP 端口号，它应该怎么做? (典型情况:程序被杀死并快速重新启动。)

有几个选择:

禁止重复使用该 IP/端口组合至少 2 倍数据包可以在飞行中的最长时间。在 TCP 中，这通常称为 2× MSL延迟。你有时也会看到 2× RTT ，大致等价。

这是所有常见 TCP/IP 堆栈的默认行为。 2×MSL 通常在 30 到 120 秒之间，它出现在 netstat 中。输出为 TIME_WAIT 期间。在那之后，堆栈假定任何流氓数据包由于过期 TTLs 已在途中被丢弃。 ，以便套接字离开 TIME_WAIT状态，允许重复使用该 IP/端口组合。

允许新程序重新绑定(bind)到该 IP/端口组合。与 BSD sockets 堆叠在一起接口(interface)——基本上所有的 Unix 和类 Unix 系统，加上 Windows，通过 Winsock — 您必须通过设置 SO_REUSEADDR 来要求此行为选项通过 setsockopt() 在您调用之前 bind() .

SO_REUSEADDR最常设置在网络服务器程序中，因为常见的使用模式是进行配置更改，然后需要重新启动该程序以使更改生效。无 SO_REUSEADDR , bind()如果在您杀死前一个实例时有连接打开，则调用重新启动的程序的新实例将失败。这些连接将在 TIME_WAIT 中保存 TCP 端口。状态 30-120 秒，因此您属于上述情况 1。

设置中的风险SO_REUSEADDR是它造成了歧义:TCP 数据包 header 中的元数据不够独特，以至于堆栈可以可靠地判断数据包是否陈旧，因此应该丢弃而不是将其传送到新监听器的套接字，因为它显然是用于一个已经死了的听众。

如果您不认为这是真的，这里是所有监听机器的 TCP/IP 堆栈必须与每个连接一起工作才能做出该决定:

本地IP:每个连接不是唯一的。事实上，我们这里的问题定义是故意重复使用本地 IP。

本地 TCP 端口:同上。

远程 IP:导致歧义的机器可能会重新连接，因此这无助于消除数据包的正确目的地的歧义。

远程端口:在行为良好的网络堆栈中，传出连接的远程端口不会被快速重用，但它只有 16 位，因此您有 30-120 秒的时间来强制堆栈通过几万个选择和重用端口。早在 1960 年代，计算机就可以如此快速地工作。

如果您对此的回答是远程堆栈应该执行类似 TIME_WAIT 的操作一边禁止 ephemeral TCP port重用，该解决方案假定远程主机是良性的。恶意行为者可以自由地重用该远程端口。

我想监听器的堆栈可以选择严格禁止来自 TCP 4 元组的连接，以便在 TIME_WAIT 期间状态一个给定的远程主机被阻止重新连接到同一个远程临时端口，但我不知道任何 TCP 堆栈具有该特定改进。

本地和远程 TCP 序列号:这些也不够独特，以至于新的远程程序无法提供相同的值。

如果我们今天重新设计 TCP，我想我们会集成 TLS或类似的东西作为非可选功能，其一个效果是使这种无意和恶意的连接劫持成为不可能，但这需要添加大字段(128 位及以上)，这在 1981 年根本不实用，当当前版本的 TCP ( RFC 793 ) 的文档发布时。

如果没有这样的强化，在 TIME_WAIT 期间允许重新绑定(bind)会造成歧义。意味着您可以 a) 将用于旧监听器的陈旧数据错误地传送到属于新监听器的套接字，从而破坏监听器的协议(protocol)或错误地将陈旧数据注入(inject)连接；或 b) 新监听器套接字的新数据错误地分配给旧监听器套接字并因此无意中丢弃。

安全的做法是等待 TIME_WAIT期间。

最终，它归结为成本的选择:WAITING TIME_WAIT期间或承担不必要的数据丢失或意外数据注入(inject)的风险。

许多服务器程序冒了这个风险，决定最好立即让服务器备份，以免错过任何不必要的传入连接。

这不是一个普遍的选择。许多程序——甚至是需要重启才能应用设置更改的服务器程序——选择离开 SO_REUSEADDR独自一人。程序员可能知道这些风险并选择不理会默认值，或者他们可能不知道这些问题但正在从明智的默认值中受益。

一些网络程序为用户提供了在配置选项中的选择，将责任推给了最终用户或系统管理员。