InfoQ: FacebookのBigPipe: ページロード時間の最適化
Facebook の高速化について語られている。HTTP/1.1 パイプラインというものが気になったので調べてみた。
HTTP 通信を高速化するための技術としては keepalive が有名だと思います。TCP 接続を使いまわして、ひとつの TCP で複数の HTTP リクエストを投げるやつです。TCP セッションの確立には時間がかかるので、その回数を減らしましょうってことです。この方法だと、先のリクエストの応答が帰ってくるまで次のリクエストは投げられません。
そこでパイプラインです。パイプラインは、その keepalive な TCP 接続の中で応答を待たずにリクエストを投げられるんだそうです。ここに通信例が出てました。
404 Blog Not Found:HTTPサーバーのパイプライン対応
ここで、ひとつの疑問が･･･。次々リクエストが投げられたら、応答はどう返すべきでしょうか。準備の完了したリクエストから応答してしまってもいいでしょうか。サーバからのレスポンスに URL は含まれていません。ブラウザがリクエストとレスポンスを紐づける情報は順番しかありません。というわけで、サーバはレスポンスを順番に帰す必要があります。
順番に帰すってことは、サーバ上のメモリも消費します。最初のリクエストのレスポンスを準備するのに時間がかかると、続くリクエストのレスポンスが完成しても、応答せずに保持する必要があるためです。
なんか在庫管理みたいだなぁ。
同じような結果を生むであろう技術に HTML への埋め込みもあります。画像や JS、CSS ファイルを外部読み込みではなくて埋め込んでしまう方法です。これなら TCP 接続も一本、HTTP リクエストも一回で済みます。
てなわけで、一本の TCP 接続で何とかしようってのがそもそも限界があるのかも。どんどん TCP セッションを張って、外部読み込みファイルを並列で読みこんじゃえば、表示にかかる時間は短くなるはず、って考えです。
並列化は確かに速くなると思います。が、TCP セッションを何本も張るってのが問題です。小規模なサイトでは問題ないでしょうが、大規模サイトになるとサーバ側で受け入れられる TCP セッション数に達してしまうでしょう。特にステートフルなロードバランサを使用していると、そこに大きな負荷をかけることになると思います。
というわけで、埋め込みが一番いいんじゃないかなー、って思いました。ただし画像の Base64 エンコーディングには CPU 負荷がかかります。キャッシュするのを忘れずに･･･。

“自宅のパソコンやスマートフォン（※）から、お手元のパソコンを操作するのと同じように弊社サーバー内にあるハイスペックなWinodwsのデスクトップ環境を自由にリモート操作できるサービスです。”

リモートデスクトップ専用サービス｜お名前.com Windowsデスクトップ
頭ん中では考えていたけど、出てきちゃった。これにグループ機能があって、データセンター内のプライベート LAN があれば、頭の中のと同じだ。
まー、サーバー用のを借りて Linux でセットアップして、X over SSH で十分な気がするんだけど。VirtualBox とかの画面だけを送ってもいいんだよな。他の形態の画面提供でリソース課金なら、またちょっと毛色の違うサービスに見えたりするかも。
社内の仮想マシンホストとデータセンタ内の仮想マシンホストでデスクトップ仮想マシンをライブマイグレーションするとかも面白いかも。

“現在では、人の眼は最初に３原色応答で色を感じ、それを反対色応答の信号に変換して脳へ伝達する「段階説」が有力とされています。”

知っておきたい、色の話。（色彩工学入門）
だそうです。会社で話題になったので残しておきます。SHARP の新しい AQUOS の CM で４原色とか言ってたのが怪しく思っていたけど、ちゃんと理論に基づいていたんですね。
４原色ディスプレイが流行ってきたら微妙な色見とかも変わってくるだろうから、対応が必要かもね、って話も出てました。3D も流行ってきてるし、新技術について行くのは大変だぁ。

“グーグルでも使われているR”

Rは統計解析のブッシュナイフだ – ＠IT
@IT のトップに記事のリンクがあって、R の勉強が停滞しているのを思い出した。やんなきゃなー。本が無駄になる。
にしても Google でも使われているなんて知らなかった。他の大手 IT 企業も活動してんだ。単なる研究者のツールかと思っていたけど、そうではないようです。
今日は早く帰って R だな。