Hypertext Transfer Protocol

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内検索
TCP/IP群
アプリケーション層

BGP / DHCP / DNS / FTP / HTTP / IMAP / IRC / LDAP / MGCP / NNTP / NTP / POP / RIP / RPC / RTP / SIP / SMTP / SNMP / SSH / Telnet / TFTP / TLS/SSL / XMPP

カテゴリ
トランスポート層

TCP / UDP / DCCP / SCTP / RSVP / ECN

カテゴリ
ネットワーク層

IP (IPv4, IPv6) / ICMP / ICMPv6 / IGMP / IPsec

カテゴリ
リンク層

ARP/InARP / NDP / OSPF / トンネリング (L2TP) / PPP / MAC (イーサネット, IEEE 802.11, DSL, ISDN, FDDI)

カテゴリ

Hypertext Transfer Protocol(ハイパーテキスト・トランスファー・プロトコル、略称 HTTP)とは、WebブラウザWebサーバの間でHTMLなどのコンテンツの送受信に用いられる通信プロトコルである。RFC 2616で規定されている。ハイパーテキスト転送プロトコルとも呼ばれる。

概要[編集]

名前の通り、 HTML (HyperText Markup Language) や XML (Extensible Markup Language) によって記述されたハイパーテキストの転送を主な目的としているが、それ以外にも、バイナリ形式の画像、音声を含め、様々なデータを扱うことが可能である。

トランスポート・プロトコルとして通常TCPを使用する。

HTTPはリクエスト-レスポンス型のプロトコルであり、クライアントがサーバにリクエストメッセージを送信する。 基本的な考え方は非常に単純で、「何を」「どうして」欲しいのかを伝える。URLが「何を」、メソッドが「どうして」に当たる。 サーバはこれにレスポンスメッセージを返し、基本的にこの時点で初期状態に戻る。つまり、サーバはクライアントの状態を保存しない。

World Wide WebにおけるWebページなどのリソースは、Uniform Resource Identifierによって指定される。HTTP を使用してリソースにアクセスするときは、http: が先頭についた URL を使用する。下にURL の例を挙げる。

http://www.example.co.jp/~test/samples/index.html

最初のHTTP/0.9ではURLのみの簡単なやりとりであったが、HTTP/1.0でNNTPSMTPのような各種ヘッダが定義され、HTTP cookieなどの利用が可能になった。HTTP/1.1では複数データを効率よく転送するための持続的接続や、プロキシの利用等も想定した仕様になった。

このほかの点を箇条書きで示す。

  • ポート番号80デフォルトとして使用する。
  • TLSで暗号化され、セキュリティを確保したHTTPは、HTTPSと呼ばれる(httpsは実際にはURIスキームの1つであり、実際のプロトコルにはHTTP over SSL/TLSが用いられる)。
  • HTTP は基本的にサーバが状態を保持しない (stateless) プロトコルだが、データベースなどを使用するWebアプリケーションにおいては状態保持が必要だったため、そのためにいわゆる Cookie とよばれる機構が Netscape Communications Corporation によって導入された。Cookie を使用することによって状態を管理し、"セッション" を維持することが可能になる。
  • HTTPの拡張プロトコルとしてWebDAVがある。
  • UPnPでは、HTTPをUDP上で使用するHTTPUや、マルチキャストで使用するHTTPMUが規定された。
  • 行末文字はWindowsと同じCRLFである。

歴史[編集]

イギリスの物理学者ティム・バーナーズ=リー1990年末、ロバート・カイリューと共に初のWebブラウザとWebサーバを作成した。ブラウザには通信をするためのプロトコルが必要だったので、二人はHTTPの最初期のバージョンを設計した。

以来インターネットの大部分をHTTP通信が占めるようになり、1998年にはインターネット上の通信の75%がHTTPによるものになった。

最初期のHTTP/0.9の仕様書は紙に印刷すれば1枚で済むような非常に簡素なドキュメントであったが、2度のバージョンアップを経たHTTP/1.1の仕様書は実に176ページ近くの分量に膨れあがった。

HTTP/1.1[編集]

名前ベースバーチャルホストをサポートした。 インターネット人気に伴い多くの企業がWebサイトを持ち始めたが、当時はまだまだ企業が自前のWebサーバを運用するのは人員、効率の問題で難しく、ISPのサーバでホスティングをしていた。また、一社ごとに専用サーバを用意するほどのことでもないため、一台のサーバで複数のWebサイトを運用していた。

