Loading AI tools
分散共同ハイパーメディア情報システムのためのアプリケーション・プロトコル ウィキペディアから
Hypertext Transfer Protocol（ハイパーテキスト・トランスファー・プロトコル、HTTP）はアプリ間コネクション上のリクエスト/レスポンス型・ステートレス・メッセージ指向通信プロトコルである[1]。
TCPやQUICはアプリケーション間のコネクション型通信を提供する。HTTPはこのコネクション上を、リソース要望と返答が、メッセージ単位で、1往復のクライアントリクエスト&サーバーレスポンスという形で通信される、と定めたプロトコルである[1]。
HTTPの発明により、インターネット上でのリソース公開とアクセスが容易になった。クライアントがサーバーとコネクションを確立し1つのHTTPメッセージを書いて送るだけで、サーバー上のリソースがHTTPメッセージとして帰ってくる。ゆえにHTTPで公開されるあらゆるリソースにHTTPという単一の手法でアクセスできるようになった。
HTTPを開発した理由でありかつ現在も広く利用される用途はWorld Wide Webである。WebサーバとWebブラウザはHTTPで主に通信しており、ブラウザからのHTTPメッセージに応答してサーバーがHTMLテキストやJavaScriptコードを送り返し、これをブラウザで表示することでウェブが成立している。
またHTTPはメッセージ形式を定める。基本的な考え方は単純で「何を」「どうして」欲しいのかを伝える。例えばリクエストメッセージ GET /apple.jpg は「apple.jpg 画像を、手に入れたい」を意味する。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 で改良された。
HTTP/1.1 では複数データを効率よく転送するための持続的接続や、プロキシの利用なども想定した仕様になった。さらに HTTP/2やHTTP/3が策定された。現在ではHTTPセマンティクスと各バージョンの手続きが分離して定義されている（#規格を参照）。
このほかの点を箇条書きで示す。
イギリスの物理学者ティム・バーナーズ＝リーは1990年末、ロバート・カイリューと共に初のWebブラウザとWebサーバを作成した。ブラウザには通信をするためのプロトコルが必要だったので、二人はHTTPの最初期のバージョンを設計した。
以来インターネットの大部分をHTTP通信が占めるようになり、1998年にはインターネット上の通信の75%がHTTPによるものになった。
最初期のHTTP/0.9の仕様書は紙に印刷すれば1枚で済むような非常に簡素なドキュメントだったが、2度のバージョンアップを経たHTTP/1.1の仕様書は実に176ページ近くの分量に膨れあがった。
1991年に最初にドキュメント化されたバージョン[2]。メソッドは GET しかなかった。レスポンスは単純にドキュメントの内容を返してコネクションを切断するだけで、レスポンスコードの規定もない。下記は、HTTP/0.9 のリクエストの例。
GET /index.html
1996年5月に RFC 1945 として発表された。仕様が RFC で扱われるようになった。メソッドに POST など GET 以外のものが増えた。レスポンスはヘッダーがつくようになり、ステータスコードを含めるようになった。HTTP/0.9 と区別するため、リクエストプロトコルにバージョンを含めることになった。
HTTP/2の目標はHTTP/1.1のトランザクション・セマンティクスとの完全な後方互換性を維持したまま非同期な接続の多重化、ヘッダ圧縮、リクエストとレスポンスのパイプライン化を実現することである。Googleによって立ち上げられ[3]、GoogleのブラウザーであるChromeだけではなく、他にも、Opera、Firefox、Amazon Silkなどが対応しているHTTP互換のプロトコルSPDYの人気が高まっていることに対応するために開発された[4]。
HTTP-over-QUIC（hq）としてIETFが開発していた新たな通信プロトコルが、HTTP/3へと改名される。[5] IETFが策定を進めているQUICはトランスポート層におけるプロトコルの名称であり、アプリケーション層プロトコルであるHTTP-over-QUICとの区別を明確にするため、このような名称変更に至った。[6]
HTTP/2と比べ、多重化するストリームの取り扱いが下位層のQUICへ移行したこと[7]、ヘッドオブラインブロッキングを回避するためのヘッダ圧縮の変更（HTTP/3用にQPACKが開発されている）[8]などの差異がある。
他のプロトコル同様、クライアント側とサーバ側では役割が大きく異なる。HTTP通信を開始できるのはクライアント側のみである。
クライアント側がサーバにリクエストを送り、サーバがクライアントにレスポンスを返すのが最も典型的なHTTPのやりとりである。
システム間でメッセージをやりとりするには接続を確立させる必要がある。HTTP/0.9～HTTP/1.1およびHTTP/2ではTCPを使用する。
HTTP/0.9ではクライアントのリクエストごとにTCP接続を確立させる必要があった。これは当時のWebサイトがシンプルなテキストベースであることが多かったためである。近年ではJavaScriptやアニメーション画像など、多数のオブジェクトが埋め込まれたWebサイトが一般的となってきており、これらのオブジェクトを取得するたびにTCP接続を確立するのはサーバやネットワークに大きな負担を強いるため、1回のTCP接続で、複数のHTTPリクエスト・レスポンスをやり取りする持続的接続がHTTP/1.0の拡張として導入された。その後、HTTP/1.1では、持続的接続がデフォルトとなった。すなわち、何も指定しなければ持続的接続となり、持続的接続を望まなければヘッダーフィールドにConnection: closeを追加する仕様となっている。
クライアントは前のリクエストに対するサーバの応答を待たずに別のリクエストを発行できる。
HTTPでは8つのメソッドが定義されている。ただし、実際のHTTP通信ではGETとPOSTメソッドが大部分を占める。
| メソッド | HTTP/0.9 | HTTP/1.0 | HTTP/1.1 |
|---|---|---|---|
| GET | ○ | ○ | ○ |
| POST | ○ | ○ | |
| PUT | △ | ○ | |
| HEAD | ○ | ○ | |
| DELETE | △ | ○ | |
| OPTIONS | ○ | ||
| TRACE | ○ | ||
| CONNECT | ○ |
HTTPの仕様以外で定義しているメソッドは、IANAのHypertext Transfer Protocol (HTTP) Method Registry[11]で管理されている。WebDavで使用するものや、 RFC 5789 のPATCHメソッドなどがある。
1つのサーバーで複数のホスト名に対するHTTPリクエストを受け付ける機能である。
インターネット人気に伴い多くの企業がWebサイトを持ち始めたが、当時はまだまだ企業が自前のWebサーバを運用するのは人員、効率の問題で難しく、ISPのサーバでホスティングをしていた。また、1社ごとに専用サーバを用意するほどのことでもないため、1台のサーバで複数のWebサイトを運用していた。
しかし、IPアドレスのみで相手を特定するHTTP/1.0はこれに対応できなかった。例えば、ある1台のサーバに foo.example.com と bar.example.com という2つの仮想Webサーバがあり、クライアントは http://foo.example.com/index.html にアクセスしたいとする。この場合はDNSサーバに foo.example.com のIPアドレスを問い合わせ、次にそのIPアドレスを使って該当サーバにアクセスし、GET index.html を要求することになる。しかし同じサーバ上にある bar.example.comもIPアドレスは同じであり、もし両方の仮想サーバに index.html というファイルが存在すれば、クライアントがどちらにアクセスしようとしているのか、判別できない。
対策としてはそれぞれにIPアドレスを付与する方法もあるが、IPv4の資源を無駄にすることになる。この問題を解決するため、HTTP/1.1でHostヘッダーフィールドが追加され、名前ベースバーチャルホストが用いられるようになった。
名前ベースバーチャルホストのため、以下のようにHTTPリクエストでホスト名を指定する。
別のURIに対して再度のメソッド実行を要求する機能である。301 Movedや303 See Otherなどのリダイレクトを指示するステータスコードとURIを受け取り、クライアントはこのURIに再度メソッドを実行する。
リクエストとレスポンスでやり取りされるデータは、HTTPメッセージと呼ばれる。クライアントからリクエストHTTPメッセージを送り、サーバーからレスポンスHTTPメッセージを返す。
HTTPメッセージは以下で構成される[12]。
なおHTTP/1.1では、コントロールデータをリクエスト行・ステータス行として表現し、コンテントを格納する部分をメッセージボディまたは単にボディと呼ぶ。
ヘッダー・コンテント・トレイラーは空となる場合もある。
下にもっとも単純なクライアントとサーバ(www.google.co.jp:80)とのやり取りの例を挙げる。
クライアントのリクエスト:
GET / HTTP/1.1
Host: www.google.co.jp
この例では、リクエスト行とヘッダーにフィールドが1項目あるのみで、ボディは空でトレーラーも無い。
リクエスト行はメソッド、リクエストターゲット、HTTPバージョンの3つの要素から構成され、それぞれスペースで区切られる。
メソッドはGET、リクエストターゲットは「/」、HTTPバージョンは1.1である。
GETはリソースを取得するためのメソッドであり、リクエストターゲットの「/」はURIのパス部分であってルートリソースを対象にしたリクエストであることを示している。
サーバのレスポンス:
HTTP/1.1 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行目以降にヘッダフィールドが続く。 さらに空行を挟んで、レスポンスボディとなる。 このレスポンスにもトレーラーは無い。
ヘッダの各要素は
フィールド名: 内容
のペアで構成される。
ブラウザの情報を表すUser-Agent、使用候補言語を表すAccept-Language、他ページへのリンクを辿った場合にそのリンク元ページのURLを表すRefererなどが代表的なフィールドである。
なお、リクエスト時のHostヘッダはHTTP/1.1では必須であるが、HTTP/1.0ではなくてもよい。
ただし、サーバがバーチャルホストを利用している場合は、Hostヘッダがないとリソース取得に失敗するので、たとえHTTP/1.0を使用していてもHostヘッダを付加しなければならない。
| ヘッダ | 概要 | 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-None-Match | If-Matchの逆で条件が真でない場合のみリクエストを処理する要求 | ○ | ||
| If-Range | 条件が真の場合のみ指定したオブジェクトの範囲を返すようサーバに要求する | ○ | ||
| If-Modified-Since | 指定日時以降にオブジェクトが変更されている場合のみリクエストを処理するよう要求する | ○ | ○ | |
| 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: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-c
Accept-Charset: UTF-8, *; q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-gb, en; q=0.8
Content-Type: text/plain; Charset=ISO-8859-4
Cookie: $Version="1"; NAME="VALUE";
$Path="/shopping"; $domain="www.shop.com"+
$Port="80"
Date: Sun, 06, Nov 1994 08:49:37 GMT
Dateヘッダを含めることを求めている。ただしレスポンスのステータスがサーバエラーの場合にはDateヘッダは返らない。Expect: 100-continue
Expiresヘッダに過去の日時を設定することが多い。仕様では1年以上先の日時は設定できない。Expires: Thu, 28 Aug 2010 16:00:00 GMT
Cache-Controlヘッダのmax-ageディレクティブはExpiresヘッダより優先されるため注意が必要である。From: user@example.com
ETagは1234。ETagは1234。ETagを再度取得。先ほど取得したETag: 1234と現在のETag: 1234が一致。ETagは1256になる。ETagと現在のETagはマッチせず。If-Matchの逆で、ETagが一致しない場合のみの実行を要求する。If-Modified-Sinceの逆で、指定時刻以降に変更がない場合のみの実行を要求する。If-Modified-Sinceヘッダと組み合わせることで、効率的な通信が可能になる。Content-Locationヘッダと名前が似ているが全く関係のない別のヘッダであるため注意。OPTIONメソッドやTRACEメソッドと共に用いられる。ステータスコードはサーバからのレスポンスで、リクエストの結果を通知する。3桁の数字から成り、おおまかな分類として、1xxは「情報」、2xxは「成功」、3xxは「リダイレクト」、4xxは「クライアントエラー」、5xxは「サーバエラー」を示す。
いくつかの観点でセキュリティに関する追加機能が存在する。
セキュアな通信路でHTTP通信を行うことを通常HTTPSと言う。
HTTPの中で認証を行う仕組みが用意されている。
HTTP/1.1で定義されている最も単純なセキュリティ技術である。「基本認証を用いるくらいならなにも使わない方がまし」と主張する人もいる[16]。平文で認証情報を送信する仕組みであるため、TLS (HTTPS)など安全を確保した通信路での利用が望ましい。通常サーバはステータスコード401で応答する。
HTTPはIETFを始めとした標準化団体により規格化されている。以下はその一部である。
歴史的には各バージョンが独立して規格化されてきた。しかし現行の3バージョン（v1.1, v2, v3）が共通のセマンティクスを維持していたことから、これを独立した規格とする活動が推進され現在の形になっている[17]。
HTTPSのほか、以下のようなHTTPのセマンティクスを利用するプロトコル、HTTPの構文を元とするプロトコルなどが存在する。以下はその一例である。
なお、このようなHTTPの利用に関する文書として RFC 9205 Building Protocols with HTTP (BCP 56)が存在する。
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
