WWW完全制覇 第6回

HTTPとCookie、SSLを理解しよう

ブラウザとサーバは何をやりとりしているの？

HTTP1.1を用いて効率的な転送を

　HTTPの最初のバージョンでは、1つのHTTPセッションでファイルを1つずつ取得していた。しかし、これでは複数のファイルを得るために、何度もTCPのコネクションを構築・切断しなればならない。3つのファイルを取得するために、TCPのコネクションを3回構築しなければならないのだ。

　もちろん、複数のTCPコネクションを同時に構築するという方法もあり、実際初期のWebブラウザでは実装されていたが、TCPのコネクションの確立と管理はサーバに大きな負担をかける。そこで、改良されたHTTP1.1では「キープアライブ」という機能を用いて、レスポンスが戻ってきても、同じTCPコネクションを再利用する。つまり、1回のTCPコネクションで、複数のファイルを取得することができるのだ。これにより、サーバの負荷を減らすほか、TCPの構築・切断にかかる時間を減らすことが可能になる。

図5　HTTPのキープアライブ

　HTTP1.1ではキープアライブの状態を維持するために、リクエストメッセージのConnectionのヘッダフィールドを用いる。通常はデフォルトでキープアライブがオンになっているため、ここでConnection：closeと任意に指定しない限りは、1つのTCPコネクションを利用し続けられる。

　また、キープアライブを利用した際は、レスポンスを待たずに、リクエストを送信するパイプラインの機能も利用できる。これはHTTPのセッションが、トランシーバのような半二重ではなく、双方に同時にデータを送信できる全二重だから実現できたものだ。これを用いることで、送受信をさらに効果的に行なえる。

　さらにHTTP1.1ではWebブラウザとWebサーバが対応していれば、データの圧縮も可能だ。まず、Webブラウザ側が、「Accept-Encoding:gzip,deflate」のようにメッセージヘッダで利用可能なアルゴリズムを提示すると、サーバはこのアルゴリズムを用いてデータを圧縮して、送信量自体を減らす。

　HTTP1.1では、これらいくつかの技術により効率的な転送が実現されており、現在のWebブラウザでも標準で採用されている。しかし、昨今では送受信するデータ量が大きくなっているため、中継機器とWebブラウザを連携させて、独自にキャッシュや圧縮を行ない、HTTPのレスポンスを高めている手法を提供しているベンダーもある。

（次ページ、「Webアプリケーションから端末を特定するCookie」に続く）