--- title: HTTP の進化 slug: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP tags: - Guide - HTTP - NeedsUpdate - NeedsUpdate(HTTP/3) translation_of: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP ---
{{HTTPSidebar}}

HTTP は World Wide Web を支えるプロトコルです。 Tim Berners-Lee によって 1989-1991 年に開発されれてから、HTTP にはシンプルさのほとんどを維持しながら柔軟性をさらに形作る、多くの変更がみられます。 HTTP は初期のいくぶん信頼された研究所の環境内でファイルを交換するプロトコルから、現代のインターネットの迷宮で高解像度や 3D の画像や動画を運ぶプロトコルに進化しました。

World Wide Web の発明

1989 年、 CERN で働いていた Tim Berners-Lee は、インターネット上のハイパーテキストシステムを構築するための提案書を執筆しました。当初 Mesh と呼ばれていたそのシステムは、1990 年に実装されている間に World Wide Web へ改名されました。 World Wide Web は既存の TCP および IP プロトコル上に構築され、4 つの要素から構成されました:

これら 4 つの構成要素は 1990 年の末に完成して、最初のサーバーが早くも 1991 年の初期に CERN の外部で稼働しました。1991 年 8 月 6 日の、 Tim Berners-Lee による alt.hypertext 公開ニュースグループへの 投稿 が、公開プロジェクトとしての World Wide Web の公式な開始日と考えられています。

初期段階で使用された HTTP プロトコルはとてもシンプルであり、後に HTTP/0.9 と名付けられ、また時にはワンラインプロトコルとも呼ばれました。

HTTP/0.9 – ワンラインプロトコル

初期バージョンの HTTP にはバージョン番号がありませんでした。以降のバージョンと区別するため、後に 0.9 と呼ばれるようになりました。HTTP/0.9 はとても単純です。リクエストは唯一使用可能なメソッドである {{HTTPMethod("GET")}} で始まって、リソースへのパス (サーバーに接続すればプロトコル、サーバー名、ポートが必要ではなくなるため、 URL ではありません) が後に続く 1 行で構成されます。

GET /mypage.html

レスポンスも、とても単純です。こちらはファイル自身だけで構成されます。

<HTML>
A very simple HTML page
</HTML>

以降の進化形とは異なり、HTTP ヘッダーがなく HTML ファイルだけが転送可能であり、他の種類の文書は転送できません。また、ステータスやエラーのコードはありません。問題が発生すると、人間が使用するために問題の説明を収めた専用の HTML ファイルを返送します。

HTTP/1.0 – 拡張性を築く

HTTP/0.9 は制約がとても多いため、多目的に使用できるようにブラウザーやサーバーがいち早く拡張しました。

この時点で、一般的なリクエストとレスポンスはこのようになりました。

GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
  <IMG SRC="/myimage.gif">
</HTML>

次のコネクションが続いて、画像の読み込みをリクエストします (前のリクエストのレスポンスに続きます)。

GET /myimage.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(画像コンテンツ)

これらの新機能は協調作業によらず、1991 年から 1995 年の間に試行錯誤によって導入されました。サーバーとブラウザーにある機能を追加して、効果があるかを確認していました。多くの相互運用性の問題が日常茶飯事でした。1996 年 11 月にこれらの問題を解消するため、共通の慣行を説明する情報文書である {{RFC(1945)}} が発行されました。これは HTTP/1.0 の定義であり、狭義の意味で公式の標準ではないことは注目に値します。

HTTP/1.1 – 標準化されたプロトコル

さまざまな HTTP/1.0 の使用によるやや混沌した状況と並行して、HTTP/1.0 の文書の公開を翌年に控えた 1995 年から、正式な標準化が進められました。HTTP で最初に標準化されたバージョンである HTTP/1.1 が、HTTP/1.0 から数か月後である 1997 年初頭に公開されました。

HTTP/1.1 ではあいまいな部分を明確にするとともに、いくつもの改良を施しました:

ひとつのコネクションで行われる典型的なリクエストのフローは、以下のようになりました。

GET /en-US/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding

(コンテンツ)


