Apache KeepAliveTimeoutは、一定の時間内に新しいリクエストが発行されない場合にキープアライブ接続を閉じるために存在します。ユーザーがブラウザ/タブを閉じない場合、このタイムアウト（通常は5〜15秒）が最終的にほとんどのキープアライブ接続を閉じ、接続を無期限に保持することでサーバーリソースの浪費を防ぎます。
現在、このMaxKeepAliveRequestsディレクティブは、単一のTCP接続（のために開いたままにするKeepAlive）が処理するHTTPリクエストの数に制限を設けています。これをに設定する0と、無制限の数の要求が許可されます。
なぜこれを「無制限」以外に設定するのですか？ クライアントが引き続き積極的にリクエストを行っている場合、同じキープアライブ接続でそれらを発生させることにはどのような害がありますか？制限に達した後も、新しい接続でのみリクエストが送信されます。
私の見方では、これを制限しても意味がありません。何が欠けていますか？
回答:
基本的に、Apacheはそのために構築されていないためです。問題はサーバーのメモリ使用量です。多くの構成では、コンテンツ生成はコンテンツ配信と同じプロセスで行われるため、各プロセスは、処理する最大のもののサイズに成長します。重いPHPスクリプトのために64MBに拡張するプロセスを想像してください。それから、肥大化したプロセスが静的ファイルを配置して提供します。これに100を掛けます。また、メモリリークがどこかにある場合、プロセスは無制限に大きくなります。
キープアライブ設定は、コンテンツのタイプとトラフィックに基づいてバランスを取る必要があります。一般に、最適な構成では、MaxKeepAliveRequestsを高く（100〜500）、KeepAliveTimeoutを低く（2〜5）して、すばやく解放します。
私はこれが古い質問であることを知っていますが、私はいくつかのデバッグを行っており、（これはApacheだけに当てはまるわけではありません）とMaxKeepAliveRequestsは無関係に動作するようですKeepAliveTimeout。
つまり、タイムアウトディレクティブは、アイドル状態の永続的な接続に対してのみカウントされます（読み取りまたは書き込みではありません）。タイムアウト未満でリクエストを続けると、同じ接続で事実上無制限の量のリクエストを実行できます。
これは、長時間実行されるTCP接続がランダムに強制終了されるなど、いくつかの理由で適切でない場合がありますか？いずれの場合も、httpクライアントはそれほど愚かではなく、「低」MaxKeepAliveRequests設定をかなりうまく処理できます。たとえば、プログラミング言語では、TCP接続がサーバーによって閉じられて再接続されているかどうかを検出するのが比較的簡単です。さらに、ほとんどのhttpクライアントは独自に制限を設けます（たとえば、ブラウザーは300秒程度でキープアライブ接続を閉じます）。
1つの理由は、ロードバランシングのためです。キープアライブまたはhttp 1.1の永続的な接続が確立されると、ロードバランサーは閉じるまで新しいホストに移動しません。1つのクライアントが1つの接続を介して膨大な数のリクエストを行う場合、サーバー間で適切なバランスが取れない可能性があります。
部分的には、1人のユーザーがすべての接続スロットを占有するのを防ぐためです。制限がなければ、悪意のある、または不適切に記述された1つのクライアントが、使用可能なすべての接続を乗っ取り、永久にそれらを保持する可能性があります。ただし、これは、IPごとの接続制限のようなものと比較すると、そのための大きな緩和策ではありません。
主にロードバランシングですが、特にメンテナンスに関してです。サーバーをオフラインにしたい場合は、サーバーを0接続にドロップしますが、既存の接続を一定時間終了させます。キープアライブ要求の数に制限を設けることは、最終的にユーザーが新しい接続を適切に作成し、新しいバックエンドサーバーに移動することを意味します。おそらく、ドレインプロセス中にキープアライブの受け入れを完全に停止する必要があることをサーバーに通知する何らかの方法がさらに良いでしょうが、私が知る限り、そのような機能は存在しません。