Linux-TCP送信元ポートの再利用（および遅延）
リモートWebサーバー/サービスに対して多くの呼び出しを行うアプリケーションがあります。クライアントアプリはLinux上のJBoss/Java（Red Hat 5）、リモートサーバーはWindows2008です。途中にCiscoACEがありますが、NATは実行されていません。
Linux/JBossが送信元ポートを再利用してHTTP呼び出しを行うと、「接続が拒否されました」というメッセージが表示されることに気づきました。クライアントが数分以内に上記の送信元ポートを再利用するときです。
両側でtcpdump/Wiresharkを実行すると、次のようになります。
リクエスト＃1：送信元ポート6666、宛先ポート80
クライアント-> Synサーバー-> SynACKクライアント-> ACKクライアント-> GET /サーバー->データを返すクライアント-> ACKサーバー-> FINACKクライアント-> FINACKサーバー-> ACK
リクエスト＃2：同じ送信元ポートと宛先ポートは成功です。
リクエスト＃3：同じ送信元ポートと宛先ポートは成功です。
リクエスト＃4：送信元ポートと宛先ポートは同じですが、今回は失敗（「接続が拒否されました」）で、次のようになります。
クライアント-> SYNクライアント-> SYN（再送信）クライアント-> RST、ACK
サーバーは両方のSYNを認識しますが、ACKまたはRSTを送信することはありません（クライアントからのRSTを認識します）。
検索を行った後、TCPタイムスタンプの潜在的な問題に遭遇しました。ACEがそれらを通過できることを確認し、Windowsがそれらを認識していることを確認できます。また、接続がTIME_WAIT状態で表示されます。サーバー/ Windows側（ただし、最初にGETが成功し、＃2と＃3がすべて成功した後でも、これが表示されます）。ポートが開いていないか、クライアント側のTIME_WAITにあります。
私が見ている場所の1つは、Windows側のTcpTimedWaitDelayレジストリエントリを30秒に減らすことです。私はこれをまだ行っていないか、テストしていませんが、問題があればうまくいくはずだと思っています。
クライアント/ Linux側のポートを15000〜60000（デフォルトの30000から60000）に増やしましたが、役に立ちませんでした（使用可能なポートの増加が、使用のランダム性のために、より長く遅延した時間に変換されることを期待しています送信元ポート）
サーバー/ Windows側がSYNの通過を確認しているのに応答しないのは奇妙だと思います。そのため、SYNは前のセッションか何かからのものであると思われます。
これが欲しいかどうかはわかりませんが、最近使用された場合にソースポートを再利用しないようにLinuxに指示する方法があるかどうか疑問に思いました。そのロジックのある種の遅延のように（もしあれば）？
使用可能なポートなどが不足しているわけではありませんが、ランダムであるため、送信元ポートが数分以内に再利用され、問題が発生する場合があります。
あなたはこれについて他に何か考えがありますか？
ありがとう！
[〜＃〜] update [〜＃〜]
WindowsサーバーでTcpTimedWaitDelayを30秒に設定しました。再利用されている送信元ポートでの呼び出しが30秒後に行われる限り、問題はありません。
ACEはまだいくつかの点で責任があると思います。それは、ACEをバイパスするかのように、何らかのSYN攻撃保護（ACEはセキュリティデバイス）である可能性があります。問題はありません。
しかし、2MSLを30秒に設定することは、今のところ十分な修正のようです。
これに答えるのに十分なWindowsソケットサイクリングについてはわかりませんが、サーバーが接続を閉じ、ソケットがTIME_WAIT状態にあり、有効期限が切れるまで再び使用できないと推測しています。
この問題を解決する「正しい」方法は、タプルを追加することです。クライアントの送信ポートを増やし（これを実行しました）、サーバーにリスニングポートを追加し、インターフェイスにIPエイリアスを追加して、アプリにそれらの追加のIPを使用させます。/ports。
「正しくない」方法は、TWタイムアウトを減らすことです。これは、TcpTimedWaitDelayで行っていると思います。
「まったく正しくないが、それでも非常に人気のある」方法は、ソケットのリサイクルを有効にすることです。Linuxにはオプションtw_reuseとtw_recycleがあり、Windowsにも同等のオプションがあります。
最後の2つのオプションは、TCP RFCを破ります。おそらく、ACEに問題がありますか？