図解HTTP二:簡単なHTTPプロトコル

2.1 HTTPプロトコルクライアントとサーバ間の通信用
HTTPプロトコルは、TCP/IPプロトコルファミリー内の他の多くのプロトコルと同じであり、クライアントとサーバ間の通信に用いられるが、HTTPプロトコルでは、どのエンドがクライアントであり、どのエンドがサーバであるかを明確に区別することができる.
2.2要求と応答の交換による通信
HTTPプロトコルは、要求がクライアントから発行され、最後にサーバ側が要求して戻ることを規定している.すなわち、サーバ側は、要求を受信する前に応答を送信しないクライアントから通信を開始するに違いない.
要求メッセージは、要求メソッド、要求URI、プロトコルバージョン、オプションの要求ヘッダフィールド、およびコンテンツエンティティから構成される.応答メッセージは、基本的に、プロトコルバージョン、ステータスコード(要求の成功または失敗を示すデジタルコード)、ステータスコードを解釈するための理由フレーズ、オプションの応答ヘッダフィールド、およびエンティティボディから構成される.
2.3 HTTPはステータスを保存しないプロトコル
HTTPは、ステータスを保存しない、すなわちステータスレスプロトコルである.HTTPプロトコル自体は要求と応答との間の通信状態を保存しない. HTTPプロトコルを使用して、新しい要求が送信されるたびに、対応する新しい応答が生成される.プロトコル自体は、以前のすべてのリクエストまたは応答メッセージの情報を保持しません.これは、大量のトランザクションをより迅速に処理し、プロトコルの伸縮性を確保するためです.
2.4 URI位置決めリソースの要求
HTTPプロトコルは、URIを使用してインターネット上のリソースを特定します.URIの特定の機能だけに、インターネット上の任意の場所のリソースにアクセスできます.クライアントがリソースへのアクセスを要求して要求を送信する場合、URIは要求メッセージとしての要求URIを含める必要がある.要求URIを指定する方法はいろいろあります.
2.5サーバの意図を知らせるHTTPメソッド

GET:GETメソッドは、URIによって識別されたリソースへのアクセスを要求するために使用される.指定したリソースは、サーバ側で解析された後、応答内容を返します.

POST:POST方法は、エンティティのボディを送信するために使用される.

PUT:PUTメソッドは、ファイルを転送するために使用される.FTPプロトコルのファイルアップロードのように,要求メッセージの主体にファイル内容を含めて要求URI指定の場所に保存することが要求される.

HEAD:HEADメソッドはGETメソッドと同様であるが,メッセージ本体部分には戻らない.URIの有効性やリソース更新の日時などを確認するために使用します.

DELETE:DELETEメソッドは、PUTとは逆の方法でファイルを削除するために使用されます.DELETEメソッドは、要求URIに従って指定されたリソースを削除する.

OPTIONS:OPTIONSメソッドは、URIに対して指定されたリソースサポートを要求するメソッドを問い合わせるために使用される.

CONNECT:CONNECTメソッドでは,プロキシサーバとの通信時にトンネルを確立し,トンネルプロトコルによるTCP通信を実現することが要求される.主にSSL(Secure Sockets Layer,セキュリティソケット層)とTLS(Transport Layer Security,トランスポート層セキュリティ)プロトコルを用いて通信内容を暗号化してネットワークトンネルを介して伝送する.

TRACE:TRACEメソッドは、Webサーバ側が以前の要求通信をクライアントにループバックさせる方法である.

2.6永続接続による通信量の節約
2.6.1永続接続
永続接続(HTTP Persistent Connections、HTTP keep-aliveまたはHTTP connection reuseとも呼ばれる)の方法.永続接続の特徴は,いずれかの端部が明確に切断接続を提案していない限り,TCP接続状態を保つことである.
永続接続は、1回のTCP接続を確立した後、複数のリクエストと応答のインタラクションを行うことを目的としています.
永続接続の利点は、TCP接続の重複確立と切断による追加のオーバーヘッドを低減し、サーバ側の負荷を軽減することです.また、オーバーヘッドの時間を少なくし、HTTPリクエストやレスポンスをより早く終了させることで、Webページの表示速度も向上します.
2.7.2管線化
永続的な接続により、多くのリクエストがパイプライン化されて送信されることが可能になります.次のリクエストを送信するには、リクエストを送信した後に応答を待機して受信する必要があります.パイプライン化技術が登場すると、応答を待たずに次のリクエストを直接送信できます.これにより、応答を次から次へと待つことなく、複数のリクエストを同時に並列に送信することができる.
応答を待たずに次のリクエストを直接送信
例えば、10枚の画像を含むHTML Webページを要求すると、1つの接続よりも永続的な接続で要求をより早く終了させることができる.パイプライン化技術は、永続的な接続よりも速い.リクエスト数が多ければ多いほど、時間差が顕著になります.
2.8 Cookieを使用した状態管理
HTTPは、以前に発生した要求や応答の状態を管理しない無状態プロトコルです.つまり,これまでの状態に応じて今回のリクエスト処理を行うことはできない.
ログイン認証を要求するWebページ自体がステータスの管理ができない(ログインしたステータスを記録しない)と仮定すると、新しいページをジャンプするたびに再ログインするのではなく、リクエストメッセージごとにパラメータを付加してログインステータスを管理する.無状態プロトコルという特徴を保持しながら類似の矛盾問題を解決し,Cookie技術を導入した.Cookie技術は、要求および応答メッセージにCookie情報を書き込むことによってクライアントの状態を制御する.Cookieは、サーバ側から送信された応答メッセージ内のSet-Cookieというヘッダフィールド情報に基づいて、クライアントにCookieの保存を通知します.次回クライアントがそのサーバに要求を送信すると,クライアントは自動的に要求メッセージにCookie値を加えて送信する.サーバ側は,クライアントから送られてきたCookieを発見すると,どのクライアントからの接続要求なのかをチェックし,サーバ上のレコードと比較し,最後に前の状態情報を得る.
Cookie情報がない状態でのリクエスト

2回目以降(Cookie情報が格納されている状態)のリクエスト
上図はCookieインタラクションが発生するシナリオを示しており,HTTPリクエストメッセージとレスポンスメッセージの内容は以下の通りである.

要求メッセージ(Cookie情報がない状態)

GET /reader/ HTTP/1.1
Host: hackr.jp
*       Cookie     

応答メッセージ(サーバ側生成Cookie情報)

HTTP/1.1 200 OK
Date: Thu, 12 Jul 2012 07:12:20 GMT
Server: Apache
＜Set-Cookie: sid=1342077140226724; path=/; expires=Wed,
10-Oct-12 07:12:20 GMT＞
Content-Type: text/plain; charset=UTF-8

要求メッセージ(保存中のCookie情報を自動送信)

GET /image/ HTTP/1.1
Host: hackr.jp
Cookie: sid=1342077140226724