しかし、IPアドレスのみで相手を特定するHTTP/1.0はこれに対応できなかった。 例えば、ある1台上のサーバに foo.example.com と bar.example.com という二つの仮想Webサーバがあり、クライアントは http://foo.example.com/index.html にアクセスしたいとする。この場合はDNSサーバに foo.example.com のIPアドレスを問い合わせ、次にそのIPアドレスを使って該当サーバにアクセスし、GET index.html を要求することになる。しかし同じサーバ上にある bar.example.comもIPアドレスは同じであり、もし両方の仮想サーバに index.html というファイルが存在すれば、クライアントがどちらにアクセスしようとしているのか、判別できない。

対策としてはそれぞれにIPアドレスを付与する方法もあるが、IPv4の資源を無駄にすることになる。 この問題を解決するため、Hostヘッダが追加された。

HTTP/1.0のリクエスト
GET /index.html HTTP/1.0
HTTP/1.1のリクエスト
GET /index.html HTTP/1.1 Host: foo.example.com

動作[編集]

通信の開始[編集]

他のプロトコル同様、クライアント側とサーバ側では役割が大きく異なる。HTTP通信を開始できるのはクライアント側のみである。

クライアント側がサーバにリクエストを送り、サーバがクライアントにレスポンスを返すのが最も典型的なHTTPのやりとりである。

接続[編集]

システム間でメッセージをやりとりするにはTCP接続を確立させる必要がある。

HTTP/0.9ではクライアントのリクエストごとにTCP接続を確立させる必要があったが、これは当時のWebサイトがシンプルなテキストベースであることが多かったためである。近年ではJavaScriptやアニメーション画像など、多数のオブジェクトが埋め込まれたWebサイトが一般的となってきており、これらのオブジェクトを取得するたびにTCP接続を確立するのはサーバやネットワークに大きな負担を強いるため、HTTP/1.1では持続的接続がサポートされることとなった。ただし、この機能が利用できるのはサーバ側がその要求を許可した場合のみである。

パイプライン[編集]

クライアントは前のリクエストに対するサーバの応答を待たずに別のリクエストを発行できる。

メソッド[編集]

HTTPでは8つのメソッドが定義されている。ただし、実際のHTTP通信ではGETとPOSTメソッドだけで殆どを占める。

HTTPメソッドの一覧
メソッド HTTP/0.9 HTTP/1.0 HTTP/1.1
GET
POST
PUT
HEAD
DELETE
OPTION
TRACE
CONNECT
GET
指定されたURIのリソースを取り出す。HTTPの最も基本的な動作で、HTTP/0.9では唯一のメソッド。
POST
GETとは反対にクライアントがサーバにデータを送信する。Webフォームや電子掲示板への投稿などで使用される。GETの場合と同じく、サーバはクライアントにデータを返すことができる。
PUT
指定したURIにリソースを保存する。URIが指し示すリソースが存在しない場合は、サーバはそのURIにリソースを作成する。画像のアップロードなどが代表的。
DELETE
指定したURIのリソースを削除する。
OPTION
サーバを調査する。例えば、サーバがサポートしているHTTPバージョンなどを知ることができる。
HEAD
GETと似ているが、サーバはHTTPヘッダのみ返す。クライアントはWebページを取得せずともそのWebページが存在するかどうかを知ることができる。例えばWebページのリンク先が生きているか、データを全て取得することなく検証することができる。
TRACE
サーバまでのネットワーク経路をチェックする。サーバは受け取ったメッセージのそれ自体をレスポンスのデータにコピーして応答する。WindowsのTracertやUNIXのTracerouteとよく似た動作。
CONNECT
暗号化したメッセージをプロキシで転送する際に用いる。

サーバの連携[編集]

バーチャルホスト[編集]

上記参照

リダイレクト[編集]

301 MovedというステータスコードとURIを受け取り、クライアントはこのURIに再度、GETメソッドを実行する。

クッキー[編集]

HTTPメッセージ[編集]

クライアントからのHTTPリクエストはメソッド、URI、HTTPバージョンの3つの要素から構成され、それぞれスペースで区切られる。 下にもっとも単純なクライアントとサーバ(www.google.co.jp:80)とのやり取りの例を挙げる。

クライアントのリクエスト:

GET / HTTP/1.0

メソッドはGET、URIは「/」、HTTPバージョンは1.0である。

GETはリソースを取得するためのメソッドであり、URIの「/」はルートリソースを対象にしたリクエストであることを示している。

サーバのレスポンス:

HTTP/1.0 200 OK
Cache-Control: private
Content-Type: text/html
Set-Cookie: PREF=ID=72c1ca72230dea65:LD=ja:TM=1113132863:LM=1113132863:S=nNO7MIp
W2o7Cqeu_; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.co.jp
Server: GWS/2.1
Date: Sun, 10 Apr 2005 11:34:23 GMT
Connection: Close

