クローラーの原理と耐クローラー技術

ビッグデータ業界にとって、データの価値は自明です。この情報爆発の時代では、インターネット上には情報データが多すぎます。中小零細企業にとって、貴重なデータをクロールするためにクローラを合理的に使用することは重要です。この記事では、主にクローラの原理、アーキテクチャ、分類、およびクローラ対策技術からクローラ技術について概要を説明します。

1. クローラー技術の概要

Web クローラーは、特定のルールに従って World Wide Web 情報を自動的にクロールするプログラムまたはスクリプトです。インターネット検索エンジンまたは他の同様の Web サイトで広く使用されており、アクセスできるすべてのページのコンテンツを自動的に収集します。これらの Web サイトのコンテンツと検索方法。機能的に言えば、クローラは通常、データ収集、処理、保存の 3 つの部分に分かれています。

従来のクローラーは、1 つまたは複数の最初の Web ページの URL から開始し、最初の Web ページ上の URL を取得します。Web ページをクロールするプロセス中、現在のページから新しい URL を継続的に抽出し、特定の URL が得られるまでキューに入れます。システムの停止条件が満たされています。フォーカスされたクローラーのワークフローはより複雑で、特定の Web ページ分析アルゴリズムに基づいてトピックに無関係なリンクをフィルタリングし、有用なリンクを保持してクロールを待つ URL キューに入れる必要があります。次に、特定の検索戦略に従ってキューから次にクロールする Web ページの URL を選択し、システムが特定の条件に達して停止するまで上記のプロセスを繰り返します。さらに、クローラによってクロールされたすべての Web ページはシステムによって保存され、後続のクエリと取得のために特定の分析、フィルタリング、およびインデックス付けが行われます。焦点を絞ったクローラの場合、このプロセスで得られた分析結果は、フィードバックやガイダンスを提供することもあります。今後のクローリングプロセス。

一般的な Web クローラーと比較して、集中型クローラーは次の 3 つの主要な問題も解決する必要があります。

(1) クローリングターゲットの説明または定義。

(2) Web ページまたはデータの分析とフィルタリング。

(3) URL の検索戦略。

2. 爬虫類原理

2.1 Webクローラの原理

Web クローラーシステムの機能は、Web ページデータをダウンロードし、検索エンジンシステムにデータソースを提供することです。Google や Baidu など、大規模なオンライン検索エンジンシステムの多くは、Web データ収集に基づいた検索エンジンシステムと呼ばれます。これは、検索エンジンにおける Web クローラーシステムの重要性を示しています。ユーザーが読むためのテキスト情報に加えて、Web ページにはいくつかのハイパーリンク情報も含まれています。Web クローラーシステムは、Web ページ内のハイパーコネクション情報を通じてネットワーク上の他の Web ページを継続的に取得します。この収集プロセスはネットワーク上を歩き回るクローラーやスパイダーのようなものであるため、Web クローラーシステムまたは Web スパイダーシステム、英語では Spider または Crawler と呼ばれます。

2.2 Web クローラーシステムの動作原理

Web クローラーのシステムフレームワークでは、主要なプロセスはコントローラー、パーサー、リソースライブラリの 3 つの部分で構成されます。コントローラーの主な仕事は、マルチスレッド内の各クローラースレッドに作業タスクを割り当てることです。パーサーの主な仕事は、Web ページをダウンロードしてページを処理することであり、主に一部の JS スクリプトタグ、CSS コードコンテンツ、スペース文字、HTML タグ、その他のコンテンツを処理します。クローラーの基本的な作業はパーサーによって完了します。リソースライブラリは、ダウンロードされた Web ページリソースを保存するために使用され、通常は Oracle データベースなどの大規模なデータベースに保存され、インデックスが付けられます。

コントローラ

コントローラーは Web クローラーの中央コントローラーであり、主にシステムから渡された URL リンクに従ってスレッドを割り当て、スレッドを開始してクローラーを呼び出して Web ページをクロールする役割を果たします。

パーサー

