アカウント名:
パスワード:
例１: 異なるサーバ上にa.jpgが置かれている場合
HTTP/1.1 ではサーバ側でパイプラインに対応することが必須だから、HTTP/1.1 なら、同時接続数は少なくても(基本的に)問題ありません。
HTTP/1.1 Pipelining は RFC 的には MAY であって MUST ではありません。
だから世の中には非対応サーバが存在し、Firefox などで「何も知らない人にこの設定を有効にさせるのは有害だ」などという話が出てくるわけで。
読み直してみましたが、確かにサーバサイドは MUST でしたね。すいません。
ただ、サーバに MUST とされているのは「リクエストされた順に返すこと」だけですね。最小限度の要求です。しかも MUST なのはこれだけで、他には何の言及もありません。
クライアント側からの非同期の送出に対して、サーバ側も非同期にそれを read することを MUST とはしていない点がポイントだと思います。つまり、最初のリクエストに対する応答を送出しつつ、裏で次のリクエストに対するコンテンツの準備を行うなどのサーバサイドの非同期処理に対する保証が無い。
実際のところ
★★ GetHTML Ver.4.13, GetHTMLW Ver.7.13 より、★★(1) 同一サーバ(ホスト)への同時取得数が 1 に固定されました(2) 同一サーバ(ホスト)への連続取得に対し、1秒の wait をデフォルトで入れました 上記は、ブロードバンド化に伴う Web サーバへの負荷を軽減する為の措置です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
多くなってもよいのでは (スコア:3, すばらしい洞察)
HTTP/1.1（RFC2080やRFC2616）が発行されたのはブロードバンドには程遠い時代のことです。
その頃の推奨セッション数が最大2だったとしてそれが現代にそのまま足枷のように残るのはいかがなものでしょうか。
たしかにむやみやたらにTCPコネクションを増やすのはサーバ負荷に対して悪影響を与えますし、お行儀が悪いと感じます。ですが近年WEBサービスを行っているサーバの数も性能も過去に比べ激増しているのでこの傾向は薄まる方向へ向いていると思います。
よほどの大人気サイトでなければ致命的に高負荷になることもないでしょう。大人気サイトであればロードバランサやクラスタリングなどでいくらでも回避の手を打つことが可能です。
巨大なトラフィックが発生する動画ストリーミングなどはクライアント・サーバ型ではなくP2P等の技術で実現されたり、何百台も使ったクラスタリングをする方向にあってサーバサービスの分散強化傾向がどんどん強まっています。
いわゆるWEB2.0？以降の現代はサーバ側のサービス供給力を競う時代でもあり、クライアントはAdSenseを見てくれたり商品を購入するお客様という考え方のもとに勢いよく進化しています。
したがって今やクライアントに対する規制を論ずるのは進化に対して逆方向だと思うのです。
クライアントがサーバに高性能を求め、それに応えられるサーバが勝ち組として生き残れる、そんな競争原理が進化の原動力なのではないでしょうか。
Re:多くなってもよいのでは (スコア:4, 参考になる)
同時に2本接続しても使える帯域が2倍になるわけではないが、次々とリクエストを送ることで、結果的に無通信時間が減り、全体のスループットが向上する。
それなら、「同時接続」しなくても、結果が返ってくる前に次のリクエストを送出して「リクエスト送信」と「結果受信」を並行して行えるようになれば、スループットの向上は見込める。
それがパイプライン化 [mozilla-japan.org]で、同時接続するよりも効率が良い。
HTTP/1.1 ではサーバ側でパイプラインに対応することが必須だから、HTTP/1.1 なら、同時接続数は少なくても(基本的に)問題ありません。
以上、ページ表示に必要なデータがすべて揃うまでの時間を考えた「スループット」についての考察です。
ロード途中でもページを表示できるようなブラウザだと、その途中での「レイテンシ」については同時接続できた方がうれしい場合が多そうです。
大きな html と(html中で指定された)小さな css を読むときに、html が全部届いてから css を受け取るよりは、同時接続とかで先にcssを貰った方がありがたそうだし。
Re:多くなってもよいのでは (スコア:2, すばらしい洞察)
>「リクエスト?結果受け取り?リクエスト?結果受け取り」を繰り返してたら、待ち時間が
>あるために通信利用率が減って全体でのスループットが落ちるから。
誤解を招く、というか説明が少し足りないようですね。
「待ち時間」がどのような待ち時間なのかが問題です。
毎回接続・切断するのはHTTP/1.0までの話で、現在主流のHTTP/1.1ではKeepAliveに
よって接続を維持したまま複数のデータの取得が出来ますね。
同時セッション数を増やすことでスループットが上がるのは、アプリケーション層の
HTTPのレベルよりも、むしろトランスポート層のTCP/IPレベルですね。
TCP/IPではラウンドトリップタイム(RTT)によって実際の帯域以下にスループットが
下がってしまいます。
「送信して受信確認が来たら次の送信」というようにするので、受信確認のための
待ち時間が大きく響くのです。RTTが大きくなると極端に低下します。
関東に住んでいる人たちは大抵のサーバに距離的に近いため意識する機会が少なく、
忘れがちな話ですが、地方に行くと結構問題になります。
>同時に2本接続しても使える帯域が2倍になるわけではないが、次々とリクエストを
>送ることで、結果的に無通信時間が減り、全体のスループットが向上する。
無通信時間が減ってスループットが上がるというより、使用できる帯域は単純に
２倍になります。もちろん使用回線の帯域が上限となりますが。
大きなRTTによるスループットの低下では、100Mbpsの帯域があっても20Mbpsほどしか
使えないケースもあります。その場合に２セッション同時に通信すれば、40Mbpsくらい
使えるようになります。
この場合サーバ側で問題となるのは、遅いコネクションを多数張られるようになることです。
サーバとしてはさっさと通信を終えて他のコネクションの相手をしたいのに、遅い接続が
大量に滞留すると同時セッションが限界に達してしまい、新たに接続しようとしても
待たされることになってしまいます。
かつて、たった9600bpsしかないi-modeの通信が急増したとき、サーバ管理者、特に
バーチャルホストサーバの管理者は戦々恐々でした。
i-modeコンテンツがあると、遅いi-mode向け通信だけでHTTPのセッション全てが埋まり、
他のPC向けの通信がほとんどできなくなる現象が多発したからです。
これは「大容量の帯域」であっても関係なく発生しました。
現在ではドコモ側もPROXYを改良して対処したようですが。
３車線の高速道路があって、３車線とも併走すれば通行できる車両数は３倍です。
でも、やはり出せる速度に応じて速い車両は右側を走るように分けたほうが
流れは良くなりますよね。
たまに遅い車が３車線ともいて、同じ速度で走っているために渋滞を引き起こす
ことがありますよね。
スーパーのレジでも「大量に買う人（カート）専用」「少量買う人（カゴ）専用」と
分けられているところがありますね。
短時間で処理できる客は短時間で通過させたほうが効率が良いのです。
だから結論としては、「同時セッションを多くしてもいいけど、限度はある。
やりすぎないようにほどほどに」といいたいです。
現実的には、IE, Firefoxの規定値のままが「ほどほど」だと思います。
Re:多くなってもよいのでは (スコア:1, 参考になる)
欠点１：対象が同一コネクション上で取得可能なリソースである場合にのみ有効。
欠点２：送出したリクエストの順にしかレスポンスをもらえない。
モデルケースとして簡単な例で説明します。
index.html内に a.jpg b.jpg c.jpg が貼られているような簡単なページを想定します。
例１: 異なるサーバ上にa.jpgが置かれている場合
たとえばa.jpgがバナー広告だったりすれば多くの場合、異なるサーバ上にありますのでパイプラインは効力を発揮できません。バナーを取得しにいこうとしてそれが取り終わるまでの間、b.jpgやc.jpgに対してリクエストを出すことができないことになります。
TCPを複数接続することを是とするならば無問題です。a.jpgがなかなか返ってこなくても先にb.jpgやc.jpgに手を出すことができます。
例２：同一のサーバ上にすべてが置かれている場合
最近こういう例は少ないのが実情ですがこれならパイプラインが有効に働きます。いっぺんに全リソースに対してGETリクエストすることができます。
ただし上記の欠点２は避けられませんので、何らかの理由でa.jpgが返ってこなければ後続の b.jpgやc.jpgも返ってこない糞詰まり状態になります。サーバ上で a.jpg の置いてあるHDDが重かったり（この例から外れますが）アクセスの重いcgiだったりするとこの現象がよく起こります。
TCPを複数接続することを是とするならば無問題です。a.jpgがなかなか返ってこなくても先にb.jpgやc.jpgを手を入れることができます。
このようにパイプラインというのは効果を発揮するシチュエーションがかなり限定されており、あまり効率の良い技術ではありません。いっぺんにリクエストを送出した後すぐになんらかのエラーで切られたりした場合のロスも少なくありません。
最近のブラウザはパイプライン機能を持っていますがたとえば firefox2.0等でもデフォルトではこの機能はOFFになっているぐらい推奨度は低いものなのです。
Re:多くなってもよいのでは (スコア:3, 参考になる)
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 です。
Re:多くなってもよいのでは (スコア:1, 参考になる)
同時接続2本のルールは同一のサーバに対するものですが。
Re:多くなってもよいのでは (スコア:1, 参考になる)
GET requestを発行してresponseを得るものです。
そして、2に制限されているのは、同一サーバに対するhttp(=TCPコネクション)の数です。
別サーバにあるコンテンツには当然TCPコネクションをもう1個作成して
やり取りすることになります。
したがって例示のようなケースでも問題ないでしょう。
Re:多くなってもよいのでは (スコア:1)
サーバーあたりの同時接続制限なんだから、adserverのa.jpgが詰まってもmainserverにb.jpg,c.jpgのリクエストは出せるんじゃね？
例２はそのとおりかもしれんが
Re:多くなってもよいのでは (スコア:1)
HTTP/1.1 Pipelining は RFC 的には MAY であって MUST ではありません。
だから世の中には非対応サーバが存在し、Firefox などで「何も知らない人にこの設定を有効にさせるのは有害だ」などという話が出てくるわけで。
Re:多くなってもよいのでは (スコア:1)
順にレスポンスを返すことがMUSTとされています。
現実に非対応だとしたらそれはRFC2616準拠ではないというだけでしょう。
Re:多くなってもよいのでは (スコア:0)
読み直してみましたが、確かにサーバサイドは MUST でしたね。すいません。
ただ、サーバに MUST とされているのは「リクエストされた順に返すこと」だけですね。最小限度の要求です。しかも MUST なのはこれだけで、他には何の言及もありません。
クライアント側からの非同期の送出に対して、サーバ側も非同期にそれを read することを MUST とはしていない点がポイントだと思います。つまり、最初のリクエストに対する応答を送出しつつ、裏で次のリクエストに対するコンテンツの準備を行うなどのサーバサイドの非同期処理に対する保証が無い。
実際のところ
Re:多くなってもよいのでは (スコア:1)
そういう状況でも、
「クライアントからサーバーに応答を送出」→「クライアントが応答が最後まで届いたことを確認」→「クライアントからサーバーに次のリクエストを送出」→「サーバーがリクエストを確認」と往復する分の通信遅延については、pipelining で得をすることになりますね。
リクエストが多数発生する「小さいファイルをたくさん取得」といった状況だと、persistent connection と比べてかなりの効果は期待できると思います。
ちなみに、
#! /bin/sh
echo 'Content-Type: text/plain'
echo 'Content-Length: 18'
echo ''
date +%H:%M:%S
sleep 3
date +%H:%M:%S
といったCGI を使って試したところ、Apache 1.3 と Apache 2.0 は、どちらも応答してから次のリクエストを処理してました。
Re:多くなってもよいのでは (スコア:1)
404 Blog Not Found:HTTPサーバーのパイプライン対応 [livedoor.jp]
#私信
#上の方での返信は、貴方のレスに対するレスになっていませんね。
#深く考えずにぶら下げただけですのでご容赦下さい。
Youthの半分はバファリンでできています。
Re:多くなってもよいのでは (スコア:2, 興味深い)
ダイヤルアップが当たり前・せいぜいがISDNの128kbpsだった時代には、末端のユーザが最大速度でアクセスしてもその負荷はたかがしれていました。
…が、その感覚で、1Mbpsは普通に出るADSLや実行でも数十Mbps出る光回線からアクセスされるとたまったものではありません。
GetHTMLWの旧バージョンが、数アクセス/秒の頻度で根こそぎダウンロードしていたログに出くわして、しみじみそう思いました。昔なら、同時接続数4・ノーウェイトでもたいした問題はなかったのですけどね。
なお、現行バージョンのでは
となっています。
＞大人気サイトであればロードバランサやクラスタリングなどでいくらでも回避の手を打つことが可能です。
普段から負荷がかかるサイトならばともかく、突如負荷がかかる場合があります。
たとえば、/.Jのコメントからリンクを張るだけでもだいたい1アクセス/分ぐらいです。タレコミ本文からだったら、桁が変わるでしょう。「カトゆー家断絶」からのリンクの場合、ピーク時に2アクセス/分ぐらいでした。おそらく、ページの内容と読者層が重ならなかったためにこの程度のアクセスで済んだと思われますが、場合によっては桁が2つほど変わることも十分あり得るでしょう。
＞クライアントがサーバに高性能を求め、それに応えられるサーバが勝ち組として生き残れる、そんな競争原理が進化の原動力なのではないでしょうか。
ADSL回線にぶら下がったPen3/600MHzのうちのWebサーバなんぞは最底辺でしょうが、そこまで酷くなくても、高速回線にぶら下がった高性能マシンだけがWebサーバでは無いと思うのです。
とはいえ、#1079136 [srad.jp]の
＞3本以上のコネクション張れないように！ → 技術的に解決可能
というのもごもっともで、これからはサーバ側が、高速回線当たり前の世の中に対応していくことが必要なのかもしれません。
Re:多くなってもよいのでは (スコア:1)
おっしゃるとおり高性能でないwebサーバもあるので私の意見が少々暴論気味なのは認識済みです。
＞3本以上のコネクション張れないように！ → 技術的に解決可能
というのもごもっともで、これからはサーバ側が、高速回線当たり前の世の中に対応していくことが必要なのかもしれません。
私が特に言いたかったのはご意見のこの部分になります。
プアーな環境の自宅サーバ等では自分の処理能力に見合ったアクセス制限をかければいいでしょうし、逆に超ハイスペックな環境ならガンガン動けばいいと思います。
そういった色々なサーバがネット上に存在している現代において、クライアント側に一律の規制を押しつけることに抵抗感を感じている次第です。
Re:多くなってもよいのでは (スコア:1)
>その頃の推奨セッション数が最大2だったとしてそれが現代にそのまま足枷のように残るのはいかがなものでしょうか。
日本の一般家庭を基準にRFCは書かれていないことを念頭に置いた方が良いと思います。
バックボーンネットワークの帯域幅増加率と末端(各家庭)のそれを比較(割合、何倍になったか)を
考えてみましょう。
今では各家庭まで100Mbps行ってるのに、サーバー側は太くて10Gbps。1999年のサーバー側が100Mbpsとしてクライアント数で割ったとすると1Mbps。…その頃は56kか64k,128k程度(日本では)でしたよね。
＃単純すぎて話にならないかもしれませんが、ある程度の目安として。
帯域幅もさることながら、各コンピュータの性能についても考える必要があります。
サーバーの性能も上がっていますが、それ以上にきっとクライアントの性能も上がっていますよね。
サーバーの性能だけが上がっていればTCPの接続数を増やしても対処できるでしょうけど、クライアントの性能も上がっているので、再接続要求の間隔なんてのも凄いことになると思いますが、どうでしょうか。
Re:多くなってもよいのでは (スコア:1)
ただ一点だけ異論を述べるとすれば、単にネットワーク帯域幅で比較できないのではないかと考えております。
回線速度の遅かった時代と現代とを比べるとトラフィック自体は格段にあがりましたが、TCP接続数が同じほどの増加幅を持っているわけではないと思うのです。
クライアント側が64Kbpsでがんばってる時代でも私はブラウザの窓を２つや３つ開いて回線を無駄に遊ばせないことに気を遣ってました（貧乏性なので・・）。いまはタブブラウザでたくさんの窓を開いたりはしますがその数は４～５倍にもなっていません。回線速度は１００倍以上になっていてもです。
※もちろん個人差が大きい話なので完全に私の主観です。すみません。
私がブロードバンドの比喩を出したのが悪かったのですが、ともかく大きく増えているのはデータ転送量であってコネクション確立数ではないと思うのです。
Re:多くなってもよいのでは (スコア:1)
最大スループットの向上ほどには遅延時間は改善していない
ということがあるように思います。
小さいファイルを多数個置かれた場合、回線が遊んでしまうので。
うちのような例は極端でしょうが… 対日本だとスループットはMbpsの桁に乗っても、
遅延が往復300msくらいあるので、余計にそう感じます。
かつ最近はやたらと細かい画像や広告を配置するサイトが増えたので、
まずいかなあと思いつつ20くらいまで上げさせてもらうことが多くなりました。
Re:多くなってもよいのでは (スコア:1)
ただ同時接続数の増加がリニアにダウンロード時間の減少に繋がるわけではないのだろうから、程々が肝心ではありましょう。
このあたりを数学的に解説してくれる人は誰かいませんか?
有効な同時接続数ってそこまで増えてるの？ (スコア:0)