Hypertext Transfer Protocol

Hypertext Transfer Protocolはアプリ間コネクション上のリクエスト/レスポンス型・ステートレス・メッセージ指向通信プロトコルである、GoogleのブラウザーであるChromeだけではなく、他にも、Opera、Firefox、Amazon Silkなどが対応しているHTTP互換のプロトコルSPDYの人気が高まっていることに対応するために開発された。

1.1. HTTP/3
-----------

HTTP-over-QUICとしてIETFが開発していた新たな通信プロトコルが、HTTP/3へと改名される。 IETFが策定を進めているQUICはトランスポート層におけるプロトコルの名称であり、アプリケーション層プロトコルであるHTTP-over-QUICとの区別を明確にするため、このような名称変更に至った。

HTTP/2と比べ、多重化するストリームの取り扱いが下位層のQUICへ移行したこと、ヘッドオブラインブロッキングを回避するためのヘッダ圧縮の変更などの差異がある。

1. 動作
-----

1.1. 通信の開始
----------

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

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

1.2. 接続
-------

システム間でメッセージをやりとりするには接続を確立させる必要がある。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を追加する仕様となっている。

1.3. パイプライン
-----------

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

2. リクエストメソッド
------------

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

GET指定されたURIのリソースを取り出す。HTTPの最も基本的な動作で、HTTP/0.9では唯一のメソッド。POSTGETとは反対にクライアントがサーバにデータを送信する。Webフォームや電子掲示板への投稿などで使用される。GETの場合と同じく、サーバはクライアントにデータを返すことができる。PUT指定したURIにリソースを保存する。URIが指し示すリソースが存在しない場合は、サーバはそのURIにリソースを作成する。画像のアップロードなどが代表的。DELETE指定したURIのリソースを削除する。OPTIONSサーバを調査する。例えば、サーバがサポートしているHTTPバージョンなどを知ることができる。HEADGETと似ているが、サーバはHTTPヘッダのみ返す。クライアントはWebページを取得せずともそのWebページが存在するかどうかを知ることができる。例えばWebページのリンク先が生きているか、データを全て取得することなく検証することができる。TRACEサーバまでのネットワーク経路をチェックする。サーバは受け取ったメッセージのそれ自体をレスポンスのデータにコピーして応答する。WindowsのTracertやUNIXのTracerouteとよく似た動作。CONNECTTCPトンネルを接続する。暗号化したメッセージをプロキシサーバを経由して転送する際に用いる。当初、ネットスケープコミュニケーションズによって考案されたものがIETFドラフト[1]として公開され、2817}} に取り込まれた。その後、7230}} で定義が更新されている。HTTPの仕様以外で定義しているメソッドは、IANAのHypertext Transfer Protocol  Method Registryで管理されている。WebDavで使用するものや、 5789}} のPATCHメソッドなどがある。

3. サーバの連携
---------

3.1. バーチャルホスト
-------------

1つのサーバーで複数のホスト名に対するHTTPリクエストを受け付ける機能である。

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

しかし、IPアドレスのみで相手を特定するHTTP/1.0はこれに対応できなかった。例えば、ある1台のサーバに foo.example.com と bar.example.com という2つの仮想Webサーバがあり、クライアントは にアクセスしたいとする。この場合は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疑似ヘッダーフィールドでホスト名を指定する。

3.2. リダイレクト
-----------

別のURIに対して再度のメソッド実行を要求する機能である。301 Movedや303 See Otherなどのリダイレクトを指示するステータスコードとURIを受け取り、クライアントはこのURIに再度メソッドを実行する。

3.3. クッキー
---------

4. HTTPメッセージ
------------

リクエストとレスポンスでやり取りされるデータは、HTTPメッセージと呼ばれる。クライアントからリクエストHTTPメッセージを送り、サーバーからレスポンスHTTPメッセージを返す。

HTTPメッセージは以下で構成される。

コントロールデータ
ヘッダー
コンテント
トレイラーなおHTTP/1.1では、コントロールデータをリクエスト行・ステータス行として表現し、コンテントを格納する部分をメッセージボディまたは単にボディと呼ぶ。

ヘッダー・コンテント・トレイラーは空となる場合もある。

下にもっとも単純なクライアントとサーバとのやり取りの例を挙げる。

クライアントのリクエスト: 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

Google<WtXmlEndTag />

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

2行目以降にヘッダフィールドが続く。 さらに空行を挟んで、レスポンスボディとなる。 このレスポンスにもトレーラーは無い。

5. HTTPヘッダフィールド
---------------

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

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

5.1. HTTPヘッダフィールドの一覧
--------------------

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-cAccept-Charsetレスポンスで返されるメッセージボディの文字コードを指定するリクエストヘッダ。Acceptと同じく複数指定でき品質係数も設定できる。定義済み文字セットはIANAが管理している。