パーサーは Web クローラーを担う主要な部分であり、その主なタスクには、Web ページのダウンロード、フィルター機能などの Web ページのテキストの処理、特殊な HTML タグの抽出、データの分析が含まれます。

リソースライブラリ

これは主に、Web ページからダウンロードされたデータレコードを保存するために使用されるコンテナであり、インデックスを生成するためのターゲットソースを提供します。中規模および大規模のデータベース製品には、Oracle、SQL Server などが含まれます。

Web クローラーシステムは通常、より大きな出次数 (Web ページ内のハイパーリンクの数) を持ついくつかのより重要な Web サイトの URL をシード URL のセットとして選択します。Web クローラーシステムは、これらのシードコレクションを初期 URL として使用して、データクロールを開始します。Web ページにはリンク情報が含まれているため、一部の新しい URL は既存の Web ページの URL を介して取得されます。Web ページ間のポインティング構造はフォレストとみなすことができます。各シード URL に対応する Web ページは、ツリーのルートノードになります。森です。

このようにして、Web クローラーシステムは、幅優先アルゴリズムまたは深さ優先アルゴリズムに従ってすべての Web ページを横断できます。深さ優先検索アルゴリズムでは、クローラーシステムが Web サイトに侵入する可能性があり、Web サイトのホームページに近い Web ページ情報を検索するのに役立たないため、Web ページの収集には通常、幅優先検索アルゴリズムが使用されます。Web クローラーシステムは、まずシード URL をダウンロードキューに入れ、次にキューの先頭から URL を取得して、対応する Web ページをダウンロードします。Web ページのコンテンツを取得して保存した後、Web ページ内のリンク情報を解析することでいくつかの新しい URL を取得でき、これらの URL がダウンロードキューに追加されます。次に、URL を取得し、対応する Web ページをダウンロードして解析します。これは、ネットワーク全体が横断されるか、特定の条件が満たされるまで繰り返され、その後停止します。

Web クローラーの基本的なワークフローは次のとおりです。

1. まず、慎重に選択したシード URL の一部を選択します。

2. これらの URL をクロールする URL キューに入れます。

3. クロール対象 URL のキューからクロール対象 URL を取り出し、DNS を解析してホストの IP を取得し、その URL に対応する Web ページをダウンロードし、ダウンロードした Web ページライブラリに保存します。さらに、これらの URL をクロールされた URL キューに入れます。

4. クロールされた URL キュー内の URL を分析し、その中の他の URL を分析して、その URL をクロール対象の URL のキューに入れて、次のサイクルに入ります。

2.3 クロール戦略

クローラーシステムでは、クロールされる URL のキューは重要な部分です。クロールされる URL キュー内の URL が配置される順序も非常に重要な問題です。これは、どのページを最初にクロールし、どのページを後でクロールするかが関係するためです。これらの URL の順序を決定する方法は、クロール戦略と呼ばれます。以下では、いくつかの一般的なクロール戦略に焦点を当てます。

2.3.1 深さ優先トラバーサル戦略

深さ優先トラバーサル戦略とは、Web クローラーが開始ページから開始してリンクごとに追跡し、この行を処理した後、次の開始ページに移動してリンクをたどり続けることを意味します。例として次の写真を見てみましょう。

通過したパス: AFG EHI BCD

2.3.2 幅優先のトラバーサル戦略

幅優先トラバーサル戦略の基本的な考え方は、新しくダウンロードされた Web ページで見つかったリンクを、クロールされる URL のキューの最後に直接挿入することです。つまり、Web クローラーは、最初に開始 Web ページにリンクされているすべての Web ページをクロールし、次にリンクされた Web ページの 1 つを選択し、この Web ページにリンクされているすべての Web ページを引き続きクロールします。上の写真を例として見てみましょう。

トラバースパス: ABCDEF GHI

2.3.3 バックリンク数戦略

