[解決済み] 現代におけるhttp keep-aliveについて

質問

httpに詳しいhaproxyの作者によると、httpはどうなんでしょう？

Keep-aliveは、CPUが100%だった時代に、サーバーのCPU使用率を減らすために発明されました。 CPUが100倍遅かった頃、サーバーの使用量を減らすために考案されました。 を削減するために考案されました。しかし、言われていないのは 持続的な接続が多くのメモリを消費することです。 多くのメモリを消費する一方で を開いたクライアント以外には使えないということです。 が使えないということです。2009年の今日、CPUは非常に安価ですが、メモリはまだ限られています。 CPUは非常に安価ですが、メモリは 数ギガバイトに制限されています。 というのが現状です。サイトがキープアライブを必要とする場合 キープアライブが必要なサイトでは、現実的な問題があります。 高負荷のサイトでは、しばしば キープアライブを無効にし、最大同時クライアント数を の同時クライアント数をサポートするためにキープアライブを無効にすることがよくあります。そのため キープアライブをしないことの本当の欠点は の待ち時間が若干長くなることです。 オブジェクトを取得するための待ち時間が若干増えることです。ブラウザは の同時接続数を2倍にします。 キープアライブでないサイトでは同時接続数を2倍にし このため

(以下 http://haproxy.1wt.eu/ )

これは他の人の経験と一致していますか？つまり、keep-alive なしで、結果は現在ほとんど目立たないのでしょうか？(おそらく、websocket などでは、非常に応答性の高いアプリのために、とにかくキープアライブの状態に関係なく接続が "オープン" 保たれることは注目に値します)。 サーバーから離れた場所にいる人や、ページを読み込む際に同じホストから多くのアーティファクトを読み込む場合、その影響は大きくなりますか？(CSS、画像、および JS のようなものは、ますますキャッシュ フレンドリーな CDN から来るようになってきていると思います）。

ご感想は？

(これがserverfault.comのことであるかどうかはわかりませんが、誰かが私にそこに移動するように言うまで、私はクロスポストしません)。

どのように解決するのですか?

この引用の著者は私なので、私が回答します :-)

大規模なサイトでは、同時接続と待ち時間の2つの大きな問題があります。同時接続は、コンテンツをダウンロードするのに時間がかかる遅いクライアントや、アイドル状態の接続によって引き起こされます。アイドル状態の接続は、キープアライブと呼ばれる、複数のオブジェクトを取得するための接続の再利用によって引き起こされ、待ち時間によってさらに増加します。クライアントがサーバーに非常に近い場所にいる場合、接続を集中的に使用することができ、ほとんどアイドル状態になることはありません。しかし、シーケンスが終了すると、誰もチャンネルをすばやく閉じることを気にせず、接続は長い間開かれたまま使用されなくなります。これが、多くの人が非常に低いキープアライブタイムアウトを使用することを提案する理由です。Apache のようないくつかのサーバでは、設定できる最小のタイムアウトは 1 秒ですが、これは高負荷を維持するにはあまりにも過大な場合があります。Apache のような汎用サーバで 20000 の同時接続は膨大で、ロードするモジュールにもよりますが 32GB から 64GB の RAM が必要で、RAM を追加してもそれ以上のことは望めないでしょう。実際には、20000 人のクライアントに対して、サーバー上で 40000 から 60000 の同時接続が発生することもあります。

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

さて、新しい接続を確立するための時間がカウントされます。遠距離にいるクライアントは、不快な遅延を経験することになります。過去には、キープアライブが無効な場合、ブラウザーは大量の同時接続を使用していました。MSIEで4、Netscapeで8という数字を覚えています。これによって、オブジェクトごとの平均待ち時間は、本当にそのくらいに分割されていたのでしょう。なぜなら、そうすることでリモートサーバーの負荷がさらに増加し、ブラウザがインターネットのインフラを保護することになるからです。

これは、最近のブラウザでは、キープアライブでないサービスをキープアライブなものと同じくらい反応させるのが難しいということを意味します。また、一部のブラウザ (例: Opera) では、パイプライン処理を使用しようとするヒューリスティックを使用しています。パイプライン化は、応答を待たずに複数のリクエストを送ることで待ち時間をほとんどなくすことができるため、キープアライブを効率的に利用することができる方法です。100枚の小さな写真を含むページで試したところ、最初のアクセスはキープアライブなしの約2倍の速さですが、次のアクセスは約8倍の速さになっています。

理想的には、フェッチしたオブジェクト間の接続を維持し、ページが完了したらすぐに接続を解除するように、ブラウザで調整可能なものがあるべきと思います。しかし、残念ながらそれは見られません。

このため、フロントサイドに Apache などの汎用サーバーをインストールする必要があり、大量のクライアントをサポートする必要がある一部のサイトでは、一般にキープアライブを無効にする必要があります。また、ブラウザに接続数を増やさせるために、ダウンロードを並列化できるように複数のドメイン名を使用することもあります。特にSSLを多用するサイトでは、ラウンドトリップが1つ増えるため、接続設定がさらに高くなることが問題です。

最近よく見られるのは、そのようなサイトが、数万から数十万の同時接続を問題なく処理できる haproxy や nginx などの軽いフロントエンドをインストールし、クライアント側で keep-alive を有効にし、Apache 側ではそれを無効にする、というものです。こちら側では、接続を確立するためのコストは、CPUの面ではほぼゼロ、時間の面では全く気にならない。クライアント側ではタイムアウトの少ないキープアライブによる低遅延、サーバー側では少ない接続数という、両者の良いとこ取りができるわけです。誰もがハッピーになれます:-)

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