この例だとクライアントはUTF-8を優先的に希望しているが他の文字セットとの相対優先度0.8で受け入れている。ただしサーバからのレスポンスのHTTPヘッダそのものの文字コードは常にISO-8859-1である。Accept-Encodingクライアントが受信できるメッセージボディのエンコーディングを指定する。

この例ではクライアントはgzip、またはzlibフォーマットに対応している。ただし必ずしもここで指定されたエンコーディングでメッセージボディが返ってくるとは限らない。Accept-Encodingで指定可能なエンコーディングは、IANAがHTTP Content Coding Registryとして管理されている。Accept-Languageレスポンスの言語に対する優先度を指定する。言語の指定にはIETF言語タグを用いる。書き方は他のAccept-群と変わらず。

上記の例はまずイギリス英語を要求し、利用できない場合はその他の英語を要求する。Accept-RangesAcceptで始まる他のヘッダフィールドと違いレスポンスヘッダである。現在の仕様では2つの指定方法しかない。Ageリソースの推定経過時間を表示するレスポンスヘッダ。キャッシュサーバーはAgeヘッダの値からキャッシュしたリソースが有効かどうかを判定する。AllowAuthentication-infoユーザ認証のやりとりの最後で用いられる、成功したレスポンスのサーバが含めることの出来るレスポンスヘッダ。Authorizationサーバに対するクライアント自身の認証を行うことが出来る。Cache-Controlキャッシングの動作を指定するためのマスターヘッダ。Connection接続に対するオプションを指定する。その値には以下が使用される。keep-alive持続的接続を行う。close持続的接続を行わない。upgrade他のプロトコルへのアップグレードを希望する。Content-EncodingContent-Languageリソースの表現に用いられる言語の明示に使われる。言語の指定はAccept-Languageヘッダと同じ。Content-LengthContent-LocationContent-MD5メッセージボディが変更されず宛先に届いたことの保証に用いる。MD5によるハッシュ値をヘッダー値に記載する。ただし悪意の改ざんに対しては当然MD5も改ざんされるのであまり機能はしない。どちらかといえば偶発的な変化が生じていないことの保証をしている。7231}}で廃止された。Content-Rangeダウンロードの再開に用いられる。Content-Type

メッセージボディに含まれるオブジェクトタイプを示す。次の例はリソースがテキストファイル、文字セットはISO-8859-4を使用していることを示している。

CookieクライアントがHTTP状態管理を望む場合にサーバから受け取ったクッキーを以後のリクエストに次の例のようなヘッダを付加する。

$VersionはHTTPのバージョン、NAMEはクッキーの名前である。$から始まるクッキー名は使用が禁止されている。Cookie2基本的にCookieヘッダとCookie2ヘッダは別物である。Dateサーバがメッセージを生成した日時を示す。リソースの更新日時を示すLast-Modifiedヘッダとは別である。HTTP/1.1では次のような形式を用いる。これは7231}}の7.1.1.1. Date/Time Formatsで定義されている。HTTP/1.1の以前の版である2616}}では、日時の形式の定義に1123}}を参照していた。

HTTP仕様ではレスポンスにDateヘッダを含めることを求めている。ただしレスポンスのステータスがサーバエラーの場合にはDateヘッダは返らない。ETag主にキャッシングのパフォーマンスを向上する目的で使われる。Expectサーバに対して特定の動作の期待を知らせる。用途としてはクライアントがサーバに対して//100 Continue//ステータスを返すことを期待する場合に使われる。

サーバが期待に応じられない場合は//417 Expectation Failed//を返す。クライアントがいくつかのプロキシ経由で通信している場合、各プロキシサーバはExpectヘッダの一切の修正を許されない。Expiresオブジェクトの有効期限を示す。このヘッダで指定された日時までキャッシュはレスポンスのコピーを保持し、リクエストに対するレスポンスとして返すことができる。サーバがオブジェクトのキャッシュを望まない場合にはExpiresヘッダに過去の日時を設定することが多い。仕様では1年以上先の日時は設定できない。

Cache-Controlヘッダのmax-ageディレクティブはExpiresヘッダより優先されるため注意が必要である。Fromリクエストを発行したユーザを特定することが出来る。1990年代では電子メールアドレスを設定することが多かったが、迷惑メールの問題もあり現在では殆ど使われていない。