バックリンクの数とは、他の Web ページによってポイントされている Web ページへのリンクの数を指します。バックリンクの数は、Web ページのコンテンツが他の人によってどの程度推奨されているかを示します。したがって、多くの場合、検索エンジンのクロールシステムはこの指標を使用して Web ページの重要性を評価し、それによってさまざまな Web ページがクロールされる順序を決定します。

実際のネットワーク環境では、広告リンクや不正リンクが存在するため、バックリンクの数が他のリンクの重要性と完全に同じになることはありません。したがって、検索エンジンは信頼できるバックリンク数を考慮する傾向があります。

2.3.4 部分的なページランク戦略

Partial PageRank アルゴリズムは、PageRank アルゴリズムの考え方を利用しています。ダウンロードされた Web ページについて、クロールされる URL キュー内の URL とともに Web ページセットが形成され、各ページの PageRank 値が計算されます。計算後、URL キュー内のクロール対象の URL が PageRank 値の大きさに従って並べられ、その順序でページがクロールされます。

ページがクロールされるたびに PageRank 値が再計算される場合、妥協策として、K ページがクロールされるたびに PageRank 値を再計算します。しかし、この状況には別の問題があります。ダウンロードされたページで分析されたリンク、つまり、前述した未知の Web ページについては、当面は PageRank 値がありません。この問題を解決するために、一時的な PageRank 値がこれらのページに与えられます。この Web ページのすべての受信リンクによって渡された PageRank 値が要約され、不明なページの PageRank 値が形成され、並べ替え。

2.3.5 OPIC 戦略戦略

このアルゴリズムは実際にはページの重要度もスコア付けします。アルゴリズムが開始される前に、すべてのページに同じ初期キャッシュが与えられます。あるページＰがダウンロードされると、Ｐから解析された全てのリンクにＰのキャッシュが分配され、Ｐのキャッシュがクリアされる。クロールされる URL キュー内のすべてのページは、キャッシュ番号によって並べ替えられます。

2.3.6 ビッグサイト重点戦略

クロールされる URL キュー内のすべての Web ページは、それらが属する Web サイトに従って分類されます。ダウンロードするページ数が多い Web サイトが最初にダウンロードされます。この戦略は大駅優先戦略とも呼ばれます。

3. 爬虫類の分類

Web クローラーを開発するには、Nutch、Crawler4j、WebMagic、scrapy、WebCollector などを選択する必要がありますか? 上記のクローラーは基本的に次の 3 つのカテゴリに分類できます。

(1) 分散型クローラ：Nutch

（2）JAVA爬虫：Crawler4j、WebMagic、WebCollector

(3) Non-JAVA クローラー：scrapy (Python 言語をベースに開発)

3.1 分散クローラー

クローラーは分散テクノロジーを使用して、主に次の 2 つの問題を解決します。

1) 大規模な URL 管理

2)インターネット速度

現在、より人気のある分散クローラーは、Apache の Nutch です。しかし、ほとんどのユーザーにとって、Nutch は次の理由から、これらのタイプのクローラーの中で最悪の選択肢です。

1) Nutch は検索エンジン向けに設計されたクローラーであり、ほとんどのユーザーは正確なデータクローリング (洗練された抽出) を実行できるクローラーを必要としています。Nutch が実行するプロセスの 3 分の 2 は検索エンジン用に設計されています。精液採取にはあまり意味がありません。言い換えれば、データ抽出に Nutch を使用すると、不必要な計算に多くの時間が無駄になります。また、Nutchを二次開発して微細な抽出業務に適したものにしようとすると、基本的にNutchの枠組みを破壊し、認識を超えてNutchを改変することになるので、Nutchを改変できる能力があるのであれば、自分で書き換えたほうが良いでしょう。クローラーフレームワーク。

2) Nutch は実行に Hadoop に依存しており、Hadoop 自体に多くの時間がかかります。クラスターマシンの数が少ない場合、クロール速度は単一マシンクローラーほど速くなりません。