GET /static/img/header-background.png HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

200 OK
Age: 9578461
Cache-Control: public, max-age=315360000
Connection: keep-alive
Content-Length: 3077
Content-Type: image/png
Date: Thu, 31 Mar 2016 13:34:46 GMT
Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
Server: Apache

(3077 バイトの画像コンテンツ)

HTTP/1.1 は、1997 年 1 月に {{rfc(2068)}} として初版が発行されました。

15 年以上にわたる拡張

HTTP の拡張性 (新たなヘッダーやメソッドを容易に追加できる) のおかげで、HTTP/2 が公開される前に 1999 年 1 月に発行された {{RFC("2616")}} や 2014 年 6 月に発行された {{RFC("7230")}}-{{RFC("7235")}} によって HTTP/1.1 プロトコルが 2 度改版されても、このプロトコルは 15 年以上にわたって極めて安定していました。

安全な転送のために HTTP を使用する

HTTP でもっとも大きな変化が、早くも 1994 年の末に発生しました。基本的な TCP/IP スタック上で HTTP を送信するかわりに、TCP/IP の上層に追加する暗号化された転送レイヤーである SSL を Netscape Communications が開発しました。SSL 1.0 は社外に公開されませんでしたが、SSL 2.0 とその後継である SSL 3.0 は、サーバーとクライアントの間で交換されるメッセージの暗号化および信頼性の保証によって、電子商取引のウェブサイトの作成を可能にしました。 SSL は標準化の過程に乗せられて最終的に TLS になり、バージョン 1.0、1.1、1.2、1.3 が脆弱性を抑えることに成功しました。

それと同時に、暗号化されたトランスポート層の必要性が発生しました。ウェブが主に学術用ネットワークにある比較的信頼された状況を失って、広告者やさまざまな個人や犯罪者が人々の個人情報を多く得ようと競い合い、なりすましや改変されたデータによる置き換えを図るようになりました。HTTP 上に構築されたアプリケーションがさらに強力になるのに従ってアドレス帳、電子メール、ユーザーの位置情報といったさらに個人的な情報へアクセスするようになり、TLS の必要性は電子商取引を越えていたるところに存在します。

複雑なアプリケーションのために HTTP を使用する

Tim Berners-Lee による当初のウェブのビジョンは、読み取り専用の手段ではありませんでした。彼はウェブについて、人々が遠隔操作で文書を追加や移動することができる開かれたファイルシステムを描いていました。1996 年頃に HTTP はオーサリングができるように拡張され、WebDAV という名前の標準仕様が作られました。これはアドレス帳の項目を扱う CardDAV やカレンダーを扱う CalDAV など、特定のアプリケーション向けにさらに拡張されました。しかしこれらの *DAV 拡張には、それが使用するサーバーに実装されている必要があり、またとても複雑であったという欠点があります。ウェブの領域でこれらは、内輪で使用されているままです。

2000 年に、HTTP を使用する新たなパターンである {{glossary("REST", "representational state transfer")}} (REST) が考案されました。API が発したアクションは新たな HTTP メソッドによって伝達されず、基本的な HTTP/1.1 メソッドによって特定の URI にアクセスする場合に限られます。これによりウェブアプリケーションは、ブラウザーやサーバーを更新することなくデータの取り出しや変更ができる API の提供が可能になります。必要なものはすべて、標準の HTTP/1.1 によってウェブサイトから提供されるファイルに埋め込まれています。それぞれのウェブサイトが独自の非標準な RESTful API を定義して、それらがウェブサイトを制御するという事実に REST モデルの欠点があります。*DAV 拡張との違いは、クライアントとサーバーが相互使用可能ではないことです。RESTful API は、2010 年代にはとても一般的になりました。

2005 年よりウェブページを格段に向上させる API セットが利用可能になりました。またこれらのいくつかは特定用途向けに、主に新たな固有の HTTP ヘッダーを作成して HTTP プロトコルを拡張しました:

ウェブのセキュリティモデルを緩和する

