タグ付けされた質問 「proxy」

3
CloudFlareのようなCDNはどのように機能しますか?
この質問は、Webmasters Stack Exchangeで回答できるため、Web Applications Stack Exchangeから移行されました。 5年前に移行され ました。 私がこれまでに理解していること: 現在のWebホスティングを維持しますが、サイトのDNSサーバーを現在のホスティングのDNSサーバーからCloudFlareのDNSサーバーに変更します。 CloudFlareは、世界中の複数のデータセンターからWebサイトのリソースを提供します。 ここで、このメカニズムの技術的な詳細を知りたいと思います。ここに私が持っているいくつかの質問があります: CloudFlareはキャッシュプロキシとして機能しますか?自分のサイトのページにたくさんの画像があるとします。CloudFlareは、それらのすべてのイメージを各データセンターにキャッシュし、それらのデータセンターから提供しますか? どのサイトリソースが影響を受けますか?静的なものだけですか?Webページ自体(HTMLドキュメント)はどうですか?ページがサーバーによって動的に生成された場合はどうなりますか?CloudFlareは、ページの最新バージョンを常に提供することをどのように確認しますか? 私のサイトへのPOSTリクエストはどうでしょうか(たとえば、訪問者がAjaxを介してデータをアップロードし、データベースに保存されます)。このことは私のサーバーで実行する必要があります。そのため、CloudFlareはこのプロセスのパフォーマンスを向上させません(できません)。それでは、CloudFlareはAjaxリクエストを元のWebホストに中継するだけですか?
23 cdn  proxy  post  cloudflare 

2
CloudFlareが動的コンテンツに実際に影響を与えないのは本当ですか?
私はCloudFlare FAQを読んでいますが、これはリバースプロキシとして機能し、ドメインへのすべてのリクエストはCloudFlareを経由することを理解しています。 彼らはFAQで動的コンテンツを遅くしないと言っていますが、これは可能ですか? 要求されたすべての動的コンテンツはサーバーから要求されるため、サーバーがサーバーに要求してクライアントに送信する必要はありません。 それは少なくとも私が理解している彼らです。 これは動的コンテンツを遅くするように思えます。 それは本当ですか?CloudFlareは動的コンテンツに影響しませんか?
11 performance  cdn  proxy 

1
GoogleがWebサイトからバイナリをダウンロードして帯域幅を使用するのはなぜですか?
2014年8月中旬以降、いくつかのGoogleサーバーが私のWebサイトにある(非常に)大きなバイナリファイルのすべてを週に1回程度ダウンロードしています。IPはすべてGoogleが所有しているものとして表示され、次のようになります:google-proxy-66-249-88-199.google.com。これらはGETリクエストであり、サーバーのトラフィックに大きな影響を与えています。 これまでは、これらのGoogleプロキシIPからのトラフィックは見られなかったため、これは比較的新しいもののようです。他のGoogle IPからのすべての種類のトラフィックが表示されますが、それらはすべてgooglebotおよびHEADリクエストのみです。 これらのファイルがすべてGoogleによってほぼ毎週ダウンロードされることを除いて、私はこれについて心配しません。使用される帯域幅が過剰になり始めています。 これらのファイルの多くはWindows実行可能ファイルであるため、おそらくGoogleがマルウェアスキャンを実行するためにそれらをダウンロードしているのではないかと推測しています。それが本当だとしても、それは本当に毎週起こる必要があるのでしょうか? これまでの11月のGoogleプロキシIPからのトラフィックの例: google-proxy-64-233-172-95.google.com: 8.09 GB google-proxy-66-102-6-104.google.com: 7.50 GB google-proxy-66-249-83-245.google.com: 3.35 GB google-proxy-66-249-84-131.google.com: 1.54 GB google-proxy-66-249-83-131.google.com: 4.98 GB google-proxy-66-249-83-239.google.com: 2.48 GB google-proxy-66-249-88-203.google.com: 2.94 GB google-proxy-66-249-88-201.google.com: 2.58 GB google-proxy-66-249-88-199.google.com: 4.89 GB アップデート#1:問題のファイルがすでにサイトのrobots.txtファイルにあることを忘れていました。robots.txtの設定が適切に機能していることを訴えるために、Googleウェブマスターツールのrobots.txtテスターも使用しました。これは、ファイルがすべてのGoogleボットに対して確実にブロックされていることを示しています。ただし、Adsbot-Googleは例外です。それがどちらなのか、よくわかりません。さらに、Googleで一部のファイルを検索しましたが、検索結果に表示されません。 更新#2:例:11月17日の午前5時12分から午前5時18分の間、約6のIP(すべてgoogle-proxy)が問題のすべてのバイナリファイル(合計27)でGETを実行しました。11月4日の午後2時9分から午後2時15分の間、それらの同じIPは基本的に同じことを行いました。 更新#3:この時点で、これらは有効なGoogle IPですが、Googleのプロキシサービスの一部であり、Googleのウェブクロールシステムの一部ではないことは明らかです。これらはプロキシアドレスであるため、GETリクエストが実際にどこから発生しているか、または1か所から送信されているのか、それとも複数の送信元から送信されているのかを判別する方法はありません。GETの散発的な性質に基づいて、悪質なことが行われているようには見えません。Googleのプロキシサービスを使用しているときに、すべてのバイナリをダウンロードすることを決めただけの可能性があります。残念ながら、そのサービスは完全に文書化されていないようで、役に立ちません。サイト管理者の観点から見ると、プロキシはかなり煩わしいものです。彼らは正当な用途があるので、私はそれらをブロックしたくありません。しかし、それらは誤用される可能性もあります。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.