<html><head><meta http-equiv="content-type" content="text/html; charset=Shift_JI
S"><title>Google</title><style><!--
・・・以下省略

先頭のステータス行はHTTPバージョン、ステータスコード、メッセージから構成される。 ステータスコードの「200」は処理の成功を表し、これを補足するメッセージが「OK」である。

2行目以降にヘッダ情報が続く。 さらに空行を挟んで、コンテンツ本体となる。

HTTPヘッダフィールド[編集]

ヘッダの各要素は

フィールド名: 内容

のペアで構成される。

ブラウザの情報を表すUser-Agent、使用候補言語を表すAccept-Language、他ページへのリンクを辿った場合にそのリンク元ページのURLを表すRefererなどが代表的なフィールドである。

なお、リクエスト時のHostヘッダはHTTP/1.1では必須であるが、HTTP/1.0ではなくてもよい。 ただし、サーバがバーチャルホストを利用している場合は、Hostヘッダがないとリソース取得に失敗するので、たとえHTTP/1.0を使用していてもHostヘッダを付加しなければならない。

HTTPヘッダフィールドの一覧[編集]

リクエストヘッダ
ヘッダ 概要 HTTP/0.9 HTTP/1.0 HTTP/1.1
Accept クライアントの受け入れ可能コンテンツタイプを示す
Accept-Charset クライアントの受け入れ可能文字セットを示す
Accept-Encoding クライアントの受け入れ可能文字エンコーディングを示す
Accept-Language クライアントの受け入れ可能言語を示す
Authorization クライアントの認証情報を示す
Cookie クライアントの状態管理情報をサーバに返す
Cookie2 HTTP/1.1のSet-Cookie2ヘッダの受け入れ可能をサーバに知らせる
Expect クライアントがサーバに期待する動作を示す
From リクエスト発行者個人の情報を示す。一般的に電子メールアドレスを使用する
Host 要求しているオブジェクトがあるホストを示す
If-Match if文を用い条件が真の場合のみリクエストを処理するようサーバに要求する
If-Modified-Since 指定日時以降にオブジェクトが変更されている場合のみリクエストを処理するよう要求する
If-None-Match If-Matchの逆で条件が真でない場合のみリクエストを処理する要求
If-Range 条件が真の場合のみ指定したオブジェクトの範囲を返すようサーバに要求する
If-Unmodified-Since If-Modified-Sinceの逆で真でないときのみ実行する
Max-Forwards リクエストの中間システム経由数を最大いくつまでかを指定する
Proxy-Authorization クライアントがプロキシサーバに対して自身の認証を行う
Range オブジェクト全体でなくリソースの一部を要求する
Referer リクエストの出所を示す。一般的にはユーザの辿ったWebページのURLが用いられる
TE レスポンスの受け入れ可能転送エンコーディングを示す
User-Agent クライアントのWebブラウザなどの情報を示す
レスポンスヘッダ
ヘッダ 概要 HTTP/0.9 HTTP/1.0 HTTP/1.1
Accept-Ranges オブジェクトの一部に対するリクエストをサーバが受け入れ可能か示す
Age オブジェクトの経過時間を秒単位で返す
ETag オブジェクトのエンティティタグ値を示す
Location オブジェクトの場所を示す
Proxy-Authenticate プロキシサーバがクライアントに認証を要求するときに用いる
Retry-After リクエストの再試行をいつ行うかをクライアントに通知する
Server サーバのベンダー名、バージョン番号を示す
Set-Cookie2 サーバがクライアントにCookieを送信するときに用いる
Vary サーバがレスポンス内容を決定する際にリクエストURI以外に用いたヘッダのリストを示す
WWW-Authenticate クライアントに対してリクエストの再発行を要求する。認証情報も含まれる
一般ヘッダ
ヘッダ 概要 HTTP/0.9 HTTP/1.0 HTTP/1.1
Cache-Control メッセージの経由する中間キャッシュの動作を指示する
Connection 中間システムが転送すべきでないヘッダのリストを示す
Date メッセージの作成日時を示す
Pragma メッセージに関する追加情報を示す
Trailer メッセージボディの後に追加のヘッダーが表れることを示す
Transfer-Encoding クライアントの転送を目的としたオブジェクトのエンコーディングを示す
Upgrade 通信相手に別のプロトコルにアップデートするよう要求する
Via プロキシサーバ等中継地点を示す。
Warning メッセージに関する追加情報を示す。通常はキャッシュの問題を警告するときに使われる
エンティティヘッダ
ヘッダ 概要 HTTP/0.9 HTTP/1.0 HTTP/1.1
Allow オブジェクトがサポートするHTTPメソッドを示す
Content-Encoding オブジェクトのエンコーディングを示す
Content-Language オブジェクトの言語(人間の言語)を示す
Content-Length オブジェクトのサイズをバイト単位で示す
Content-Location オブジェクトの場所を示す
Content-MD5 オブジェクトのメッセージダイジェストを運ぶ
Content-Range メッセージボディで運ばれるオブジェクトの範囲を示す
Content-Type オブジェクトのタイプを示す
Expires オブジェクトの有効期限の日時を示す
Last-Modified オブジェクトが最後に変更された日時を示す
Accept
サーバのレスポンスに含まれるメッセージボディで受け入れることが出来るコンテンツタイプと各コンテンツタイプの相対的な優先度を指定するリクエストヘッダ。指定できるコンテンツタイプはIANAによって定義されている。
Accept: text/plain; q=0.5, text/html,
        text/x-dvi; q=0.8, text/x-c
