mdn · mfuji09 · Oct 23, 2024 · Oct 18, 2024
@@ -3,19 +3,19 @@ title: HTTP の進化
 slug: Web/HTTP/Evolution_of_HTTP
 original_slug: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP
 l10n:
-  sourceCommit: eb9eef29f1ccdaf1c8a464dbe4483c78f7a13b2a
+  sourceCommit: 783ffd9c1cf35421242e028a1b8743cf2b1918dd
 ---
 
 {{HTTPSidebar}}
 
-**HTTP** は World Wide Web を支えるプロトコルです。1989 年から 1991 年にかけてティム・バーナーズ＝リーとそのチームによって開発された HTTP は、その柔軟性を形成しながら分かりやすさを維持するために、多くの変化を遂げてきました。HTTP が、実験室でファイルを交換するためのプロトコルから、高解像度や 3D の画像や動画を伝送する現代のインターネットの迷路へと進化していった経緯をご紹介します。
+**HTTP** (HyperText Transfer Protocol) は World Wide Web を支えるプロトコルです。1989 年から 1991 年にかけてティム・バーナーズ＝リーとそのチームによって開発された HTTP は、その柔軟性を形成しながら分かりやすさを維持するために、多くの変化を遂げてきました。HTTP が、実験室でファイルを交換するためのプロトコルから、高解像度や 3D の画像や動画を伝送する現代のインターネットの迷宮へと進化していった経緯をご紹介します。
 
 ## World Wide Web の発明
 
 1989 年、CERN で働いていたティム・バーナーズ＝リーは、インターネット上のハイパーテキストシステムを構築するための提案書を執筆しました。当初 _Mesh_ と呼ばれていたそのシステムは、1990 年に実装されている間に _World Wide Web_ へ改名されました。 World Wide Web は既存の TCP および IP プロトコル上に構築され、4 つの要素から構成されました。
 
 - ハイパーテキスト文書を表現するテキスト形式である _[HyperText Markup Language](/ja/docs/Web/HTML)_ (HTML)。
-- それらの文書を交換するシンプルなプロトコルである _HypertText Transfer Protocol_ (HTTP)。
+- それらの文書を交換するシンプルなプロトコルである _HyperText Transfer Protocol_ (HTTP)。
 - それらの文書を表示（および編集）するクライアントである、_WorldWideWeb_ と呼ばれた最初のウェブブラウザー。
 - 文書へのアクセス機能を提供するサーバーである、_httpd_ の初期バージョン。
 
@@ -28,7 +28,7 @@ l10n:
 初期バージョンの HTTP にはバージョン番号がありませんでした。以降のバージョンと区別するため、後に 0.9 と呼ばれるようになりました。HTTP/0.9 はとても単純です。リクエストは唯一使用可能なメソッドである {{HTTPMethod("GET")}} で始まって、リソースへのパスが後に続く 1 行で構成されます。サーバーに接続すればプロトコル、サーバー名、ポートが必要ではなくなるため、 URL ではありませんでした。
 
 ```http
-GET /mypage.html
+GET /my-page.html
 ```
 
 レスポンスも、とても単純でした。こちらはファイル自身だけで構成されます。
@@ -47,39 +47,39 @@ HTTP/0.9 はとても限定的なものでしたが、ブラウザーとサー
 
 - バージョン情報は各リクエストの中で送信されました（`HTTP/1.0` は `GET` 行に付加されました）。
 - ステータスコード行もレスポンスの始めに送られるようになりました。これにより、ブラウザーはリクエストの成否を認識し、それに応じて動作を変化させることができるように、例えば、固有の方法でローカルキャッシュを更新したり使用したりすることができるようになりました。
