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

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

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

      とか思ったりもするよ
      • by kicchy (4711) on 2006年12月20日 21時13分 (#1079146)
        >しかし10や20のタブを同時に閲覧することは出来ないから、セッション数増やさなくても
        >問題ないんじゃないかなぁ~

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

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

            それが出来て、今のソケットを浪費するやり方よりも
            スマートに並列処理を扱えるならそっちがいいね。

            # サーバ側があるユーザからのリクエスト、という切り口で複数のリクエストをまとめられるから
            # ファイルの大きさやコンテンツの種類に応じて帯域をわけたりできるのかな?
            # テキストは早く送ってくれたり、画像はヘッダ部分だけ早く送られてくるとか
            # でも、個人毎っていうことならセッションにユーザ毎のユニークIDがあればいいだけか・・・
            # やっぱ、一つの接続に限定するのってそんなに良くない気がしてきた・・・事態を複雑にしているだけだ・・・
            # ソケット接続を効率的に捌く方法を考えた方がいい気が・・・
            親コメント
          • by Stealth (5277) on 2006年12月21日 11時48分 (#1079457)

            おそらく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ではダウンロードに接続が使われていても途中に別のリクエストを割り込ませることができる仕様になるだろう…というイメージで書いたつもりなのですが説明が下手で伝わっていなかったでしょうか。
              • by Stealth (5277) on 2006年12月21日 22時26分 (#1080018)

                失礼、そのニュアンスで取れていませんでした。

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

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

                HTTP/2.0 でリクエストした場合のみそのような対応をするのはアリでしょうけど、今の世の中の Web サーバは、Apache httpd ですらリクエストを HTTP/1.0 で出しても HTTP/1.1 で返してきますから、同様に HTTP/1.1 で要求しても HTTP/2.0 で帰ってくる、とかやられるとかなり悲しい事になりそうです。

                # とはいえ、現在でもブラウザ + ダウンローダに分けていれば問題なさそうなパターンにも思えます。

                親コメント
              • > しかし、そうなると要求順序と応答順序がマッチせず 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に「コネクション減らせ」と書いた以上責任とれよ、という意味で技術的可能性を考えてみたので。
      • 画像サイトとかアップローダの画像をタブに読み込みを任せながら、取捨選択してクリックしまくるような使い方をすると、正直セッション数20や30じゃ効かないなぁ~

        とかやってたりするよ俺。
        #ごめんなさい。

日々是ハック也 -- あるハードコアバイナリアン

処理中...