From 44d6851daeace9f33b9e47e481cfb5d4a3957930 Mon Sep 17 00:00:00 2001 From: Masahiro FUJIMOTO Date: Tue, 13 Jul 2021 02:49:38 +0900 Subject: Web/HTTP/Connection_management_in_HTTP_1.x を更新 (#1375) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - conflicting 版は正規版に吸収されているため削除 - 2021/02/16 時点の英語版に同期 --- files/ja/web/http/connection_management_in_http_1.x/index.html | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'files/ja/web') diff --git a/files/ja/web/http/connection_management_in_http_1.x/index.html b/files/ja/web/http/connection_management_in_http_1.x/index.html index c85e10de12..31a7b684ef 100644 --- a/files/ja/web/http/connection_management_in_http_1.x/index.html +++ b/files/ja/web/http/connection_management_in_http_1.x/index.html @@ -20,7 +20,7 @@ translation_of: Web/HTTP/Connection_management_in_HTTP_1.x

HTTP/1.1 で、新たなモデルを 2 種類導入しました。持続的なコネクションモデルは、連続したリクエストの間はコネクションを開き続けておくことで、新たなコネクションを開始するために必要な時間を削減します。 HTTP パイプラインモデルはさらに 1 歩進んで、回答を待っている間も複数の連続したリクエストを送信して、ネットワークの遅延の大部分を削減します。

-

HTTP/1.x の3つのコネクションモデルにおけるパフォーマンスの比較: 短命なコネクション、持続的なコネクション、 HTTP パイプライン

+

HTTP/1.x の3つのコネクションモデルにおけるパフォーマンスの比較: 短命なコネクション、持続的なコネクション、 HTTP パイプライン

HTTP/2 では、コネクションの管理モデルをさらに追加しました。

@@ -28,7 +28,7 @@ translation_of: Web/HTTP/Connection_management_in_HTTP_1.x

特筆すべき重要なポイントとして、 HTTP のコネクション管理は隣接したノードの間のコネクション、すなわちエンドツーエンドではなくホップバイホップに適用されることがあります。クライアントと最初のプロキシの間で使用するモデルと、プロキシと宛先サーバー (または任意の中間プロキシ) の間で使用するモデルが異なることもあります。{{HTTPHeader("Connection")}} や {{HTTPHeader("Keep-Alive")}} といったコネクションモデルの定義にかかわる HTTP ヘッダーは、中間のノードが値を変更できる ホップバイホップ ヘッダーです。

-

関連するトピックとしては、 HTTP コネクションのアップグレードの概念、つまり HTTP/1.1 コネクションが TLS/1.0、 WebSocket、 又は平文の HTTP/2 のような異なるプロトコルにアップグレードされたことが挙げられます。このプロトコルのアップグレードメカニズムは他の場所でもっと詳しく文書化されています。

+

関連するトピックとしては、 HTTP コネクションのアップグレードの概念、つまり HTTP/1.1 コネクションが TLS/1.0、 WebSocket、 又は平文の HTTP/2 のような異なるプロトコルにアップグレードされたことが挙げられます。このプロトコルのアップグレードメカニズムは他の場所でもっと詳しく文書化されています。

短命なコネクション

@@ -68,11 +68,11 @@ translation_of: Web/HTTP/Connection_management_in_HTTP_1.x

これらの理由により、パイプラインはよりよいアルゴリズムである多重化に置き換えられました。こちらは HTTP/2 で使用されています。

-

既定で、HTTP リクエストは順次発行されます。次のリクエストは、現在のリクエストのレスポンスが到着してから発行されます。これはネットワークの遅延や帯域の制約を受けるため、次のリクエストがサーバーで見えるようになるまでにかなりの遅延が発生する可能性があります。

+

既定で、HTTP リクエストは順次発行されます。次のリクエストは、現在のリクエストのレスポンスが到着してから発行されます。これはネットワークの遅延や帯域の制約を受けるため、次のリクエストがサーバーで見えるようになるまでにかなりの遅延が発生する可能性があります。

パイプラインは連続したリクエストを同一の持続的なコネクションで、回答を待たずに処理します。これは、コネクションの遅延を回避します。理論上は、2 つのリクエストを同じ TCP メッセージに収めた場合でもパフォーマンスが向上するでしょう。典型的な MSS (最大セグメントサイズ) は複数のシンプルをリクエストを収めるには十分な大きさですが、 HTTP リクエストのサイズの需要は増え続けています。

-

パイプライン化できない HTTP リクエストもあります。 {{glossary("idempotent","べき等")}} なメソッドである {{HTTPMethod("GET")}}, {{HTTPMethod("HEAD")}}, {{HTTPMethod("PUT")}}, {{HTTPMethod("DELETE")}} だけが安全に再実行できます。これらは失敗しても、パイプラインの内容を単純に再実行できます。

+

パイプライン化できない HTTP リクエストもあります。 {{glossary("idempotent","べき等")}} なメソッドである {{HTTPMethod("GET")}}, {{HTTPMethod("HEAD")}}, {{HTTPMethod("PUT")}}, {{HTTPMethod("DELETE")}} だけが安全に再実行できます。これらは失敗しても、パイプラインの内容を再実行できます。

現在、すべての HTTP/1.1 に準拠するプロキシやサーバーはパイプラインをサポートしているはずですが、実際は多くの制限があります。さまざまな理由で、現行のブラウザーはパイプラインを既定で有効化していません。

@@ -86,7 +86,7 @@ translation_of: Web/HTTP/Connection_management_in_HTTP_1.x

サーバーがウェブサイトやウェブアプリケーションのレスポンスを早くしたい場合、より多くのコネクションを開かせることが考えられます。例えば、すべてのリソースを同じドメイン www.example.com で持つのではなく、www1.example.com、www2.example.com、www3.example.com といった複数のドメインに分散させることができます。それぞれのドメインは同じサーバーに名前解決されて、ウェブブラウザーーはドメインごとに 6 つのコネクションを開きます (この例では、コネクション数が 18 に増加します)。この技術はドメインシャーディングと呼ばれます。

-

+

まとめ

-- cgit v1.2.3-54-g00ecf