アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
多くなってもよいのでは (スコア:3, すばらしい洞察)
HTTP/1.1（RFC2080やRFC2616）が発行されたのはブロードバンドには程遠い時代のことです。
その頃の推奨セッション数が最大2だったとしてそれが現代にそのまま足枷のように残るのはいかがなものでしょうか。
たしかにむやみやたらにTCPコネクションを増やすのはサーバ負荷に対して悪影響を与えますし、お行儀が悪いと感じます。ですが近年WEBサービスを行っているサーバの数も性能も過去に比べ激増しているのでこの傾向は薄まる方向へ向いていると思います。
よほどの大人気サイトでなければ致命的に高負荷になることもないでし
Re:多くなってもよいのでは (スコア:4, 参考になる)
同時に2本接続しても使える帯域が2倍になるわけではないが、次々とリクエストを送ることで、結果的に無通信時間が減り、全体のスループットが向上する。
それなら、「同時接続」しなくても、結果が返ってくる前に次のリクエストを送出して「リクエスト送信」と「結果受信」を並行して行えるようになれば、スループットの向上は見込める。
それが
Re:多くなってもよいのでは (スコア:1, 参考になる)
欠点１：対象が同一コネクション上で取得可能なリソースである場合にのみ有効。
欠点２：送出したリクエストの順にしかレスポンスをもらえない。
モデルケースとして簡単な例で説明します。
index.html内に a.jpg b.jpg c.jpg が貼られているような簡単なページを想定します。
例１: 異なるサーバ上にa.jpgが置かれている場合
たとえばa.jpgがバナー広告だったりすれば多くの場合、異なるサーバ上にありますのでパイプラインは効力を発揮できません。バナーを取得しにいこうとしてそ
Re:多くなってもよいのでは (スコア:1)
サーバーあたりの同時接続制限なんだから、adserverのa.jpgが詰まってもmainserverにb.jpg,c.jpgのリクエストは出せるんじゃね？
例２はそのとおりかもしれんが