031.3 レッスン 1

クライアントとサーバの間で行われるHTTPデータ交換の最初の段階は、クライアントがサーバにリクエストメッセージを書き込むことで始まります。例えば、ブラウザの一般的なタスクとして、 https://learning.lpi.org/ja/ といったWebサイトをホストしているサーバからHTMLページを読み込むことが挙げられます。このアドレスまたはURLには、いくつかの関連情報が含まれています。この例では、3つの情報が表示されています。

HTTPサーバがリクエストメッセージヘッダーを受け取った後、クライアントにレスポンスメッセージを返します。HTMLファイルのリクエストは、通常、次のようなレスポンスヘッダーがあります。

最初の行には、応答メッセージで使用されているHTTPプロトコルのバージョンが示されています。このバージョンは、リクエストヘッダーで使用されているバージョンと一致していなければなりません。そして、やはり1行目には、サーバがリクエストに対してどのように解釈してレスポンスを生成したかを示す、レスポンスのステータスコードが表示されます。

ステータスコードは3桁の数字で、左端の桁がレスポンスクラスを表します。ステータスコードには、1から5までの5つのクラスがあり、それぞれサーバが取るアクションの種類を示しています。

2桁目と3桁目は追加の詳細を示すために使用されます。例えば、コード200は、リクエストに問題なく回答できたことを示します。例に示すように、応答コード（ OK ）に続く簡単なテキストの説明を提供することもできます。いくつかの特定のコードは、不利な状況でもHTTPクライアントがリソースにアクセスできることを保証したり、リクエストが失敗した場合に失敗の理由を特定するのに役立つ、特に重要なものです。

ステータスコード 4xx と 5xx は、リクエストに応えることができなかったことを示していますが、少なくとも HTTP サーバが稼働しており、リクエストを受信することができることを示しています。 4xx のコードは、クライアントのURLや認証情報が間違っているため、クライアントでアクションを起こすことが必要です。これに対して、 5xx コードは、サーバ側に何か問題があることを示しています。したがって、Webアプリケーションのコンテキストでは、これらの2つのクラスのステータスコードは、エラーの原因が基礎となるインフラではなく、クライアントまたはサーバのいずれかのアプリケーション自体にあることを示します。

HTTPサーバは、2つの基本的なメカニズムを使って、クライアントから要求されたコンテンツを実現します。1つ目のメカニズムは、 静的コンテンツ を提供します。つまり、リクエストメッセージで示されたパスは、サーバのローカルファイルシステム上のファイルに対応します。2つ目のメカニズムは、 動的コンテンツ を提供します。つまり、HTTPサーバはリクエストを別のプログラム（おそらくスクリプト）に転送し、データベースや他のファイルなどの異なるソースからレスポンスを構築します。

HTTPサーバにはさまざまな種類がありますが、いずれも同じHTTP通信プロトコルを使用し、多かれ少なかれ同じ規約を採用しています。特定のニーズがないアプリケーションであれば、ApacheやNGINXなど、従来のサーバでも実装可能です。どちらも動的コンテンツの生成と静的コンテンツの提供が可能ですが、それぞれの設定には微妙な違いがあります。

例えば、提供される静的ファイルの場所は、ApacheとNGINXで異なる方法で定義されています。規約では、この目的のために特定のディレクトリにこれらのファイルを保持することになっており、そのディレクトリにはホストに関連した名前、例えば /var/www/learning.lpi.org/ が付けられます。Apacheでは、このパスは、バーチャルホストを定義するセクションの中で、設定ディレクティブ DocumentRoot /var/www/learning.lpi.org によって定義されます。NGINXでは、設定ファイルの server セクションの root /var/www/learning.lpi.org が使われています。

どちらのサーバを選択しても、 /var/www/learning.lpi.org/ にあるファイルは、ほぼ同じ方法で HTTP 経由で提供されます。レスポンスヘッダーのいくつかのフィールドとその内容は2つのサーバ間で異なるかもしれませんが、 Content-Type のようなフィールドはレスポンスヘッダーに存在しなければならず、どのサーバ間でも一貫していなければなりません。

HTTPは、高速・低速を問わず、あらゆるタイプのインターネット接続で動作するように設計されています。さらに、インターネットは分散型のアーキテクチャを採用しているため、ほとんどのHTTP通信は多くのネットワークノードを通過しなければなりません。そのため、以前にダウンロードしたコンテンツの冗長な転送を避けるために、何らかのコンテンツキャッシング戦略を採用することが重要です。HTTP転送は、2つの基本的なタイプのキャッシュで動作します。 共有 と プライベート です。

