このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
SSJS, ASP, PHP, Java Servlet + JSP と、
サーバ側の開発基盤が進歩してくると、
Web サーバの仕事はどんどん多くなってきた。
利用者が対話的に操作をするような Web サイトの場合、
静的なデータを配信するサーバと比較しても、
HTTP による通信回数は多く、
送受信されるデータ量も半端でなく増加している。
従来であれば、Web サーバの負担を減らすために、
キャッシュを利用する事が可能であった。
これは、サーバが静的なデータを返すことが多いからで、
一度 URL にアクセスして取得したデータを記憶しておき、
次回以降は、サーバ側のデータが更新されない限り、
手元に記憶していたものを利用すれば良かったからだ。
しかし、Web サーバが動的に処理をして返したデータは、
利用者の操作によって生成された結果であることが多く、
それらをキャッシュしても再利用できる可能性が低く、
全体的にキャッシュのヒット率が低下しだした。
また、HTTP/1.0 の規格では、キャッシュサーバや
プロキシサーバ等、通信を仲介する Web サーバでは、
キャッシュを行う方法が曖昧となっていた。
そのため、URL 上のデータが更新されても、
間違って古いデータを送り返す可能性があった。
これが、Web システムと組み合わせて発生すると、
大きな問題につながりかねない。
そのため、下手にキャッシュを行うことができなくなり、
仲介サーバにおけるキャッシュ効率も悪くなる一方であった。
そのような事情を考慮して、1997 年に
HTTP の新しいバージョン 1.1 が公開された。
HTTP/1.1 は、現在も使われているバージョンである。
HTTP/1.1 では、プロトコル仕様として
通信量を極力削減できる仕組みが数多く導入されている。
まずは、キャッシュに関する仕組みが、
プロトコル内で明確に定義され、
キャッシュの性能を向上させることが可能になった。
そして、一番の目玉が、持続性接続機能である。
mixi の自分のトップページを見てみよう。
この画面を表示するためには、ページの HTML だけでなく、
CSS, JavaScript、そして数多くの画像が必要だ。
それらの数を数えてみると、なんと 100 近い。
従来は、HTTP の 1 度の通信ごとに、
毎回個別の TCP による接続が行われていた。
つまり、通信ごとに、Web サーバに接続⇒リクエスト送信
⇒レスポンス受信⇒切断という一連の流れが発生する。
つまり、mixi の画面を表示するためには、
この通信を 100 回以上行わなければいけないことになる。
TCP は、データを着実に届ける信頼性を持つが故に、
その接続や切断には高いオーバヘッドが生じる。
TCP はよく電話に例えられるが、
上記の場合、100 回電話をかけることに相当するのだ。
つまり、本題（データ）の通信以上に、
電話をかける・切ることに手間や時間がかかるのだ。
さて、100 項目の内訳を見てみると、
ほとんどが、同じ Web サーバのデータであることが分かる。
どうせ同じサーバに接続するのであれば、
1 度の通信で、それらを 1 度に取得できないだろうか。
持続性接続は、これを実現するために規格化された。
従来の HTTP は、ユーザエージェントがリクエストを送り、
それに対して Web サーバがレスポンスを返した。
Web サーバのレスポンスにはステータスやヘッダ、
そしてデータ本体が含まれているが、本体の長さは不定で、
「Web サーバが通信を閉じる」までの残り全てであった。
持続性接続では、1 度の通信の間で、
何度もリクエストとレスポンスのやり取りが行われるため、
Content-Length ヘッダや転送コーディング等を利用し、
必ず本体のサイズが計算できるようになっている。
そのため、複数のレスポンスを受け取る場合でも、
各レスポンスを明確に区切る事ができる。
これにより、通信中に急に切断が発生したとしても、
受け取ったデータが不完全かどうかを調べられるため、
正常に Web サーバが通信を切断したのか、
障害が発生したのかどうかがすぐに解るのだ。
また、HTTP/1.1 は通信のパイプライン化も規定しており、
ユーザエージェントは、レスポンスを待たずして、
複数のリクエストを一気に送ることも可能となった。
持続性接続を利用すると、大半のケースにおいて、
TCP 接続の回数を減らすことができるため、
全体的なスループット（処理性能）が飛躍的に向上するのだ。