Hypertext Transfer Protocol
Hypertext Transfer Protocol（ハイパーテキスト・トランスファー・プロトコル、略称 HTTP）とは、HTMLなどのコンテンツの送受信に用いられる通信プロトコルである。主としてWorld Wide Webにおいて、WebブラウザとWebサーバとの間での転送に用いられる。日本標準仕様書ではハイパテキスト転送プロトコルとも呼ばれる。
HTTP/1.1 が RFC 7230 から RFC 7235 で規定されている。かつては RFC 2616 が HTTP/1.1 を規定していたため、こちらもよく参照されている。また、HTTP/2が RFC 7540 で規定されている。
名前の通り、 HTML (HyperText Markup Language) や XML (Extensible Markup Language) によって記述されたハイパーテキストの転送を主な目的としているが、それ以外にも、バイナリ形式の画像、音声を含め、様々なデータを扱うことが可能である。その汎用性からセンサーからの定期的なデータの取得などにも用いられる。
トランスポート・プロトコルとして通常TCPを使用する。
HTTPはリクエスト-レスポンス型のプロトコルであり、クライアントがサーバにリクエストメッセージを送信する。
基本的な考え方は非常に単純で、「何を」「どうして」欲しいのかを伝える。URLが「何を」、メソッドが「どうして」に当たる。
サーバはこれにレスポンスメッセージを返し、基本的にこの時点で初期状態に戻る。つまり、サーバはクライアントの状態を保存しない。
World Wide WebにおけるWebページなどのリソースは、Uniform Resource Identifierによって指定される。HTTP を使用してリソースにアクセスするときは、http: が先頭についた URL を使用する。下にURL の例を挙げる。
最初のHTTP/0.9ではURLを指定してコンテントをダウンロードするのみの簡単なやりとりであったが、HTTP/1.0で改良された。
HTTP/1.1では複数データを効率よく転送するための持続的接続や、プロキシの利用等も想定した仕様になった。
このほかの点を箇条書きで示す。イギリスの物理学者ティム・バーナーズ＝リーは1990年末、ロバート・カイリューと共に初のWebブラウザとWebサーバを作成した。ブラウザには通信をするためのプロトコルが必要だったので、二人はHTTPの最初期のバージョンを設計した。
以来インターネットの大部分をHTTP通信が占めるようになり、1998年にはインターネット上の通信の75%がHTTPによるものになった。
最初期のHTTP/0.9の仕様書は紙に印刷すれば1枚で済むような非常に簡素なドキュメントであったが、2度のバージョンアップを経たHTTP/1.1の仕様書は実に176ページ近くの分量に膨れあがった。
1991年に最初にドキュメント化されたバージョン。メソッドは GET しかなかった。レスポンスは単純にドキュメントの内容を返してコネクションを切断するだけで、レスポンスコードの規定もない。下記は、HTTP/0.9 のリクエストの例。
1996年5月に RFC 1945 として発表された。仕様が RFC で扱われるようになった。メソッドに POST など GET 以外のものが増えた。レスポンスはヘッダーがつくようになり、ステータスコードを含めるようになった。HTTP/0.9 と区別するため、リクエストプロトコルにバージョンを含めることになった。
HTTP/2の目標はHTTP/1.1のトランザクション・セマンティクスとの完全な後方互換性を維持したまま非同期な接続の多重化、ヘッダ圧縮、リクエストとレスポンスのパイプライン化を実現することである。Googleによって立ち上げられ、GoogleのブラウザーであるChromeだけではなく、他にも、Opera、Firefox、Amazon Silk等が対応しているHTTP互換のプロトコルSPDYの人気が高まっていることに対応するために開発された。
HTTP-over-QUIC（hq）としてIETFの開発していた新たなプロトコルが、HTTP/3へと改名される。このプロトコルはUDPをベースにHTTP/2の一部の機能を組み合わせたものとなっている。
IETFが策定を進めているQUICはトランスポート層におけるプロトコルの名称であるが、その中のHTTP-over-QUICとして定められるものを明確に区別する為、このような名称変更に至った。
他のプロトコル同様、クライアント側とサーバ側では役割が大きく異なる。HTTP通信を開始できるのはクライアント側のみである。
クライアント側がサーバにリクエストを送り、サーバがクライアントにレスポンスを返すのが最も典型的なHTTPのやりとりである。
システム間でメッセージをやりとりするにはTCP接続を確立させる必要がある。
HTTP/0.9ではクライアントのリクエストごとにTCP接続を確立させる必要があったが、これは当時のWebサイトがシンプルなテキストベースであることが多かったためである。近年ではJavaScriptやアニメーション画像など、多数のオブジェクトが埋め込まれたWebサイトが一般的となってきており、これらのオブジェクトを取得するたびにTCP接続を確立するのはサーバやネットワークに大きな負担を強いるため、HTTP/1.1では持続的接続がサポートされることとなった。ただし、この機能が利用できるのはサーバ側がその要求を許可した場合のみである。
クライアントは前のリクエストに対するサーバの応答を待たずに別のリクエストを発行できる。
HTTPでは8つのメソッドが定義されている。ただし、実際のHTTP通信ではGETとPOSTメソッドだけで殆どを占める。HTTPの仕様以外で定義しているメソッドは、IANAのHypertext Transfer Protocol (HTTP) Method Registryで管理されている。WebDavで使用するものや、 RFC 5789 のPATCHメソッドなどがある。
上記参照
別のURIに対して再度のメソッド実行を要求する機能である。301 Movedや303 See Otherなどのリダイレクトを指示するステータスコードとURIを受け取り、クライアントはこのURIに再度メソッドを実行する。
リクエストとレスポンスでやり取りされるデータは、HTTPメッセージと呼ばれる。
リクエストメッセージはリクエスト行・ヘッダーフィールド・ボディで構成され、レスポンスメッセージは、ステータス行・ヘッダーフィールド・ボディで構成される。ヘッダーフィールドとボディは空となる場合もある。
下にもっとも単純なクライアントとサーバ(www.google.co.jp:80)とのやり取りの例を挙げる。
クライアントのリクエスト:
この例では、リクエスト行のみで、ヘッダーフィールドとボディは空となっている。
リクエスト行はメソッド、URI、HTTPバージョンの3つの要素から構成され、それぞれスペースで区切られる。
メソッドはcodice_1、URIは「/」、HTTPバージョンは1.0である。
codice_1はリソースを取得するためのメソッドであり、URIの「/」はルートリソースを対象にしたリクエストであることを示している。
サーバのレスポンス:
先頭のステータス行はHTTPバージョン、ステータスコード、メッセージから構成される。
ステータスコードの「200」は処理の成功を表し、これを補足するメッセージが「OK」である。
2行目以降にヘッダフィールドが続く。
さらに空行を挟んで、レスポンスボディとなる。
ヘッダの各要素はのペアで構成される。
ブラウザの情報を表すcodice_3、使用候補言語を表すcodice_4、他ページへのリンクを辿った場合にそのリンク元ページのURLを表すcodice_5などが代表的なフィールドである。
なお、リクエスト時のcodice_6ヘッダはHTTP/1.1では必須であるが、HTTP/1.0ではなくてもよい。
ただし、サーバがバーチャルホストを利用している場合は、codice_6ヘッダがないとリソース取得に失敗するので、たとえHTTP/1.0を使用していてもcodice_6ヘッダを付加しなければならない。ステータスコードはサーバからのレスポンスで、リクエストの結果を通知する。3桁の数字から成り、おおまかな分類として、1xxは「情報」、2xxは「成功」、3xxは「リダイレクト」、4xxは「クライアントエラー」、5xxは「サーバエラー」を示す。
HTTP/1.1でBasic認証が定義されており最も単純なセキュリティ技術である。。「基本認証を用いるくらいならなにも使わない方がまし」と主張する人もいる。通常サーバはステータスコード401で応答する。