3) Nutch にはプラグイン機構がありますが、それがハイライトとして宣伝されています。優れた抽出機能を提供するオープンソースの Nutch プラグインをいくつか見ることができます。しかし、Nutch プラグインを開発したことがある人なら誰でも、Nutch のプラグインシステムがいかにひどいものであるかを知っています。リフレクションメカニズムを使用してプラグインをロードしたり呼び出したりすると、プログラムの作成とデバッグが非常に困難になり、ましてや複雑で洗練された抽出システムを開発することは非常に困難になります。さらに、Nutch は、微細な抽出に対応するプラグイン取り付けポイントを提供していません。Nutch のプラグインには 5 つまたは 6 つのマウントポイントしかなく、これら 5 つまたは 6 つのマウントポイントは検索エンジンサービス用であり、詳細な抽出のためのマウントポイントは提供しません。Nutch の洗練された抽出プラグインのほとんどは、「ページパーサー」(パーサー) マウントポイントにマウントされています。このマウントポイントは実際にリンクを解析し (後続のクローリング用の URL を提供する)、一部の検索エンジンに抽出が容易な Web を提供するために使用されます。ページ情報（Webページのメタ情報、テキスト）。

4) クローラーの二次開発に Nutch を使用するクローラーの作成とデバッグに必要な時間は、多くの場合、単一マシンのクローラーの 10 倍以上です。Nutch のソースコードを理解するための学習コストは非常に高く、ましてやチームの全員に Nutch のソースコードを理解させる必要はありません。デバッグを行っていると、プログラム以外にもさまざまな問題（Hadoopの問題、hbaseの問題）が発生します。

5) Nutch2 にはデータを avro ファイル、hbase、mysql などに永続化できる gora があると多くの人が言います。ここで言う永続データとは、avro、hbase、mysql に URL 情報（URL 管理に必要なデータ）を格納することを指します。抽出したいのは構造化データではありません。実際、ほとんどの人にとって、URL 情報がどこに存在するかは重要ではありません。

6) Nutch2 のバージョンは現在開発に適していません。Nutch の公式安定バージョンは Nutch2.2.1 ですが、このバージョンは gora-0.3 にバインドされています。Nutch で hbase を使用したい場合 (ほとんどの人は hbase を使用するためだけに Nutch2 を使用します)、hbase はバージョン 0.90 程度しか使用できないため、Hadoop のバージョンを Hadoop 0.2 程度に下げる必要があります。また、Nutch2 の公式チュートリアルは非常に誤解を招きやすいもので、Nutch2 には Nutch1.x と Nutch2.x の 2 つのチュートリアルがあり、Nutch2.x の公式 Web サイトには hbase 0.94 をサポートすると記載されています。しかし実際には、Nutch2.x とは Nutch2.3 より前と Nutch2.2.1 以降のバージョンを意味しており、このバージョンは公式 SVN で常に更新されています。そしてそれは非常に不安定です（常に変更されています）。

したがって、検索エンジンを使用しない場合は、クローラーとして Nutch を選択しないようにしてください。一部のチームはトレンドに従うことを好み、洗練されたクローラーの開発に Nutch を選択することに固執します。これは実際には Nutch の評判によるものです。もちろん、最終的な結果としてプロジェクトの完了が遅れることがよくあります。

検索エンジンになりたい場合は、Nutch1.x が非常に良い選択です。Nutch1.x を solr または es と組み合わせると、非常に強力な検索エンジンを形成できます。Nutch2 を使用する必要がある場合は、Nutch2.3 がリリースされるまで待つことをお勧めします。現在の Nutch2 は非常に不安定なバージョンです。

分散型クローラプラットフォームのアーキテクチャ図

3.2 JAVA クローラー

Web クローラーにおける JAVA のエコシステムは非常に完全であるため、JAVA クローラーはここでは別のカテゴリに分類されます。関連情報も最も充実しています。ここで議論があるかもしれませんが、私はただカジュアルに話しているだけです。

