キャッシングは、より高速なアクセスを可能にする方法で、一般的に要求されるコンテンツの一時的なストレージを許可することにより、サーバーのパフォーマンスを向上させる方法です。これにより、リソースを大量に消費する操作が削減され、処理と配信が高速化されます。
効果的なキャッシングルールを作成することにより、キャッシングに適したコンテンツが保存され、応答時間が短縮され、リソースが節約され、負荷が最小限に抑えられます。 Apacheは、さまざまなタイプの操作を高速化するのに適したさまざまなキャッシュを提供します。このガイドでは、さまざまなキャッシングモジュールを使用してUbuntu14.04でApache2.4を構成する方法について説明します。
このチュートリアルを完了するには、次のものが必要です。
sudoコマンドを使用できる非rootアカウントを持つUbuntu サーバーがセットアップされ、ファイアウォールがオンになっています。サーバーをお持ちでない学生は[こちら]（https://cloud.tencent.com/product/cvm?from=10680）から購入できますが、個人的には無料のTencent Cloud [Developer Lab]（https://cloud.tencent.com/developer/labs?from=10680）を使用して実験し、[サーバーを購入]（ https://cloud.tencent.com/product/cvm?from=10680）。
SSL証明書：この証明書の設定方法は、サーバーを解決できるドメイン名があるかどうかによって異なります。
ドメイン名をお持ちの場合、Webサイトを保護する最も簡単な方法は、無料の信頼できる証明書を提供する[Tencent Cloud SSL Certificate Service]（https://cloud.tencent.com/product/ssl?from=10680）を使用することです。 [Tencent Cloud SSL Certificateインストールおよび操作ガイド]（https://cloud.tencent.com/document/product/400/6814?from=10680）の設定。
ドメイン名をお持ちでない場合は、まずここにアクセスすることをお勧めします[ドメイン名の登録]（https://dnspod.cloud.tencent.com/）。この構成をテストまたは個人使用のみに使用する場合は、ドメイン名を購入せずに自己署名証明書を使用できます。自己署名証明書は同じタイプの暗号化を提供しますが、ドメイン名検証のアナウンスはありません。自己署名証明書については、[Apacheの自己署名SSL証明書の作成]（https://cloud.tencent.com/developer/article/1165840?from=10680）と[Nginxの自己署名SSL証明書の作成方法]（https://cloud.tencent.com/developer/article/1160294?from=10680）の2つの記事を参照してください。
Apacheは、さまざまなレベルの複雑さとスケーラビリティでコンテンツをキャッシュできます。プロジェクトは、コンテンツのキャッシュ方法に基づいて、これらを3つのグループに分けます。一般的な内訳は次のとおりです。
上記の説明を一目見れば、上記の方法にいくつかの重複があることがわかりますが、複数の戦略を同時に使用すると役立つ場合があります。たとえば、SSLセッションにキー値ストレージを使用し、応答に標準のHTTPキャッシングを有効にすると、データソースの負荷を大幅に削減し、クライアント側での多くのコンテンツ配信操作を高速化できます。
Apacheの各キャッシングメカニズムについての幅広い理解ができたので、これらのシステムをさらに詳しく見ていきましょう。
mod_file_cache mod_file_cacheモジュールは、主に、ファイルシステムが遅いサーバーでのファイルアクセスを高速化するために使用されます。 2つの構成手順を選択できます。これら2つの構成手順の目的は、ファイルを要求する代わりに、サーバーの起動時に何らかの作業を実行することにより、静的ファイルを提供するプロセスを高速化することです。
CacheFileディレクティブは、アクセスを高速化するディスク上のファイルのパスを指定するために使用されます。 Apacheが起動すると、Apacheは指定された静的ファイルを開き、ファイルハンドルをキャッシュするため、要求されたときにファイルを開く必要はありません。この方法で開くことができるファイルの数は、オペレーティングシステムの設定によって制限されます。
MMapFileディレクティブは、Apacheを初めて起動したときにもファイルを開きます。ただし、 MMapFileは、ファイルハンドラだけでなく、メモリにファイルの内容をキャッシュします。これにより、これらのページのパフォーマンスを向上させることができますが、いくつかの重大な制限があります。使用するメモリの量は記録されないため、メモリが不足する可能性があります。また、子プロセスは割り当てられたメモリをコピーするため、当初の予想よりも早くリソースが使い果たされる可能性があることに注意してください。このコマンドは注意してのみ使用できます。
これらの命令は、Apacheの起動時にのみ評価されます。これは、起動後に行われた変更を取得するためにApacheに依存できないことを意味します。これらのファイルは静的ファイルでのみ使用してください。これらのファイルは、Apacheセッションの存続期間中は変更されません。ファイルの変更方法によっては、サーバーに変更が通知される場合がありますが、これは予期された動作ではなく、常に正しく機能するとは限りません。これらの手順に渡されたファイルに変更を加える必要がある場合は、変更の完了後にApacheを再起動してください。
ファイルキャッシュは、 mod_file_cacheモジュールによって提供されます。この機能を使用するには、モジュールを有効にする必要があります。
Ubuntu 14.04を実行している場合、このモジュールはインストールされますが、Apacheをインストールすると無効になります。次のように入力して、モジュールを有効にできます。
sudo a2enmod file_cache
その後、メイン構成ファイルを編集して、ファイルキャッシングディレクティブを設定する必要があります。次のコマンドを入力してファイルを開きます。
sudo nano /etc/apache2/apache2.conf
ファイルハンドルキャッシュを設定するには、 CacheFileディレクティブを使用します。この命令では、次に示すように、スペースで区切られたファイルパスのリストを使用します。
CacheFile /var/www/html/index.html /var/www/html/somefile.index
サーバーを再起動した後、Apacheはリストされたファイルを開き、アクセスを高速化するためにファイルハンドルをキャッシュに保存します。
逆に、複数のファイルをメモリに直接マップする場合は、 MMapFileディレクティブを使用できます。ファイルパスのリストのみが必要なため、その構文は基本的に最後のコマンドと同じです。
MMapFile /var/www/html/index.html /var/www/html/somefile.index
実際には、同じグループ両方のファイルに対して CacheFileと MMapFileを構成する必要はありませんが、異なるファイルセットで同時に使用できます。
完了したら、ファイルを保存して閉じることができます。次のコマンドを入力して、構成ファイルの構文を確認します。
sudo apachectl configtest
最後の行に「SyntaxOK」と表示されている場合は、Apacheインスタンスを安全に再起動できます。
sudo service apache2 restart
Apacheは、使用した指示に従って、ファイルの内容またはハンドラーを再起動してキャッシュします。
mod_socache_dbm、 mod_socache_dc、 mod_socache_memcache、 mod_socache_shmcbmod_authn_socache、 mod_sslキー値キャッシングはファイルキャッシングよりも複雑であり、より多くの重要な利点があります。 Apacheのキー値キャッシングは、共有オブジェクトキャッシングとも呼ばれます。これは主に、コンテンツ自体ではなく、コンテンツへのクライアントアクセスの繰り返し設定に伴うコストのかかる操作を回避するために使用されます。具体的には、認証の詳細、SSLセッションをキャッシュし、SSLステープリングを提供するために使用できます。
**注：**現在、各共有オブジェクトキャッシュプロバイダー*にはいくつかの問題があります。これらの問題への参照の概要を以下に示します。この機能を有効にするかどうかを評価するときは、これらの要素を考慮してください。
実際のキャッシングは、共有オブジェクトキャッシングプロバイダーモジュールの1つを使用して行われます。これらは：
dbmデータベースエンジンを使用します。このプロバイダーにはメモリリークがあるため、ほとんどの場合、 mod_socache_shmcbを使用することをお勧めします。上記のプロバイダーモジュールとともに、キャッシュするオブジェクトに応じて、追加のモジュールが必要になります。たとえば、SSLセッションを有効にしたり、SSLステープルを構成したりするには、 mod_sslを有効にする必要があります。これによりそれぞれ SSLSessionCacheコマンドと SSLStaplingCacheコマンドが提供されます。同様に、認証キャッシュを設定するには、 mod_authn_socacheモジュールを有効にして、 AuthnCacheSOCacheディレクティブを設定できるようにする必要があります。
上記のエラーと警告を考慮して、Apacheでこのタイプのキャッシュを構成する場合は、以下の手順に従ってください。
キー値キャッシュの設定に使用される方法は、使用目的と使用するプロバイダーによって異なります。以下に、認証キャッシングとSSLセッションキャッシングの基本を紹介します。
現在、認証キャッシュにエラーがあり、パラメーターがキャッシュプロバイダーに渡されません。したがって、デフォルト設定を提供しないプロバイダーでは問題が発生します。
高価な認証方法（LDAPやデータベース認証など）を使用する場合は、認証キャッシュが役立ちます。認証要求が発行されるたびにバックエンドをヒットする必要がある場合、これらのタイプの操作はパフォーマンスに大きな影響を与える可能性があります。
キャッシュの設定には、既存の認証構成の変更が含まれます（このガイドでは、認証の設定方法については説明しません）。バックエンドの認証方法に関係なく、変更自体はほぼ同じです。デモのために mod_socache_shmcbを使用します。
まず、次のコマンドを入力して、 authn_socacheモジュールと mod_socache_shmcbプロバイダーモジュールを有効にします。
sudo a2enmod authn_socache
sudo a2enmod socache_shmcb
メインのApache構成ファイルを開いて、認証用にこの共有キャッシュバックエンドを指定します。
sudo nano /etc/apache2/apache2.conf
内部的に、 AuthnCacheSOCacheディレクティブをファイルの先頭に追加します。 shmcbがプロバイダーとして使用されることを指定します。この記事を読んだときに、前述のエラー防止オプションの配信が修正されている場合は、キャッシュの場所とサイズを指定できます。数値はバイト単位であるため、コメント付きの例では512KBのキャッシュになります。
AuthnCacheSOCache shmcb
# If the bug preventing passed arguments to the provider gets fixed,
# you can customize the location and size like this
# AuthnCacheSOCache shmcb:${APACHE_RUN_DIR}/auth_cache(512000)
完了したら、ファイルを保存して閉じます。
次に、認証が構成されている仮想ホスト構成ページを開きます。 000-default.conf仮想ホスト構成を使用していることを前提としていますが、環境を反映するように変更する必要があります。
sudo nano /etc/apache2/sites-enabled/000-default.conf
認証を構成する場合は、ブロックを変更してキャッシュを追加します。具体的には、「AuthnCacheProvideFor」を追加してキャッシュする認証ソースを指定し、「AuthnCacheTimeout」を使用してキャッシュタイムアウトを追加し、従来の認証方法の前に「AuthBasicProvider」のリストに「socache」を追加する必要があります。結果は次のようになります。
< VirtualHost *:80>
...
< Directory /var/www/html/private>
AuthType Basic
AuthName "Restricted Files"
AuthBasicProvider socache file
AuthUserFile /etc/apache2/.htpasswd
AuthnCacheProvideFor file
AuthnCacheTimeout 300
Require valid-user
< /Directory></VirtualHost>
上記の例はファイル認証用であり、キャッシュのメリットがない場合があります。ただし、他の認証方法を使用する場合、実装は非常に似ている必要があります。唯一の大きな違いは、上記の例の「ファイル」仕様を他の認証方法に置き換える必要があることです。
ファイルを保存して閉じます。 Apacheを再起動して、キャッシュの変更を実装します。
sudo service apache2 restart
SSL接続を確立するために実行する必要のあるハンドシェイクは、かなりのオーバーヘッドが発生する可能性があります。したがって、セッションデータをキャッシュして、以降の要求に対するこの初期化手順を回避すると、このペナルティを回避できる場合があります。共有オブジェクトキャッシュは完璧な場所です。
ApacheサーバーにSSLが構成されている場合、 mod_sslが有効になります。 Ubuntuでは、これは ssl.confファイルが / etc / apache2 / mods-enabledディレクトリに移動されたことを意味します。これは実際にはすでにキャッシュを設定しています。内部には、次のような行が表示されます。
...
SSLSessionCache shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)
SSLSessionCacheTimeout 300
...
これは実際にはセッションキャッシュを設定するのに十分です。それをテストするには、OpenSSL接続クライアントを使用できます。入る：
openssl s_client -connect 127.0.0.1:443-reconnect -no_ticket | grep Session-ID
すべての結果のセッションIDが同じである場合、セッションキャッシュは正常に動作しています。 CTRL-Cを押してターミナルに戻ります。
mod_cachemod_cache_disk、 mod_cache_socacheHTTPプロトコルは、コンテンツ配信パスで応答をキャッシュするためのメカニズムを奨励および提供します。コンテンツにアクセスできるコンピュータは、コンテンツのソースと、コンピュータ独自のキャッシュルールで指定されているキャッシュ戦略に応じて、特定の期間、各アイテムをキャッシュできます。
Apache HTTPキャッシングメカニズムは、表示されるHTTPキャッシング戦略に基づいて応答をキャッシュします。これは、任意の中間サーバーが従う配信と同じルールに従う汎用キャッシングシステムです。これにより、システムは非常に柔軟で強力になり、コンテンツに設定する必要のあるタイトルを利用できるようになります（これを行う方法を以下に示します）。
ApacheのHTTPキャッシュは、「スリーステート」キャッシュとも呼ばれます。これは、保存するコンテンツが3つの状態のいずれかになり得るためです。新鮮な場合もあります。つまり、さらに検査することなくクライアントに提供できます。古い場合は、コンテンツのTTLが期限切れになっている場合があります。または、コンテンツがキャッシュに見つからない場合は利用できない場合があります。存在します。
コンテンツが古くなった場合、キャッシュは次のリクエストでオリジンのコンテンツをチェックすることでコンテンツを再検証できます。変更されていない場合は、鮮度の日付をリセットして、現在のコンテンツを提供できます。それ以外の場合は、変更されたコンテンツをフェッチし、キャッシュポリシーで許可されている期間保存します。
HTTPキャッシングロジックは、 mod_cacheモジュールを介して利用できます。実際のキャッシングは、キャッシングプロバイダーによって行われます。通常、キャッシュは mod_cache_diskモジュールを使用してディスクに保存されますが、共有オブジェクトキャッシュは mod_cache_socacheモジュールを介して取得することもできます。
mod_cache_diskモジュールはディスクにキャッシュされるため、リモートの場所からコンテンツをプロキシする場合、動的プロセスからコンテンツを生成する場合、またはコンテンツが通常存在するよりも高速なディスクにキャッシュすることでコンテンツを高速化する場合、これは便利です。 。これは最も徹底的にテストされたプロバイダーであり、ほとんどの場合、最初の選択肢となるはずです。キャッシュは自動的にクリーンアップされないため、キャッシュするには「htcacheclean」というツールを時々実行する必要があります。これは手動で実行するか、通常の cronジョブとして設定するか、デーモンとして実行できます。
mod_cache_socacheモジュールは、共有オブジェクトプロバイダーの1つにキャッシュします（前のセクションで説明したものと同じ）。これは、 mod_cache_disk（どの共有キャッシュプロバイダーを選択するか）よりもパフォーマンスが優れている可能性があります。ただし、更新され、前述のバグがある共有オブジェクトプロバイダーに依存しています。 mod_cache_socacheオプションを実装する前に、徹底的なテストをお勧めします。
ApacheのHTTPキャッシュは、必要に応じて2つの異なる構成で展開できます。
CacheQuickHandlerが" on "に設定されている場合、キャッシュはリクエスト処理中にできるだけ早くチェックされます。コンテンツが見つかった場合、それ以上の処理を行わずに直接提供されます。これは非常に高速であることを意味しますが、コンテンツの認証などのプロセスを許可しないことも意味します。キャッシュ内のコンテンツが一般に認証またはアクセス制御を必要とする場合、不明な人なら誰でもコンテンツにアクセスできます（ CacheQuickHandlerが" on "に設定されている場合）。
基本的に、これはWebサーバーの前にある個別のキャッシュをシミュレートします。 Webサーバーで何らかの条件チェック、認証、または承認が必要な場合、これは発生しません。 Apacheはその中の命令さえ評価しません <Location> または<Directory> ブロック。 ** CacheQuickHandlerはデフォルトで「オン」に設定されていることに注意してください**！
CacheQuickHandlerが" off "に設定されている場合、キャッシュはリクエスト処理シーケンスの後半でチェックされます。この構成は、Apache処理ロジックと実際のコンテンツの間にキャッシュを配置することと考えることができます。これにより、コンテンツがキャッシュから取得される前に、従来の処理命令を実行できるようになります。これを「オフ」に設定すると、リクエストをより深く処理するためにトランザクションが高速になります。
キャッシングを有効にするには、 mod_cacheモジュールとキャッシュプロバイダーの1つを有効にする必要があります。上記のように、 mod_cache_diskは完全にテストされており、これに依存します。
Ubuntuシステムでは、次のように入力してこれらのモジュールを有効にできます。
sudo a2enmod cache
sudo a2enmod cache_disk
これにより、次にサーバーを再起動したときにキャッシュが有効になります。
また、必要に応じてキャッシュを削減するためのユーティリティ htcachecleanを含む apache2-utilsパッケージをインストールする必要があります。次のコマンドを入力してインストールできます。
sudo apt-get update
sudo apt-get install apache2-utils
ほとんどのキャッシュ構成は、単一の仮想ホスト定義またはロケーションブロックで行われます。ただし、 mod_cache_diskを有効にすると、特定の一般属性を指定するために使用できるグローバル構成も有効になります。次に、ファイルを開いて表示します。
sudo nano /etc/apache2/mods-enabled/cache_disk.conf
コメントを削除すると、ファイルは次のようになります。
< IfModule mod_cache_disk.c>
CacheRoot /var/cache/apache2/mod_cache_disk
CacheDirLevels 2
CacheDirLength 1</IfModule>
IfModuleパッケージは、 mod_cache_diskモジュールが有効になっている場合、これらの命令について心配するようにApacheに指示します。 CacheRootディレクティブは、キャッシュが保持されるディスク上の場所を指定します。 CacheDirLevelsと CacheDirLengthはどちらも、制限されたキャッシュディレクトリ構造を構築する方法を定義するのに役立ちます。
ハッシュ値 md5を使用して、データを格納するためのキーとして提供されるURLを作成します。データは、各ハッシュの開始文字から派生したディレクトリに編成されます。 CacheDirLevelsは作成されるサブディレクトリの数を指定し、 CacheDirLengthは各ディレクトリの名前として使用される文字数を指定します。したがって、上記のデフォルト値「b1946ac92492d2347c6235b4d2611184」のハッシュは、ディレクトリ構造「b / 1 / 946ac92492d2347c6235b4d2611184」にアーカイブされます。通常、これらの値を変更する必要はありませんが、それらの目的を知っておくとよいでしょう。
注： CacheRoot値を変更する場合は、 / etc / default / apache2ファイルを開き、その HTCACHECLEAN_PATH値を選択に一致するように変更する必要があります。これはキャッシュを定期的にクリーンアップするために使用されるため、キャッシュの正しい場所が必要です。
このファイルには、他のいくつかの値 CacheMaxFileSizeと CacheMinFileSizeを設定できます。これらの値は、Apacheがキャッシュに送信するファイルサイズの範囲と、バイト CacheReadSizeと CacheReadTimeを設定します。クライアントは前にコンテンツを待機してバッファリングします。このオプションは、コンテンツがこのサーバー以外の場所にある場合に役立ちます。
ほとんどのキャッシュ構成は、仮想ホスト定義内であろうと特定のロケーションブロック内であろうと、より詳細なレベルで行われます。
フォローする仮想ホストファイルを開きます。このガイドでは、デフォルトのファイルを使用していることを前提としています。
sudo nano /etc/apache2/sites-enabled
仮想ホストブロック内の任意のロケーションブロックの外側で、いくつかのキャッシュプロパティの構成を開始できます。このガイドでは、さらに処理を完了するために、 CacheQuickHandlerをオフにすることを前提としています。これにより、より完全なキャッシュルールを取得できます。
また、この機会にキャッシュロックを構成します。これは、コンテンツがまだ有効かどうかを確認するためにコンテンツソースにチェックインするときにApacheが使用するファイルロックシステムです。このクエリが満たされている間に、同じコンテンツに対する他のリクエストが着信すると、バックエンドリソースに対する他のリクエストが発生し、負荷のピークが発生する可能性があります。
検証中にリソースのキャッシュロックを設定すると、リソースが現在更新されていることがApacheに通知されます。この間、ステータスを示す警告ヘッダーを使用して、廃止されたリソースを提供できます。 / tmpフォルダにキャッシュロックディレクトリを設定します。有効と見なされる前に、最大5秒間ロックを許可します。これらの例はApacheのドキュメントから直接引用されているため、私たちの目的に適しているはずです。
また、Apacheに Set-Cookieヘッダーを無視し、それらをキャッシュに保存しないように指示します。そうすることで、Apacheがユーザー固有のCookieを誤って他の当事者に漏らさないようにします。 Set-Cookieヘッダーは、ヘッダーがキャッシュされる前に削除されます。
< VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
CacheQuickHandler off
CacheLock on
CacheLockPath /tmp/mod_cache-lock
CacheLockMaxAge 5
CacheIgnoreHeaders Set-Cookie
< /VirtualHost>
この仮想ホストのキャッシュを実際に有効にする必要があります。 CacheEnable命令を使用してこの操作を実行できます。これが仮想ホストブロックで設定されている場合は、キャッシュ方法（ diskまたは socache）とキャッシュする必要のある要求URIを指定する必要があります。たとえば、すべての応答をキャッシュするには、 CacheEnable disk /に設定できますが、応答を / public URIでのみキャッシュする場合は、 CacheEnable disk / publicに設定できます。
特定のロケーションブロックでキャッシュを有効にすることで、別のパスを使用します。そうすることは、 CacheEnableコマンドのURIパスを提供する必要がないことを意味します。その場所から提供されたURIはすべてキャッシュされます。また、 CacheHeaderディレクティブをオンにして、応答ヘッダーがキャッシュが要求の処理に使用されているかどうかを示すようにします。
設定するもう1つの命令は CacheDefaultExpireです。ヘッダーファイル Expiresもヘッダーファイル Last-Modifiedもコンテンツに設定されていない場合、有効期限（秒単位）を設定できます。同様に、 CacheMaxExpireを設定してプロジェクトの保存時間を制限します。 CacheLastModifiedFactorを設定して、Apacheが Last-Modifiedの日付はあるが有効期限がない場合に、有効期限を作成できるようにします。この係数に変更後の時間を掛けて、妥当な有効期限を設定します。
< VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
CacheQuickHandler off
CacheLock on
CacheLockPath /tmp/mod_cache-lock
CacheLockMaxAge 5
CacheIgnoreHeaders Set-Cookie
< Location />
CacheEnable disk
CacheHeader on
CacheDefaultExpire 600
CacheMaxExpire 86400
CacheLastModifiedFactor 0.5</Location></VirtualHost>
必要なものをすべて構成したら、ファイルを保存して閉じます。
次のように入力して、構成全体の構文エラーを確認します。
sudo apachectl configtest
エラーが報告されない場合は、次のコマンドを入力してサービスを再起動します。
sudo service apache2 restart
上記の構成では、HTTPヘッダーに依存するHTTPキャッシュを構成しました。ただし、提供するコンテンツには、インテリジェントなキャッシュの決定に必要な「Expires」または「Cache-Control」ヘッダーが実際にはありません。これらのヘッダーを設定するには、より多くのモジュールを利用する必要があります。
mod_expiresモジュールは、 Cache-Controlタイトルに Expiresタイトルと max-ageオプションを設定できます。 mod_headersモジュールを使用して、より具体的な Cache-Controlオプションを追加し、キャッシュ戦略をさらに調整できます。
次のように入力すると、これら2つのモジュールを有効にできます。
sudo a2enmod expires
sudo a2enmod headers
これらのモジュールを有効にした後、仮想ホストファイルを再度直接変更できます。
sudo nano /etc/apache2/sites-enabled/000-default.conf
mod_expiresモジュールは3つの命令しか提供しません。 ExpiresActiveで、特定のコンテキストで有効期限処理を「オン」に設定して有効にします。他の2つの命令は互いに非常に似ています。 ExpiresDefaultディレクティブはデフォルトの有効期限を設定し、 ExpiresByTypeはコンテンツのMIMEタイプに従って有効期限を設定します。これらは両方とも、 Expiresと Cache-Controlの「max-age」を正しい値に設定します。
これらの2つの設定には、2つの異なる構文を使用できます。最初は単純な「A」または「M」で、その後に数秒かかります。これにより、コンテンツが最後に「アクセス」または「変更」された時刻を基準にして有効期限が設定されます。たとえば、どちらもコンテンツにアクセスしてから30秒後に期限切れになります。
ExpiresDefault A30
ExpireByType text/html A30
別の構文では、より詳細な構成が可能です。これにより、人間による計算が容易な秒以外の単位を使用できます。また、「アクセス」または「変更」という完全な用語も使用します。以下に示すように、期限切れの構成全体を引用符で囲む必要があります。
ExpiresDefault "modification plus 2 weeks 3 days 1 hour"
ExpiresByType text/html "modification plus 2 weeks 3 days 1 hour"
ここでは、デフォルトの有効期限のみを設定します。慣れて間違えてもお客様のパソコンに長期間保存されないように、5分の設定から始めます。コンテンツに適したポリシーを選択する能力に自信が持てれば、より積極的なアプローチに調整できます。
< VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
CacheQuickHandler off
CacheLock on
CacheLockPath /tmp/mod_cache-lock
CacheLockMaxAge 5
CacheIgnoreHeaders Set-Cookie
< Location />
CacheEnable disk
CacheHeader on
CacheDefaultExpire 600
CacheMaxExpire 86400
CacheLastModifiedFactor 0.5
ExpiresActive on
ExpiresDefault "access plus 5 minutes"</Location></VirtualHost>
これにより、 Expiresタイトルが将来5分に設定され、 Cache-Control max-age = 300が設定されます。キャッシング戦略をさらに改善するために、 Headerディレクティブを使用できます。 mergeオプションを使用して、他の Cache-Controlオプションを追加できます。このオプションを複数回呼び出して、必要な他の戦略を追加できます。この例では、「public」を設定するだけで、他のキャッシュがコピーの保存を確実に許可できるようになります。
当サイトで ETagsを静的コンテンツ（検証用）として設定するには、 FileETagコマンドを使用できます。これは静的コンテンツに適用されます。動的に生成されたコンテンツの場合、アプリケーションは「ETag」を正しく生成する責任があります。
このディレクティブを使用して、Apacheが Etagの計算に使用する属性を設定します。これは、 ETagを変更するかどうかに応じて、 INode、 MTime、 Size、または Allになります（ファイルが inodeによって変更されるたびに、変更時刻が変更され、サイズが変更されます。 、または上記のすべて）。複数の値を指定できます。また、新しい設定の前に +または -を追加することで、サブコンテキストで継承された設定を変更できます。ここでは、「all」のみを使用して、すべての変更が登録されるようにします。
< VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
CacheQuickHandler off
CacheLock on
CacheLockPath /tmp/mod_cache-lock
CacheLockMaxAge 5
CacheIgnoreHeaders Set-Cookie
< Location />
CacheEnable disk
CacheHeader on
CacheDefaultExpire 600
CacheMaxExpire 86400
CacheLastModifiedFactor 0.5
ExpiresActive on
ExpiresDefault "access plus 5 minutes"
Header merge Cache-Control public
FileETag All
< /Location></VirtualHost>
これにより、「Cache-Control」の既存の値に「public」（コンマで区切られます）が追加され、「ETag」の静的コンテンツが含まれます。
終了したら、ファイルを保存して閉じます。次のコマンドを入力して、変更された構文を確認します。
sudo apachectl configtest
エラーが見つからない場合は、サービスを再起動してキャッシュ戦略を実装します。
sudo service apache2 restart
非常に多くのオプションがあるため、Apacheを使用してキャッシュを構成することは困難な作業のように思われます。幸いなことに、単純なものから始めて、さらに複雑にする必要があるときに成長するのは簡単です。ほとんどの管理者は、すべてのタイプのキャッシュを必要としません。
キャッシュを構成するときは、さまざまな実装の選択で迷子にならないように、解決しようとしている特定の問題に留意してください。ほとんどのユーザーは、少なくともヘッダーを設定することで恩恵を受けるでしょう。コンテンツをプロキシまたは生成する場合は、HTTPキャッシングを設定すると役立つ場合があります。バックエンドプロバイダーを使用する場合、共有オブジェクトキャッシュは、SSLセッションや認証の詳細の保存などの特定のタスクに役立ちます。ファイルのキャッシュは、システム速度が遅いファイルに制限される場合があります。
コンテンツキャッシングの構成に関するその他の関連チュートリアルについては、[Tencent Cloud + Community]（https://cloud.tencent.com/developer?from=10680）にアクセスして詳細を確認してください。
参照：「Ubuntu14.04でApacheコンテンツキャッシングを構成する方法」
Recommended Posts