Azure Load Balancerを使用していくつかの奇妙な動作をデバッグしている間、ローカルのDebian Stretch TCPスタックが偶数ポートにのみTCP接続を作成することがわかりました。私は奇妙なソースポートで単一のTCPハンドシェイクを開始しません。意図的なことでしょうか？
ベストアンサー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セッションの数が多い場合は可能です。 非常に高い、すべてのポートが1つ以上のフローで使用されます。 その後のバインド（0）の試行は失敗するか、ほとんどをスキャンする必要があります。 スロットが見つかるスペースです。 今回のパッチでは、__inet_hash_connect() の始点を変更しました。 だから私たちは偶数[1]ポートをサポートしようとし、バインド（）に奇数ポートを残します。 ユーザー。 まだ順次検索をしているので保証できませんが、 connect() ターゲットが非常に異なる場合、最終結果は私たちが去ることです。 バインド（）でより多くのポートを使用できるため、範囲全体に分散します。 スロットを見つけるのに必要なconnect（）とバインディング（）の時間を短縮します。 このポリシーは、/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送信。