Tomcat 7サーブレットは永続的なNIO接続を強制的に閉じる必要があります

Question

私は、リモートクライアントからの接続を受け入れ、可能な限り数時間または数日間接続を維持するTomcat 7サーブレットを持っています。したがって、私たちはNIOコネクタを使用しています。 物理接続の帯域幅は高価な場合があるため、トラフィックは絶対最小限に抑える必要があります。したがって、非常にまれなpingで接続をテストするようにリモートクライアントをプログラムしました。

サーブレットに接続が閉じられていると伝えられることもありますが、リモートクライアントには通知されていないようです。クライアントは、pingを実行するまで、新しい接続を確立することはできません。 pingを増やすことなく、クライアントが接続されていない時間を短縮する必要があります。

1つの方法は、Tomcatサーバーをシャットダウンすることです。クライアントはすぐに切断されることを知っています。明らかに私たちはTomcatをシャットダウンしたくありません - 私の要点は、通常静かな接続を介して何らかの信号を送信する必要があることです。

Tomcatにこの信号を送信させるにはどうすればよいですか？私がそれを信じることができなかった理由と、それが信じたくないことが主な理由のために、なぜ具体的な理由があるのか​​を教えてくれることができない限り、奇妙に思える - 誰かに電話を掛けることができないように。

代替質問＃1 - サーブレットは接続が解除されたことを通知することはできますか？

替わりの質問＃2 - 誰でも助けてくれると思いますか？

Answer 1

思考のカップル：

• 私は、クライアントが接続が切断されたことに気付いていない驚いています。例外がクライアント側のどこかで飲み込まれていないことは確かですか？
• 長い接続で、私はTCPレイヤーで何が起こっているのか見始めます。あなたは診断や情報について言及していません...
  • これらの問題のクライアント/サーバー接続には依然として存在するTCP/IP接続が存在するかどうかを確認しようとしましたか？
  • クライアントとサーバー間のネットワークはどれくらい安定していますか？
  • プロキシやルータなどのネットワークデバイスが不正に動作する可能性がありますか？
• NIOコネクタを長寿命接続のこのコンテキストで使用する利点は実際にはわかりません。毎秒多くのリクエストがありますか？はい。しかし、長生きの接続のためだけに？ No.
  • これまで、NIOコネクタと、デフォルトのHTTPコネクタを使用して魔法のように離れたサーブレットプロトコルゲートウェイ（OpenAMF）の奇妙な問題がありました。
  • 他の2つのコネクタ（HTTP、ネイティブARP）をテストし、ベンチマークします。
• また、UDPベースのアプローチのために、HTTPなどのTCPベースのプロトコルを削除することも検討します。そうすれば、あなたの接続は状態がなくなり、カスタマイズされたペイロードで、パケットは非常に小さくなります。

Answer 2

我々はHTTP接続（または任意のTCP接続）と同じ問題を見てきたように私はこの古い質問に答えるよ、ファイアウォール越えていないトラフィックで数十分間開いたまま。実際にファイアウォールがない場合、私の答えは適用されません。

この理論は、クライアントとサーバー上で同時にtcpdump/wiresharkといくつかの辛抱強さを確認することで確認できます。

ファイアウォールがある場合は、接続を有効にするために、ファイアウォールのアイドルTCP接続のタイムアウトよりも頻繁に「ping」パケットが発生することを確認する必要があります。ファイアウォールのタイムアウトを増やす前に2度考えてください。私が説明しているように、ファイアウォールはそれまでではないかもしれません。

クライアントとサーバー間のファイアウォールがNATまたはパケット検査を実行している可能性があります。これらの機能にはファイアウォール上のリソースが必要であり、ファイアウォールが追跡する接続数には制限があります。したがって、リソースを節約するために、デフォルトではアイドルタイムアウト後にこれらの接続を「静かに閉じる」でしょう。

ファイアウォールは、クライアントまたはサーバーのいずれかがトラフィックを送信するまで、いずれの側にもパケットを送信しないので、私は静かに言う。この時点で、ファイアウォールは通常、RSTパケットで応答します。クライアントとサーバーの両方からtcpdumpを使用してこれをトレースしました。これは、ファイアウォールが接続の側からこのRSTパケットを送信していることを示しています。しかし、反対側のtcpdumpはこのパケットが送信されなかったことを確認しました。それはファイアウォールでなければならなかった。

ファイアウォールで接続の数を処理できない可能性があるため、ファイアウォールでのアイドルタイムアウトのサイズを大きくすると、さらに問題が発生する可能性があります。これにより、ファイアウォールのリセットが発生し、ファイアウォールの向こう側にすべてのtcpソケットが表示されることがあります。

TCPを使用する必要があるので、ファイアウォール（NAT、アカウンティング、パケットインスペクション）で接続の追跡が必要なファイアウォール機能は使用しないでください。または、すべての接続を追跡するのに十分なリソースを備えたファイアウォールがあることを確認してください。