上記のようにAcceptヘッダには行をわけて複数のコンテンツタイプを指定できる。上記の例はいずれの4のコンテンツタイプのいずれも受け入れ可能であることを示す。0.5や0.8といった数字は品質係数で0~1の範囲の数値である。数値の指定がなければ1.0となる。
  • text/plain; q=0.5
  • text/html
  • text/x-dvi; q=0.8
  • text/x-c
Accept-Charset
レスポンスで返されるメッセージボディの文字コードを指定するリクエストヘッダ。Acceptと同じく複数指定でき品質係数も設定できる。定義済み文字セットはIANAが管理している。
Accept-Charset: unicode, *; q=0.8
この例だとクライアントはUnicode文字セットを優先的に希望しているが他の文字セットとの相対優先度0.8で受け入れている。ただしサーバからのレスポンスのHTTPヘッダそのものの文字コードは常にISO-8859-1である。
Accept-Encoding
クライアントが受信できるメッセージボディのエンコーディングを指定する。
Accept-Encoding: gzip, deflate
この例ではクライアントはgzip、またはzlibフォーマットに対応している。ただし必ずしもここで指定されたエンコーディングでメッセージボディが返ってくるとは限らない。
Accept-Language
レスポンスの言語(人間の言語)に対する優先度を指定する。言語コードはISO-639の2文字の省略コードを用いる。書き方は他のAccept-群と変わらず。
Accept-Language: en-gb, en; q=0.8
上記の例はまずイギリス英語を要求し、利用できない場合はその他の英語を要求する。
Accept-Ranges
Acceptで始まる他のヘッダフィールドと違いレスポンスヘッダである。現在の仕様では2つの指定方法しかない。
Age
リソースの推定経過時間を表示するレスポンスヘッダ。キャッシュサーバーはAgeヘッダの値からキャッシュしたリソースが有効かどうかを判定する。
Allow
Authentication-info
ユーザ認証のやりとりの最後で用いられる、成功したレスポンスのサーバが含めることの出来るレスポンスヘッダ。
Authorization
サーバに対するクライアント自身の認証を行うことが出来る。
Cache-Control
キャッシングの動作を指定するためのマスターヘッダ。
Connection
Content-Encoding
Content-Language
リソースを英語などの自然言語で示すのに使われる。言語の指定はAccept-Languageヘッダと同じ。
Content-Length
Content-Location
Content-MD5
メッセージボディが変更されず宛先に届くことを保証する。MD5アルゴリズムを実行する。ただし悪意の改ざんに対しては当然MD5も改ざんされるのであまり機能はしない。どちらかといえば偶発的な変更の保証をしている。
Content-Range
ダウンロードの再開に用いられる。
Content-Type
メッセージボディに含まれるオブジェクトタイプを示す。次の例はリソースがテキストファイル、文字セットはISO-8859-4を使用していることを示している。
Content-Type: text/plain; Charset=ISO-8859-4
Cookie
クライアントがHTTP状態管理を望む場合にサーバから受け取ったクッキーを以後のリクエストに次の例のようなヘッダを付加する。
Cookie: $Version="1"; NAME="VALUE";
        $Path="/shopping"; $domain="www.shop.com"+
        $Port="80"
