現代におけるhttpキープアライブ

したがって、httpについて少し知っているhaproxy作者によると、

キープアライブは、CPUが100倍遅いときにサーバーのCPU使用率を削減するために開発されました。しかし、永続的な接続は、それらを開いたクライアント以外の誰も使用できない一方で、大量のメモリを消費するとは言いません。2009年の今日、CPUは非常に安価であり、メモリはアーキテクチャまたは価格によって数ギガバイトに制限されています。サイトでキープアライブが必要な場合は、実際に問題があります。負荷の高いサイトでは、キープアライブを無効にして、同時クライアントの最大数をサポートすることがよくあります。キープアライブがないことの本当の欠点は、オブジェクトをフェッチするための待ち時間がわずかに増えることです。これを補うために、ブラウザは非キープアライブサイトでの同時接続数を2倍にします。

（http://haproxy.1wt.eu/から）

これは他の人々の経験と一致していますか？つまり、キープアライブなし-結果はほとんど目立たなくなりますか？（おそらくWebSocketなどでは、接続はキープアライブステータスに関係なく「オープン」に保たれます-非常に応答性の高いアプリの場合）。サーバーから離れている人にとって効果は大きいですか、またはページをロードするときに同じホストからロードするアーティファクトがたくさんある場合は？（CSS、画像、JSなどは、キャッシュフレンドリーなCDNからますます増えていると思います）。

考え？

（これがserverfault.comのものかどうかはわかりませんが、誰かがそこに移動するように指示するまで、私はクロスポストしません）。

私はこの引用の作成者なので、返信します:-)

大規模なサイトには、同時接続と遅延という2つの大きな問題があります。同時接続は、コンテンツのダウンロードに時間がかかる低速のクライアントと、アイドル状態の接続が原因で発生します。これらのアイドル接続状態は、キープアライブと呼ばれる複数のオブジェクトをフェッチするための接続の再利用が原因で発生し、レイテンシによってさらに増加し​​ます。クライアントがサーバーに非常に近い場合、クライアントは接続を集中的に使用し、アイドル状態になることはほとんどありません。ただし、シーケンスが終了すると、誰もすぐにチャネルを閉じようとはしません。接続は開いたままで、長期間使用されません。これが、非常に低いキープアライブタイムアウトの使用を推奨する理由です。Apacheのような一部のサーバーでは、設定できる最小のタイムアウトは1秒で、多くの場合、高負荷を維持するには長すぎます。目の前に20000クライアントがあり、平均で毎秒1つのオブジェクトをフェッチする場合、それらの20000接続が永続的に確立されます。Apacheのような汎用サーバーでの20000同時接続は巨大であり、ロードするモジュールに応じて32〜64 GBのRAMが必要になります。RAMを追加しても、それ以上の容量は望めません。実際には、20000クライアントの場合、サーバーには40000から60000の同時接続が表示されることもあります。ブラウザがフェッチするオブジェクトが多い場合、ブラウザは2から3の接続を設定しようとするためです。また、RAMを追加しても、それ以上高くなることは望めません。実際には、20000クライアントの場合、サーバーには40000から60000の同時接続が表示されることもあります。ブラウザがフェッチするオブジェクトが多い場合、ブラウザは2から3の接続を設定しようとするためです。また、RAMを追加しても、それ以上高くなることは望めません。実際には、20000クライアントの場合、サーバーには40000から60000の同時接続が表示されることもあります。ブラウザがフェッチするオブジェクトが多い場合、ブラウザは2から3の接続を設定しようとするためです。

各オブジェクトの後に接続を閉じると、同時接続の数は劇的に減少します。実際、オブジェクト間の時間によってオブジェクトをダウンロードする平均時間に対応する係数で低下します。オブジェクト（ミニチュア写真、ボタンなど）をダウンロードするために50ミリ秒必要で、上記のように平均で1秒あたり1つのオブジェクトをダウンロードする場合、クライアントごとに0.05接続しかなく、これはわずか1000です。 20000クライアントの同時接続。

ここで、新しい接続を確立する時間がカウントされます。遠く離れたクライアントでは、不快な遅延が発生します。以前は、ブラウザはキープアライブを無効にすると、大量の同時接続を使用していました。MSIEでは4、Netscapeでは8の数字を覚えています。これにより、オブジェクトあたりの平均レイテンシはそれだけ割り切れるはずです。キープアライブがすべての場所に存在するようになったため、リモートサーバーの負荷がさらに増加し​​、ブラウザーがインターネットのインフラストラクチャを保護するため、このような高い数値は見られなくなりました。

つまり、今日のブラウザでは、キープアライブサービスと同じくらい応答性の高い非キープアライブサービスを取得するのが難しくなっています。また、一部のブラウザー（例：Opera）は、ヒューリスティックを使用してパイプライン処理を使用しようとします。パイプラインは、キープアライブを使用する効率的な方法です。応答を待たずに複数の要求を送信することにより、レイテンシがほとんどなくなります。100枚の小さな写真があるページで試してみました。最初のアクセスはキープアライブなしの約2倍の速度ですが、次のアクセスは約8倍の速さです。 「304」応答）。

