アカウント名:
パスワード:
推測ですが、以下のようなことを狙っているのではないでしょうか。
HTTPでWebページを読み込もうとすると、恐しいほどの時間がかかるわけです。試しに、50msのRTTのネットワークで、20KBのコンテンツ50個(合計:1MB)に取得に必要な時間を計算してみましょう。
1コンテンツの取得に必要な時間1RTT: 15002RTT: 1500+3000=45003RTT: 4500+6000=105004RTT: 10,500+12,000=22,500すなわち、4RTT(50ms*4=200ms)です。
標準的なブラウザでは、5コネクションまでしか張れません。したがって、50/5=10スロット分の通信を行なう必要があり、ウェブページの読み込みに必要な時間は、10*200ms=20秒となります。
実際には、画像ファイルにリンクするhtmlファイルの読み込みなども必要となりますから、もっと時間がかかるでしょう。
これらの複数のコネクションを1つにまとめて、SSL上にのっけた場合、単一のコネクションで済むのであれば、わずか9RTT(450ms)で済んでしまいます。(1RTT毎のトータル転送量: 1500, 4500, 10500, 22500,46500,94500,382500,766500,1534K)
昔のサーバはそれほど性能がよくなかったので、リクエストに応じてコンテンツを再構成するのは結構大変な仕事でしたが、マルチコアが安価になった昨今、サーバの負荷を多少高くしてでも、通信のオーバーヘッドを減らすのは重要なことといえるのではないでしょうか。
# プロトコルをちゃんと見てないので、すべて推測ですが…。
普通 HTTP/1.1 で keep-alive して新規セッションを張るコストを避ける + deflate なりでテキストコンテンツの自動圧縮を行う形を取るため、自動圧縮の処理負荷を避けたいくらい処理性能限界に近付くような状況でもなければ転送時間はもっと少なくなりますよ。 また、リクエストのパイプライン化を行うことで応答の完了を待たずに次のリクエストを送り、応答結果を流している間に次の要求を処理できるようになっています。
SSI/CGI 等を利用していても自動的にコンテンツ圧縮をかける事ができるサーバが大半 + HTTP/1.1 非対応のサーバーを探す方が大変という現状なので、今時そんなことを言うのは色々とアレです。
> また、リクエストのパイプライン化を行うことで応答の完了を待たずに次のリクエストを送り、応答結果を流している間に次の要求を処理できるようになっています。
それは知りませんでした。それができるのであれば、挙げた例は該当しないです。
確かに。
HTTP/1.1 の以下ですね。
http://www.studyinghttp.net/cgi-bin/rfc.cgi?2616 [studyinghttp.net]
8.1.2.2 パイプライン化持続的接続をサポートするクライアントは、そのリクエストを "パイプライン" する事ができる (例えば、複数のレスポンスを待つ事無く、複数のリクエストを送る)。サーバは、リクエストが受信されたのと同じ順番で、それらのリクエストのレスポンスを返さなければならない。持続的接続を想定し、接続確立の後にすぐパイプラインを行うクライアントは、もし最初のパイプライン化への試行が失敗した場合は、それらの接続を再試行する準備をすべきである。クライアントがそのような再試行を行う場合は、その接続が持続的であると分かるまではパイプラインを行ってはならない。もし、サーバがすべての通信のレスポンスを返す前に接続を閉じてしまったら、クライアントはそれらのリクエストを再送信する準備をしなければならない。
8.1.2.2 パイプライン化
持続的接続をサポートするクライアントは、そのリクエストを "パイプライン" する事ができる (例えば、複数のレスポンスを待つ事無く、複数のリクエストを送る)。サーバは、リクエストが受信されたのと同じ順番で、それらのリクエストのレスポンスを返さなければならない。
持続的接続を想定し、接続確立の後にすぐパイプラインを行うクライアントは、もし最初のパイプライン化への試行が失敗した場合は、それらの接続を再試行する準備をすべきである。クライアントがそのような再試行を行う場合は、その接続が持続的であると分かるまではパイプラインを行ってはならない。もし、サーバがすべての通信のレスポンスを返す前に接続を閉じてしまったら、クライアントはそれらのリクエストを再送信する準備をしなければならない。
まあ、データを1つにまとめることができれば、html取得 -> パース -> データ再取得 のタイムラグは短かくできそうですよね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
プロトコルやGoogleのドキュメントを見たわけではありませんが (スコア:2)
推測ですが、以下のようなことを狙っているのではないでしょうか。
HTTPでWebページを読み込もうとすると、恐しいほどの時間がかかるわけです。
試しに、50msのRTTのネットワークで、20KBのコンテンツ50個(合計:1MB)
に取得に必要な時間を計算してみましょう。
1コンテンツの取得に必要な時間
1RTT: 1500
2RTT: 1500+3000=4500
3RTT: 4500+6000=10500
4RTT: 10,500+12,000=22,500
すなわち、4RTT(50ms*4=200ms)です。
標準的なブラウザでは、5コネクションまでしか張れません。したがって、
50/5=10スロット分の通信を行なう必要があり、ウェブページの読み込み
に必要な時間は、10*200ms=20秒となります。
実際には、画像ファイルにリンクするhtmlファイルの読み込みなども
必要となりますから、もっと時間がかかるでしょう。
これらの複数のコネクションを1つにまとめて、SSL上にのっけた場合、
単一のコネクションで済むのであれば、わずか9RTT(450ms)で済んでしまいます。
(1RTT毎のトータル転送量: 1500, 4500, 10500, 22500,46500,94500,382500,766500,1534K)
昔のサーバはそれほど性能がよくなかったので、リクエストに応じて
コンテンツを再構成するのは結構大変な仕事でしたが、マルチコアが安価
になった昨今、サーバの負荷を多少高くしてでも、通信のオーバーヘッド
を減らすのは重要なことといえるのではないでしょうか。
# プロトコルをちゃんと見てないので、すべて推測ですが…。
Re:プロトコルやGoogleのドキュメントを見たわけではありませんが (スコア:2, 参考になる)
普通 HTTP/1.1 で keep-alive して新規セッションを張るコストを避ける + deflate なりでテキストコンテンツの自動圧縮を行う形を取るため、自動圧縮の処理負荷を避けたいくらい処理性能限界に近付くような状況でもなければ転送時間はもっと少なくなりますよ。
また、リクエストのパイプライン化を行うことで応答の完了を待たずに次のリクエストを送り、応答結果を流している間に次の要求を処理できるようになっています。
SSI/CGI 等を利用していても自動的にコンテンツ圧縮をかける事ができるサーバが大半 + HTTP/1.1 非対応のサーバーを探す方が大変という現状なので、今時そんなことを言うのは色々とアレです。
Re:プロトコルやGoogleのドキュメントを見たわけではありませんが (スコア:1)
> また、リクエストのパイプライン化を行うことで応答の完了を待たずに次のリクエストを送り、応答結果を流している間に次の要求を処理できるようになっています。
それは知りませんでした。
それができるのであれば、挙げた例は該当しないです。
Re:プロトコルやGoogleのドキュメントを見たわけではありませんが (スコア:1)
確かに。
HTTP/1.1 の以下ですね。
http://www.studyinghttp.net/cgi-bin/rfc.cgi?2616 [studyinghttp.net]
まあ、データを1つにまとめることができれば、html取得 -> パース -> データ再取得 のタイムラグは短かくできそうですよね。