「HTTP」の仕組みをおさらいしよう(その2)リトライ! 触って学ぶTCP/IP(3)(3/3 ページ)

» 2015年11月27日 05時00分 公開
[福永勇二インタラクティブリサーチ]
前のページへ 1|2|3       

実際のHTTPレスポンスを見てみよう

 では、実際のレスポンスに含まれるヘッダーを観察してみましょう。なお、この解説で使用するツールである「プロトコルビュワー」のインストール方法などについては、第1回を参照してください。

図7 送ったリクエストと返ってきたレスポンス

 プロトコルビュワーを立ち上げ、初期値のままで@ITのWebサイトに接続すると、図7のようなレスポンスが返ってきました。レスポンスに含まれる内容は、サーバーの設定や状態によって多少変わることがあるため、必ずしもこの図と同一になるとは限りませんが、おそらくは皆さんの画面にも、これと似たような内容が表示されているはずです。

 さて、このレスポンスはどのような意味を持つのでしょうか。図8に、ヘッダーフィールド1行ごとの意味を示します。

図8 レスポンスに含まれる各情報の意味

 以下は、各行についての解説です。少し長くなりますが、図8と照らし合わせながら確認してみてください。

(0)ステータス行を見ると、ステータスコード「200」が返ってきています。図3で説明した通り、これはリクエストの処理(この例ではGETメソッドによる取得処理)が正常に完了したことを示しています。なお、GETメソッドが正常に処理されたときは、取得した内容がメッセージ本体部分に格納されますが、この図ではその部分は省略しています。

(1)キャッシュ制御情報(Cache-Controlヘッダー)では、返送した内容が、ブラウザーのキャッシュの中でいつまで有効かを示しています。この例では1800秒(30分)となっています。なお、キャッシュとは、サーバーから取得した情報を手元のコンピューターなどにしばらく保存しておき、有効期間中に再度読み出し指示があった場合に、サーバーからの読み出しを省略して、手元の情報で代用する仕組みです。

(2)内容の形式(Content-Typeヘッダー)は、返送した内容がどのような情報なのかを示します。例えば、HTMLならtext/html、文字だけのテキストならtext/plain、画像ならimage/jpeg(JPEG形式)やimage/gif(GIF形式)といったフィールド値をとります。

(3)内容を生成した日時(Dateヘッダー)は、返送した内容を生成した日時を示します。日時の末尾にGMTとある場合、その日時はグリニッジ標準時で表されています。従って、その値に9時間を足したものが日本時間になります。

(4)古くなったと見なせる日時(Expiresヘッダー)は、(1)と同様に、この内容がいつまで有効かを示しています。つまり、主旨は(1)と同じです。ではなぜこのフィールドが必要なのかというと、例えば、時間を測ることはできるが、正確な現在時刻を取得することができないコンピューターの場合、(4)だけでは有効期間を判定できないためです。

(5)サーバープログラムの名称やバージョン(Serverヘッダー)は、このレスポンスを返してきたサーバーがどのようなものかを表しています。ここでは「nginx(エンジンエックス)」という種類のWebサーバーであることが示されています。

(6)(7)結果に影響を与える可能性のあるリクエストヘッダー(Varyヘッダー)は、その値に示すヘッダーがリクエストに含まれていた場合に、値によってサーバーが返送する内容が変わる可能性があることを示しています。例えば、リクエストに含まれる「Accept-Encoding」は、リクエストを出す側が「自分はこんな形式が受け取れる」ということを示す情報です。サーバーはその内容に応じて、異なる形式で結果を送ります。同じく、リクエストに含まれる「User-Agent」はブラウザーなどの種類を表す情報で、サーバーはブラウザーなどの種類によっても、異なる結果を返す可能性があるということになります。

