問題の本質を掘り下げないために、次の記事から、部長のAlexander Zharovとのインタビューの断片を取り上げます。
「4社が競争に参加しています。 要件は、シンプルで非常に厳しいという事実にもかかわらず。 勝者は、最低価格と最高のソリューションを提供する人です。 初期契約価格は1億ルーブルです。」 監督当局の長によると、「検査官」システムにより、禁止サイトのブロックの有効性をリアルタイムで監視できるようになります。
問題の本質（引用）：
プローブまたはプログラムの本質は、通常のユーザーとして、単純なユーザーよりも高速で、禁止リソースのリスト全体に大量のリクエストを送信し、サイトがブロックされている場合にRoskomnadzorのインスペクターに通知できることです。
最終結果のみに関心があると仮定します。ILVインスペクターは、各プロバイダーに対してサイトがブロックされているかどうかについての情報を取得したいと考えています。
原則として、タスクは非常に明確です。「最適なソリューション」を見つけてください。
仮に、いわゆる「インスペクタ」が特定のプロキシのサーバー応答を受け取る通常のプロキシチェッカーであると仮定しましょう。 必要なもの：
- すべてのプロバイダーのリスト
- 各プロバイダーからの約10のプロキシ
- 禁止ページのリスト（レジストリからの情報）
この入力があれば、3段階で動作するプロキシチェッカーを作成できます。
- レジストリから禁止ページのリストをアンロードします（あまり多くありません。非公式データによると12,000）
- すべてのプロバイダーのIPアドレスごとにサーバー応答を受信する
- レポート生成/提出
すべてのプロバイダーの最新リストがあり、各プロバイダーがすべての地域データセンターから1つのプロキシを割り当てることを約束しているとします。 プロバイダープロキシごとに禁止ページの登録簿からリスト全体の調査を周期的に行い、各地域のデータセンターの回答を受け取るだけで十分です。 レポートでは、このドキュメントまたはそのドキュメントが正しい答えを示し、レジストリからのドキュメントがブロックされている最新情報を常に受け取り、レポートに対する否定的な回答を公開します。これは、どのプロバイダーおよびどのデータセンターが禁止リソースへのアクセスを制限していないかを明確に示します。 さて、生成されたレポートに基づいて、あなたはすでに空想することができます。 検査官は関連情報を見るでしょう-これは明らかですが、これは制限できません。 各データセンターのプロキシのリストを提供するだけでなく、レジストリの処理を担当する認定機関の連絡先メールアドレスを同時に提供するようプロバイダーに義務付ける場合、各プロバイダーに技術要件の違反を自動的に通知できます。
さらに、各プロバイダーのほとんどのデータセンターは同じレジストリ処理システムを使用しています。この場合、プロバイダーはRoskomnadzorの要件を完全に満たしているか、どこかで欠陥が発生しており、データセンターはまったく問題ではありません。プロバイダー全体で規模がグローバルになります。
それにもかかわらず。 プロキシを提供するように各プロバイダーに義務付けることは、あまりにもグローバルに見えますが、原始的ですが、おそらくこれは監査人の仕事です-この必要性を回避すること。 しかし、人件費の最適化について話す場合、検査官はこのリストを実際には助けません。そのため、いずれの場合でも、レポートを通じてプロバイダーに通知する必要があります。 したがって、各プロバイダーの最新情報を維持している場合は、適切な部門に信号を送信して問題を解消できます。
これは複雑ですが、かなり原始的なソリューションです。 プロバイダーがILVに関連するプロキシサーバーのリストを作成するまで待ちます。解決方法はありません。 しかし、「初期段階で、700のプローブが主要な通信事業者の回線にインストールされる」という事実から判断すると、プロバイダーにプロキシの提供を義務付けることは、すべてのトラブルの中で最小です！
それでは、タスクに戻って、「集合農場」を考えてみましょう。しかし、目的の結果を得るためのより迅速でより原始的な方法です。 繰り返しになりますが、タスクの引用を思い出します。「ILVインスペクターは、各プロバイダーに対してサイトがブロックされているかどうかについての情報を取得したいのです」。
さて、ロシアから入手可能なすべてのプロキシのリストがあると想像してください。 たとえば、100,000個ありますが、4つのステージが必要です。
- プロバイダー定義のプロキシを確認する
- 一意のプロバイダーのリストを作成する
- 各プロキシのレジストリからのページの応答の確認
- 同じレポートを生成する
最初のポイントだけが理解できないように見えるかもしれません。 その上で私は詳細な答えをします。 使用可能なプロキシのリストがあるため、各IPアドレスのホスト名を使用して各プロバイダーを簡単に識別できます。また、そのようなソリューションは既に利用可能です。 たとえば、2ipサービスを開くと、IPアドレスに関する情報が表示されます。
ご覧のとおり、プロバイダーのIPアドレスを特定することは難しくありません。 したがって、現在のプロキシサーバーのリストを使用しても、2段階でプロバイダーのメンバーシップの各プロキシのポーリングを確認し、重複するプロバイダーをすべてマークしてプロキシをグループ化し、グループが一意である可能性のあるプロバイダーの最大一意リストに従ってレジストリをポーリングできますこのプロバイダーまたはそのプロバイダーへのプロキシ。 プロバイダーの人気に応じて、拡張プロキシグループがありますが、結局、各プロキシを通じて12,000のすべての禁止ページを追い出し、人気のあるプロバイダーの問題が解決された場合（人気のあるプロバイダーとプロキシグループがかなり大きく、12全体に回答を均等に分散するため000のドキュメントは非常に現実的です）、その後、神が1つのライブプロキシのみが禁止されているプロバイダーのリストをどう処理しますか？ 12,000ページのリスト全体を実行しないでください。
PS最後に、プロキシの使用は非常に「集合的なファーム方式」であり、実装の可能性のみを示しています。 しかし、ほとんどの場合、利用可能なプロキシを忘れないでください。これは誰かのボットネットであり、もちろんILVはプロキシリストを使用できません。
実際、Roskomnadzorは、タスクを実装するためのはるかに高価で最適性の低いオプションを計画していました。 ただし、ブロッキングサイトの実行の関連性の問題が非常に深刻な場合、禁止されたサイトのレジストリから特定のリソースへの応答を実際に確認するために、プロバイダーにデータセンターからいくつかのプロキシを選択するよう義務付ける方がより信頼性が高くなります。 さらに、レジストリ処理センターはデータセンターに一切結び付けられておらず、レジストリ処理アルゴリズムはプロバイダー全体でグローバルである可能性が高いです。 したがって、不発もグローバルになります。つまり、データセンターごとに追加のトラブルを発生させることなく、プロバイダーのリストに限定することができます。
このようなソリューションは十分に高速で信頼できるように見えます。最も重要なことは、車輪を再発明してプローブと呼ぶことです。 さらに、プロバイダーは、オプションの実装に何らかの形で参加する必要があります。 そのため、プロバイダの側で何かを制御するよりも、あなたの側でアルゴリズムの関連性を維持する方が簡単であり、それを実装するために多くを必要としません。