Hypertext Transfer Protocol
Hypertext Transfer Protocol
Hypertext Transfer Protocol(ハイパーテキスト・トランスファー・プロトコル、HTTP)はアプリ間コネクション上のリクエスト/レスポンス型・ステートレス・メッセージ指向通信プロトコルである。
TCPやQUICはアプリケーション間のコネクション型通信を提供する。HTTPはこのコネクション上を、リソース要望と返答が、メッセージ単位で、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 で改良された。
リクエストのセマンティクスを指定する、様々なリクエストメソッドが追加された。POSTを使って、アップロード(クライアントからサーバへのデータの転送)が可能になった。
NNTPやSMTPのような各種ヘッダが定義され、HTTP cookieなどの利用が可能になった。
HTTP/1.1 では複数データを効率よく転送するための持続的接続や、プロキシの利用なども想定した仕様になった。さらに HTTP/2やHTTP/3が策定された。現在ではHTTPセマンティクスと各バージョンの手続きが分離して定義されている(#規格を参照)。
このほかの点を箇条書きで示す。
TCPのポート番号80をデフォルトとして使用する(HTTP/0.9〜1.1とHTTP/2の場合)。
TLSで暗号化され、セキュリティを確保したHTTPは、HTTPSと呼ばれる(httpsは実際にはURIスキームの1つであり、実際のプロトコルにはHTTP over SSL/TLSまたはHTTP/3が用いられる)。
HTTP は基本的にサーバが状態を保持しない (stateless) プロトコルだが、データベースなどを使用するWebアプリケーションにおいては状態保持が必要だったため、いわゆる Cookie(クッキー)とよばれる機構が Netscape Communications Corporation によって導入された。Cookie を使用することによって状態を管理し、セッションを維持することが可能になる。
行末文字はCRLFで、インターネット・プロトコル・スイートにおいてアプリケーション層に属する他の多くのプロトコルと同じである(HTTP/0.9〜1.1の場合)。
イギリスの物理学者ティム・バーナーズ=リーは1990年末、ロバート・カイリューと共に初のWebブラウザとWebサーバを作成した。ブラウザには通信をするためのプロトコルが必要だったので、二人はHTTPの最初期のバージョンを設計した。
以来インターネットの大部分をHTTP通信が占めるようになり、1998年にはインターネット上の通信の75%がHTTPによるものになった。
最初期のHTTP/0.9の仕様書は紙に印刷すれば1枚で済むような非常に簡素なドキュメントだったが、2度のバージョンアップを経たHTTP/1.1の仕様書は実に176ページ近くの分量に膨れあがった。
1991年に最初にドキュメント化されたバージョン。メソッドは GET しかなかった。レスポンスは単純にドキュメントの内容を返してコネクションを切断するだけで、レスポンスコードの規定もない。下記は、HTTP/0.9 のリクエストの例。
GET /index.html
1996年5月に RFC 1945 として発表された。仕様が RFC で扱われるようになった。メソッドに POST など GET 以外のものが増えた。レスポンスはヘッダーがつくようになり、ステータスコードを含めるようになった。HTTP/0.9 と区別するため、リクエストプロトコルにバージョンを含めることになった。
<dl>
<dt>HTTP/1.0のリクエスト</dt>
<dd>
</dd>
1997年1月に RFC 2068 として初版が発表された。その後、3回改訂され、現在はセマンティクス・キャッシングを除く部分がRFC 9112で規定されている。
名前ベースバーチャルホストのため、Hostヘッダーフィールドの規定が追加された。
<dt>HTTP/1.1のリクエスト</dt>
<dd>
</dd>
</dl>
HTTP/2の目標はHTTP/1.1のトランザクション・セマンティクスとの完全な後方互換性を維持したまま非同期な接続の多重化、ヘッダ圧縮、リクエストとレスポンスのパイプライン化を実現することである。Googleによって立ち上げられ、GoogleのブラウザーであるChromeだけではなく、他にも、Opera、Firefox、Amazon Silkなどが対応しているHTTP互換のプロトコルSPDYの人気が高まっていることに対応するために開発された。
HTTP-over-QUIC(hq)としてIETFが開発していた新たな通信プロトコルが、HTTP/3へと改名される。
IETFが策定を進めているQUICはトランスポート層におけるプロトコルの名称であり、アプリケーション層プロトコルであるHTTP-over-QUICとの区別を明確にするため、このような名称変更に至った。
HTTP/2と比べ、多重化するストリームの取り扱いが下位層のQUICへ移行したこと、ヘッドオブラインブロッキングを回避するためのヘッダ圧縮の変更(HTTP/3用にQPACKが開発されている)などの差異がある。
他のプロトコル同様、クライアント側とサーバ側では役割が大きく異なる。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メソッドが大部分を占める。
指定されたURIのリソースを取り出す。HTTPの最も基本的な動作で、HTTP/0.9では唯一のメソッド。
GETとは反対にクライアントがサーバにデータを送信する。Webフォームや電子掲示板への投稿などで使用される。GETの場合と同じく、サーバはクライアントにデータを返すことができる。
指定したURIにリソースを保存する。URIが指し示すリソースが存在しない場合は、サーバはそのURIにリソースを作成する。画像のアップロードなどが代表的。
指定したURIのリソースを削除する。
サーバを調査する。例えば、サーバがサポートしているHTTPバージョンなどを知ることができる。
GETと似ているが、サーバはHTTPヘッダのみ返す。クライアントはWebページを取得せずともそのWebページが存在するかどうかを知ることができる。例えばWebページのリンク先が生きているか、データを全て取得することなく検証することができる。
サーバまでのネットワーク経路をチェックする。サーバは受け取ったメッセージのそれ自体をレスポンスのデータにコピーして応答する。WindowsのTracertやUNIXのTracerouteとよく似た動作。
TCPトンネルを接続する。暗号化したメッセージをプロキシサーバを経由して転送する際に用いる。当初、ネットスケープコミュニケーションズによって考案されたものがIETFドラフトとして公開され、RFC 2817 に取り込まれた。その後、RFC 7230 で定義が更新されている。
HTTPの仕様以外で定義しているメソッドは、IANAのHypertext Transfer Protocol (HTTP) Method Registryで管理されている。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リクエストでホスト名を指定する。
HTTP/1.1: Hostヘッダーフィールドでホスト名を指定する。
HTTP/2およびHTTP/3: :authority疑似ヘッダーフィールドでホスト名を指定する。
別のURIに対して再度のメソッド実行を要求する機能である。301 Movedや303 See Otherなどのリダイレクトを指示するステータスコードとURIを受け取り、クライアントはこのURIに再度メソッドを実行する。
リクエストとレスポンスでやり取りされるデータは、HTTPメッセージと呼ばれる。クライアントからリクエストHTTPメッセージを送り、サーバーからレスポンスHTTPメッセージを返す。
HTTPメッセージは以下で構成される。
なおHTTP/1.1では、コントロールデータをリクエスト行・ステータス行として表現し、コンテントを格納する部分をメッセージボディまたは単にボディと呼ぶ。
ヘッダー・コンテント・トレイラーは空となる場合もある。
下にもっとも単純なクライアントとサーバ(www.google.co.jp:80)とのやり取りの例を挙げる。
クライアントのリクエスト:
この例では、リクエスト行とヘッダーにフィールドが1項目あるのみで、ボディは空でトレーラーも無い。
リクエスト行はメソッド、リクエストターゲット、HTTPバージョンの3つの要素から構成され、それぞれスペースで区切られる。
メソッドはGET、リクエストターゲットは「/」、HTTPバージョンは1.1である。
GETはリソースを取得するためのメソッドであり、リクエストターゲットの「/」はURIのパス部分であってルートリソースを対象にしたリクエストであることを示している。
サーバのレスポンス:
先頭のステータス行はHTTPバージョン、ステータスコード、ステータスメッセージから構成される。
ステータスコードの「200」は処理の成功を表し、これを補足するメッセージが「OK」である。
2行目以降にヘッダフィールドが続く。
さらに空行を挟んで、レスポンスボディとなる。
このレスポンスにもトレーラーは無い。
ヘッダの各要素は<pre>フィールド名: 内容</pre>のペアで構成される。
ブラウザの情報を表すUser-Agent、使用候補言語を表すAccept-Language、他ページへのリンクを辿った場合にそのリンク元ページのURLを表すRefererなどが代表的なフィールドである。
なお、リクエスト時のHostヘッダはHTTP/1.1では必須であるが、HTTP/1.0ではなくてもよい。
ただし、サーバがバーチャルホストを利用している場合は、Hostヘッダがないとリソース取得に失敗するので、たとえHTTP/1.0を使用していてもHostヘッダを付加しなければならない。
ステータスコードはサーバからのレスポンスで、リクエストの結果を通知する。3桁の数字から成り、おおまかな分類として、1xxは「情報」、2xxは「成功」、3xxは「リダイレクト」、4xxは「クライアントエラー」、5xxは「サーバエラー」を示す。
いくつかの観点でセキュリティに関する追加機能が存在する。
セキュアな通信路でHTTP通信を行うことを通常HTTPSと言う。
HTTPの中で認証を行う仕組みが用意されている。
HTTP/1.1で定義されている最も単純なセキュリティ技術である。「基本認証を用いるくらいならなにも使わない方がまし」と主張する人もいる。平文で認証情報を送信する仕組みであるため、TLS (HTTPS)など安全を確保した通信路での利用が望ましい。通常サーバはステータスコード401で応答する。
HTTPはIETFを始めとした標準化団体により規格化されている。以下はその一部である。
歴史的には各バージョンが独立して規格化されてきた。しかし現行の3バージョン(v1.1, v2, v3)が共通のセマンティクスを維持していたことから、これを独立した規格とする活動が推進され現在の形になっている。
HTTPSのほか、以下のようなHTTPのセマンティクスを利用するプロトコル、HTTPの構文を元とするプロトコルなどが存在する。以下はその一例である。
WebDAV: HTTP上でファイル転送を実現するプロトコル。
WebSocket: 双方向通信プロトコル。
Internet Printing Protocol (IPP): プリンタの制御と印刷データの伝送を行うプロトコル。
UPnPでは、HTTPをUDP上で使用するHTTPUや、マルチキャストで使用するHTTPMUが規定された。
Hyper Text Coffee Pot Control Protocol (HTCPCP): エイプリルフールのジョーク。コーヒーポットの制御機能を有するプロトコル。
なお、このようなHTTPの利用に関する文書として RFC 9205 Building Protocols with HTTP (BCP 56)が存在する。