チェックしておきます。ソース自体が二度目のアクセスで書き換えられるケースも多く、決して「早くなった」ということはありません。逆にキャッシュされた差分の更新のため、ページの表示が一時停止してしまい、リロードなどが必要なケースも増えます。ウェブページの先頭に別サイトへの広告リンクやSNSへのリンクがあるサイトはあまり高速化されません。そもそもローカルキャッシュが先に使われるわけですから、同じページを見たときに「早い」と思うか「遅い」と感じるかは、そもそもPC自体の使い方、性能の問題です。プロクシが間に入る分、オーバーヘッドがあるので、一概に「早く快適」になるものではありません。効果はあまりないように思えます。エッジの効率化を目的としたキャッシュアプライアンンスを導入したほうがよいように思います。プロクシがあっても、ローカルキャッシュの方がよいに決まっています。ディストリビューションのダウンロードなどは、「あまりいじらない」仮想PCで行うのが一番確実なのですが、LAN内に「暴れん坊PC」が一台あるとたちまち回線は混雑してくれます。彼らが動画サイトなどにアクセスすると、他でダウンロードが途切れたりするのですが、構内LANにあるキャッシュを経由するようになると、トラフィックの交通整理をしてくれるためなのか、非常に安定した速度でダウンロードしてくれます。利用者のPCとサイトの接続をプロクシが代理応答するわけですから、たとえ遅くてもユーザシステムの通信負荷は若干減ります。使ってみてもらうと、よく落ちていたシステムが安定したという話は聞きます。逆に「プチフリーズしたか」という面もあります。「暴れん坊」のアクセスは途切れたりするわけですが、これはこれで「ルールを守って100Kmで走ろう」ということであれば、仕方のないことです。高速道路には、日常物資を運ぶトラックも走っているというわけです。設定を変更して再起動すると、これまでキャッシュ経由してダウンロードしていたリクエストは全部キャンセルされます。設定の変更は十分な計画とテストを行うべきでしょう。-明示的にキャッシュを指定する必要がある-アプリケーションによっては明示的にキャッシュサーバを指定しなければならないものがあります。自分で設定する必要があります。他のアプリケーション、特にアップデート系のアクセスは不明です。グループポリシーで設定できないと、ユーザに明示的に利用させるしかないでしょう。導入する際にダウンロードできるのは「本体」ではなくインストーラだけです。さんから本体をダウンロードさせます。アプリケーションではプロクシを使った場合どのような結果になるか、明らかにしている場合もあれば、まったく公開していない場合もあります。アナライザで調べるしか方法はありません。簡単にボタンひとつで変更ができればよいのですが、プロクシの設定は管理者権限が必要なので、一般ユーザ権限でプロクシの設定を変えることはできないのは何とかしたいものです。ツールで見る限り、これらのアプリケーションのアップデートはシステムのデフォルトプロクシを使っているようですが例外も多くあります。並に利用中のアプリケーションのアップデートが始まったら、ユーザになるべく同じ時間帯にアップデートさせれば、効果はあるのかもしれません。よいのは、トランスペアレントプロクシを使うことですが、耐障害性を考えると複数用意したいところです。複数用意するとキャッシュ効果も下がるため、お勧めできるものでもありません。ネットワークの設計がかなり複雑になります。凝ったネットワークデザインは「マニアック」に陥りやすく運用面でトラブルが出るとお手上げになります。全てのトラフィックがプロクシを経由するため、通信状況(ログ)の把握やブラックリストの管理は容易になります。-キャッシュ容量-これだけ光だDSLだ動画だSNSだとなると、今まで数Gもあれば良かったキャッシュ容量も膨大になります。本当に「効果」を感じるには数百Gバイト単位でウェブキャッシュを使う必要がありそうです。3G通信などは3Gバイトの転送制限をしている、あるいはOCNの光通信では月間アップロード量が30Gあると「お仕置き」が待っているように、1日1人1Gというのが最低の目安だとすれば、100人で1日100Gは最低。できれば1Tくらいのキャッシュ容量がなければ「快適になった」という実感はなさそうです。本体が動作するどこかのディスクにキャッシュを用意しなければならないということになります。ここだけ別パーティション、別デバイスとするべきでしょう。デバイスなどを使う限り、ローカルLAN内のトラフィックを増やすだけなので、DAS接続したドライブを使うべきなのかもしれません。-それでも入れて見るべきかウェブキャッシュ-これは技術の問題よりモラルの問題かもしれません。固定専用回線であっても、上位のISPがパンクするようでは意味がないので、クラウドを有効活用するには、少しでも自分たちの回線の「効率化」と「整流化」を考えても良いと思います。ここでもし自分たちのためにウェブキャッシュを導入しようとするならば、自分たちの構内に置かなければまったく意味がないということです。データセンターにウェブキャッシュをおきたいというお客様がいましたが、データセンター自体、巨大なウェブキャッシュを持っているだろうから、まったく効果はありません。センターと構内を結ぶエッジに置くべきものです。-DNSと同居-ウェブキャッシュはDNSと同居させるのが一番楽な方法です。アドレスクエリを内部で処理できるため、余分なトラフィックを作らないでしょう。DNS本体が肥大化するため、この点でも設計は結構難しいかもしれません。-問題はCIFSのアクセラレーション-これは現実にお客様で聞いた話なのですが、某社の高価なCIFSアクセラレータを100人程度のリモートオフィスに導入したところ、全く役に立たなかったという話を聞いたことがあります。サーバを利用することになったようでした。プロトコルの方が効率は良かったようです。エッジの効率化はまだまだ問題が多そうです。ツールをインストールします。インターフェース名を指定します。yy:yy:yy:xx:xx:xxこのような感じでトラフィック監視を行います。白い部分はグラフです。