-- リクエストとレスポンスの両方に、HTTP ヘッダーの概念が導入されました。メタデータを送信できるようになり、プロトコルは非常に柔軟で拡張性が高くなった。
+- リクエストとレスポンスの両方に、HTTP ヘッダーの概念が導入されました。メタデータを送信できるようになり、プロトコルは非常に柔軟で拡張性が高くなりました。
 - {{HTTPHeader("Content-Type")}} ヘッダーのおかげで、プレーンな HTML ファイル以外の文書も送信できるようになりました。
 
 この時点で、一般的なリクエストとレスポンスはこのようになりました。
 
 ```http
-GET /mypage.html HTTP/1.0
+GET /my-page.html HTTP/1.0
 User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
 
-200 OK
+HTTP/1.0 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">
+  <IMG SRC="/my-image.gif">
 </HTML>
 ```
 
 次の接続が続いて、画像の読み込みをリクエストします (前のリクエストのレスポンスに続きます)。
 
 ```http
-GET /myimage.gif HTTP/1.0
+GET /my-image.gif HTTP/1.0
 User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
 
-200 OK
+HTTP/1.0 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 を定義しました。
+1991 年から 1995 年にかけて、これらは試行錯誤で導入されました。サーバーとブラウザーが機能を追加して、それが取得されるかどうかを確認するのです。相互運用性の問題はよくあることでした。これらの問題を解決するために、1996 年 11 月に一般的な方法を記述した情報文書が公開されました。これは {{RFC(1945)}} として知られ、HTTP/1.0 を定義しました。
 
 ## HTTP/1.1 – 標準化されたプロトコル
 
@@ -97,15 +97,15 @@ HTTP/1.1 では、曖昧な点が明確にされ、多くの改良が加えら
 すべて単一の接続で行われる典型的なリクエストの流れは、次のようなものになりました。
 
 ```http
-GET /ja/docs/Glossary/Simple_header HTTP/1.1
+GET /ja/docs/Glossary/CORS-safelisted_request_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/ja/docs/Glossary/Simple_header
+Referer: https://developer.mozilla.org/ja/docs/Glossary/CORS-safelisted_request_header
 
-200 OK
+HTTP/1.1 200 OK
 Connection: Keep-Alive
 Content-Encoding: gzip
 Content-Type: text/html; charset=utf-8
