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

多くなってもよいのでは

[shinji.ueno (32854)]

それも時代の流れではないかと。
HTTP/1.1（RFC2080やRFC2616）が発行されたのはブロードバンドには程遠い時代のことです。
その頃の推奨セッション数が最大2だったとしてそれが現代にそのまま足枷のように残るのはいかがなものでしょうか。

たしかにむやみやたらにTCPコネクションを増やすのはサーバ負荷に対して悪影響を与えますし、お行儀が悪いと感じます。ですが近年WEBサービスを行っているサーバの数も性能も過去に比べ激増しているのでこの傾向は薄まる方向へ向いていると思います。
よほどの大人気サイトでなければ致命的に高負荷になることもないでし

Re:多くなってもよいのでは

[taka2 (14791)]

なぜ「同時に複数のコネクションを張りたい」のか、その理由は、毎回接続・切断して「リクエスト→結果受け取り→リクエスト→結果受け取り」を繰り返してたら、待ち時間があるために通信利用率が減って全体でのスループットが落ちるから。
同時に2本接続しても使える帯域が2倍になるわけではないが、次々とリクエストを送ることで、結果的に無通信時間が減り、全体のスループットが向上する。

それなら、「同時接続」しなくても、結果が返ってくる前に次のリクエストを送出して「リクエスト送信」と「結果受信」を並行して行えるようになれば、スループットの向上は見込める。
それが

Re:多くなってもよいのでは

[Stealth (5277)]

HTTP/1.1 ではサーバ側でパイプラインに対応することが必須だから、HTTP/1.1 なら、同時接続数は少なくても(基本的に)問題ありません。

HTTP/1.1 Pipelining は RFC 的には MAY であって MUST ではありません。

だから世の中には非対応サーバが存在し、Firefox などで「何も知らない人にこの設定を有効にさせるのは有害だ」などという話が出てくるわけで。

Re:多くなってもよいのでは

[Y.Itsumi (13874)]

MAYなのはクライアント側の話であって、サーバはリクエストを受け取った
順にレスポンスを返すことがMUSTとされています。

現実に非対応だとしたらそれはRFC2616準拠ではないというだけでしょう。

Re:多くなってもよいのでは

[Anonymous Coward]

読み直してみましたが、確かにサーバサイドは MUST でしたね。すいません。

ただ、サーバに MUST とされているのは「リクエストされた順に返すこと」だけですね。最小限度の要求です。しかも MUST なのはこれだけで、他には何の言及もありません。

クライアント側からの非同期の送出に対して、サーバ側も非同期にそれを read することを MUST とはしていない点がポイントだと思います。つまり、最初のリクエストに対する応答を送出しつつ、裏で次のリクエストに対するコンテンツの準備を行うなどのサーバサイドの非同期処理に対する保証が無い。

実際のところ

Re:多くなってもよいのでは

[taka2 (14791)]

> そうではない場合 (単なる順次解釈のみ) には、単なる persistent connection レベルでの通信と全く差が無い事となります。

そういう状況でも、
「クライアントからサーバーに応答を送出」→「クライアントが応答が最後まで届いたことを確認」→「クライアントからサーバーに次のリクエストを送出」→「サーバーがリクエストを確認」と往復する分の通信遅延については、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 は、どちらも応答してから次のリクエストを処理してました。