ねえ、私はこの引用の著者なので、返答します:-)
大規模なサイトには、同時接続と遅延という2つの大きな問題があります。同時接続は、コンテンツのダウンロードに時間がかかる低速のクライアントと、アイドル状態の接続状態が原因で発生します。これらのアイドル状態の接続状態は、キープアライブと呼ばれる複数のオブジェクトをフェッチするための接続の再利用によって発生します。これは、遅延によってさらに増加します。クライアントがサーバーに非常に近い場合、接続を集中的に使用して、アイドル状態になることはほとんどありません。ただし、シーケンスが終了すると、誰もチャネルをすばやく閉じることを気にせず、接続は開いたままで、長期間使用されません。これが、多くの人が非常に低いキープアライブタイムアウトの使用を提案する理由です。Apacheなどの一部のサーバーでは、設定できる最小のタイムアウトは1秒であり、多くの場合、高負荷に耐えるには長すぎます。目の前に20000のクライアントがあり、それらが平均して毎秒1つのオブジェクトをフェッチする場合、それらの20000の接続が永続的に確立されます。Apacheのような汎用サーバーでの20000の同時接続は巨大であり、ロードされるモジュールに応じて32〜64 GBのRAMが必要になり、RAMを追加してもそれほど高くなることはおそらく期待できません。実際には、20000クライアントの場合、ブラウザにフェッチするオブジェクトが多数ある場合、ブラウザは2〜3の接続を設定しようとするため、サーバー上に40000〜60000の同時接続が表示されることもあります。また、RAMを追加しても、これ以上高くなることはおそらく期待できません。実際には、20000クライアントの場合、ブラウザにフェッチするオブジェクトが多数ある場合、ブラウザは2〜3の接続を設定しようとするため、サーバー上に40000〜60000の同時接続が表示されることもあります。また、RAMを追加しても、これ以上高くなることはおそらく期待できません。実際には、20000クライアントの場合、ブラウザにフェッチするオブジェクトが多数ある場合、ブラウザは2〜3の接続を設定しようとするため、サーバー上に40000〜60000の同時接続が表示されることもあります。
各オブジェクトの後で接続を閉じると、同時接続の数が大幅に減少します。実際、オブジェクト間の時間までにオブジェクトをダウンロードする平均時間に対応する係数で低下します。オブジェクト（ミニチュア写真、ボタンなど）をダウンロードするのに50ミリ秒必要で、上記のように1秒あたり平均1つのオブジェクトをダウンロードする場合、クライアントあたりの接続数は0.05、つまり1000になります。 20000クライアントの同時接続。
これで、新しい接続を確立する時間が重要になります。遠く離れたクライアントでは、不快な遅延が発生します。以前は、キープアライブが無効になっていると、ブラウザは大量の同時接続を使用していました。MSIEでは4、Netscapeでは8の数字を覚えています。これは、実際には、オブジェクトごとの平均レイテンシをその分で割ったものになります。キープアライブがどこにでも存在するようになった今、リモートサーバーの負荷がさらに増加し、ブラウザがインターネットのインフラストラクチャの保護を処理するため、それほど多くの数は見られなくなりました。
これは、今日のブラウザでは、非キープアライブサービスをキープアライブサービスと同じくらい応答性の高いものにするのが難しいことを意味します。また、一部のブラウザ（例：Opera）は、ヒューリスティックを使用してパイプラインを使用しようとします。パイプライン処理は、応答を待たずに複数の要求を送信することでレイテンシーをほぼ排除するため、keep-aliveを使用する効率的な方法です。100枚の小さな写真があるページで試してみましたが、最初のアクセスはキープアライブなしの約2倍の速さですが、応答が非常に小さいため遅延のみがカウントされるため、次のアクセスは約8倍の速さです（ 「304」応答）。
理想的には、ブラウザにいくつかの調整機能を設定して、フェッチされたオブジェクト間の接続を維持し、ページが完成したらすぐに削除する必要があると思います。しかし、残念ながらそれは見られません。
このため、Apacheなどの汎用サーバーをフロントサイドにインストールする必要があり、大量のクライアントをサポートする必要がある一部のサイトでは、通常、キープアライブを無効にする必要があります。また、ブラウザに接続数を増やすように強制するために、ダウンロードを並列化できるように複数のドメイン名を使用します。SSLを集中的に使用しているサイトでは、ラウンドトリップが1回追加されるため、接続設定がさらに高くなるため、特に問題が発生します。
最近より一般的に観察されているのは、そのようなサイトはhaproxyやnginxなどの軽いフロントエンドをインストールすることを好むということです。これらは数万から数十万の同時接続を問題なく処理し、クライアント側でキープアライブを有効にし、 Apache側。この面では、接続を確立するためのコストはCPUの観点からはほとんどゼロであり、時間の観点からはまったく目立ちません。このようにして、これは両方の長所を提供します。クライアント側でのタイムアウトが非常に少なく、サーバー側での接続数が少ない、維持による待ち時間が短いことです。みんなが幸せだ ：-）
一部の商用製品は、フロントロードバランサーとサーバー間の接続を再利用し、それらを介してすべてのクライアント接続を多重化することにより、これをさらに改善します。サーバーがLBに近い場合、ゲインは以前のソリューションよりもそれほど高くはありませんが、複数のユーザー間で予期しない接続の共有が原因でユーザー間でセッションが交差するリスクがないように、アプリケーションを調整する必要があります。 。理論的には、これは決して起こらないはずです。現実は大きく異なります:-)