アカウント名:
パスワード:
例1: 異なるサーバ上にa.jpgが置かれている場合
HTTP/1.1 ではサーバ側でパイプラインに対応することが必須だから、HTTP/1.1 なら、同時接続数は少なくても(基本的に)問題ありません。
HTTP/1.1 Pipelining は RFC 的には MAY であって MUST ではありません。
だから世の中には非対応サーバが存在し、Firefox などで「何も知らない人にこの設定を有効にさせるのは有害だ」などという話が出てくるわけで。
読み直してみましたが、確かにサーバサイドは MUST でしたね。すいません。
ただ、サーバに MUST とされているのは「リクエストされた順に返すこと」だけですね。最小限度の要求です。しかも MUST なのはこれだけで、他には何の言及もありません。
クライアント側からの非同期の送出に対して、サーバ側も非同期にそれを read することを MUST とはしていない点がポイントだと思います。つまり、最初のリクエストに対する応答を送出しつつ、裏で次のリクエストに対するコンテンツの準備を行うなどのサーバサイドの非同期処理に対する保証が無い。
実際のところ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
多くなってもよいのでは (スコア:3, すばらしい洞察)
HTTP/1.1(RFC2080やRFC2616)が発行されたのはブロードバンドには程遠い時代のことです。
その頃の推奨セッション数が最大2だったとしてそれが現代にそのまま足枷のように残るのはいかがなものでしょうか。
たしかにむやみやたらにTCPコネクションを増やすのはサーバ負荷に対して悪影響を与えますし、お行儀が悪いと感じます。ですが近年WEBサービスを行っているサーバの数も性能も過去に比べ激増しているのでこの傾向は薄まる方向へ向いていると思います。
よほどの大人気サイトでなければ致命的に高負荷になることもないでし
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倍になるわけではないが、次々とリクエストを
>送ることで、結果的に無通信時間が減り、全体のスループットが向上する。
無通信時間が減ってスループットが上がるというより、使用できる帯域は単純に
2倍になります。もちろん使用回線の帯域が上限となりますが。
大きなRTTによるスループットの低下では、100Mbpsの帯域があっても20Mbpsほどしか
使えないケースもあります。その場合に2セッション同時に通信すれば、40Mbpsくらい
使えるようになります。
この場合サーバ側で問題となるのは、遅いコネクションを多数張られるようになることです。
サーバとしてはさっさと通信を終えて他のコネクションの相手をしたいのに、遅い接続が
大量に滞留すると同時セッションが限界に達してしまい、新たに接続しようとしても
待たされることになってしまいます。
かつて、たった9600bpsしかないi-modeの通信が急増したとき、サーバ管理者、特に
バーチャルホストサーバの管理者は戦々恐々でした。
i-modeコンテンツがあると、遅いi-mode向け通信だけでHTTPのセッション全てが埋まり、
他のPC向けの通信がほとんどできなくなる現象が多発したからです。
これは「大容量の帯域」であっても関係なく発生しました。
現在ではドコモ側もPROXYを改良して対処したようですが。
3車線の高速道路があって、3車線とも併走すれば通行できる車両数は3倍です。
でも、やはり出せる速度に応じて速い車両は右側を走るように分けたほうが
流れは良くなりますよね。
たまに遅い車が3車線ともいて、同じ速度で走っているために渋滞を引き起こす
ことがありますよね。
スーパーのレジでも「大量に買う人(カート)専用」「少量買う人(カゴ)専用」と
分けられているところがありますね。
短時間で処理できる客は短時間で通過させたほうが効率が良いのです。
だから結論としては、「同時セッションを多くしてもいいけど、限度はある。
やりすぎないようにほどほどに」といいたいです。
現実的には、IE, Firefoxの規定値のままが「ほどほど」だと思います。
Re:多くなってもよいのでは (スコア:1, 参考になる)
欠点1:対象が同一コネクション上で取得可能なリソースである場合にのみ有効。
欠点2:送出したリクエストの順にしかレスポンスをもらえない。
モデルケースとして簡単な例で説明します。
index.html内に a.jpg b.jpg c.jpg が貼られているような簡単なページを想定します。
例1: 異なるサーバ上にa.jpgが置かれている場合
たとえばa.jpgがバナー広告だったりすれば多くの場合、異なるサーバ上にありますのでパイプラインは効力を発揮できません。バナーを取得しにいこうとしてそれが取り終わるまでの間、b.jpgやc.jpgに対してリクエストを出すことができないことになります。
TCPを複数接続することを是とするならば無問題です。a.jpgがなかなか返ってこなくても先にb.jpgやc.jpgに手を出すことができます。
例2:同一のサーバ上にすべてが置かれている場合
最近こういう例は少ないのが実情ですがこれならパイプラインが有効に働きます。いっぺんに全リソースに対してGETリクエストすることができます。
ただし上記の欠点2は避けられませんので、何らかの理由で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のリクエストは出せるんじゃね?
例2はそのとおりかもしれんが
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の半分はバファリンでできています。