HTTP はウェブのセキュリティモデルである 同一オリジンポリシー とは独立した存在です。実は、現在のウェブのセキュリティモデルは HTTP を作成した後に開発されたのです!長年かけて、一定の条件の下でこのポリシーの制限の一部を解除できるようにすることにより、より寛大にできることが有効であると立証されました。いつどのようにしてこれらの制限を解除するかは、新たな HTTP ヘッダー群を使用してサーバーからクライアントに送信されます。これは Cross-Origin Resource Sharing (CORS) や Content Security Policy (CSP) といった仕様で定義されています。

これらの大きな拡張に加えて、ほかにも実験用に限るものを含めて多くのヘッダーが追加されました。主なヘッダーとしてプライバシーを制御するための Do Not Track ({{HTTPHeader("DNT")}}) ヘッダー、{{HTTPHeader("X-Frame-Options")}}、{{HTTPHeader('Upgrade-Insecure-Request')}} がありますが、さらに多くのヘッダーが存在します。

HTTP/2 – 高パフォーマンスなプロトコル

長年かけてウェブページはより複雑になり、アプリケーション自体も同様に複雑化しました。表示する視覚メディアの量や、対話機能を追加するスクリプトの規模やサイズも増加しました。著しく多くの HTTP リクエストによって、より多くのデータが転送されます。HTTP/1.1 のコネクションは、正しい順序でリクエストを送信しなければなりません。理論上は並行していくつかのコネクションを使用できます (通常 5 から 8 の間) が、かなりのオーバーヘッドや複雑性をもたらします。たとえば HTTP パイプラインは、ウェブ開発でリソースの負荷になることが明らかになりました。

2010 年代の前半に Google は実験的なプロトコルである SPDY を実装して、クライアントとサーバーの間でデータを交換するための代替手段を示しました。これは、ブラウザーやサーバーの両方の開発者から多くの関心を集めました。応答性の向上を明確にするとともに、転送するデータの重複による問題を解決することで、SPDY は HTTP/2 プロトコルの基礎を務めました。

HTTP/2 プロトコルには、HTTP/1.1 との大きな違いがいくつかあります:

HTTP/2 は 2015 年 5 月に正式に標準化され、多くの成功例がありました。2016 年 7 月には、すべてのウェブサイトの 8.7% [1] ですでに使用されており、すべてのリクエストの 68% 以上を占めています[2]。トラフィックが多いウェブサイトでもっとも早く採用されており、データ転送のオーバーヘッドやそれによる経費をかなり削減しています。

HTTP/2 はウェブサイトやアプリケーションの改造が不要 (これらにとって HTTP/1.1 を使用するか HTTP/2 を使用するかは透過的です) ですので、このすばやい採用のペースはもっともです。最近のブラウザーと通信する最新のサーバーがあれば、HTTP/2 を有効化するのに十分です。限られたグループだけが採用のきっかけとして必要であり、古いブラウザーやサーバーが更新されるのに従って、ウェブ開発者の努力なしに使用個所が自然に増えていきます。

HTTP/2 以降の進化

HTTP/2 の公開によって HTTP の進化が止まったわけではありません。過去の HTTP/1.x と同様に、新しい機能を追加するために HTTP の拡張性が今でも活用されています。特に、2016 年に現れた新たな HTTP の拡張を挙げることができます:

これらの HTTP の進化はプロトコルの拡張性やシンプルさを実証しており、多くのアプリケーションの作成やプロトコルの採用を促しています。今日の HTTP が使用される環境は、1990 年代初頭にみられた環境とは大きく異なっています。 HTTP の本来の設計は傑作であることを実証しており、四半世紀にわたって抵抗されることなくウェブを進化させることができました。 HTTP を成功させた柔軟性や拡張性を維持ししながら欠点を直した HTTP/2 の採用は、プロトコルの明るい未来を暗示しています。

HTTP/3 - HTTP over QUIC

{{Draft}}{{SeeCompatTable}}

次のメジャーバージョンの HTTP である HTTP/3 は、トランスポート層に TCP/TLS の代わりに QUIC を使用する予定です。

Firefox での実装状況については {{bug(1158011)}} を参照してください。