web-dev-qa-db-ja.com

開いたままの確立された接続が多すぎる

私は（おそらくかなり古い）CentOS 4.5サーバーで、カスタムJavaアプリケーションが内部で実行されています。

しばらく実行するとアプリケーションがクラッシュし、1024の接続を処理していて、死んだときにもう1つのソケットを開こうとしていることがわかりました。

実際、私がチェックした場合ulimit -n 1024であることを確認できました。空きファイル記述子がなくなったため、アプリケーションが閉じられます。

私が気になっているのは、すべてが比較的少数のIP（約200）からの "確立されたオフ"状態にある数百の明らかに非アクティブな接続があり、時間が経過してクライアントが接続するにつれて、それらは合計される傾向があることです。これらのように私は走っているのを見ているnetstat -nato：

tcp        0      0 ::ffff:10.39.151.20:10000   ::ffff:78.152.97.98:12059   ESTABLISHED off (0.00/0/0)
tcp        0      0 ::ffff:10.39.151.20:10000   ::ffff:78.152.97.98:49179   ESTABLISHED off (0.00/0/0)
tcp        0      0 ::ffff:10.39.151.20:10000   ::ffff:78.152.97.42:45907   ESTABLISHED off (0.00/0/0)

私はそれがDOS攻撃ではないことを知っています。接続は合法ですが、クライアントが接続してサーバーとの短いデータ交換を行った後に閉じられていないようです。さらに、200のクライアントによって生成されるため、ペースは遅いです（カウント別のIP）。

奇妙なアプリケーションのバグ（多分jre 1.6）を調査するべきでしょうか、それともCentOSネットワーク構成を掘り下げるべきでしょうか？これ以上何を見るべきか、私には手がかりがありません。

よろしくお願いいたします。ヒントはありがたいです。

networkingcentosnetstatconnections
5
Luke

仮説1：アプリケーションがファイアウォールの背後にあり、一定時間後にアイドル状態のTCP接続をドロップする.

クライアントがこの接続を再度使用しようとすると、応答がないことが判明し、接続が切断されて新しい接続が開始されます。

サーバーの場合、TCP接続にはキープアライブタイマーがないため、接続が無効であり、無期限に開いたままになることを知る方法はありません。

証明するには：1つの接続を長時間実行するtcpdumpを作成して、一定の時間が経過すると未使用になることを確認します。

解決：

  • TCPソケットでキープアライブを使用するようにコードを変更し、（オプションで最高のパフォーマンスを得るために）キープアライブタイマーをファイアウォールのTCPアイドルタイマーよりも低く設定します。
  • ファイアウォールのtcp-idleタイマーを、クライアントの最大機能アイドル時間を超える高い値に変更します。ほとんどの場合、これはファイアウォールのグローバル設定になるため、セキュリティ管理者はそうすることに少し消極的かもしれません。
7
Zabuzzman