最近、クライアントがプロキシサーバーからページをリクエストしたときに何が起こるかについてのディスカッションに参加しました。この一連のイベントに対する私の理解が一般的なケースで正しいことを確認したかっただけです。
どんなフィードバックでも最もありがたいです。
厳密には、クライアントの構成方法によって異なります。基本的な例としてIEを使用しましょう。
IE withexplicitproxy:を設定した場合、例:no他のオプションはチェックされ、プロキシは何かに設定されます:8080。
ユーザーが住所を入力する
IEは文字列の一致についてアドレスをIEプロキシ例外リストと照合します(つまり、「これらのアドレスのプロキシをバイパスする:」))
a。 Bypassリストのエントリと一致する場合、client独自のDNSを使用して名前を解決し、クライアントはポートのターゲットIPアドレスに直接接続します80(想定)、次のようなリクエストを送信します:
GET /something.htm HTTP/1.1
Host: fulldomainame.example.com
b。 一致するバイパスリストエントリがない場合、続行します。
IEは設定されたプロキシに接続し、次の形式のリクエストを送信します。
GET http://fulldomainname.example.com/something.htm HTTP/1.1
ボーナスfactoid:URLでのFQDNの使用は、クライアントが実際のWebサーバーではなくプロキシと通信している
プロキシはそのホスト名を自身のDNSを使用して解決し、ターゲットサイトに接続します(アクション上記のステップ2のクライアントのように)など.
WPAD/PACを使用する場合:
自動構成が有効になっているときにISA/TMGによって提供されるスクリプトなど、Webプロキシ自動検出(WPAD)またはプロキシ自動構成(PACまたはAutoconfig)スクリプトを使用する場合、それは異なります。
ユーザーが住所を入力する
クライアントダウンロード構成された場所から現在のwpad.dat/autoproxy.js/.pacファイル
クライアントはjsファイルで関数「FindProxyForUrl」を探して実行します
Autoproxyスクリプトはhostnameと[〜#〜] url [〜#〜]を処理します。これは機能が制限されたJavaScriptファイルですが、多くのことがまだ可能です。
a。これにはname resolution(IsInNet、DnsResolve)が含まれる場合があります
b。これにはstring matching(ShExpMatch)が含まれる場合があります
c。これには100万までのカウントが含まれます(i ++)
d。これには、厄介な警告ポップアップメッセージが含まれる場合があります(管理者がジャークの場合)
FindProxyForUrl関数は、少なくとも1つの文字列を返します:使用する最適なプロキシの順序付きリスト(セミコロン)分離)
a。 "DIRECT"のいずれか。この場合、上記のバイパスの場合と同様に、クライアントは名前自体を解決して直接接続する必要があります。
b。または "PROXYプロキシ名:8080"または同様の場合、クライアントはそのプロキシのポートに接続し、完全なURLを取得するように指示します、プロキシは名前解決を実行します。
時々グリッチ、微妙な問題、原因不明の動作が発生しますが、ほとんどが奇妙で興味深い方法で問題が解決されない場合、上記は長年に渡って動作することを私が見てきた方法です。新しいブラウザーは、動作を最適化し、さまざまなものを並列化し、常に興味深いことを試みています。詳細については、ご使用のブラウザーの最新のドキュメントを確認してください。
WinSock Proxy/ISA Firewall Client/TMG Client:
Winsock Proxy Client(TMG/ISA Serverから)に興味がある場合は、これは別の話ですが、より柔軟で可動部分があります。ここでは説明が多すぎますが、それがどのように機能するかを説明するドキュメントがあります。つまり、Windowsソケットにプラグインし、TCP/UDPベースのトラフィックと名前解決要求の両方をアプリごとおよびユーザーごとに傍受できます。非常に強力ですが、現在は非推奨であり、数年間更新されていません。
クライアントは本当にドキドキすることができます:
1つ最後の注意:HTTPクライアントが特定のサイト/ URLのプロキシと通信することを決定すると、プロキシがそれを伝える方法はありませんしない。
「私はそれを提供しません、代わりに直接それに行くべきです」のためのHTTPステータスコードまたはヘッダーはありません...
特定のURLがプロキシで配信されるとクライアントが判断すると、proxy-death-gripが続きます。
これを回避する唯一の方法は、PACまたはバイパスリストで、クライアントが接続する直前に選択ロジックを取得することです。
ゾーンとPACファイルに関する最後の注記
IEは、[〜#〜] direct [〜#〜]に接続されているサイトを扱います-URLにドットが含まれている場合でも-URLの一部としてローカルイントラネットゾーン(デフォルト-ゾーンのプロパティで設定可能)。これらのサイトに統合Windows認証を許可する(KerberosやNTLM認証などを透過的に許可する)などの処理を行います。したがって、何かがローカルイントラネットゾーンにあるかどうかを制御することで、自動認証に関してそれがどれほど信頼できるかを定義します。繰り返しますが、少なくともデフォルトでは。
私はそうは思いません-IPとドメインを例外リストに入力するか、ドメインを入力し、IPが例外リストにある場合、おそらくプロキシを経由します。
Proxy.pac/wpad.datを使用すると、この動作から抜け出すことができます。
DNSの部分が正しいかわかりません。有効なDNSサーバーがないマシンがIEでページをフェッチするプロキシを使用して問題なく動作することを確認しました。
私はubuntu 10.04、wine、IE 6.0とsquid 2.7を試します(システムには1つのdnsとsquidには他のdnsサーバーがあります)
IE 6.0はDNS名を解決しません。