initial commit

1 files changed, 70 insertions, 0 deletions

diff --git a/files/ja/web/http/compression/index.html b/files/ja/web/http/compression/index.html
new file mode 100644
index 0000000000..fd48194c13
--- /dev/null
+++ b/files/ja/web/http/compression/index.html
@@ -0,0 +1,70 @@
+---
+title: HTTP の圧縮
+slug: Web/HTTP/Compression
+tags:
+  - Guide
+  - HTTP
+  - ガイド
+  - 圧縮
+translation_of: Web/HTTP/Compression
+---
+<div>{{HTTPSidebar}}</div>
+
+<p class="summary"><strong>圧縮</strong>は、ウェブサイトのパフォーマンスを向上させるための重要な手段です。ドキュメントによっては、必要な帯域を最大 70% 削減するほどサイズが縮減します。長年かけてアルゴリズムはより効率的になり、またクライアントおよびサーバーが新たなアルゴリズムをサポートしました。</p>
+
+<p>実際のところ、圧縮の仕組みはブラウザーやサーバーがすでに実装していますので、ウェブ開発者が実装する必要性はありません。しかし、サーバーが適切に設定されるように注意しなければなりません。圧縮は、3 種類の異なるレベルで実施します。</p>
+
+<ul>
+ <li>始めに、一部のファイル形式は、固有の最適化された方法で圧縮されます。</li>
+ <li>そして、一般的な暗号化が HTTP レベルで行われれる場合があります (リソースはエンドツーエンドで圧縮されて転送されます)</li>
+ <li>最後に HTTP コネクションの 2 つのノード間で、コネクションレベルで圧縮が定義される場合があります。</li>
+</ul>
+
+<h2 id="File_format_compression" name="File_format_compression">ファイル形式の圧縮</h2>
+
+<p>それぞれのデータ形式には、<ruby>無駄なスペース<rp> (</rp><rt><em>wasted space</em></rt><rp>) </rp></ruby>と呼ばれる冗長な領域が内部にあります。テキストが一般的に 60% もの冗長性を持つとして、この割合は音声や動画といった他のメディアよりはるかに高くなります。テキストとは異なり、これらのその他のメディア形式はデータを格納するためにより多くの領域を使用するので、ストレージを最適化し領域を取り戻す必要性はごく初期に明らかになりました。技術者は特定の用途向けに設計されたファイル形式で使用される、最適化された圧縮アルゴリズムを設計しました。メディアファイルで使用される圧縮アルゴリズムは、大きく 2 つのカテゴリーに分類できます。</p>
+
+<ul>
+ <li><em>可逆圧縮</em>。圧縮・展開のサイクルで取り出したデータが変化しません。これは元のデータに (バイト単位で) 一致します。<br>
+  画像では <code>gif</code> や <code>png</code> が可逆圧縮を使用しています。</li>
+ <li><em>非可逆圧縮</em>。圧縮・展開のサイクルで、ユーザーが (できるだけ) 感知できない方法で元のデータを変更します。<br>
+  ウェブ上の動画形式は非可逆です。 <code>jpeg</code> 画像も非可逆です。</li>
+</ul>
+
+<p><code>webp</code> のように可逆圧縮と非可逆圧縮のいずれかを使用できる形式もありますが、通常は非可逆圧縮で高圧縮・低圧縮を設定でき、当然ながらそれは品質の高低に結びつきます。サイトのパフォーマンスを高めるには、満足できる品質レベルを維持しながら、できるだけ圧縮することが理想です。画像の場合は、ツールが生成する画像はウェブ向けに十分最適化されていない場合があります。要求する品質で可能な限り圧縮するツールを使用することをお勧めします。この用途に特化した <a href="https://www.creativebloq.com/design/image-compression-tools-1132865">多くのツール</a> があります。</p>
+
+<p>非可逆圧縮アルゴリズムは一般的に、可逆圧縮より効率がよくなります。</p>
+
+<div class="note">
+<p>特定の種類のファイルは圧縮が良好に機能しているため、通常は 2 度目の圧縮を行いません。実際のところ、大きなファイルの圧縮によって得られる追加の利益よりもオーバーヘッド (アルゴリズムは一般的に、初期のサイズに追加する辞書が必要です) のコストが上回る場合があります。圧縮済み形式のファイルで、以下の2つの技術は使用しないでください。</p>
+</div>
+
+<h2 id="End-to-end_compression" name="End-to-end_compression">エンドツーエンドの圧縮</h2>
+
+<p>エンドツーエンドの圧縮は、ウェブサイトのパフォーマンスをもっとも向上させます。エンドツーエンドの圧縮は、サーバーによって行われるメッセージボディの圧縮を指しており、圧縮されたデータはクライアントに到達するまで変更されません。中間のノードはすべて、ボディ部分に手をつけないままにします。</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/13801/HTTPEnco1.png" style="height: 307px; width: 955px;"></p>
+
+<p>現代のすべてのブラウザーやサーバーはこの圧縮をサポートしており、唯一取り決めることは、使用する圧縮アルゴリズムです。これらのアルゴリズムは、テキストに最適化されています。1990 年代に圧縮技術は速いペースで進歩して、いくつものアルゴリズムが、使用可能な選択肢に追加されました。現在妥当なアルゴリズムは、もっとも一般的な <code>gzip</code> と新たな挑戦者である <code>br</code> の 2 つだけです。</p>
+
+<p>使用するアルゴリズムを選択するには、ブラウザーとサーバーで <a href="/ja/docs/Web/HTTP/Content_negotiation">プロアクティブなコンテンツネゴシエーション</a> を行います。ブラウザーは {{HTTPHeader("Accept-Encoding")}} ヘッダーで、サポートするアルゴリズムを優先度順に並べて送信します。サーバーはそのうちひとつを選択して、レスポンスのボディの圧縮に使用します。そして {{HTTPHeader("Content-Encoding")}} ヘッダーを使用して、選択したアルゴリズムをブラウザーに伝えます。エンコーディングに基づいて表現を選択するためにコンテンツネゴシエーションを使用したとき、少なくとも {{HTTPHeader("Content-Encoding")}} を含めた {{HTTPHeader("Vary")}} ヘッダーを、レスポンスとともに送信しなければなりません。この方法によって、リソースのさまざまな表現をキャッシュすることができます。</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/13811/HTTPCompression1.png" style="height: 307px; width: 771px;"></p>
+
+<p>圧縮によってパフォーマンスが大きく向上しますので、画像・音声・動画といったすでに圧縮されているものを除くすべてのファイルで圧縮を有効化することを推奨します。</p>
+
+<p>Apache は圧縮や <a href="https://httpd.apache.org/docs/current/mod/mod_deflate.html">mod_deflate</a> をサポートします。 nginx では <a href="https://nginx.org/en/docs/http/ngx_http_gzip_module.html">ngx_http_gzip_module</a>、 IIS では <code><a href="https://www.iis.net/configreference/system.webserver/httpcompression">&lt;httpCompression&gt;</a></code> 要素があります。</p>
+
+<h2 id="Hop-by-hop_compression" name="Hop-by-hop_compression">ホップバイホップの圧縮</h2>
+
+<p>ホップバイホップの圧縮はエンドツーエンドの圧縮に似ています。しかし、サーバー内のリソースでは圧縮を行わずに特定の表現形式を生成して転送しますが、クライアントとサーバーの間のパス上にある任意の 2 つのノードの間でメッセージのボディが圧縮されるという根本的な違いがあります。連続した中間ノードの間のコネクションで、<em>異なる</em>圧縮が行われることがあります。</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/13807/HTTPTE1.png"></p>
+
+<p>これを行うために、 HTTP ではエンドツーエンドの圧縮のコンテンツネゴシエーションに似ている仕組みを使用します。リクエストを転送するノードは {{HTTPHeader("TE")}} ヘッダーを使用して圧縮アルゴリズムを伝えます。相手のノードは適切な方式を選択して圧縮を行い、 {{HTTPHeader("Transfer-Encoding")}} ヘッダーを使用して、選択した方式を示します。</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/13809/HTTPComp2.png"></p>
+
+<p>実際は、ホップバイホップの圧縮はサーバーやクライアントにとって透過的であり、あまり使用されません。 {{HTTPHeader("TE")}} および {{HTTPHeader("Transfer-Encoding")}} は主にチャンク形式でレスポンスを送信するために使用され、長さがわからないリソースの転送を開始することができます。</p>
+
+<p>ホップレベルで圧縮や {{HTTPHeader("Transfer-Encoding")}} を使用することは Apache、nginx、IIS などほとんどのサーバーでまれであり、簡単に設定する方法はありません。このような設定は、主にプロキシレベルで行います。</p>