Debian Stretch源TCP端口甚至总是*

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

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

提交07f4c90062f8fc7c8c26f8f95324cbe8fa3145a5
作者：埃里克·杜马兹（Eric Dumazet） 
日期：2015年5月24日星期日14:49:35

    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。