アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
多くなってもよいのでは (スコア: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:多くなってもよいのでは (スコア:3, 参考になる)
RFC2616 の制限はサーバひとつについて同時2接続まで、といってるだけで、
リソースがふたつのサーバにわけて置かれているのならば 2 x 2 で同時4接続しても
まったく問題なく、あなたの挙げる前者の例は的外れです。
さらに、1サーバであっても、複数接続が最大2とはいえ禁止されているわけではないので、
>何らかの理由でa.jpgが返ってこなければ後続の b.jpgやc.jpg
はもうひとつの接続のほうが生きていればちゃんと取得できます。
>最近のブラウザはパイプライン機能を持っていますがたとえば firefox2.0等でもデフォルトではこの機能はOFFになっているぐらい
persistent connection と pipelining を混同してませんか。
前者は1回の接続で複数のリクエスト/レスポンスのやりとりをおこなうこと、
後者はレスポンスが完了しないうちに非同期に次のリクエストを出すこと。
pipelining が firefox でデフォルト off なのは事実ですが、今話題になっている件とは関係なく、
persistent connection は firefox でもデフォルト on です。