共有キャッシュは、複数のクライアントによって使用されます。例えば、大規模なコンテンツプロバイダーでは、地理的に分散したサーバでキャッシュを使用し、クライアントが最寄りのサーバからデータを取得できるようにしています。あるクライアントがリクエストを行い、そのレスポンスが共有キャッシュに保存されると、同じ地域で同じリクエストを行った他のクライアントは、キャッシュされたレスポンスを受け取ることになります。

プライベートキャッシュとは、クライアント自身が自分専用に作成するものです。Webブラウザが画像、CSSファイル、JavaScript、HTMLドキュメントなどをキャッシュすることで、近い将来にリクエストされても、再度ダウンロードする必要がないようにするものです。

共有キャッシュ、プライベートキャッシュともに、ダウンロードしたコンテンツをどのようにキャッシュするかを制御するために、HTTPヘッダーを使用します。プライベートキャッシュの場合、クライアントはレスポンスヘッダーを参照し、ローカルキャッシュ内のコンテンツが現在のリモートコンテンツにまだ対応しているかどうかを検証します。対応している場合、クライアントは応答ペイロードの転送を放棄し、ローカルバージョンを使用します。

キャッシュされたリソースの有効性は、いくつかの方法で評価することができます。サーバは最初のリクエストの応答ヘッダーに有効期限を指定することで、クライアントは期間終了時にキャッシュリソースを破棄し、更新されたバージョンを取得するために再度リクエストすることができます。しかし、サーバはリソースの有効期限を常に判断できるわけではないので、リソースのバージョンを識別するために、 例えば、 Etag: "606adcd4-46fa" のように、 ETag レスポンスヘッダーフィールドを使用するのが一般的です。

キャッシュされたリソースに更新の必要性があるかどうかを確認するために、クライアントはサーバからの応答ヘッダーのみを要求します。 ETag フィールドがローカルに保存されているバージョンのものと一致すれば、クライアントはキャッシュされたコンテンツを再利用します。それ以外の場合は、リソースの更新されたコンテンツをサーバからダウンロードします。

従来のWebサイトやWebアプリケーションでは、セッション制御を処理する機能は、HTTPヘッダーに基づいています。例えば、サーバは、同じIPアドレスから来るすべてのリクエストが同じクライアントからのものであると仮定することはできません。サーバが異なるリクエストを1つのクライアントに関連付けることができる最も伝統的な方法は、 cookies を使用することです。クッキーとは、サーバからクライアントに与えられる識別タグで、HTTPヘッダーに記載されています。

クッキーを使用すると、クライアントを実行している人が自分自身を明確に識別していなくても、サーバは特定のクライアントに関する情報を保持することができます。クッキーを使用すると、ログイン、ショッピングカート、環境設定などを、それらを提供した同一のサーバへの異なるリクエストの間で保存するセッションを実現することができます。クッキーはユーザーのブラウジングを追跡するためにも使用されるので、送信する前に同意を得ることが重要です。

サーバはレスポンスヘッダーの中で、 Set-Cookie フィールドを使ってクッキーを設定します。フィールドの値は、特定のクライアントに関連する何らかの属性を表すように選択された name=value のペアです。サーバは例えば、あるリソースを初めて要求したクライアントのために識別番号を作成し、それをレスポンスヘッダーの中でクライアントに伝えることができます。

クライアントがクッキーの使用を許可している場合、同じサーバへの新しいリクエストには、ヘッダーにクッキーフィールドが含まれます。

この識別番号を使って、サーバはクライアントの特定の定義を取得し、カスタマイズされた応答を生成することができます。また、複数の Set-Cookie フィールドを使用して、同じ顧客に異なるクッキーを提供することも可能です。このようにして、クライアント側で複数の定義を保存することができます。

クッキーは、サーバによって元のクライアントとして識別される別のクライアントに転送される可能性があるため、プライバシーの問題と潜在的なセキュリティホールの可能性の両方をもたらします。セッションを保持するために使用されたクッキーは、元のクライアントの機密情報にアクセスできる可能性があります。したがって、クライアントは、クッキーが許可なく抽出されたり再利用されたりしないように、ローカルな保護メカニズムを採用することが非常に重要です。