アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
多くなってもよいのでは (スコア:3, すばらしい洞察)
HTTP/1.1（RFC2080やRFC2616）が発行されたのはブロードバンドには程遠い時代のことです。
その頃の推奨セッション数が最大2だったとしてそれが現代にそのまま足枷のように残るのはいかがなものでしょうか。
たしかにむやみやたらにTCPコネクションを増やすのはサーバ負荷に対して悪影響を与えますし、お行儀が悪いと感じます。ですが近年WEBサービスを行っているサーバの数も性能も過去に比べ激増しているのでこの傾向は薄まる方向へ向いていると思います。
よほどの大人気サイトでなければ致命的に高負荷になることもないでし
Re:多くなってもよいのでは (スコア:1)
>その頃の推奨セッション数が最大2だったとしてそれが現代にそのまま足枷のように残るのはいかがなものでしょうか。
日本の一般家庭を基準にRFCは書かれていないことを念頭に置いた方が良いと思います。
バックボーンネットワークの帯域幅増加率と末端(各家庭)のそれを比較(割合、何倍になったか)を
考えてみましょう。
今では各家庭まで100Mbps行ってるのに、サーバー側は太くて10Gbps。1999年のサーバー側が100Mbpsとしてクライアント数で割ったとすると1Mbps。…その頃は56kか64k,128k程度(日本では)でしたよね。
＃単純すぎて話にならないかもしれませんが、ある程度の目安として。
帯域幅もさることながら、各コンピュータの性能についても考える必要があります。
サーバーの性能も上がっていますが、それ以上にきっとクライアントの性能も上がっていますよね。
サーバーの性能だけが上がっていればTCPの接続数を増やしても対処できるでしょうけど、クライアントの性能も上がっているので、再接続要求の間隔なんてのも凄いことになると思いますが、どうでしょうか。
Re:多くなってもよいのでは (スコア:1)
ただ一点だけ異論を述べるとすれば、単にネットワーク帯域幅で比較できないのではないかと考えております。
回線速度の遅かった時代と現代とを比べるとトラフィック自体は格段にあがりましたが、TCP接続数が同じほどの増加幅を持っているわけではないと思うのです。
クライアント側が64Kbpsでがんばってる時代でも私はブラウザの窓を２つや３つ開いて回線を無駄に遊ばせないことに気を遣ってました（貧乏性なので・・）。いまはタブブラウザでたくさんの窓を開いたりはしますがその数は４～５倍にもなっていません。回線速度は１００倍以上になっていてもです。
※もちろん個人差が大きい話なので完全に私の主観です。すみません。
私がブロードバンドの比喩を出したのが悪かったのですが、ともかく大きく増えているのはデータ転送量であってコネクション確立数ではないと思うのです。
Re:多くなってもよいのでは (スコア:1)
最大スループットの向上ほどには遅延時間は改善していない
ということがあるように思います。
小さいファイルを多数個置かれた場合、回線が遊んでしまうので。
うちのような例は極端でしょうが… 対日本だとスループットはMbpsの桁に乗っても、
遅延が往復300msくらいあるので、余計にそう感じます。
かつ最近はやたらと細かい画像や広告を配置するサイトが増えたので、
まずいかなあと思いつつ20くらいまで上げさせてもらうことが多くなりました。