即時更新可能な静止ファイルクライアントキャッシュ
自動回転
http://blog.csdn.net/zandershi/article/details/2989131
Webサイトでは、css/js/imageなどの静止ファイルは、大量のネットワーク帯域幅を占めるだけでなく、サーバー側のCPUやIOシステムに大きな負荷をかけることが、サーバのスループットに影響する重要な要素である.この問題を解決するための有効な方法は、クライアントで静止ファイルをキャッシュすることである.キャッシュは、クライアントで即時に更新できない静的ファイルをもたらす可能性がありますが、いくつかのウェブサイトは、クライアントのjs/cssなどのキャッシュファイルを即時に更新しなければなりません.そうでなければ、ユーザー体験に影響を与えます.Web 2.0の時代には、これはさらに無視できない問題です.
では、ネットワークの流量やサーバーの負荷を減らすにはどうすればいいですか?また必要な時にすぐにクライアントキャッシュを更新する目的がありますか?
クライアントキャッシュを有効にする
HTTP/1.0の年代には、HTTPヘッダのExpiresフィールドを設定することで、ブラウザキャッシュの有効時間を教えることができます.しかし、この時間はサーバ側で生成され、クライアント側で検証されるので、サーバとクライアントの時間が同期していないと問題が発生する可能性があります.また、有効期限が切れる前に、ブラウザは直接にローカルキャッシュの内容を使って、ファイルが更新されているかどうかを確認するためにサーバとコミュニケーションを取りません.
HTTP/1.1プロトコルは、Cache-Coontrolという新しいHTTPヘッダフィールドを導入し、ブラウザがサーバにアクセスする時の時間を基準として、この基準に対する時間をキャッシュが無効になるべき時間として、サーバとクライアント時間が同期しないと発生する問題を解決しました.キャッシュが失効した後、
キャッシュが失効した後のファイル内容の検証
設定されたキャッシュの失効時間が到来すると、ブラウザはサーバに要求を送り、サーバ側の内容が正しく修正されたかどうかを検証する必要がある.
HTTP/1.0年代において、検証はLast-MaodifiedというHTTPヘッダフィールドを通じて、ファイルの最終修正時間によって判断されます.しかし、Last-Maodifiedの最小単位は秒ですので、ファイルの修正が一秒以内に発生したら、この仕組みは効果がありません.
この問題を解決するために、HTTP/1.1プロトコルはE-TAGフィールドを導入しており、ファイル修正のフラグをカスタマイズできます.ApacheのE-TAGはデフォルトでinode、ファイルサイズ、最終修正時間によって決定されます.
検証を行う場合、ブラウザはファイルの前回の修正時間またはE-TAG値をサーバに送信し、サーバはこの値からブラウザのキャッシュが更新されるかどうかを判断します.更新が必要な場合は、ファイルの内容をブラウザに送信します.そうでなければ、ファイルは変更として304ヘッダだけ送信します.
キャッシュ内容の即時更新
一部のサイトでは、クライアントキャッシュのjs/css/imageファイルはすぐに更新できるように要求されるかもしれません.つまり、サーバー側のファイルが修正されたら、クライアントは次回訪問時に更新されます.キャッシュが失効するまで待つ必要はありません.
一つの簡単な方法は、各静的ファイルに拡張子を付けることです.例えば、最後の修正時間を拡張子として使うと、一つのabc.jpgファイルに対する参照は、拡張子となる可能性があります.http://www.xxx.com/image/abc.jpg?v=1221109171.この拡張子を手動で生成するのは面倒くさいです.もしウェブサイトでスクリプト言語を使ってプログラムするなら、静的ファイルを引用するHTMLスクリプトを動的プログラミング言語に変更できます.
これにより、より良いクライアントキャッシュを実現し、必要に応じて即時にキャッシュを更新することができます.キャッシュを更新する必要がなければ、キャッシュが失効する前に、不要なクライアントとサーバとの間の接続要求がありません.キャッシュが失効した後、ファイルの内容が変更されていない場合、サーバは304ヘッダに戻るだけで、ネットワークトラフィックを最大限に低減します..
http://blog.csdn.net/zandershi/article/details/2989131
Webサイトでは、css/js/imageなどの静止ファイルは、大量のネットワーク帯域幅を占めるだけでなく、サーバー側のCPUやIOシステムに大きな負荷をかけることが、サーバのスループットに影響する重要な要素である.この問題を解決するための有効な方法は、クライアントで静止ファイルをキャッシュすることである.キャッシュは、クライアントで即時に更新できない静的ファイルをもたらす可能性がありますが、いくつかのウェブサイトは、クライアントのjs/cssなどのキャッシュファイルを即時に更新しなければなりません.そうでなければ、ユーザー体験に影響を与えます.Web 2.0の時代には、これはさらに無視できない問題です.
では、ネットワークの流量やサーバーの負荷を減らすにはどうすればいいですか?また必要な時にすぐにクライアントキャッシュを更新する目的がありますか?
クライアントキャッシュを有効にする
HTTP/1.0の年代には、HTTPヘッダのExpiresフィールドを設定することで、ブラウザキャッシュの有効時間を教えることができます.しかし、この時間はサーバ側で生成され、クライアント側で検証されるので、サーバとクライアントの時間が同期していないと問題が発生する可能性があります.また、有効期限が切れる前に、ブラウザは直接にローカルキャッシュの内容を使って、ファイルが更新されているかどうかを確認するためにサーバとコミュニケーションを取りません.
HTTP/1.1プロトコルは、Cache-Coontrolという新しいHTTPヘッダフィールドを導入し、ブラウザがサーバにアクセスする時の時間を基準として、この基準に対する時間をキャッシュが無効になるべき時間として、サーバとクライアント時間が同期しないと発生する問題を解決しました.キャッシュが失効した後、
キャッシュが失効した後のファイル内容の検証
設定されたキャッシュの失効時間が到来すると、ブラウザはサーバに要求を送り、サーバ側の内容が正しく修正されたかどうかを検証する必要がある.
HTTP/1.0年代において、検証はLast-MaodifiedというHTTPヘッダフィールドを通じて、ファイルの最終修正時間によって判断されます.しかし、Last-Maodifiedの最小単位は秒ですので、ファイルの修正が一秒以内に発生したら、この仕組みは効果がありません.
この問題を解決するために、HTTP/1.1プロトコルはE-TAGフィールドを導入しており、ファイル修正のフラグをカスタマイズできます.ApacheのE-TAGはデフォルトでinode、ファイルサイズ、最終修正時間によって決定されます.
検証を行う場合、ブラウザはファイルの前回の修正時間またはE-TAG値をサーバに送信し、サーバはこの値からブラウザのキャッシュが更新されるかどうかを判断します.更新が必要な場合は、ファイルの内容をブラウザに送信します.そうでなければ、ファイルは変更として304ヘッダだけ送信します.
キャッシュ内容の即時更新
一部のサイトでは、クライアントキャッシュのjs/css/imageファイルはすぐに更新できるように要求されるかもしれません.つまり、サーバー側のファイルが修正されたら、クライアントは次回訪問時に更新されます.キャッシュが失効するまで待つ必要はありません.
一つの簡単な方法は、各静的ファイルに拡張子を付けることです.例えば、最後の修正時間を拡張子として使うと、一つのabc.jpgファイルに対する参照は、拡張子となる可能性があります.http://www.xxx.com/image/abc.jpg?v=1221109171.この拡張子を手動で生成するのは面倒くさいです.もしウェブサイトでスクリプト言語を使ってプログラムするなら、静的ファイルを引用するHTMLスクリプトを動的プログラミング言語に変更できます.
function show_image($img){
return '<img src="'.$img.filemtime(WEB_ROOT.'/image/'.$img) . '"./>'
}これにより、より良いクライアントキャッシュを実現し、必要に応じて即時にキャッシュを更新することができます.キャッシュを更新する必要がなければ、キャッシュが失効する前に、不要なクライアントとサーバとの間の接続要求がありません.キャッシュが失効した後、ファイルの内容が変更されていない場合、サーバは304ヘッダに戻るだけで、ネットワークトラフィックを最大限に低減します..