httpプロキシはどのように機能するのですか?
質問
http-proxyについてWebで検索してみました。 私はプロキシサーバーについてのWiki-articlesを読みました。 しかし、私はまだhttpプロキシがどのように動作するかを理解していない、愚かな私。
以下は、httpプロキシの仕組みについての私の推測です。 もし私がhttp-proxyを特定のもの、例えばProxy_Aに設定した場合、私がクロム/IEを起動し、特定のURL、例えばURL_Aを入力すると、クロム/IEはProxy_Aに直接リクエストを送るのでしょうか? その後、Proxy_AはURL_Aの実サーバーにリクエストを送信するのでしょうか?
どのように解決するのですか?
HTTP プロキシは HTTP プロトコルを話し、特に HTTP 接続のために作られていますが、他のプロトコルにも悪用することができます (これはすでにある種の標準です)。
ブラウザ (CLIENT) は
GET http://SERVER/path HTTP/1.1
をプロキシに送る。
これで PROXY は実際のリクエストを SERVER に転送することになります。
サーバーはPROXYを接続とみなし、CLIENTに対するのと同じようにPROXYに応答します。
PROXYは応答を受信し、CLIENTに転送する。
これは透過的な処理であり、ほとんどサーバと直接通信しているようなものなので、ブラウザがHTTPプロキシを実装するのは小さなオーバーヘッドに過ぎません。
クライアントを識別するために送信できる追加のヘッダーがいくつかあり、プロキシを使用していることを明らかにします。
プロキシは、さまざまな目的のためにデータストリーム内のコンテンツを変更/追加することがあります。
たとえば、一部のプロキシは、サーバー側でログを記録したり、スクリプトで傍受したりできる特別な HTTP HEADER に実際の IP を含めます。
CLIENT <---> PROXY <---> SERVER
更新しました。
セキュリティ/プライバシー機能としてのプロキシの使用に関するもの
上のアスキーでわかるように、CLIENTとSERVERの間には直接の通信はありません。両者はただ、両者の間にあるプロキシと会話しているだけです。
現代の世界では、クライアントがブラウザで、サーバーがウェブサーバー(例えばApache)であることがよくあります。
このような環境では、ユーザーはしばしばPROXYが安全であり、自分の身元を漏らさないと信じています。
しかし、ブラウザ上で動作する複雑なソフトウェアフレームワークのために、このセキュリティモデルを台無しにする多くの可能性があります。
例えば、Flash や Java アプレットは、プロキシ接続が壊れる可能性がある完全な例です。Flash と Java は両方とも、親アプリケーション(ブラウザ)のプロキシ設定をあまり気にしていないかもしれません。
別の例として、DNS リクエストがあり、PROXY とアプリケーションの設定によって、PROXY なしで宛先のネームサーバーに到達することができます。
他の例として、クッキーまたはブラウザーのメタ足跡(再溶解、応答時間、ユーザーエージェントなど)があります。
そして最終的には、プロキシはそれを通過するすべてのデータを読むことができ、さらにSSLセキュリティ(man in the middleについて読む)を破ることができるかもしれないので、プロキシ自体を信頼する必要があるのです。
どこからプロキシを入手するか
プロキシはサービスとして購入することも、スキャンすることも、単に自分で実行することもできます。
公開プロキシ
これらは最もよく使われるプロキシで、通常の「公開」という言葉はかなり誤解を招きます。
より良い用語は、"オープン プロキシ"です。ファイアウォールや認証なしでプロキシサーバを実行すると、世界中の誰もがそれを見つけて悪用することができます。
プロキシを販売する企業の大多数は、そのようなプロキシをインターネット上でスキャンするか、ハッキングされたWindowsコンピュータ(ボットネット)を使用して、主に違法行為/スパム行為のためにそれらを販売しています。
ほとんどの現代的な国は、許可なくオープン・プロキシを使用することを乱用と見なすことができます。
インターネット上でオープンポートを検索することで、プロキシをスキャンすることができます。
https://nmap.org
注意事項として より大規模なスキャンを行うと、ほぼ間違いなく ISP によってインターネット接続が禁止されます。
有償プロキシ
ここでは、4種類のプロキシをご紹介します。
1) 有料公開(オープン)プロキシ
基本的にこれらの販売者は、定期的に死んだものを削除するために更新されているプロキシの巨大なリストを販売または再販しています。
このプロキシは大規模に悪用され、通常、Googleを含むほとんどのサイトでブラックリストに登録されています。
また、これらのプロキシは通常、非常に不安定で非常に遅いです。
これらのプロキシの大部分は、単に間違って設定されたサーバーを悪用しているのです。
これは非常に競争の激しい市場であり、Google は多くの例を導いてくれるでしょう。
2) 有料のハッキングされた (ボットネット) プロキシ
これらは、プロキシホストとして、主にインターネット・オブ・シングスやウィンドウズ・デスクトップなどのコンピュータを悪用するものです。攻撃者は、さまざまな違法な目的のためにそれらを大規模に使用します。
販売者は通常、その違法性を隠すために、これらを "residential proxies" と呼びます。
このようなプロキシを使用することは間違いなく違法であり、悪用されたユーザーは、接続先への接続を乗っ取る可能性も含め、接続すれば簡単に "あなたの" IP を記録することが可能です。
送信元によっては、それらのIPはブラックリストに載っていないので、quot;品質"は公開プロキシよりもはるかに優れています。
3) 有料共有プロキシ
これらはデータセンターのプロキシで、通常、高速アップリンクで合法的かつ潜在的なものです。
多くの電子商取引スパムが発生しているため、これらのIPは大量に乱用され、通常はブラックリストに掲載されています。
典型的な使用方法は、craigslist の制限や地域制限の回避です。
4) 有料のプライベート/専用プロキシ
private"は専用を意味します。オペレータがプロである場合、それはあなたのプロキシが他の人々の間で共有されていないことを意味します。
これらはしばしばより専門的で法的な活動のために使用され、特にプロキシIPがより長い期間のためにレンタルされるときです。
よく知られたオペレータは
https://us-proxies.com
独自のプロキシ
独自のプロキシを実行することも可能で、様々なオープンソースプロジェクトがあります。
主に使用されるプロキシサーバーは
https://squid-cache.org
関連
-
[解決済み] HTTP GET(リクエストボディ付き
-
[解決済み] java.net.URLConnectionを使用してHTTPリクエストを発生させ処理する方法
-
[解決済み] HTTP POSTリクエストでは、どのようにパラメータが送信されるのですか?
-
[解決済み] updateとdeleteのHTTPステータスコード?
-
[解決済み] カスタムHTTPヘッダー:命名規則
-
[解決済み] HTTPファイルアップロードの仕組みを教えてください。
-
[解決済み] OPTIONSリクエストを送信する理由と、それを無効にする方法を教えてください。
-
[解決済み】HTTPのPOSTとPUTの違いは何ですか?
-
[解決済み】REST APIでのPUTメソッドとPATCHメソッドの使い分け 実生活でのシナリオ
-
[解決済み] HTTPリダイレクトコードの違い
最新
-
nginxです。[emerg] 0.0.0.0:80 への bind() に失敗しました (98: アドレスは既に使用中です)
-
htmlページでギリシャ文字を使うには
-
ピュアhtml+cssでの要素読み込み効果
-
純粋なhtml + cssで五輪を実現するサンプルコード
-
ナビゲーションバー・ドロップダウンメニューのHTML+CSSサンプルコード
-
タイピング効果を実現するピュアhtml+css
-
htmlの選択ボックスのプレースホルダー作成に関する質問
-
html css3 伸縮しない 画像表示効果
-
トップナビゲーションバーメニュー作成用HTML+CSS
-
html+css 実装 サイバーパンク風ボタン
おすすめ
-
[解決済み] リバースルーティングとは何ですか?
-
[解決済み] リソースを "アンキャッシュ" する
-
multipart/form-data と application/octet-stream, application/x-www-form-urlencoded の違いについて
-
[解決済み] Google ChromeでSPDYを無効にする方法
-
[解決済み] X-REQUEST-ID httpヘッダーとは何ですか?
-
[解決済み】全てのブラウザで、Webページのキャッシュを制御するには?
-
[解決済み】no-cacheとmust-revalidateの違いについて
-
[解決済み] サーバーサイドでCookieを削除する正しい方法
-
[解決済み] HTTPヘッダーの設定
-
[解決済み] URLのプロトコルを継承するために、先頭のダブルスラッシュを使用することに何か不都合はありますか? 例:src="//domain.com"