Debian Stretchソースのtcpポートは*常に*です

Azureロードバランサーを使用していくつかの奇妙な動作をデバッグしているときに、ローカルのDebian Stretch TCPスタックが偶数番号のポートとのTCP接続しか確立していないことに気付きました。奇数のソースポートで単一のTCPハンドシェイクを開始しません。それは意図されていますか？

それは間の競合を減らすためだconnect()とbind()する（Linux 4.2で登場し、ジェシーは3.16を持っており、ストレッチは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セッションをたくさん持っている場合、可能性は
    すべてのポートが少なくとも1つのフローによって使用されている非常に高い
    その後のbind（0）の試行が失敗するか、大部分をスキャンする必要があります
    スロットを見つけるためのスペース。

    このパッチでは、__ inet_hash_connect（）の開始点を変更しました
    bind [）に奇数のポートを残して、偶数の[1]ポートを優先するようにします
    ユーザー。

    引き続きシーケンシャル検索を実行するため、保証はありませんが、
    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を確認することもできます。