私は今日のプロキシサーバーが果たすことができる役割について正確には知りません.クライアント側でプロキシ環境から抜け出す方法をネゴシエートします。
私は既存のクライアントおよびサーバー システムを C および C++ で記述して速度を上げ、クライアントに少量の MFC を使用してユーザー インターフェイスを処理しています。私は Windows 上のシステムのサーバー側とクライアント側の両方を作成しました (私が働いている人々は主に Windows のすべてを使用する Web 開発者です - 選択ではありません) 効率のために wsock32 を介したバークレーソケットに固執しています。クライアントは、非標準ポートを介してサーバーに接続します (ポート 80 を使用することは一部の環境から抜け出すためのオプションですが、それを通過するプロトコルは HTTP ではありません)。クライアントがリアルタイム会議に参加している間、TCP 接続は開いたままになります。
当社の顧客ベースは、あらゆる種類のネットワーク環境に拡大しています。ポート 443 経由で安全に接続する機能を追加し、内部パケットを傍受できないため、プロトコルが多くの環境を通過できるようにするセキュア ソケットを使用することで、多くの問題を解決できました。しかし、ますます多くのお客様がプロキシ サーバー環境の背後にいて、私の直接接続がうまくいきません。私の昔からのプロキシ サーバーの理解では、プロキシ サーバーは HTTP 経由で外部の HTML コンテンツのプロキシとして機能し、ローカル アクセスを高速化するために人気のあるコンテンツをローカルにキャッシュし、IT スタッフが特定の宛先サイトをブラックリストに登録できるようにします。顧客は、私のソフトウェアがプロキシ環境を認識せず、簡単にナビゲートできないと不満を言っていますが、私は 「最適な」ソリューションを決定するのが難しいと感じています。私のソフトウェアは、各クライアント要求の後に接続を切断しません。その上、パケットはいつでもどちらの側からも来ることができます。基本的に、特定のニッチ向けの典型的なカスタム クライアント/サーバー システムです。
私の最初の反応は、「なぜ彼らは私のサーバーのアドレスをホワイトリストに追加できないのか」というものですが、IT スタッフに助けを求めずにやり遂げることができるプログラム的な方法があれば、それは政治的に優れており、間違いなくより良い解決策です。さらに、最近のプロキシ サーバーと環境の役割と目的をまだ理解していない可能性もあります。
私の最初の試みは、WinInet のさまざまなプロキシ機能を使用して、ポート 80 経由で非標準プロトコル サーバー (単純な HTTP に見える GET 要求を認識して応答し、単純な初期パケット スニッフィング (DPI) を使用する一部の環境を回避するための HTTP 応答ページ)。WinInet の HINTERNET 要求オブジェクトの背後にある実際の SOCKET ハンドルを取得し、ソフトウェアの既存の SOCKET 接続の代わりにそれを使用することを望んでいました。クライアント側でこれ以上変更する必要がないことを願っています。最初はそれが私の解決策のように見えましたが、さらに調べてみると、標準の select(...
クライアント側のライブラリ (商用でも問題ありません) を使用すると、ユーザーと IT スタッフの助けを最小限に抑えて、これらのプロキシ サーバー環境を乗り越えることができると誰か教えてもらえますか? 私が読んだことから、それはSOCKSを超えて成長しており、誰かが私の前にこの問題を解決しなければならないと考えています.
私の長々とした質問を読んでくれてありがとう、
破れた