@@ -125,9 +125,9 @@ User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101
 Accept: */*
 Accept-Language: en-US,en;q=0.5
 Accept-Encoding: gzip, deflate, br
-Referer: https://developer.mozilla.org/ja/docs/Glossary/Simple_header
+Referer: https://developer.mozilla.org/ja/docs/Glossary/CORS-safelisted_request_header
 
-200 OK
+HTTP/1.1 200 OK
 Age: 9578461
 Cache-Control: public, max-age=315360000
 Connection: keep-alive
@@ -142,9 +142,9 @@ Server: Apache
 
 HTTP/1.1 は、1997 年 1 月に {{rfc(2068)}} として初版が発行されました。
 
-## 15 年以上にわたる拡張
+## 20 年以上にわたる開発
 
-HTTP の拡張性により、新しいヘッダーやメソッドを簡単に作成することができました。HTTP/1.1 プロトコルは、1999 年 6 月に公開された {{RFC("2616")}} と HTTP/2 のリリース前の 2014 年 6 月に公開された {{RFC("7230")}}-{{RFC("7235")}} という 2 回の改訂を経て改良されたとはいえ、15年以上も極めて安定していました。
+HTTP の拡張性により、新しいヘッダーやメソッドを簡単に作成することができました。HTTP/1.1 プロトコルは 2 回の改訂を経て改良されましたが、1999 年 6 月に発行された {{RFC("2616")}}、および HTTP/2 のリリース前の 2014 年 6 月に発行された {{RFC("7230")}}-{{RFC("7235")}} は、15 年以上にわたって極めて安定していました。HTTP/1.1 は、2022 年に {{RFC("9110")}} で再び更新されました。HTTP/1.1 が更新されただけでなく、HTTP 全体が改訂され、セマンティクス ({{RFC("9110")}})、すべてのバージョンの HTTP に適用されるキャッシュ ({{RFC("9111")}})、HTTP/1.1 ({{RFC("9112")}})、HTTP/2 ({{RFC("9113")}})、HTTP/3 ({{RFC("9114")}}) の文書に分割されました。さらに、それまでは常に提案/草案の標準にとどまっていたこの仕様は、ついにインターネット標準 (STD 97) の地位を獲得しました。
 
 ### 安全な転送のための HTTP の使用
 
@@ -156,7 +156,7 @@ HTTP の最大の変化が、1994 年末に起こりました。コンピュー
 
 ティム・バーナーズ＝リーは元々、HTTP を読み取り専用のメディアとして想定していたわけではありません。彼は、人々がリモートで文書を追加したり移動したりできるウェブ、つまり分散ファイルシステムのようなものを作成したかったのです。1996 年頃、HTTP はオーサリングを可能にするために拡張され、WebDAV と呼ばれる標準が作成されました。さらに、アドレス帳の項目を処理する CardDAV、カレンダーを扱う CalDAV など、固有のアプリケーションを記載するようになりました。しかし、これらの \*DAV 拡張はすべて、サーバーが実装しなければ使えないという欠点がありました。
 
-2000 年、HTTP を使用するための新しいパターンが設計さ れました。{{glossary("REST", "representational state transfer")}}（またはREST）です。このAPIは、新しいHTTPメソッドに基づくものではなく、基本的なHTTP/1.1メソッドによる固有のURIへのアクセスに頼っていました。これにより、どんなウェブアプリケーションでも、ブラウザーやサーバーを更新することなく、APIにデータを取得したり変更したりさせることができるようになりました。必要な情報はすべて、ウェブサイトが標準のHTTP/1.1で提供するファイルに埋め込まれていました。RESTモデルの欠点は、各ウェブサイトが自分自身で非標準のRESTful APIを定義し、それを完全に制御していたことです。この点は、クライアントとサーバーが相互運用可能であった⽶⽶DAV拡張とは異なる形であった。RESTful APIは、2010年代にとても一般的になりました。
+2000 年、HTTP を使用するための新しいパターンが設計さ れました。{{glossary("REST", "representational state transfer")}}（または　REST）です。この API は、新しい HTTP メソッドに基づくものではなく、基本的な HTTP/1.1 メソッドによる固有の URI へのアクセスに頼っていました。これにより、どんなウェブアプリケーションでも、ブラウザーやサーバーを更新することなく、API にデータを取得したり変更したりさせることができるようになりました。必要な情報はすべて、ウェブサイトが標準の HTTP/1.1 で提供するファイルに埋め込まれていました。REST モデルの欠点は、各ウェブサイトが自分自身で標準化されていない RESTful API を定義し、それを完全に制御していたことです。この点は、クライアントとサーバーが相互運用可能であった \*DAV 拡張とは異なる形でした。。RESTful API は、2010 年代にとても一般的になりました。
 
 2005 年以降、より多くの API がウェブページで利用できるようになりました。これらの API のうちいくつかは、特定の目的のために HTTP プロトコルを拡張しました。
 
@@ -175,7 +175,7 @@ HTTP はウェブのセキュリティモデルである[同一オリジンポ
 
 HTTP/2 プロトコルには、HTTP/1.1 との大きな違いがいくつかあります。
 
-- テキスト形式ではなく、バイナリ形式のプロトコルです。このハードルにより内容を読んだり手作業で作成したりすることができなくなりましたが、改良された最適化技術が実装できるようになりました。
+- テキスト形式ではなく、バイナリー形式のプロトコルです。このハードルにより内容を読んだり手作業で作成したりすることができなくなりましたが、改良された最適化技術が実装できるようになりました。
 - 多重化されたプロトコルです。同じ接続でリクエストを並行して扱うことができ、HTTP/1.x プロトコルの制約を排除しています。
 - ヘッダーを圧縮します。一連のリクエスト内で似たものが存在することが多いため、これはデータ転送の重複やオーバーヘッドを削減します。
 - サーバープッシュと呼ばれる仕組みによって、リクエストより先にサーバーがクライアントのキャッシュにデータを加えることができます。