このサイトは、
高橋登史朗さんのご厚意で公開されています。(author:
komasshu blog)
このサンプルは、「websocket pipelineを使うと、それだけで普通のページのブラウジングが早くなるんじゃないか？」という思いをテストするために作成しました。
「画像をたくさん含むようなサイトを見ようとすると、画像のダウンロードに時間がかかって中々開かない（・ω・）」という経験をされた方は多いはずです。で、この要因の一つとして「httpでは、前の画像のダウンロードが終わらないと、次の画像のダウンロードが始まらない（待ってる時間だけ時間を食っている）」というのがあるのでは？と考えました。
一方，websokcet pipelineなら「いちいち、（前の画像のダウンロードが終わるのを）待たないんだから、ひょっとして早くなるんじゃない？」と考えたのが、このサンプルを作った理由です。
"via ws(websocket pipeline)"をクリックすると、websocket pipelineで100個の画像をダウンロードし、"via http(append DOM)"をクリックすると、普通のhttp（DOMのappendChildで実装しています）で同じ個数の画像をダウンロードします。
正直、僕が以前作った
websocket pipelineデモほど、その差は顕著ではないのですが（僕の環境ではwebsocket pipelineの方が2倍程度早いだけだった。アメリカとかからなら、もっと開くと期待）、その理由は以下ように考えられます。
続きを見る
- 同時コネクション数の違い
DOMの追加で画像ダウンロードを行うと、最大で6個のtcp connectionが張られるようです(chromeの場合：xhrでは最大で3コネクションでした）。同時にコネクションを複数張るというのは、例えるなら、６台のトラックで複数の荷物を手分けして運ぶのと同じですので、それだけ従来のhttpでも早くなります。
- base64エンコード
websocket(執筆時点では72)では、binary-frameも運べることになっているのですが、現状binaryを扱うapiが無い(;-;)ということで、websocket pipelineではbase64でテキストエンコードした画像をダウンロードしています。ですので、ダウンロードするバイト数がwebsokcketのほうが現状では大きくなってしまう（1.5倍程度）というのが、顕著なスピードの差に繋がらなかったと考えられます。
「じゃぁ、websocket pipelineは、このケースではあまり有効ではないの？」というとそんなことは無いと思います。現状のhttpではスピードをあげるために6個のコネクションをwebサーバーと同時に張っていますが、これはそれだけサーバーのリソースを消費していることになります。apacheの場合だと、単純に6倍のメモリを消費することになりますし、CPUリソースを見ても（正確なテストはしていませんので、参考値として見てください）http(6 connection)でCPU loadが大体5%程度だったのに対し、websocket pipeline(1 connction)では、0.5%程度でした。同時接続ユーザー数が増えると、この数値は単純には掛け算で効いてきますので、この差は無視できないものになります。
更に、クライアントとサーバーの間には、たくさんのNW機器が存在しますが、これらの中には同時セッション数に比例して、リソースを消費する機械が数多く存在します。例えば、NATやfirewall, ロードバランサー, proxyなどが挙げられます。これらの機械は、ルーターやスイッチなどに比べると比較的高価な機械です。
従って、現状のhttpのままで（スピードを出すために大量のコネクション数が消費されて）webが進化していくことは、サーバーコストやNWコストの増大を意味しているとも考えられますし、そのコストは最終的にエンドユーザーに返ってきます（ここで"返ってくる"という言葉は、サービスの進展を阻害すると捉えて欲しいです）。そういった目線で、このサンプルデモを見ていただけると嬉しいです(^-^)。