Hypertext Transfer Protocol（ハイパーテキスト・トランスファー・プロトコル、略称 HTTP）とは、WebブラウザとWebサーバの間でHTMLなどのコンテンツの送受信に用いられる通信プロトコルである。ハイパーテキスト転送プロトコルとも呼ばれる。HTTP/1.1 が RFC 7230 から RFC 7235 で規定されている。かつては RFC 2616 が HTTP/1.1 を規定していたため、こちらもよく参照されている。また2010年代に入り、HTTP/1.1 を Google が改良した SPDY が普及したことを受けて、SPDY を基とした HTTP/2 の制定作業が開始され進められている。名前の通り、 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でNNTPやSMTPのような各種ヘッダが定義され、HTTP cookieなどの利用が可能になった。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 と区別するため、リクエストプロトコルにバージョンを含めることになった。1997年1月に RFC 2068 として初版が発表された。その後、2回改訂された。名前ベースバーチャルホストをサポートした。インターネット人気に伴い多くの企業が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/2の目標はHTTP/1.1のトランザクション・セマンティクスとの完全な後方互換性を維持したまま非同期な接続の多重化、ヘッダ圧縮、リクエストとレスポンスのを実現することである。Googleによって立ち上げられ、Chrome、Opera、Firefox、Amazon Silkが対応しているHTTP互換のプロトコルSPDYの人気が高まっていることに対応するために開発された。他のプロトコル同様、クライアント側とサーバ側では役割が大きく異なる。HTTP通信を開始できるのはクライアント側のみである。クライアント側がサーバにリクエストを送り、サーバがクライアントにレスポンスを返すのが最も典型的なHTTPのやりとりである。システム間でメッセージをやりとりするにはTCP接続を確立させる必要がある。HTTP/0.9ではクライアントのリクエストごとにTCP接続を確立させる必要があったが、これは当時のWebサイトがシンプルなテキストベースであることが多かったためである。近年ではJavaScriptやアニメーション画像など、多数のオブジェクトが埋め込まれたWebサイトが一般的となってきており、これらのオブジェクトを取得するたびにTCP接続を確立するのはサーバやネットワークに大きな負担を強いるため、HTTP/1.1では持続的接続がサポートされることとなった。ただし、この機能が利用できるのはサーバ側がその要求を許可した場合のみである。クライアントは前のリクエストに対するサーバの応答を待たずに別のリクエストを発行できる。HTTPでは8つのメソッドが定義されている。ただし、実際のHTTP通信ではGETとPOSTメソッドだけで殆どを占める。上記参照別のURIに対して再度のメソッド実行を要求する機能である。301 Movedや303 See Otherなどのリダイレクトを指示するステータスコードとURIを受け取り、クライアントはこのURIに再度メソッドを実行する。クライアントからのHTTPリクエストはメソッド、URI、HTTPバージョンの3つの要素から構成され、それぞれスペースで区切られる。下にもっとも単純なクライアントとサーバ(www.google.co.jp:80)とのやり取りの例を挙げる。クライアントのリクエスト:メソッドは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認証が定義されており最も単純なセキュリティ技術である。しかし仕様書を読むと定義を書いた著者自身が認証技術に疎いことがよくわかる。『HTTPプロトコル セキュア＆スケーラブルなWeb開発』の著者は「基本認証を用いるくらいならなにも使わない方がまし」と著書に書いている。通常サーバはステータスコード401で応答する。

出典:wikipedia