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

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

  • TCP の congestion control みたいにちゃんと理論の裏付けのあるルールならわかるけど、なんとなく 2 とか 4 とか言われてもなあ。
    10 も 20 もタブ同時に開いて使うのが普通の時代にはそぐわない制限。他の人が書いてるようにサーバー側で制御すればいいし、エロサイトとかではそういう技術も確立されてるように思う。
    • しかし10や20のタブを同時に閲覧することは出来ないから、セッション数増やさなくても
      問題ないんじゃないかなぁ~

      とか思ったりもするよ
      • >しかし10や20のタブを同時に閲覧することは出来ないから、セッション数増やさなくても
        >問題ないんじゃないかなぁ~

        10や20の画像が含まれてるページはあるんじゃないですかね?

        # サーバの性能如何では、むしろ接続(転送の)持続時間を短くできて
        # そんなに負荷をあげずに快適度を上げれることも
        # あるんじゃないかなぁとは思うの
        • by Anonymous Coward
          > 10や20の画像が含まれてるページはあるんじゃないですかね?
          そのためのpersistent connectionです。RFC 2616は理由もなく接続数を(それまで慣習的に使われていた4から)減らせと言っているわけではありません。
          まあ現実問題として巨大なファイルを2つダウンロードすると、もうそのサーバの別のページを見ようとしても接続できないので困ったりするわけですが。おそらくHTTP/2.0では1つの接続に複数のリクエストを並列に織り交ぜられるような仕様にする予定なのでしょう。
          • おそらくHTTP/2.0では1つの接続に複数のリクエストを並列に織り交ぜられるような仕様にする予定なのでしょう。

            それが HTTP/1.1 Keep Alive + Pipelining なんですが。

            • > それが HTTP/1.1 Keep Alive + Pipelining なんですが。

              失礼ですが元コメントはちゃんと読まれましたか?
              HTTP/1.1 Keep Alive + Pipeliningでは対応できないケースを

              > まあ現実問題として巨大なファイルを2つダウンロードすると、もうそのサーバの別のページを見ようとしても接続できないので困ったりする

              のようにわざわざ例を挙げて説明したのですが。
              HTTP/1.1のPipeliningはリクエストとレスポンスの順番を逆転させることはできないので、先の2つのダウンロードが終了しない限り次のリクエストは一切送れません。厳密には先行して送ることはできるでしょうけどダウンロードが完了するまでレスポンスを受け取れないのでユーザーの体感的には意味がありません。

              そこでHTTP/2.0ではダウンロードに接続が使われていても途中に別のリクエストを割り込ませることができる仕様になるだろう…というイメージで書いたつもりなのですが説明が下手で伝わっていなかったでしょうか。
              • 失礼、そのニュアンスで取れていませんでした。

                しかし、そうなると要求順序と応答順序がマッチせず HTTP/1.0 や HTTP/1.1 との互換性がなくなってしまい、HTTP/2.0 対応クライアントでのみ通信が可能となる事となります。要求と応答の順序が同一であることが HTTP/1.0 や HTTP/1.1 では保証されていますから。

                応答ヘッダに File: /index.html とか乗せるにしても、おそらくは 80 番以外のポートで通信するなどしないと Web を混乱させる要因ともなってしまいかねないため、互換性を持ったプロトコルで 80 番を使い続けるという点においては難しいような気がします

              • by Anonymous Coward on 2006年12月21日 22時36分 (#1080026)
                > しかし、そうなると要求順序と応答順序がマッチせず HTTP/1.0 や HTTP/1.1 との互換性がなくなってしまい、
                だからHTTP/1.2ではなくHTTP/2.0なのです。詳しくはHTTPのバージョン番号に関するRFCを調べてみてください。某Firefoxみたいにマーケティング上の都合とかその場の気分でバージョン番号を思いついたわけではありません。
                > HTTP/2.0 対応クライアントでのみ通信が可能となる事となります。
                あとUpgrade:ヘッダフィールドについても。
                親コメント
              • by Stealth (5277) on 2006年12月22日 11時08分 (#1080334)

                読んでみましたが、大きめなファイルのダウンロード時にセッション数に空きがなくなるから、といった理由のためにさらにこれ以上 HTTP を拡張して複雑化させていくよりは、素直に BitTorrent などに任せる方向の方が良さそうに思えました。

                他にも実装した方がいいと思われる理由があれば別ですが、そうでもないならさほどメリットがあるとは感じられませんが、どうでしょうか。

                # なんでも HTTP でやってしまおうという方向性は好きではないので。

                親コメント
              • > さほどメリットがあるとは感じられませんが、
                おそらくそれこそが今に至るまでHTTP NGが放置プレイにされている理由だと思います。
                ただ、RFC 2616に「コネクション減らせ」と書いた以上責任とれよ、という意味で技術的可能性を考えてみたので。

皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー

処理中...