実際、オープンソースの Web クローラー (フレームワーク) の開発は非常に単純で、難しく複雑な問題 (DOM ツリーの解析と位置決め、文字セットの検出、大規模な URL 重複排除など) は以前の人々によって解決されてきたと言えます。技術的な内容はございません。Nutchも含めて、実はNutchの技術的な難しさはHadoopの開発であり、コード自体は非常にシンプルです。ある意味、Web クローラーは、ローカルマシン上のファイルを走査してファイル内の情報を見つけることに似ています。難しいことはまったくありません。私がオープンソースのクローラーフレームワークを選択した理由は、トラブルを避けるためです。たとえば、クローラー URL 管理やスレッドプールなどのモジュールは誰でも作成できますが、安定させるにはデバッグと修正の期間がかかります。

クローラー機能用。多くの場合、ユーザーがより懸念している問題は次のとおりです。

1) クローラーはマルチスレッドをサポートしていますか? クローラーはプロキシを使用できますか? クローラーは重複データをクロールしますか? クローラーは JS によって生成された情報をクロールできますか?

マルチスレッドをサポートせず、プロキシをサポートせず、重複 URL をフィルタリングできない場合は、オープンソースクローラーとは呼ばれず、http リクエストの周期的実行と呼ばれます。

js によって生成された情報をクロールできるかどうかは、クローラー自体とはあまり関係がありません。クローラーは主に、Web サイトを走査してページをダウンロードする役割を果たします。js のクローリングによって生成される情報は、Web ページ情報抽出モジュールに関連しており、多くの場合、ブラウザ (htmlunit、selenium) をシミュレートすることによって完了する必要があります。これらのシミュレートされたブラウザーは、ページの処理に多くの時間がかかります。したがって、1 つの戦略は、これらのクローラを使用して Web サイトを横断し、解析する必要があるページに遭遇したら、Web ページの関連情報をシミュレートされたブラウザに送信して、JS で生成された情報の抽出を完了することです。

2) クローラーは ajax 情報をクロールできますか?

Web ページには非同期で読み込まれたデータがいくつかあります。このデータをクロールするには 2 つの方法があります: シミュレートされたブラウザーを使用する (質問 1 で説明)、または ajax http リクエストを分析し、ajax リクエスト URL を自分で生成して、返されたデータを取得する。Ajax リクエストを自分で生成する場合、オープンソースクローラーを使用する意味は何でしょうか? 実際には、オープンソースクローラーのスレッドプールと URL 管理機能 (ブレークポイントクロールなど) を使用する必要があります。

必要な ajax リクエスト (リスト) をすでに生成できている場合、これらのクローラーを使用してこれらのリクエストをクロールするにはどうすればよいですか?

クローラーは多くの場合、静的ページまたは動的ページを走査するために幅または深さのトラバーサルモードで設計されています。Ajax 情報のクロールはディープ Web のカテゴリに属しますが、ほとんどのクローラーはそれを直接サポートしていません。しかし、いくつかの方法でそれを行うこともできます。たとえば、WebCollector は幅走査を使用して Web サイトを走査します。クローラーによるクロールの最初のラウンドは、シードコレクション (シード) 内のすべての URL をクロールすることです。簡単に言うと、生成された ajax リクエストがシードとして使用され、クローラーに入れられます。クローラーを使用して、これらのシードに対して深さ 1 の幅走査を実行します (デフォルトは幅走査です)。

3) クローラーは、ログインしたい Web サイトをどのようにクロールしますか?

これらのオープンソースクローラーはすべて、クロール時の Cookie の指定をサポートしており、シミュレートされたログインは主に Cookie に依存しています。Cookie の取得方法については、クローラーの問題ではありません。手動で取得したり、http リクエストでログインをシミュレートしたり、シミュレートされたブラウザで自動的にログインして Cookie を取得したりできます。

4) クローラーはどのようにして Web ページから情報を抽出しますか?

オープンソースクローラーは通常、Web ページ抽出ツールを統合します。主に CSS SELECTOR と XPATH の 2 つの仕様をサポートします。どちらが優れているかについては、ここではコメントしません。

5) クローラーはどのようにして Web ページの情報を保存しますか?