理想的には、ブラウザに調整可能なパラメータをいくつか用意して、フェッチされたオブジェクト間の接続を維持し、ページが完成したらすぐにドロップできるようにする必要があると思います。しかし、残念ながらそれは見られません。

このため、Apacheなどの汎用サーバーを前面にインストールする必要があり、大量のクライアントをサポートする必要があるサイトでは、通常、キープアライブを無効にする必要があります。また、ブラウザに接続数を増やすように強制するために、複数のドメイン名を使用して、ダウンロードを並列化できます。SSLを集中的に使用しているサイトでは、ラウンドトリップが1つ増えるため、接続設定がさらに高くなるため、これは特に問題になります。

最近よく見られるのは、そのようなサイトが数万から数十万の同時接続を問題なく処理できるhaproxyやnginxなどの軽いフロントエンドをインストールすることを好み、クライアント側でキープアライブを有効にし、クライアントで無効にすることです。 Apache側。この面では、接続を確立するためのコストは、CPUの観点からはほぼゼロであり、時間の観点からはまったく目立ちません。このようにして、クライアント側でのタイムアウトが非常に低く、キープアライブによる遅延が少なく、サーバー側での接続数が少ないという、両方の長所を提供します。みんなが幸せだ ：-）

一部の商用製品では、フロントロードバランサーとサーバー間の接続を再利用し、それらを介してすべてのクライアント接続を多重化することで、これをさらに改善しています。サーバーがLBに近い場合、以前のソリューションよりも大幅に向上することはありませんが、複数のユーザー間で予期しない接続の共有が発生し、ユーザー間でセッションが交差するリスクがないことを保証するために、アプリケーションの調整が必要になることがよくあります。 。理論的には、これは決して起こらないはずです。現実は大きく異なります:-)

これが書かれて（そしてここでstackoverflowに投稿されて）以来、人気が高まっているnginxなどのサーバーがあります。

たとえば、nginxは、2.5 MB（メガバイト）のRAMのみを使用して、1つのプロセスでオープン10,000のキープアライブ接続を保持できます。実際、非常に少ないRAMで数千の接続を開いたままにしておくのは簡単であり、ヒットする唯一の制限は、開いているファイルハンドルの数やTCP接続などの他の制限です。

キープアライブの問題は、キープアライブの仕様自体に問題があるのではなく、Apacheのプロセスベースのスケーリングモデルと、それに対応するように設計されていないアーキテクチャのサーバーにハッキングされたキープアライブの問題でした。

特に問題があるのは、Apache Prefork + mod_php +キープアライブです。これは、PHPプロセスが完全にアイドル状態で、キープアライブとしてのみ開いたままであっても、すべての接続がPHPプロセスが占有するすべてのRAMを占有し続けるモデルです。これはスケーラブルではありません。ただし、サーバーをこのように設計する必要はありません。サーバーがすべてのキープアライブ接続を個別のプロセスに保持する必要がある特定の理由はありません（特に、そのようなすべてのプロセスに完全なPHPインタープリターがある場合はそうではありません）。PHP-FPMとnginxのようなイベントベースのサーバー処理モデルが問題をエレガントに解決します。

2015年更新：

SPDYとHTTP / 2は、HTTPのキープアライブ機能をさらに優れたものに置き換えます。接続を維持し、それを介して複数の要求と応答を作成するだけでなく、それらが多重化されるため、応答を任意の順序で送信できます。 、および要求された順序だけではなく、並行して これにより、遅い応答が速い応答をブロックするのを防ぎ、ブラウザが単一のサーバーへの複数の並列接続を開いたままにしておくという誘惑を排除します。これらのテクノロジーはさらに、mod_phpアプローチの不備と、PHP-FPMのようなものと個別に結合されたイベントベースの（または少なくともマルチスレッドの）Webサーバーのようなものの利点を際立たせています。

私の理解では、CPUとはほとんど関係がありませんでしたが、繰り返しソケットを開くときの待ち時間は、世界の反対側にありました。帯域幅が無限であっても、接続遅延によりプロセス全体の速度が低下します。ページに多数のオブジェクトがある場合は増幅されます。永続的な接続であってもリクエスト/レスポンスのレイテンシはありますが、平均して2つのソケットがある場合は減少します。1つはデータをストリーミングし、もう1つはブロックしている可能性があります。また、ルーターは、ソケットへの書き込みを許可する前に、ソケットの接続を前提とすることは決してありません。完全な往復ハンドシェイクが必要です。繰り返しますが、私は専門家であると主張していませんが、これは私がいつもそれを見た方法です。本当にクールなのは完全にASYNCプロトコルです（いいえ、完全に病気のプロトコルではありません）。

CloudFrontやCloudFlareなどの「元のプル」CDNを使用している場合は、非常に長いキープアライブが役立ちます。実際、完全に動的なコンテンツを提供している場合でも、CDNがない場合よりも高速になる可能性があります。

キープアライブが長く、基本的に各PoPがサーバーに永続的に接続している場合、ユーザーが初めてサイトにアクセスしたときに、低速のハンドシェイクではなく、ローカルのPoPで高速TCPハンドシェイクを実行できます。（光自体がファイバーを介して世界中の半分まで行くのに約100ミリ秒かかります。TCP接続を確立するには、3つのパケットをやり取りする必要があります 。SSLには3つの往復が必要です。）