$VersionはHTTPのバージョン、NAMEはクッキーの名前である。$から始まるクッキー名は使用が禁止されている。
Cookie2
基本的にCookieヘッダとCookie2ヘッダは別物である。
Date
サーバがメッセージを生成した日時を示す。リソースの更新日時を示すLast-Modifiedヘッダとは別である。
HTTP/1.1では次のような形式を用いるようRFC1123で定義されている。
Date: Sun, 06, Nov 1994 08:49:37 GMT
HTTP仕様ではレスポンスにDateヘッダを含めることを求めている。ただしレスポンスのステータスがサーバエラーの場合にはDateヘッダは返らない。
ETag
主にキャッシングのパフォーマンスを向上する目的で使われる。
Expect
サーバに対して特定の動作の期待を知らせる。用途としてはクライアントがサーバに対して100 Continueステータスを返すことを期待する場合に使われる。
Expect: 100-continue
サーバが期待に応じられない場合は417 Expectation Failedを返す。クライアントがいくつかのプロキシ経由で通信している場合、各プロキシサーバはExpectヘッダの一切の修正を許されない。
Expires
オブジェクトの有効期限を示す。このヘッダで指定された日時までキャッシュはレスポンスのコピーを保持し、リクエストに対するレスポンスとして返すことができる。サーバがオブジェクトのキャッシュを望まない場合にはExpiresヘッダに過去の日時を設定することが多い。仕様では1年以上先の日時は設定できない。
Expires: Thu, 28 Aug 2010 16:00:00 GMT
Cache-Controlヘッダのmax-ageディレクティブはExpiresヘッダより優先されるため注意が必要である。
From
リクエストを発行したユーザを特定することが出来る。1990年代では電子メールアドレスを設定することが多かったが、迷惑メールの問題もあり現在では殆ど使われていない。
From: user@example.com
Host
主にレンタルサーバのサポートを目的としてHTTP/1.1で導入された。現在ではHostヘッダを利用できない場合、レンタルサーバのWebサイトとまともな通信ができないと言ってよい(詳細はHTTP#歴史を参照)。
If-Match
ETagが一致した場合のみ、メソッドを実行するようにサーバに要求する。例えばウィキペディアを編集する際、記事のソースを取得し、書き換える際の間に別のユーザが既に編集していないかを判断するときなどに用いられる。
  1. 利用者:AがHTTPの記事を取得。ETagは1234。
  2. 利用者:BがHTTPの記事を取得。ETagは1234。
  3. 利用者:AがHTTPのETagを再度取得。先ほど取得したETag: 1234と現在のETag: 1234が一致。
  4. 利用者:AがHTTPの記事を編集。ETagは1256になる。
  5. 利用者:BがHTTPのETagを再度取得。先ほど取得したETagと現在のETagはマッチせず。
  6. サーバは利用者:Bの書き込みを拒否。
If-Modified-Since
指定日時以降にオブジェクトが変更されている場合のみ、メソッドを実行するようにサーバに要求する。通信量の削減に効果がある。
If-None-Match
If-Matchの逆で、ETagが一致しない場合のみの実行を要求する。
If-Range
クライアントがキャッシュにオブジェクトの一部分を持っている場合にパフォーマンスを向上できる。
If-Unmodified-Since
If-Modified-Sinceの逆で、指定時刻以降に変更がない場合のみの実行を要求する。
Last-Modified
レスポンスでオブジェクトの最終更新日時を示す。リクエスト時のIf-Modified-Sinceヘッダと組み合わせることで、効率的な通信が可能になる。
Location
サーバがクライアントにリダイレクト先URLを知らせる際に用いられる。一般的にステータスコードが3xx代のレスポンスと共に使われるが201 Createdのレスポンスでも使うことができる。Content-Locationヘッダと名前が似ているが全く関係のない別のヘッダであるため注意。
Max-Forwards
プロキシサーバ等を経由する際の最大ホップ数を指定する。二重ループなどでサーバから応答が得られない場合の問題解決の際、OPTIONメソッドやTRACEメソッドと共に用いられる。

HTTPステータスコード[編集]

ステータスコードはサーバからのレスポンスで、リクエストの結果を通知する。3桁の数字から成り、おおまかな分類として、1xxは「情報」、2xxは「成功」、3xxは「リダイレクト」、4xxは「クライアントエラー」、5xxは「サーバエラー」を示す。

セキュリティ技術[編集]

Basic認証[編集]

HTTP/1.1でBasic認証が定義されており最も単純なセキュリティ技術である。しかし仕様書を読むと定義を書いた著者自身が認証技術に疎いことがよくわかる。『HTTPプロトコル セキュア&スケーラブルなWeb開発』の著者は「基本認証を用いるくらいならなにも使わない方がまし」と著書に書いている。通常サーバはステータスコード401で応答する。

Digest認証[編集]

関連項目[編集]

外部リンク[編集]