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/_redirects.txt | 2 +- files/ja/_wikihistory.json | 7 ---- .../connection_management_in_http_1.x/index.html | 39 ---------------------- .../connection_management_in_http_1.x/index.html | 10 +++--- 4 files changed, 6 insertions(+), 52 deletions(-) delete mode 100644 files/ja/conflicting/web/http/connection_management_in_http_1.x/index.html diff --git a/files/ja/_redirects.txt b/files/ja/_redirects.txt index 596610570d..ffd9ddf17c 100644 --- a/files/ja/_redirects.txt +++ b/files/ja/_redirects.txt @@ -2587,7 +2587,7 @@ /ja/docs/HTTP/Headers /ja/docs/Web/HTTP/Headers /ja/docs/HTTP/Response_codes /ja/docs/Web/HTTP/Status /ja/docs/HTTP/X-Frame-Options /ja/docs/Web/HTTP/Headers/X-Frame-Options -/ja/docs/HTTP_Pipelining_FAQ /ja/docs/conflicting/Web/HTTP/Connection_management_in_HTTP_1.x +/ja/docs/HTTP_Pipelining_FAQ /ja/docs/Web/HTTP/Connection_management_in_HTTP_1.x /ja/docs/HTTP_access_control /ja/docs/Web/HTTP/CORS /ja/docs/Hacking_Mozilla /ja/docs/conflicting/Mozilla/Developer_guide/How_to_Submit_a_Patch /ja/docs/Help_Viewer:Creating_a_Help_Content_Pack /ja/docs/Help_Viewer/Creating_a_Help_Content_Pack diff --git a/files/ja/_wikihistory.json b/files/ja/_wikihistory.json index 0dee16d4be..a4a4d7cd21 100644 --- a/files/ja/_wikihistory.json +++ b/files/ja/_wikihistory.json @@ -48603,13 +48603,6 @@ "Taken" ] }, - "conflicting/Web/HTTP/Connection_management_in_HTTP_1.x": { - "modified": "2019-01-16T15:51:39.110Z", - "contributors": [ - "Kohei", - "Mgjbot" - ] - }, "conflicting/Web/HTTP/Headers/User-Agent/Firefox": { "modified": "2019-03-23T23:58:03.561Z", "contributors": [ diff --git a/files/ja/conflicting/web/http/connection_management_in_http_1.x/index.html b/files/ja/conflicting/web/http/connection_management_in_http_1.x/index.html deleted file mode 100644 index cfb98c2888..0000000000 --- a/files/ja/conflicting/web/http/connection_management_in_http_1.x/index.html +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: HTTP Pipelining FAQ -slug: conflicting/Web/HTTP/Connection_management_in_HTTP_1.x -tags: - - Necko -translation_of: Web/HTTP/Connection_management_in_HTTP_1.x -translation_of_original: Web/HTTP/Pipelining_FAQ -original_slug: HTTP_Pipelining_FAQ ---- -

HTTP/1.1 パイプライン化 FAQ -

-

HTTP パイプライン化とは？

-

通常、HTTP リクエストは、次のリクエストは完全に受け取られた現在のリクエストに対するレスポンスのあとにだけ発行されるという形で、連続して発行されます。ネットワークの待ち時間と帯域幅の制限により、次のリクエストがサーバによって受け取られるまでに、著しい遅れを生じさせることもあります。 -

HTTP/1.1 では、複数 HTTP リクエストを対応するレスポンスを待つことなくソケットに同時に書き出すことを許しています。リクエスト発行者は、リクエストされた順序での到着のためのレスポンスを待っています。リクエストの「パイプライン化」の作用でページ読み込み時に劇的に改善をみせることもあります。高い待ち時間をともなう接続においては特にそうです。 -

パイプライン化はまた、TCP/IP パケットの数を劇的に減少させることもあります。536 ～ 1460 バイトの典型的な MSS (最大セグメントサイズ) で、1 つの TCP/IP パケットにいくつかの HTTP リクエストが可能です。少ないパケットは通常、IP ルータとネットワークの負荷を減らすため、読み込みに必要なパケットの数を減らすことは、全体としてはインターネットに利益になります。 -

HTTP/1.1 に合致するサーバはパイプライン化のサポートが必要とされています。これはサーバにパイプライン化したレスポンスが必要とされることを意味するわけではありません。しかし、クライアントがパイプライン化したリクエストを選択した時に失敗してはいけないことを要求します。著名な Mozilla 以外のブラウザがパイプライン化を実装していないため、これは明らかにエバンジェリズム (啓蒙) に関する新しいカテゴリのバグとなる可能性があります。 -

-

パイプライン化したリクエストをいつすべきですか？

-

GET や HEAD といったリクエストのように独立したリクエストだけが、パイプライン化可能です。POST と PUT といったリクエストはパイプライン化すべきではありません。新しいコネクションの上でもまた、パイプライン化したリクエストをすべきではありません。なぜなら、相手のサーバ (もしくはプロキシ) が HTTP/1.1 をサポートしているかどうかまだわからないからです。そのために、パイプライン化は存在する「keep-alive」接続の再利用時のみ可能です。 -

-

どのくらいの数のリクエストのパイプライン化をすべきでしょうか？

-

うーん。多くのリクエストのパイプライン化は、もし早い時点でコネクションが切断された場合コストが高くつきます。新しいコネクションの上でだけ繰り返せばいいのに、ネットワークへリクエストを書き出す時間を浪費するからです。そのうえ、最初のリクエストが完了するのに長い時間がかかると、長いパイプライン化は実際にユーザに知覚されてしまうほどの遅れを引き起こします。サーバあたり、2 つの「keep-alive」接続を超えないという制限を勧めます。明らかに、それはアプリケーションに依存します。Web ブラウザはたぶん、前述の理由のためにあまりに長いパイプライン化は望まないでしょう。2 というのは適切な値でしょう。しかし、この数値にはまだ試行により変えられる余地があります。 -

-

もし、リクエストがキャンセルされたらどうなるのでしょうか？

-

もし、リクエストがキャンセルされたとき、パイプライン全体がキャンセルされるのでしょうか？ それとも、パイプラインに属する他のリクエストを繰り返すことを強いてはいけないので、キャンセルされたリクエストだけがただ単に捨てられるべきなのでしょうか？ 答えは、受け取られていないままキャンセルされたリクエストに対するレスポンスの破片のサイズを含むいくつかの要素に依存します。実直なアプローチでは、ただパイプラインをキャンセルし、すべてのリクエストを再発行するというのもあるでしょう。これは、リクエストが一度の発行で何度も利用できるときだけできることです。パイプライン化さているリクエストは大抵、キャンセルされている同じ読み込みのグループ (ページ) に属するので、この実直なアプローチはよく筋が通っています。 -

-

コネクションに失敗するとどうなるのでしょうか？

-

もし、コネクションが失敗するか、サーバによってパイプライン化されたレスポンスのダウンロードの一部へ放り込まれた時、Web ブラウザは失ったリクエストの再開始の能力がなくてはなりません。この場合、単純にも、上述の取り消された場合と等価にハンドリンクされているでしょう。 -

-
-

原文書の情報

- -
-
-
-{{ languages( { "en": "en/HTTP_Pipelining_FAQ" } ) }} 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