一部のクローラーには、永続化を担当するモジュールが付属しています。たとえば、Webmagic にはパイプラインと呼ばれるモジュールがあります。簡単な構成により、クローラによって抽出された情報をファイルやデータベースなどに永続化できます。データ永続化モジュールをユーザーに直接提供しないクローラーもあります。Crawler4j や WebCollector など。ユーザーが Web ページ処理モジュールにデータベースに送信する操作を追加できるようにします。パイプラインのようなモジュールを使うのが良いかどうかは、データベースの操作にORMを使うのが良いのと同じで、ビジネスによって異なります。

6) クローラーが Web サイトによってブロックされている場合はどうすればよいですか?

クローラーが Web サイトによってブロックされている場合、通常は複数のプロキシ (ランダムプロキシ) を使用することで解決できます。ただし、これらのオープンソースクローラーは通常、ランダムなエージェントの切り替えを直接サポートしません。したがって、ユーザーは多くの場合、取得したエージェントをグローバル配列に配置し、(配列から) エージェントをランダムに取得するコードを記述する必要があります。

7) Web ページはクローラーを呼び出すことができますか?

クローラーはWebのサーバー側で呼ばれるもので、普段と同じように利用することができます。

8) クローラーの速度はどうですか?

スタンドアロンのオープンソースクローラーの速度は、基本的にローカルネットワーク速度の制限に達する可能性があります。クローラーの速度が遅いのは、多くの場合、ユーザーが開いたスレッドが少ない、ネットワーク速度が遅い、またはデータが永続化されている場合のデータベースとの対話が遅いことが原因です。これらは多くの場合、ユーザーのマシンと二次開発コードによって決まります。これらのオープンソースクローラーの速度は非常に優れています。

9) コードは正しく記述されていますが、データをクロールできない場合は、クローラーに問題がありますか? クローラーを変更することで解決できますか?

コードが正しく記述されていてもデータをクロールできない場合、他のクローラーもそのデータをクロールできなくなります。この場合、Web サイトによってブロックされているか、クロールされたデータが JavaScript によって生成されたかのいずれかです。データのクロールに失敗した場合は、クローラーを変更しても解決できません。

10) Web サイトがクロールされたかどうかを判断できるのはどのクローラーですか?また、トピックに基づいてクロールできるのはどのクローラーですか?

クローラーは Web サイトがクロールされたかどうかを判断することはできず、可能な限りカバーすることしかできません。

トピックに基づくクロールに関しては、クローラーはコンテンツをクロールした後でのみ、それがどのトピックであるかを認識します。そのため、通常は完全にダウンしてからコンテンツをフィルタリングします。クロールの範囲が広すぎると思われる場合は、URL の正規化やその他の方法を制限することで範囲を狭めることができます。

11) クローラーの設計パターンとアーキテクチャはどれが優れていますか?

デザインパターンはデタラメです。ソフトウェアの設計パターンが優れていると言えるのは、ソフトウェアが開発され、いくつかの設計パターンがまとめられているからです。デザインパターンはソフトウェア開発において指導的な役割を持ちません。デザインパターンを使用してクローラを設計すると、クローラの設計がさらに肥大化するだけです。

アーキテクチャに関して言えば、オープンソースクローラーは現在、クロールスレッドプールやタスクキューなど、誰もが制御できる詳細なデータ構造の設計に重点を置いています。クローラービジネスは単純すぎるため、構造について語ることはできません。

したがって、JAVA オープンソースクローラーについては、使いやすいものを見つければよいと思います。ビジネスが複雑な場合、どのクローラを使用しても、ニーズを満たすために複雑な二次開発が必要になります。

3.3 非JAVAクローラ

非JAVA言語で書かれたクローラの中にも優れたクローラが数多くあります。ここでカテゴリとして抽出する目的は、クローラー自体の品質を議論することではなく、larbin やscrapy などのクローラーが開発コストに与える影響を議論することです。