(8)内容の転送形式(Transfer-Encodingヘッダー)は、メッセージ本体に特定の形式が採用されていることを示しています。値としては、「チャンク形式」「圧縮形式」などの値をとります。この例では、チャンク形式を使用していることが示されています。チャンク形式は、返送内容をチャンク(小さなかたまり)に小分けして返送する方式です。詳細については、機会があれば本連載でも取り上げたいと思います。ちなみに、チャンク形式を使わないときは、「Content-Length」ヘッダーにより、返送した内容のサイズが示されます。

(9)接続状態の通知(Connectionヘッダー)は、レスポンスを返した後に、この接続がどのような状態になるかを示しています。HTTPでは、一つのリクエストに対して一つのレスポンスを返したら、接続を切断するのが原則です。しかし、クライアントがすぐに次のリクエストを送るような場合には、レスポンスを返送するたびに接続を切るのは非効率です。このような場合には、レスポンス返送後にも接続を切らずにおくという手法が使われます。これを「keep-alive」と呼びます。このヘッダーは、接続状態をkeep-aliveにしていることを示しています。

 このように、ヘッダーには、リクエストやレスポンスに関するさまざまな詳細情報が含まれています。次回は、ヘッダーと認証の関係など、さらに踏み込んだ話題を取り上げます。お楽しみに!

鬯ゥ謳セ�ス�オ�ス�ス�ス�コ鬯ョ�ヲ�ス�ョ髯キ�サ�ス�サ�ス�ス�ス�ソ�ス�ス�ス�ス鬯ッ�ッ�ス�ィ�ス�ス�ス�セ�ス�ス�ス�ス�ス�ス�ス�」鬯ッ�ョ�ス�エ髣費ソス�ス�・�ス�ス�ス�ウ�ス�ス�ス�ィ�ス�ス�ス�ス髯懶ス」�ス�、�ス�ス�ス�ク�ス�ス�ス�イ鬯ゥ蠅捺��ス�ソ�ス�ス�ス縺、ツ€�ス�ス�ス�ス�ス�ス�ス�」鬯ッ�ョ�ス�エ鬯ゥ蟶壽桶�ス�ュ鬮ョ�」�ス�ソ�ス�ス�ス�ス�ス�ィ鬮ッ蛹コ�サ繧托スス�ソ�ス�ス�ス�ス�ス�ス�ス�ス�ス�コ鬮」蛹�スス�オ髫エ謫セ�ス�エ�ス�ス隶難ス」�守「托スュ雜」�ス�「�ス�ス�ス�ス�ス�ス�ス�ゥ鬯ゥ蟷「�ス�「髫エ雜」�ス�「�ス�ス�ス�ス�ス�ス�ス�シ鬯ゥ蟷「�ス�「髫エ荳サ�ス隶捺サゑスソ�ス邵コ�、�つ€鬯ッ�ョ�ス�ヲ�ス�ス�ス�ェ鬩包スカ闔ィ�ス�ス�ヲ�ス�エ�ス縺、ツ€髯キ闌ィ�ス�キ�ス�ス�ス�ス�ス�ス�ス�サ鬯ッ�ッ�ス�ェ�ス�ス�ス�ュ�ス�ス�ス�ス�ス�ス�ス�イ鬯ゥ謳セ�ス�オ�ス�ス�ス�コ鬮ッ�キ�ス�キ�ス�ス�ス�カ�ス�ス�ス�ス�ス�ス�ス�ス New
前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

Master of IP Network 鬯ョ�ォ�ス�ェ髯区サゑスソ�ス�ス�ス�ス�コ髣包スオ隴∵コキ�ク�キ�ス�ケ隴趣ス「�ス�ス�ス�ウ鬩幢ス「�ス�ァ�ス�ス�ス�ュ鬩幢ス「隴趣ス「�ス�ス�ス�ウ鬩幢ス「�ス�ァ�ス�ス�ス�ー

鬮ォ�エ陝キ�「�ス�ス�ス�ャ鬮ォ�エ鬲�シ夲スス�ス�ス�・鬮ォ�エ陝カ�キ�ス�」�ス�ッ髣厄スォ�ス�」

注目のテーマ

4AI by @IT - AIを作り、動かし、守り、生かす
Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。