アカウント名:
パスワード:
例１: 異なるサーバ上にa.jpgが置かれている場合
より多くのコメントがこの議論にあるかもしれませんが、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がバナー広告だったりすれば多くの場合、異なるサーバ上にありますのでパイプラインは効力を発揮できません。バナーを取得しにいこうとしてそれが取り終わるまでの間、b.jpgやc.jpgに対してリクエストを出すことができないことになります。
TCPを複数接続することを是とするならば無問題です。a.jpgがなかなか返ってこなくても先にb.jpgやc.jpgに手を出すことができます。
例２：同一のサーバ上にすべてが置かれている場合
最近こういう例は少ないのが実情ですがこれならパイプラインが有効に働きます。いっぺんに全リソースに対してGETリクエストすることができます。
ただし上記の欠点２は避けられませんので、何らかの理由でa.jpgが返ってこなければ後続の b.jpgやc.jpgも返ってこない糞詰まり状態になります。サーバ上で a.jpg の置いてあるHDDが重かったり（この例から外れますが）アクセスの重いcgiだったりするとこの現象がよく起こります。
TCPを複数接続することを是とするならば無問題です。a.jpgがなかなか返ってこなくても先にb.jpgやc.jpgを手を入れることができます。
このようにパイプラインというのは効果を発揮するシチュエーションがかなり限定されており、あまり効率の良い技術ではありません。いっぺんにリクエストを送出した後すぐになんらかのエラーで切られたりした場合のロスも少なくありません。
最近のブラウザはパイプライン機能を持っていますがたとえば firefox2.0等でもデフォルトではこの機能はOFFになっているぐらい推奨度は低いものなのです。
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 です。
Re:多くなってもよいのでは (スコア:1, 参考になる)
同時接続2本のルールは同一のサーバに対するものですが。
Re:多くなってもよいのでは (スコア:1, 参考になる)
GET requestを発行してresponseを得るものです。
そして、2に制限されているのは、同一サーバに対するhttp(=TCPコネクション)の数です。
別サーバにあるコンテンツには当然TCPコネクションをもう1個作成して
やり取りすることになります。
したがって例示のようなケースでも問題ないでしょう。
Re:多くなってもよいのでは (スコア:1)
サーバーあたりの同時接続制限なんだから、adserverのa.jpgが詰まってもmainserverにb.jpg,c.jpgのリクエストは出せるんじゃね？
例２はそのとおりかもしれんが