まず Python クローラーについて話しましょう. Python は 30 行のコードを使用して、50 行の JAVA コードのタスクを完了できます。Python でコードを書くのは確かに速いですが、コードのデバッグ段階では、Python コードのデバッグには、コーディング段階で節約された時間よりもはるかに長い時間がかかることがよくあります。Python で開発する場合、プログラムの正確性と安定性を確保するには、より多くのテストモジュールを作成する必要があります。もちろん、クローリングの規模が大きくなく、クローリング業務が複雑でない場合には、簡単にクローリング作業を完了できるscrapyのようなクローラを利用するのも良いでしょう。

上の図は Scrapy のアーキテクチャ図です緑の線はデータの流れの方向です最初の URL から始まり、スケジューラはダウンローダーに渡してダウンロードしますダウンロード後、スパイダーに渡して分析します保存する必要があるデータは、アイテムパイプラインに送信されます。つまり、データの後処理が行われます。さらに、データフローチャネルには、必要な処理を実行するためにさまざまなミドルウェアをインストールできます。したがって、クローラを開発するときは、最初にさまざまなモジュールを計画することが最善です。私のアプローチは、ダウンロードモジュール、クローリングモジュール、スケジュールモジュール、データストレージモジュールを個別に計画することです。

C++ クローラーの場合、学習コストは比較的高くなります。また、学習コストは 1 人だけでは計算できず、チーム開発や引き継ぎが必要なソフトウェアの場合、多くの人の学習コストとなります。ソフトウェアのデバッグもそれほど簡単ではありません。

Ruby や PHP クローラーもいくつかありますが、ここではあまりコメントしません。確かに、ruby または php を使用すると非常に便利な非常に小さなデータ収集タスクがいくつかあります。しかし、これらの言語でオープンソースクローラーを選択する場合、一方では関連するエコシステムを調査する必要があり、他方では、これらのオープンソースクローラーには見つけられないバグがある可能性があります (使用している人はほとんどいません)。そして情報も少ない）

4. 耐クローラ技術

検索エンジンの普及により、Web クローラーは非常に人気のあるネットワークテクノロジになりました。検索を専門とする Google、Yahoo、Microsoft、Baidu に加えて、ほとんどすべての大規模なポータル Web サイトには独自の検索エンジンがあり、コンテンツ主導の Web サイトでは、Web クローラーによる訪問は避けられません。

一部のスマートな検索エンジンクローラーは、適切なクロール頻度を備え、Web サイトリソースの消費量が少なくなりますが、多くの悪質な Web クローラーは、Web クロール機能が貧弱で、繰り返しクロールするために数十、数百の同時リクエストを行うことがよくあります。特に、クローラー作成の経験のないプログラマーによって作成されたクローラーは非常に破壊的であり、Web サイトへのアクセスに大きな負荷を与え、Web サイトへのアクセスが遅くなったり、アクセス不能になったりすることがあります。

一般に、Web サイトは、ユーザーが要求するヘッダー、ユーザーの行動、Web サイトのディレクトリ、データの読み込み方法という 3 つの側面からクローラー対策されています。最初の 2 つは比較的簡単に遭遇することができ、ほとんどの Web サイトはこれらの観点からクローラーと戦います。3 番目のタイプは、ajax を使用する一部の Web サイトで使用されており、クロールの難易度が高くなります。

4.1 ヘッダーを介したアンチクローラー

ユーザーから要求されたヘッダーのクロール防止は、最も一般的なクロール防止戦略です。多くの Web サイトはヘッダーのユーザーエージェントを検出し、一部の Web サイトはリファラーを検出します (一部のリソース Web サイトのリーチ防止はリファラーを検出することです)。このタイプのクローラー対策メカニズムが発生した場合は、ヘッダーをクローラーに直接追加してブラウザーのユーザーエージェントをクローラーのヘッダーにコピーするか、リファラー値をターゲット Web サイトのドメイン名に変更します。ヘッダーを検出するアンチクローラーの場合、クローラーにヘッダーを変更または追加することで簡単にバイパスできます。

[コメント: 簡単に無視されることがよくあります。リクエストのパケットキャプチャを分析することでリファラーを特定し、プログラム内の模擬アクセスリクエストヘッダーに追加します。]

