Debian Stretch 源 tcp 端口*总是*甚至

Question

在使用 Azure 负载平衡器调试一些奇怪的行为时，我注意到我的本地 Debian Stretch TCP 堆栈仅与偶数端口建立 TCP 连接。我不会使用奇怪的源端口启动单个 TCP 握手。这是故意的吗？

Answer 1

这是为了减少connect()和之间的争用bind()（出现在 Linux 4.2 中；Jessie 有 3.16，Stretch 有 4.9）：

提交07f4c90062f8fc7c8c26f8f95324cbe8fa3145a5
添加一名作者 
日期：2015年5月24日星期日14:49:35-0700

    tcp/dccp: 尽量不要在 connect() 中耗尽 ip_local_port_range

    繁忙的服务器上一个长期存在的问题是可用的 TCP 端口很小
    范围（/proc/sys/net/ipv4/ip_local_port_range）和默认值
    connect() 系统调用中源端口的顺序分配。

    如果主机有很多活动的 TCP 会话，则很有可能
    非常高，所有端口都被至少一个流使用，
    并且随后的 bind(0) 尝试失败，或者必须扫描大部分
    空间找到一个插槽。

    在这个补丁中，我改变了 __inet_hash_connect() 中的起点
    所以我们尝试支持偶数 [1] 端口，为 bind() 留下奇数端口
    用户。

    我们仍然执行顺序搜索，所以不能保证，但是
    如果 connect() 目标非常不同，最终结果是我们离开
    可用于 bind() 的更多端口，我们将它们分布在整个范围内，
    减少 connect() 和 bind() 找到插槽的时间。

    此策略仅适用于 /proc/sys/net/ipv4/ip_local_port_range
    是偶数，即如果开始/结束值具有不同的奇偶校验。

    因此，默认 /proc/sys/net/ipv4/ip_local_port_range 改为
    32768 - 60999（而不是 32768 - 61000）

    这里的安全方面没有变化，只有一些糟糕的散列
    计划最终可能会受到这一变化的影响。

    [1] ：奇数/偶数属性取决于 ip_local_port_range 值奇偶性

您可能还想查看后续提交 1580ab63fc9a03593072cc5656167a75c4f1d173。