Чем веб-пауки отличаются от паука Wget?

следующее предложение попалось мне на глаза в руководстве Wget

wget --spider --force-html -i bookmarks.html

This feature needs much more work for Wget to get close to the functionality of real web spiders.

Я нахожу следующие строки кода, относящиеся к опции spider в wget.

src/ftp.c
780:      /* If we're in spider mode, don't really retrieve anything.  The
784:      if (opt.spider)
889:  if (!(cmd & (DO_LIST | DO_RETR)) || (opt.spider && !(cmd & DO_LIST)))
1227:      if (!opt.spider)
1239:      if (!opt.spider)
1268:      else if (!opt.spider)
1827:          if (opt.htmlify && !opt.spider)

src/http.c
64:#include "spider.h"
2405:  /* Skip preliminary HEAD request if we're not in spider mode AND
2407:  if (!opt.spider
2428:      if (opt.spider && !got_head)
2456:      /* Default document type is empty.  However, if spider mode is
2570:           * spider mode.  */
2571:          else if (opt.spider)
2661:              if (opt.spider)

src/res.c
543:  int saved_sp_val = opt.spider;
548:  opt.spider       = false;
551:  opt.spider       = saved_sp_val;  

src/spider.c
1:/* Keep track of visited URLs in spider mode.
37:#include "spider.h"
49:spider_cleanup (void)

src/spider.h
1:/* Declarations for spider.c

src/recur.c
52:#include "spider.h"
279:      if (opt.spider)
366:              || opt.spider /* opt.recursive is implicitely true */
370:             (otherwise unneeded because of --spider or rejected by -R) 
375:                   (opt.spider ? "--spider" : 
378:                     (opt.delete_after || opt.spider
440:      if (opt.spider) 

src/options.h
62:  bool spider;           /* Is Wget in spider mode? */

src/init.c
238:  { "spider",           &opt.spider,            cmd_boolean },

src/main.c
56:#include "spider.h"
238:    { "spider", 0, OPT_BOOLEAN, "spider", -1 },
435:       --spider                  don't download anything.n"),
1045:  if (opt.recursive && opt.spider)

Я хотел бы видеть различия в коде, а не абстрактно. Я люблю примеры использования.

чем веб-пауки отличаются от паука Wget в коде?

7
open-source web-crawler wget

4 ответов

настоящий паук-это много работы

написание паука для всего WWW-довольно сложная задача - - - вы должны заботиться о многих "маленьких деталях", таких как:

  • каждый компьютер spider должен получать данные от нескольких тысяч серверов параллельно, чтобы эффективно использовать пропускную способность соединения. (асинхронный сокет ввода-вывода).
  • вам нужно несколько компьютеров, которые Спайдер параллельно для того, чтобы покрыть огромное количество информации на WWW (кластеризация; разбиение работы)
  • вы должны быть вежливы с паукообразными веб-сайтов:
    • уважать роботов.txt-файл.
    • не извлекайте много информации слишком быстро: это перегружает серверы.
    • не извлекайте файлы, которые вам действительно не нужны (например, образы дисков iso; пакеты tgz для загрузки программного обеспечения...).
  • вы должны иметь дело с cookies / session ids: многие сайты прикрепляют уникальные идентификаторы сеанса к URL-адресам для идентификации сеансов клиента. Каждый раз, когда вы приходите на сайт, вы получаете новый идентификатор сеанса и новый виртуальный мир страниц (с тем же контентом). Из-за таких проблем ранние поисковые системы игнорировали динамический контент. Современные поисковые системы узнали, в чем заключаются проблемы и как с ними бороться.
  • вы должны обнаружить и игнорировать хлопотные данные: соединения, которые обеспечивают, казалось бы, бесконечное количество данных или соединений, которые слишком медленно, чтобы закончить.
  • кроме по ссылкам, можно парсить sitemaps чтобы получить URL-адреса страниц.
  • вы можете оценить, какая информация важна для вас, и изменения часто будут обновляться чаще, чем другие страницы. Примечание: паук для всего WWW получает много данных - - - вы платите за эту пропускную способность. Вы можете использовать запросы HTTP HEAD, чтобы угадать, изменилась страница или нет.
  • помимо получения, вы хотите обработать информацию и сохранить ее. Google создает индексы, которые перечисляют для каждого слова страницы, содержащие его. Для их подключения могут потребоваться отдельные компьютеры хранения и инфраструктура. Традиционные реляционные базы данных не соответствуют требованиям к объему данных и производительности хранения/индексирования всего WWW.

Это много работы. Но если ваша цель более скромна, чем чтение всего WWW, вы можете пропустить некоторые части. Если вы просто хотите загрузить копию wiki и т. д. ты начинаешь ... спецификации wget.

Примечание: Если вы не верите, что это так много работы, вы можете прочитать о том, как Google заново изобрел большинство вычислительных колес (поверх основного ядра Linux) для создания хороших пауков. Даже если вы срезали много углов, это большая работа.

позвольте мне добавить еще несколько технических замечаний по трем точкам

параллельные соединения / асинхронная связь сокетов

вы можете запустить несколько программ spider в параллельных процессах или потоках. Но вам нужно около 5000-10000 параллельных соединений, чтобы хорошо использовать ваше сетевое соединение. И это количество параллельных процессов / потоков создает слишком много накладных расходов.

лучшим решением является асинхронный ввод / вывод: обработайте около 1000 параллельных соединений в одном потоке, открыв сокеты в неблокирующем режиме и используйте epoll или выберите для обработки только те соединения, которые получили данные. Начиная с ядра Linux 2.4, Linux имеет отличную поддержку масштабируемости (я также рекомендую вам изучать файлы, сопоставленные с памятью), постоянно улучшается в более поздних версиях.

Примечание: использование асинхронного ввода-вывода помогает гораздо больше, чем использование "быстрого языка": лучше написать epoll-управляемый процесс для 1000 соединений, написанных на Perl, чем запускать 1000 процессов, написанных на C. Если вы сделаете это правильно, вы можете насытить соединение 100Mb с процессами, написанными на perl.

из исходного ответа: Недостатком этого подхода является то, что вам придется реализовать спецификацию HTTP самостоятельно в асинхронной форме (я не знаю повторно используемой библиотеки, которая делает это). Это намного проще сделать с помощью более простого протокола HTTP / 1.0, чем современный протокол HTTP/1.1. Вы, вероятно, не выиграли бы от преимуществ HTTP/1.1 для обычных браузеров в любом случае, поэтому это может быть хорошим местом для экономии некоторых затрат на разработку.

редактировать пять лет спустя: Сегодня есть много свободных / открытых исходных технологий, доступных, чтобы помочь вам в этой работе. Мне лично нравится асинхронный реализация http of узел.js --- это экономит вам всю работу, упомянутую в приведенном выше оригинальном абзаце. Конечно, сегодня есть также много модулей, доступных для других компонентов, которые вам нужны в вашем spider. Обратите внимание, однако, что качество сторонних модулей может значительно отличаться. Вы должны проверить все, что вы используете. [информация о старении:] недавно я написал паука, используя node.мы с js обнаружили недостаточную надежность модулей npm для обработки HTML для извлечения ссылок и данных. Для этой работы я "передал" эту обработку процессу, написанному на другом языке программирования. Но все быстро меняется, и к тому времени, когда вы прочтете этот комментарий, эта проблема может уже уйти в прошлое...

разбиение работы на несколько серверов

один компьютер не может идти в ногу с пауком всего WWW. Необходимо распределить работу по нескольким серверам и обмен информацией между ними. Я предлагаю назначить определенные "диапазоны доменных имен" каждому серверу: сохранить центральную базу данных доменных имен со ссылкой на компьютер-паук.

извлекать URL-адреса из полученных веб-страниц пакетами: сортировать их по доменным именам; удалять дубликаты и отправлять их на ответственный компьютер spider. На этом компьютере, держите индекс URL-адресов, которые уже извлекаются и извлекают остальные URL-адреса.

Если вы держите очередь URL-адресов, ожидающих извлечения на каждом компьютере spider, у вас не будет узких мест производительности. Но это довольно много программирования для реализации этого.

читать стандарты

Я упомянул несколько стандартов (HTTP / 1.Икс, роботы.txt, Cookies). Потратьте время, чтобы прочитать их и реализовать. Если вы просто следуете примерам сайтов, которые вы знаете, вы будете делать ошибки (забыли части стандарта, которые не относятся к вашим образцам) и вызвать проблемы для тех сайтов, которые используют эти дополнительные функции.

Это боль, чтобы прочитать стандартный документ HTTP / 1.1. Но все мелкие детали были добавлены к нему, потому что кто-то действительно нуждается в этой маленькой детали и теперь использует ее.

33

Я не уверен, что именно имел в виду первоначальный автор комментария, но я могу догадаться, что wget медленный, как паук, поскольку он, похоже, использует только один поток выполнения (по крайней мере, тем, что вы показали).

"реальные" пауки, такие как heritrix используйте много параллелизма и трюков, чтобы оптимизировать скорость их обхода, в то же время хорошо к веб-сайту они ползают. Это обычно означает ограничение посещений одного сайта со скоростью 1 на во-вторых (или около того), и обход нескольких веб-сайтов одновременно.

опять же, это всего лишь догадка, основанная на том, что я знаю о пауках в целом, и то, что вы разместили здесь.

4

к сожалению, многие из более известных "реальных" веб-пауков являются закрытыми, и действительно закрытыми двоичными. Однако существует ряд основных методов wget отсутствует:

  • параллелизм; вы никогда не сможете идти в ногу со всей сетью, не получая несколько страниц за раз
  • приоритизация; некоторые страницы более важны для spider, чем другие
  • ограничение скорости; вы будете запрещены быстро, если вы продолжаете тянуть вниз страницы, как быстро, как вы можете
  • сохранение в нечто иное, чем локальная файловая система; сеть достаточно велика, чтобы она не поместилась в одном дереве каталогов
  • перепроверка страниц периодически без перезапуска всего процесса; на практике, с реальным пауком вы захотите перепроверить "важные" страницы для обновлений часто, в то время как менее интересные страницы могут идти в течение нескольких месяцев.

также различные другие входные сигналы которые можно использовать как sitemaps и как. Дело в том, что wget не предназначен для паутины всей сети, и это не то, что можно захватить в небольшом примере кода, так как это проблема всей используемой общей техники, а не какой-либо одной небольшой подпрограммы, неправильной для задачи.

2

Я не собираюсь вдаваться в подробности о том, как паук интернет, я думаю, что wget комментарий относительно паука один веб-сайт, который по-прежнему является серьезной проблемой.

  • как паук вам нужно выяснить, когда остановиться, а не идти в рекурсивные обходы только потому, что URL изменился, как date=1/1/1900 до 1/2/1900 и так
  • еще большая проблема, чтобы разобраться переписать URL (я понятия не имею, что так когда-либо, как google или любой другой обрабатывает это). Он довольно большой задача ползти достаточно, но не слишком много. И как можно автоматически распознать переписывание URL с некоторыми случайными параметрами и случайными изменениями в содержимом?
  • вам нужно проанализировать Flash / Javascript, по крайней мере, до некоторого уровня
  • вам нужно рассмотреть некоторые сумасшедшие проблемы HTTP, такие как базовый тег. Даже синтаксический анализ HTML непросто, учитывая, что большинство веб-сайтов не XHTML и браузеры настолько гибки в синтаксисе.

Я не знаю сколько из них реализовано или рассмотрено в wget, но вы можете взглянуть на httrack, чтобы понять проблемы этой задачи.

Я хотел бы дать вам некоторые примеры кода, но это большие задачи и приличный паук будет около 5000 ЛК без сторонних библиотек.

+ некоторые из них уже объяснены @yaakov-belch, поэтому я не собираюсь вводить их снова

1