4.2 ユーザーの行動に基づくアンチクローラー

また、同じ IP が短期間に同じページに複数回アクセスしたり、同じアカウントが短期間に同じ操作を複数回実行したりするなど、ユーザーの行動を検出する Web サイトもあります。

[コメント: この種のアンチクライミングには、それに対処するのに十分な IP が必要です]

ほとんどの Web サイトは前者の状況にありますが、この状況については IP プロキシを使用することで解決できます。特別なクローラーを作成して、インターネット上で公開されているプロキシ IP をクロールし、検出後にそれらをすべて保存できます。このようなプロキシ IP クローラーはよく使用されるため、自分で用意するのが最善です。多数のプロキシ IP を取得した後は、数リクエストごとに 1 つの IP を変更できます。これはリクエストまたは urllib2 で簡単に実行できるため、最初のアンチクローラーを簡単にバイパスできます。

[コメント: 動的ダイヤルも解決策です]

2 番目のケースでは、各リクエストの後、次のリクエストを行う前にランダムに数秒待つことができます。論理的な抜け穴のある一部の Web サイトでは、リクエストを数回行い、ログアウトし、再度ログインし、リクエストを続けることで、同じアカウントが短期間に同じリクエストを複数回行うことができないという制限を回避できます。

[コメント: アカウントのクロール防止制限に対処するのは一般的に困難です。数秒間のランダムなリクエストはブロックされることがよくあります。複数のアカウントをお持ちの場合は、アカウントを切り替えると効果が向上します。]

4.3 動的ページのクロール防止

上記の状況のほとんどは静的ページで発生し、一部の Web サイトでは、クロールする必要のあるデータが ajax リクエストを通じて取得されるか、Java を通じて生成されます。まず、Firebug または HttpFox を使用してネットワークリクエストを分析します。ajax リクエストを見つけて、特定のパラメータとレスポンスの特定の意味を分析できれば、上記の方法を使用して、リクエストまたは urllib2 を使用して ajax リクエストを直接シミュレートし、レスポンスの json を分析して必要なデータを取得できます。

[コメント：GoogleやIEのネットワークリクエスト解析も非常に役立つと感じました]

Ajax リクエストを直接シミュレートしてデータを取得できるのは素晴らしいことですが、一部の Web サイトでは、Ajax リクエストのすべてのパラメータが暗号化されています。必要なデータのリクエストを作成する方法がありません。最近巡回した Web サイトはこんな感じで、ajax パラメータの暗号化に加えて、いくつかの基本的な関数もカプセル化しており、それらはすべて独自のインターフェイスを呼び出しており、インターフェイスのパラメータはすべて暗号化されています。このような Web サイトに遭遇した場合、上記の方法は使用できず、selenium + phantomJS フレームワークを使用し、ブラウザーのカーネルを呼び出し、phantomJS を使用して js を実行し、人間の操作をシミュレートし、ページ内で js スクリプトをトリガーします。フォームへの入力からボタンのクリック、ページのスクロールに至るまで、特定のリクエストとレスポンスのプロセスに関係なく、ユーザーがページを閲覧してデータを取得するプロセスを完全にシミュレートできます。

[コメント: phantomJS をサポート]

このフレームワークを使用すると、ほとんどのアンチクローラーを回避できます。これは、データを取得するためにブラウザーのふりをしているわけではなく (上記のヘッダーの追加は、ある程度ブラウザーのふりをしています)、ブラウザ自体であるためです。 phantomJS はインターフェイスのないブラウザですが、ブラウザは人間によって制御されません。selenium+phantomJS を使用すると、タッチ (12306) やスライド検証コードの識別、ページフォームのブルートフォースクラッキングなど、多くのことを行うことができます。後述する自動侵入でも才能を発揮します。

[クローラーを学びたい人のために、Python 学習教材をたくさんまとめて CSDN 公式にアップロードしました。必要な友達は以下の QR コードをスキャンして入手してください]