HTTPクライアントが全てのレスポンスデータを受信せず、かつTCP接続を維持し続けた場合のApacheとTomcatの動作を調べてみました。

追試する場合の注意点

レスポンスデータのサイズが小さい場合、サーバ側のsend(2)は成功します(HTTP固有の話ではなくソケットレベルの話です。send(2)の成功はネットワークスタックの送信バッファに書き込めれば成功するからです)。下記の話は、サーバ側のアプリレベルで送信データを全て送れない場合の話です。レスポンスデータのサイズが一定以上ないと再現できません。

以下の3つの構成を調べました。

• apache単体
• tomcat単体
• mod_jkでapacheとtomcat連携

apache単体の場合

httpd.confのTimeout設定の値が経過するとapacheがTCP接続を切ります。apacheのログにはステータス200で載ります(もちろんステータス200で返した場合)。ログの%Xの値がXになるのが唯一の異常を示す値です。

tomcat単体の場合

tomcatが永遠に待ち続けます。タイムアウト系の設定は効かないようです。HTTPクライアントが全てのワーカースレッドをブロックさせると簡単にDoS攻撃できます。あまりに脆弱すぎてなにか変かもしれません。動作確認はtomcat6.0.18です。ちなみにHTTPクライアントはサーバと同一ホストで動かしています。それが影響している可能性はゼロではありません(接続相手が同一ホストの場合、信頼して特別措置をしてもおかしくないからです)。

内部実装は見ていませんが、java.io.Socketのwriteメソッド待ちなら、この動作(永遠にブロック)もそんなものか、という感じですが。

mod_jkの場合

httpd.confのTimeout設定の値が経過するとapacheがTCP接続を切ります。apacheのログに残る情報は上記「apache単体の場合」と同じです。apacheがTCP接続を切ると同時にtomcat側のワーカースレッドは空きます(DoS攻撃はできません)。tomcatのログは特別に異常を示す情報は残りません。

JMeterにこの(全レスポンスデータを受信せず接続だけを維持し続ける)バグがある疑いを持っていましたが、上記の動作からすると疑いは晴れました。