パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

HTTPの同時接続数はどうあるべきか?」記事へのコメント

  • それも時代の流れではないかと。
    HTTP/1.1(RFC2080やRFC2616)が発行されたのはブロードバンドには程遠い時代のことです。
    その頃の推奨セッション数が最大2だったとしてそれが現代にそのまま足枷のように残るのはいかがなものでしょうか。

    たしかにむやみやたらにTCPコネクションを増やすのはサーバ負荷に対して悪影響を与えますし、お行儀が悪いと感じます。ですが近年WEBサービスを行っているサーバの数も性能も過去に比べ激増しているのでこの傾向は薄まる方向へ向いていると思います。
    よほどの大人気サイトでなければ致命的に高負荷になることもないでし
    • なぜ「同時に複数のコネクションを張りたい」のか、その理由は、毎回接続・切断して「リクエスト→結果受け取り→リクエスト→結果受け取り」を繰り返してたら、待ち時間があるために通信利用率が減って全体でのスループットが落ちるから。
      同時に2本接続しても使える帯域が2倍になるわけではないが、次々とリクエストを送ることで、結果的に無通信時間が減り、全体のスループットが向上する。

      それなら、「同時接続」しなくても、結果が返ってくる前に次のリクエストを送出して「リクエスト送信」と「結果受信」を並行して行えるようになれば、スループットの向上は見込める。
      それが
      • by shinji.ueno (32854) on 2006年12月20日 22時55分 (#1079202)
        パイプライン化よりもTCPを複数接続した方が有利です。2つの大きな欠点があります。

        欠点1:対象が同一コネクション上で取得可能なリソースである場合にのみ有効。
        欠点2:送出したリクエストの順にしかレスポンスをもらえない。

        モデルケースとして簡単な例で説明します。
        index.html内に a.jpg b.jpg c.jpg が貼られているような簡単なページを想定します。

        例1: 異なるサーバ上にa.jpgが置かれている場合
        たとえばa.jpgがバナー広告だったりすれば多くの場合、異なるサーバ上にありますのでパイプラインは効力を発揮できません。バナーを取得しにいこうとしてそれが取り終わるまでの間、b.jpgやc.jpgに対してリクエストを出すことができないことになります。
        TCPを複数接続することを是とするならば無問題です。a.jpgがなかなか返ってこなくても先にb.jpgやc.jpgに手を出すことができます。

        例2:同一のサーバ上にすべてが置かれている場合
        最近こういう例は少ないのが実情ですがこれならパイプラインが有効に働きます。いっぺんに全リソースに対してGETリクエストすることができます。
        ただし上記の欠点2は避けられませんので、何らかの理由でa.jpgが返ってこなければ後続の b.jpgやc.jpgも返ってこない糞詰まり状態になります。サーバ上で a.jpg の置いてあるHDDが重かったり(この例から外れますが)アクセスの重いcgiだったりするとこの現象がよく起こります。
        TCPを複数接続することを是とするならば無問題です。a.jpgがなかなか返ってこなくても先にb.jpgやc.jpgを手を入れることができます。

        このようにパイプラインというのは効果を発揮するシチュエーションがかなり限定されており、あまり効率の良い技術ではありません。いっぺんにリクエストを送出した後すぐになんらかのエラーで切られたりした場合のロスも少なくありません。
        最近のブラウザはパイプライン機能を持っていますがたとえば firefox2.0等でもデフォルトではこの機能はOFFになっているぐらい推奨度は低いものなのです。
        親コメント
        • by Anonymous Coward on 2006年12月20日 23時54分 (#1079226)
          異なるサーバに複数接続することについては誰も議論してないと思いますが。
          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 です。
          親コメント
        • by Anonymous Coward on 2006年12月20日 23時54分 (#1079227)
          例1: 異なるサーバ上にa.jpgが置かれている場合

          同時接続2本のルールは同一のサーバに対するものですが。
          親コメント
        • by Anonymous Coward on 2006年12月21日 0時05分 (#1079231)
          パイプラインはそもそも同一のサーバに対して非同期に
          GET requestを発行してresponseを得るものです。

          そして、2に制限されているのは、同一サーバに対するhttp(=TCPコネクション)の数です。

          別サーバにあるコンテンツには当然TCPコネクションをもう1個作成して
          やり取りすることになります。

          したがって例示のようなケースでも問題ないでしょう。
          親コメント
        • 例1:
          サーバーあたりの同時接続制限なんだから、adserverのa.jpgが詰まってもmainserverにb.jpg,c.jpgのリクエストは出せるんじゃね?

          例2はそのとおりかもしれんが
          親コメント

私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike

処理中...