パスワードを忘れた? アカウント作成
14213 story

HTTPの同時接続数はどうあるべきか? 175

ストーリー by kazekiri
そいや4ってどこからきたのだろう 部門より

Anonymous Coward 曰く、

Web屋のネタ帳に百式の中の人、RFC違反はもちろんWebサーバ運営者の迷惑をまるで考えない設定を 推奨するの巻というエントリがある。百式の姉妹サイトであるpop*popにてFirefoxとIEを高速化するための動画チュートリアルという記事があったのだが、ようはこの記事ではFirefoxとIE(Windowsのレジストリ)の設定を変えて、HTTPの同時接続数を10にまで上げてしまうということを推奨していたため、それに対して反対意見を述べているのである。

HTTPの同時接続数はHTTP 1.0では特に制限はないが、通常どのブラウザも4までにしている。 HTTP 1.1では2を上限とすることが推奨されている。TCPコネクションの数を増やせば、まあ ユーザからは一見快適になるかもしれないが、それが常態化すればサーバ側からすればたまったものではないことは確か。その意を汲んでpop*popのほうでは、記事が訂正されている。

ただ、記憶を遡れば、Netscapeが4本もコネクションを張る!と激怒していた頃はもはや前世紀なのだなぁと思い出すと、RFCによる同時接続数の コンセンサスも現在では古い感覚なのだろうか? まあ、けど10本も接続されたら、DoSアタックだと見なされるところも多いと思いますが。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 利己的に増やさない (スコア:5, すばらしい洞察)

    by bero (5057) on 2006年12月20日 19時48分 (#1079090) 日記
    行列や車の割り込みと同じです。
    自分一人だけ割り込みできたら早くなりますが、皆が割り込みするようになったら、混雑してむしろ遅くなります。海外旅行等で経験した人もいると思います。
    なんか囚人のジレンマに似てますね。

    また、サイトによってはサーバ側で同時接続数を制限していることがあります。
    IEやFirefoxの実装は知りませんが、昔ダウンロードソフトの類を使ったとき、(制限で)接続失敗してるのに何度も接続しようとしてかえって遅くなってました。
    ダウンロードが主のサイトでは制限していることが多いので、どうでもいいサイトで若干速くなっても、いざ大きいファイルをダウンロードするときに遅くなったのではむしろ損です。

    以上の理由から、サーバ運営者の迷惑をまるで考えないで利己的に考えても増やさないほうが良いと思います。
    • by Anonymous Coward on 2006年12月21日 1時20分 (#1079269)
      今から4年以上前に某オンラインゲームのクライアント配布の1次ミラーをしたとき、国内外から猛烈な多重ダウンローダーによる"攻撃"を受けてサーバがハングアップしかけたことがあります。
      当時サーバ管理者としてデビューして一年ちょっとでしたが、Apacheのプロセスが大量に出来てしまい管理のためにリモートログインすらままならず、吃驚したことがあります。
      # 対策として(FreeBSD4.X系でしたので)maxusersを増やしてカーネル再コンパイルをして、ApacheのmoduleによりIPアドレス1個に対して1コネクションしかはれないように設定しました。
      対策後、順調に収まっていったんですがmoduleがCPUをコネクション接続瞬間毎に喰う現象が見られ結局対策を見いだせないままマシンパワーを挙げるという力業でしのいだことがあります。

      私としては、接続コネクションを増やした分早く転送が終われば基本的には良いと思います。ですが、遅い回線からのアクセスは困りますね。
      転送速度が遅くてプロセスを解放してくれるまでに時間がかかるのは、サーバ管理者サイドからすると余り好ましくない人だと思います。
      かといって、無下にコネクションをぶちっと一定速度以下は切断するようなこともできないわけですし…。

      10コネクションはろうともそれが1頁あたり0.5秒以下で全転送が転送が終わるのではれば複数同時コネクションありかなと思います。
      正し、最近多いメニューなどのデザイン性を高めるために画像を細切れにしてきれいに表示しようとしているサイトを抱えているサーバにとっては、
      サーバへのアクセス数を更に増やすことになるので、個人的にはそっちからも何らかの対策を考えて欲しい所です。

      クライアントの設定も悪いけど、無駄に画像を配置しまくってかっこよくなったと満足している作成者側にも見直して欲しい所です。

      # Web2.0全盛になると更にサーバへの負担がより増える気が…。
      親コメント
    • ダウンロードが主のサイトでは制限していることが多いので、どうでもいいサイトで若干速くなっても、いざ大きいファイルをダウンロードするときに遅くなったのではむしろ損です。

      httpって一つのファイルに複数同時接続しないよね。大きいファイル一つ二つなら同時接続数は関係ないと思う。

      親コメント
  • SHOULD NOT (スコア:5, 参考になる)

    by superfox (31908) on 2006年12月20日 22時26分 (#1079187)
    ぐぐって最初に出てきた「RFC文書中で要求レベルを表現するために用いられるキーワードの使用法について」 [asahi-net.or.jp]を見ると、以下のように定義されています。
     
    4. SHOULD NOT
     
    「SHOULD NOT」あるいは「NOT RECOMMENDED」は、ある特定の行動が望ましいかまたは有意義なのだと言いうる妥当な理由が存在するような状況下で、全ての意味が理解され、また慎重に判断された場合、この語で否定されている行動を行っても構わないということになります。
     
    SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
    個人的にこの手の文書における should はかなり強い意味だと思っているので、「構わない」という訳には抵抗があります。「有用な場合もあるかもしれないが、全ての意味が理解され、また慎重に判断されない限り、この語の用いられている機能の一部でも実装してはならない」くらいかな。

    # "You shall die!" → 「殺してやる!」みたいな :-)
  • Operaでは、 (スコア:4, 参考になる)

    by ZYT (14695) on 2006年12月20日 18時25分 (#1079043) 日記
    サーバへの最大接続数8(標準)
    最大総接続数20(標準)
    となっている。
    ちなみに、どちらも128まで増やせる。
    @9.10で調べてみた。
    さすが世界最速Opera(?)

    そういえば、昔のOpera(4くらいかな?)には、Webページの定期更新(nSec毎にGet requestする)があったなぁ。
    友人のアクセスカウンタをぶん回した遠い思い出(笑
    • by miyabi9821 (29975) on 2006年12月20日 18時37分 (#1079050)
      IEでは確か標準が1.0が4、1.1が2だったと思うのですが、
      これだとファイルを複数ダウンロードしようとすると、
      ファイルの保存ダイアログがすぐ出なくなって不便なので、窓の手で8に上げてました。
      IE7でどうなってるかはわかりませんが、とりあえずOS入れ直すと8にします。

      まぁ、閲覧者から見れば「サーバの性能が」とか知らんがな。
      何で相手の資源のことまで考えてWeb見なきゃいけないんだよ。という感じでしょうかね
      # サーバ運営してて、アレな発言だけどID。制限されるの嫌いなんだもの
      親コメント
      • Re:IE (スコア:1, 興味深い)

        by Anonymous Coward on 2006年12月20日 20時50分 (#1079127)
        「窓の手」以外にも,Windows高速化をうたうツールには最大接続数10ぐらいに上げるものがいろいろありますね
        親コメント
    • 言いたいことを先に言われてしまいました・・・
      #Operaユーザーならトピックアイコンが無いことに文句を言って下さいよ。
      ということはおいておいて、

      Casheに強いプロクシを通すことでコンテンツサーバーの負荷を減らそうな気がするんですが、どうでしょ?
      実際のところhttp://www.cybersyndrome.net/ [cybersyndrome.net]とかのリスト眺めててもいまいちどのプロクシが信用できるのか分からないです。
      こちらが送信したクエリまでキャッシュするような「悪意のあるプロクシ」って都市伝説ですか?

      安心して利用できるプロクシリストみたいのがあれば
      サイトごとに特定のプロクシを経由するようにお願いしてみるとか啓蒙のしようがあると思うんですがねぇ。

      プロクシって2chで手の込んだ自演するためにしか使われていないイメージ。
      --
      Youthの半分はバファリンでできています。
      親コメント
      • 動的なコンテンツにアクセスが集中するのが最大の問題であって、
        cache できるような静的なコンテンツは、アクセスが集中しても全然問題にならないです。

        しかし、最近は blog だの wiki だのといったほとんど静的なのに動的に生成してるコンテンツが流行ってるから困りもの…
        画像投稿掲示板的なcgiシステムを動かしているのですが、
        たま~に「ウェブ高速化ツール」らしきものから、複数のリンクをまとめてアクセスしてきたりしてひどいことになります。

        一応、load average が 一定値を超えるとアクセスを拒否するようにしてるのですが、
        load average が上がるのはアクセスが集中した後なので、ほとんど無力というか
        ひどいときはload average が 50 を超えたりすることもたまに…

        静的コンテンツの方は、少々アクセスが集中しても問題ないので、対応が難しいところです。

        #というわけで、自前の日記に毛が生えたようなエセblogシステムでは、ほとんどのコンテンツは html に吐き出すようにしてます。
        #リクエストの量に比べて、内容が更新される頻度はそれほど多くないのに、
        #毎回リクエストに応じて生成するのがCPU資源が「もったいない」ので好きになれません。
        #それが、Web2.0 いうものなのかもしれませんが…
        親コメント
        • このトピックを下まで読んできましたが方向性は間違っていないような気がしてきました。

          HTTP接続数をどう設定しようと、読み込むのはブラウザのキャッシュに見当たらないファイルか、そろそろ更新されているかも知れないファイルだけですよね?
          下の方でFireFox+FasterFoxで先読みを有効にした場合はローラー作戦で潰される、という意見もありましたが、
          FasterFoxもキャッシュサイズを拡張する設定が付いているのでそれほど迷惑ではないかと。
          Operaでもドキュメントと画像に対して更新の確認を何時間ごとにチェックするか選べますし、キャッシュサイズも最大400MBまで拡張できます。
          #デフォルトは療法5時間ですので画像だけ24時間に直してみたり、
          #RSSのデフォルト3時間は絶対やりすぎだろう、と思い登録するたびに直したりしてますが。
          しかし、ブラウザ終了時やシャットダウン時にキャッシュを消したいユーザーも沢山いるでしょうから根本的な解決策としては外部に複数のユーザーでキャッシュを共有することであると思われます。

          動的コンテンツの中にstyle属性やjavascriptソースが埋まっているのは論外として、
          CSSやJSは外部ファイル化して(X)HTML自体は小さなサイズを維持する前提では
          ・閲覧者が一定のプロクシを利用する(例えばプロバイダ提供で)
          ・管理者もプロクシを用意する、もしくは一定のプロクシを利用するようにお願いする
          のどちらかで画像と静的コンテンツに対するリクエストはプロクシのキャッシュまでで止まることになるでしょう?
          そうすると、たとえブラウザが複数リクエストを出していようとも、サーバーに届くリクエストは本当に動的なコンテンツのみに絞られるのでは?

          Operaではずいぶん前からプロトコルごとにプロクシを設定できるんですが、使ってません。
          プロクシサーバーのIPアドレスがコロコロ変わってしまっていちいち設定が必要なのも問題でしたし、
          Mixiみたいに入り口だけhttpsで後はhttp、みたいなサイトだとうっかり余計なモノまで読み取られないか不安になります。

          必要なのは、信用できて安定してるプロクシサーバーでは?

          と、ここまで書いておいて正直自分が無知なだけだと思っているんですがね、
          僕より無知な人は沢山いるでしょうから詳しい人に真っ当な補足をお願いしたいです。
          --
          Youthの半分はバファリンでできています。
          親コメント
      • 悪意のある可能性のあるプロキシかどうかということは、
        結局情報が漏れてみなきゃわからない話ですね。

        予防策としては、串リストとか称されるリストに載ってるような
        どこの誰が管理してるのかも怪しいプロキシを使わない。
        ということくらいしか挙げられないですよね。

        プロバイダが用意してるものとか、自前で用意してるものくらいですかね。
        まぁ、串リストなるものを使う人たちの目的は「匿名性」の確保なのだろうから、的外れなんでしょうけど。

        所詮、ローカルネットワークの中に1台サーバマシンを用意してプロキシを設置すれば、
        キャッシュ効果で高速化するかなぁとか、その程度にしか使えないのです。

        高速化目当てなら、airproxyとかAirEdge向けのプロキシを動かしてみるというのも手でしょうね。
        画像を圧縮してくれたりするので転送速度は格段に上がるでしょう(ただし不可逆なので荒くなる)。
        親コメント
  • by Anonymous Coward on 2006年12月20日 21時15分 (#1079148)
    ユーザにRFCに違反するような使い方を許可するソフトウエアのほうだと思うんだけど。
    (RFCに従う必要があるかどうかは別問題ね)

    普通の人はRFCなんて知らないし、知ってる必要も無いでしょ。
    そういう普通の人が「同時接続数増やしたら速くなるんだぜ」と自慢しても、それは責めたりするべきではないと思う。普通の人なんだから、設定弄るだけで速くなるんだったらやっちゃうよね。
  • by shinji.ueno (32854) on 2006年12月20日 21時28分 (#1079156)
    それも時代の流れではないかと。
    HTTP/1.1(RFC2080やRFC2616)が発行されたのはブロードバンドには程遠い時代のことです。
    その頃の推奨セッション数が最大2だったとしてそれが現代にそのまま足枷のように残るのはいかがなものでしょうか。

    たしかにむやみやたらにTCPコネクションを増やすのはサーバ負荷に対して悪影響を与えますし、お行儀が悪いと感じます。ですが近年WEBサービスを行っているサーバの数も性能も過去に比べ激増しているのでこの傾向は薄まる方向へ向いていると思います。
    よほどの大人気サイトでなければ致命的に高負荷になることもないでしょう。大人気サイトであればロードバランサやクラスタリングなどでいくらでも回避の手を打つことが可能です。
    巨大なトラフィックが発生する動画ストリーミングなどはクライアント・サーバ型ではなくP2P等の技術で実現されたり、何百台も使ったクラスタリングをする方向にあってサーバサービスの分散強化傾向がどんどん強まっています。

    いわゆるWEB2.0?以降の現代はサーバ側のサービス供給力を競う時代でもあり、クライアントはAdSenseを見てくれたり商品を購入するお客様という考え方のもとに勢いよく進化しています。
    したがって今やクライアントに対する規制を論ずるのは進化に対して逆方向だと思うのです。
    クライアントがサーバに高性能を求め、それに応えられるサーバが勝ち組として生き残れる、そんな競争原理が進化の原動力なのではないでしょうか。
    • by taka2 (14791) on 2006年12月20日 22時10分 (#1079175) ホームページ 日記
      なぜ「同時に複数のコネクションを張りたい」のか、その理由は、毎回接続・切断して「リクエスト→結果受け取り→リクエスト→結果受け取り」を繰り返してたら、待ち時間があるために通信利用率が減って全体でのスループットが落ちるから。
      同時に2本接続しても使える帯域が2倍になるわけではないが、次々とリクエストを送ることで、結果的に無通信時間が減り、全体のスループットが向上する。

      それなら、「同時接続」しなくても、結果が返ってくる前に次のリクエストを送出して「リクエスト送信」と「結果受信」を並行して行えるようになれば、スループットの向上は見込める。
      それがパイプライン化 [mozilla-japan.org]で、同時接続するよりも効率が良い。
      HTTP/1.1 ではサーバ側でパイプラインに対応することが必須だから、HTTP/1.1 なら、同時接続数は少なくても(基本的に)問題ありません。

      以上、ページ表示に必要なデータがすべて揃うまでの時間を考えた「スループット」についての考察です。
      ロード途中でもページを表示できるようなブラウザだと、その途中での「レイテンシ」については同時接続できた方がうれしい場合が多そうです。

      大きな html と(html中で指定された)小さな css を読むときに、html が全部届いてから css を受け取るよりは、同時接続とかで先にcssを貰った方がありがたそうだし。
      親コメント
      • by Anonymous Coward on 2006年12月21日 9時18分 (#1079325)
        >なぜ「同時に複数のコネクションを張りたい」のか、その理由は、毎回接続・切断して
        >「リクエスト?結果受け取り?リクエスト?結果受け取り」を繰り返してたら、待ち時間が
        >あるために通信利用率が減って全体でのスループットが落ちるから。

        誤解を招く、というか説明が少し足りないようですね。
        「待ち時間」がどのような待ち時間なのかが問題です。

        毎回接続・切断するのはHTTP/1.0までの話で、現在主流のHTTP/1.1ではKeepAliveに
        よって接続を維持したまま複数のデータの取得が出来ますね。

        同時セッション数を増やすことでスループットが上がるのは、アプリケーション層の
        HTTPのレベルよりも、むしろトランスポート層のTCP/IPレベルですね。
        TCP/IPではラウンドトリップタイム(RTT)によって実際の帯域以下にスループットが
        下がってしまいます。
        「送信して受信確認が来たら次の送信」というようにするので、受信確認のための
        待ち時間が大きく響くのです。RTTが大きくなると極端に低下します。

        関東に住んでいる人たちは大抵のサーバに距離的に近いため意識する機会が少なく、
        忘れがちな話ですが、地方に行くと結構問題になります。

        >同時に2本接続しても使える帯域が2倍になるわけではないが、次々とリクエストを
        >送ることで、結果的に無通信時間が減り、全体のスループットが向上する。

        無通信時間が減ってスループットが上がるというより、使用できる帯域は単純に
        2倍になります。もちろん使用回線の帯域が上限となりますが。
        大きなRTTによるスループットの低下では、100Mbpsの帯域があっても20Mbpsほどしか
        使えないケースもあります。その場合に2セッション同時に通信すれば、40Mbpsくらい
        使えるようになります。

        この場合サーバ側で問題となるのは、遅いコネクションを多数張られるようになることです。
        サーバとしてはさっさと通信を終えて他のコネクションの相手をしたいのに、遅い接続が
        大量に滞留すると同時セッションが限界に達してしまい、新たに接続しようとしても
        待たされることになってしまいます。

        かつて、たった9600bpsしかないi-modeの通信が急増したとき、サーバ管理者、特に
        バーチャルホストサーバの管理者は戦々恐々でした。
        i-modeコンテンツがあると、遅いi-mode向け通信だけでHTTPのセッション全てが埋まり、
        他のPC向けの通信がほとんどできなくなる現象が多発したからです。
        これは「大容量の帯域」であっても関係なく発生しました。
        現在ではドコモ側もPROXYを改良して対処したようですが。

        3車線の高速道路があって、3車線とも併走すれば通行できる車両数は3倍です。
        でも、やはり出せる速度に応じて速い車両は右側を走るように分けたほうが
        流れは良くなりますよね。
        たまに遅い車が3車線ともいて、同じ速度で走っているために渋滞を引き起こす
        ことがありますよね。

        スーパーのレジでも「大量に買う人(カート)専用」「少量買う人(カゴ)専用」と
        分けられているところがありますね。
        短時間で処理できる客は短時間で通過させたほうが効率が良いのです。

        だから結論としては、「同時セッションを多くしてもいいけど、限度はある。
        やりすぎないようにほどほどに」といいたいです。
        現実的には、IE, Firefoxの規定値のままが「ほどほど」だと思います。

        親コメント
    •  むしろ高速回線当たり前の今日だからこそ節度は守るべきではないか、とも思います。

       ダイヤルアップが当たり前・せいぜいがISDNの128kbpsだった時代には、末端のユーザが最大速度でアクセスしてもその負荷はたかがしれていました。
      …が、その感覚で、1Mbpsは普通に出るADSLや実行でも数十Mbps出る光回線からアクセスされるとたまったものではありません。

       GetHTMLWの旧バージョンが、数アクセス/秒の頻度で根こそぎダウンロードしていたログに出くわして、しみじみそう思いました。昔なら、同時接続数4・ノーウェイトでもたいした問題はなかったのですけどね。

       なお、現行バージョンのでは
      ★★ GetHTML Ver.4.13, GetHTMLW Ver.7.13 より、★★

      (1) 同一サーバ(ホスト)への同時取得数が 1 に固定されました
      (2) 同一サーバ(ホスト)への連続取得に対し、1秒の wait をデフォルトで入れました

          上記は、ブロードバンド化に伴う Web サーバへの負荷を軽減する為の措置です。
      となっています。

      >大人気サイトであればロードバランサやクラスタリングなどでいくらでも回避の手を打つことが可能です。

       普段から負荷がかかるサイトならばともかく、突如負荷がかかる場合があります。
       たとえば、/.Jのコメントからリンクを張るだけでもだいたい1アクセス/分ぐらいです。タレコミ本文からだったら、桁が変わるでしょう。「カトゆー家断絶」からのリンクの場合、ピーク時に2アクセス/分ぐらいでした。おそらく、ページの内容と読者層が重ならなかったためにこの程度のアクセスで済んだと思われますが、場合によっては桁が2つほど変わることも十分あり得るでしょう。

      >クライアントがサーバに高性能を求め、それに応えられるサーバが勝ち組として生き残れる、そんな競争原理が進化の原動力なのではないでしょうか。

       ADSL回線にぶら下がったPen3/600MHzのうちのWebサーバなんぞは最底辺でしょうが、そこまで酷くなくても、高速回線にぶら下がった高性能マシンだけがWebサーバでは無いと思うのです。

       とはいえ、#1079136 [srad.jp]の
      >3本以上のコネクション張れないように! → 技術的に解決可能
      というのもごもっともで、これからはサーバ側が、高速回線当たり前の世の中に対応していくことが必要なのかもしれません。
      親コメント
  • pipelining使えよ (スコア:3, 参考になる)

    by koshian (6999) on 2006年12月20日 21時59分 (#1079169) ホームページ 日記
    TCP接続をあんまりたくさんopen/closeすると負荷かかるから、2個にしてpipelining使おうよってのがHTTP/1.1なわけでしょ。
    IEはpipeliningを実装してるのかどうかも調べてませんけど、Firefoxではデフォルトオフとはいえ実装されてます。
    なのでこれをオンにするだけで相当速くなるんですよ、Firefox。
    他のチューニングなんてオマケみたいなもん。

    Operaはよくしらないけど、誰かが「デフォルト8になってるのはpipeliningの最大リクエスト数」って言ってました。
    なのでうちのFirefoxもそれに合わせてmaxrequestsを8にしてあります。

    まあ、あんまし最大接続数増やしていい気になってると、mod_limitipconnみたいなのでガンガン対策されて、NAPTの内側で見てる人が503食らいまくる世界になるわけです。
    ホントに迷惑被るのはサーバ管理者じゃなくてこういう人たちね。
    • Re:pipelining使えよ (スコア:3, 参考になる)

      by ruto (17678) on 2006年12月20日 22時24分 (#1079184) 日記
      もしかして: persistent connection

      persistent connection:
      クラ: 接続したいよ。
      サバ: OK。
      クラ: ファイル1ちょうだい。
      サバ: はいよ(ファイル1)。
      クラ: ファイル2ちょうだい、終わったら閉じていいよ。
      サバ: はいよ(ファイル2)。(コネクションを閉じる)

      pipelining:
      クラ: 接続したいよ。
      サバ: OK。
      クラ: ファイル1ちょうだい。ファイル2ちょうだい、終わったら閉じていいよ。
      サバ: はいよ(ファイル1)。はいよ(ファイル2)。(コネクションを閉じる)

      どちらもコネクションはいちいち閉じません。
      そして、Firefoxはデフォルトでもちゃんとpersistent connectionを使います。
      親コメント
  • サーバ側に実装してしまうほうが生産的だと思う。例えば応答で「5xx ちょぉ待てや、コネクション張りすぎ」を定義してみるとか。同一ホストからの接続を数えなきゃならんけど。
    # 5xx:500番台は一時的な失敗。
  • Proxy 経由の場合 (スコア:2, 参考になる)

    by STRing (14928) on 2006年12月20日 19時22分 (#1079075) 日記
    個人的に欠かせないアプリケーションである Proxomitron を経由する場合、IE では対 proxy(Proxomitron) の要求が RFC に準じたような気がします。
    これは流石に厳しいので窓の手で普通に弄っていました。サーバに負荷が掛かるのは漠然と理解していましたけど。
    挙動としては正しいような気もするのですが、実際に使うとストレスたまりました……タブブラウザが標準だし。

    サーバ側の自衛策としては limitipconn とかで 2本以上は 503 ってのが妥当っぽい。
    503 とか返されたときに忠犬のように待つ UA はあるのかなぁ……

    # 逆に GetHTML は自主規制で 1接続を初期設定にしていますね。
    • by Anonymous Coward on 2006年12月20日 20時36分 (#1079117)
      教育機関でPCのある教室使ってますが、もしもIP単位で同時接続数制限なんざかけられると、
      授業中はほぼ常に503とかになりかねません。たぶん企業からのアクセスもしかり。
      Web屋さんとしてはしっかりセッション単位で制限かけるべきでしょうね。
      親コメント
      • by tanji (6368) on 2006年12月21日 0時49分 (#1079252) ホームページ
        本来、そういう場合は機関内にキャッシュサーバを置くべきだと思いますが...

        大学の英語の講義で、複数のクラスが一気に外部の個人が作ってる英語サイトにアクセスして、相手方サーバが落ちてしまい、結果まったく授業にならなかったのを見たことがあります。
        # さらに先生も学生も情報リテラシーのない人間ばかり、リロードを繰り返す訳で...
        親コメント
  • FasterFox (スコア:2, 参考になる)

    by Anonymous Coward on 2006年12月21日 0時36分 (#1079247)
    見たところ話題に出てないようですが、Firefoxではこの手のパラメータを最適化するアドオンとしてFasterFox [mozdev.org]と言うのがあります。これだとRFC準拠の最適化からRFCを越えるようなレベルの高速化、またカスタマイズでは最大接続数やパイプライン、レンダリングの最適化まで細かい設定ができます(関連情報 [geckodev.org])。

    ただこれ、RFC違反と明言しているターボ(サーバ当り24コネクション(persistent 8)・パイプライン最大8)はともかく「RFCに従った最適化」と言うモードでも結構無法な設定 [mozdev.org]になっている(サーバ当り16コネクション(persistent 6)・パイプライン最大6)ようで微妙な気がするんですが、どのRFCなんですかねこれ。私は「微調整」設定にしていますが、ページの読み込み時間が ms 単位で出るのが結構便利だったりします。

    このアドオンでは Prefech するのも微妙だなと思ったんですが、Mozilla Link Prefetching [mozilla.org] にしたがっているようで link 要素のものを先読みしているらしいです。
    それとは別に(最近の版の)標準では無効化されている「先読み」と言う設定はあって、こっち a 要素を絨毯爆撃してくる類のものです。正直言ってサーバの同時接続数も迷惑ですが、この手の「リンク先の絨毯先読みアクセス」ほど迷惑なものは無いですね。
  • by O1iver (31019) on 2006年12月21日 8時54分 (#1079318) ホームページ 日記
    TCPの同時コネクション数が10なので、IE/Firefoxの11以降は効かないはずです。
    Patch当てれば [bitcomet.com]できるけど。

    #FlashGet [flashget.com]とか天敵ですかね。
  • by Anonymous Coward on 2006年12月20日 18時26分 (#1079044)
    RFCに書かれているなら、それを守る方がよいのではないか?
    • by kicchy (4711) on 2006年12月20日 19時40分 (#1079085)
      >RFCに書かれているなら、それを守る方がよいのではないか?

      RFCが書かれた時に生まれた犬は老犬となっていないだろうか?

      # RFC2616が書かれたのは1999年らしいですよ
      # むしろ古い基準を新しくしていく必要もあるまいか?
      # 単純に数を増やすのではなく、ね
      親コメント
      • by Anonymous Coward on 2006年12月20日 21時52分 (#1079166)
        理想的には、サーバ等のリソースにより動的に変更するが可能ならそれに越したことは無い、では?
        ビジーなら皆で分け合おうよ、暇ならある程度多めに使ってもいいよ、的な動的な制御をサーバでさ。
        TCP/IPあたりなどのスライディングウィンドウとは傾向が違うけど、リソースの動的な調整は
        やろうと思えばできなくはないし、昔のリソースの少ない時代の静的な設定に固執することも
        ないと思う。

        ねぇ、IPアドレスの割り当てだって今じゃDHCPが当たり前の時代なんだしさ。

        #問題は誰がそれに気付いて始めるかだけどね。
        #ま、現状でも破綻してなきゃそのままでもいいのかもしれないが。
        親コメント

  • もうこれからはコンピューティング・ソサエティ・サイエンスという分野を設けてはどうだろうか。

    例えば、P2Pアプリケーションと総トラフィック制御方法論、とか。

    「風が吹けば桶屋が儲かる」
    --

    ---
    TaddyHatty - always @( posedge ↑ or negedge ↓ )
  • でもさ (スコア:1, 興味深い)

    by Anonymous Coward on 2006年12月20日 19時26分 (#1079077)
    接続数の制限しちゃうと、imodeとかezとかのproxy経由でくる携帯アクセスを相当制限しちゃわない?

    • by admineko (9202) on 2006年12月20日 20時35分 (#1079114)
      そこはまさに悩み所ですね

      PCサイト専用サーバはiptablesで接続数制限をかければ困らないのですが
      携帯サイトとPCサイトが一台のサーバに入っていると困ります.

      最近、KeepAliveが必須のサービスで大量のコネクションを張って
      keep Aliveで大量にプロセス数を消費するユーザに頭を抱えています。
      同じ接続元IPからであれば喜んでFireWallで跳ねるんですが・・・。

      ApacheやApacheモジュールで制限する機能が欲しいですね。
      親コメント
  • by Anonymous Coward on 2006年12月20日 20時12分 (#1079099)
    IE7 で変更しようと見てみると 16 進で 20 = 32 と なっていました.
  • 同一ドメインでは両手(2)で抱えられる程度にしてくれ。

    # 肩甲骨を使って、お手手が4本にできる三つ目族の方はコメントをお控えください。
    --
    ==========================================
    投稿処理前プレビュー確認後書込処理検証処理前反映可否確認処理後……
typodupeerror

人生の大半の問題はスルー力で解決する -- スルー力研究専門家

読み込み中...