Host主にレンタルサーバのサポートを目的としてHTTP/1.1で導入された。現在ではHostヘッダを利用できない場合、レンタルサーバのWebサイトとまともな通信ができないと言ってよい。If-MatchETagが一致した場合のみ、メソッドを実行するようにサーバに要求する。例えばウィキペディアを編集する際、記事のソースを取得し、書き換える際の間に別のユーザが既に編集していないかを判断するときなどに用いられる。
利用者：AがHTTPの記事を取得。ETagは1234。
利用者：BがHTTPの記事を取得。ETagは1234。
利用者：AがHTTPのETagを再度取得。先ほど取得したETag: 1234と現在のETag: 1234が一致。
利用者：AがHTTPの記事を編集。ETagは1256になる。
利用者：BがHTTPのETagを再度取得。先ほど取得したETagと現在のETagはマッチせず。
サーバは利用者：Bの書き込みを拒否。If-Modified-Since指定日時以降にオブジェクトが変更されている場合のみ、メソッドを実行するようにサーバに要求する。通信量の削減に効果がある。If-None-MatchIf-Matchの逆で、ETagが一致しない場合のみの実行を要求する。If-Rangeクライアントがキャッシュにオブジェクトの一部分を持っている場合にパフォーマンスを向上できる。If-Unmodified-SinceIf-Modified-Sinceの逆で、指定時刻以降に変更がない場合のみの実行を要求する。Last-Modifiedレスポンスでオブジェクトの最終更新日時を示す。リクエスト時のIf-Modified-Sinceヘッダと組み合わせることで、効率的な通信が可能になる。Locationサーバがクライアントにリダイレクト先URLを知らせる際に用いられる。一般的にステータスコードが3xx代のレスポンスと共に使われるが//201 Created//のレスポンスでも使うことができる。Content-Locationヘッダと名前が似ているが全く関係のない別のヘッダであるため注意。Max-Forwardsプロキシサーバなどを経由する際の最大ホップ数を指定する。二重ループなどでサーバから応答が得られない場合の問題解決の際、OPTIONメソッドやTRACEメソッドと共に用いられる。

6. HTTPステータスコード
---------------

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

7. セキュリティ技術
-----------

いくつかの観点でセキュリティに関する追加機能が存在する。

7.1. HTTPS
----------

セキュアな通信路でHTTP通信を行うことを通常HTTPSと言う。

7.2. HTTP認証
-----------

HTTPの中で認証を行う仕組みが用意されている。

7.2.1. Basic認証
--------------

HTTP/1.1で定義されている最も単純なセキュリティ技術である。「基本認証を用いるくらいならなにも使わない方がまし」と主張する人もいる。平文で認証情報を送信する仕組みであるため、TLS など安全を確保した通信路での利用が望ましい。通常サーバはステータスコード401で応答する。

7.2.2. Digest認証
---------------

8. 規格
-----

HTTPはIETFを始めとした標準化団体により規格化されている。以下はその一部である。

歴史的には各バージョンが独立して規格化されてきた。しかし現行の3バージョンが共通のセマンティクスを維持していたことから、これを独立した規格とする活動が推進され現在の形になっている。

9. 派生・拡張プロトコル
-------------

HTTPSのほか、以下のようなHTTPのセマンティクスを利用するプロトコル、HTTPの構文を元とするプロトコルなどが存在する。以下はその一例である。

WebDAV: HTTP上でファイル転送を実現するプロトコル。
WebSocket: 双方向通信プロトコル。
Internet Printing Protocol : プリンタの制御と印刷データの伝送を行うプロトコル。
UPnPでは、HTTPをUDP上で使用するHTTPUや、マルチキャストで使用するHTTPMUが規定された。
Hyper Text Coffee Pot Control Protocol : エイプリルフールのジョーク。コーヒーポットの制御機能を有するプロトコル。なお、このようなHTTPの利用に関する文書として 9205}} Building Protocols with HTTP が存在する。

10. 関連項目
--------

HTTP/2
HTTPステータスコード
FTP
WebDAV
Webサーバ
ウェブブラウザ
アプリケーションサーバ
Representational State Transfer 
HTTPヘッダ・インジェクション
Hyper Text Coffee Pot Control Protocol
バーチャルホスト

11. 参照
------

12. 外部リンク
---------

9110}} - HTTP Semantics
9111}} - HTTP Caching
9112}} - HTTP/1.1
9113}} - HTTP/2
9114}} - HTTP/3
9205}} - Building Protocols with HTTP
[2]以下は旧式であり非推奨となった仕様

7540}} - Hypertext Transfer Protocol Version 2 
[3]
7230}} - Hypertext Transfer Protocol : Message Syntax and Routing
[4]
7231}} - Hypertext Transfer Protocol : Semantics and Content
[5]
7232}} - Hypertext Transfer Protocol : Conditional Requests
[6]
7233}} - Hypertext Transfer Protocol : Range Requests
[7]
7234}} - Hypertext Transfer Protocol : Caching
[8]
7235}} - Hypertext Transfer Protocol : Authentication
[9]
2818}} - HTTP Over TLS
[10]
2817}} - Upgrading to TLS Within HTTP/1.1
2616}} - HTTP/1.1
[11]
2068}} - HTTP/1.1
[12] - ハイパテキスト転送プロトコル HTTP/1.1 日本標準仕様書
1945}} - HTTP/1.0
[13] - HTTP/0.9その他