¿Cómo se diferencian las arañas web de la araña de Wget?

Question

La siguiente frase me llamó la atención en el manual del 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. 

encuentro las siguientes líneas de código relevantes para la opción de araña en 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) 

Me gustaría ver las diferencias en el código, no en abstracto. Me encantan los ejemplos de código.

¿Cómo se diferencian las arañas web de la araña de Wget en el código?

Answer 1

Una araña real es mucho trabajo

Escribir una araña para toda la WWW es una tarea --- hay que tener cuidado acerca de muchos "pequeños detalles", tales como:

• Cada computadora spider debe recibir datos de unos pocos miles de servidores en paralelo con el fin de hacer un uso eficiente del ancho de banda de la conexión. (socket asíncrono i/o).
• necesita varias computadoras que Spider en paralelo con el fin de cubrir la gran cantidad de información en la WWW (agrupación; particionamiento de la obra)
• Necesita ser educado con los sitios web spidered:
  • Respeto los archivos robots.txt.
  • No recupere demasiada información demasiado rápido: esto sobrecarga los servidores.
  • No recuperar los archivos que usted realmente no necesita (por ejemplo, imágenes de disco ISO; paquetes TGZ para descargar el software ...).
• Tiene que lidiar con cookies/ids de sesión: muchos sitios adjuntan identificaciones de sesión únicas a las URL para identificar las sesiones de los clientes. Cada vez que llega al sitio, obtiene una nueva identificación de sesión y un nuevo mundo virtual de páginas (con el mismo contenido). Debido a estos problemas, los primeros motores de búsqueda ignoraron el contenido dinámico. Los motores de búsqueda modernos han aprendido cuáles son los problemas y cómo lidiar con ellos.
• Usted tiene que detectar e ignorar los datos problemático: las conexiones que proporcionan una cantidad aparentemente infinita de datos o conexiones que son demasiado lento para terminar.
• Además de seguir los enlaces, es posible que desee analizar sitemaps para obtener URL de las páginas.
• Es posible que desee evaluar qué información es importante para usted y que los cambios se actualicen frecuentemente con más frecuencia que otras páginas. Nota: Una araña para toda la WWW recibe una gran cantidad de datos, usted paga por ese ancho de banda. Es posible que desee usar las solicitudes HTTP HEAD para adivinar si una página ha cambiado o no.
• Además de recibir, desea procesar la información y almacenarla. Google crea índices que enumeran para cada palabra las páginas que lo contienen. Es posible que necesite computadoras de almacenamiento separadas y una infraestructura para conectarlas. Las bases de datos relacionales tradicionales no se ajustan al volumen de datos y los requisitos de rendimiento para almacenar/indexar toda la WWW.

Se trata de una gran cantidad de trabajo. Pero si su objetivo es más modesto que leer toda la WWW, puede omitir algunas de las partes. Si solo desea descargar una copia de un wiki, etc., acceda a las especificaciones de wget.

Nota: Si no crees que sea demasiado trabajo, tal vez quieras leer sobre cómo Google reinventó la mayoría de las ruedas de cálculo (sobre el núcleo básico de Linux) para construir buenos spiders. Incluso si cortas muchas esquinas, es mucho trabajo.

permítanme añadir unas cuantas observaciones técnicas en tres puntos

paralelo conexiones/socket asincrónico de comunicación

Se puede ejecutar varios programas de araña en procesos paralelos o hilos. Pero necesita alrededor de 5000-10000 conexiones en paralelo para hacer un buen uso de su conexión de red. Y esta cantidad de procesos/hilos paralelos produce demasiada sobrecarga.

Una mejor solución es la entrada/salida asíncrona: procesa aproximadamente 1000 conexiones paralelas en una sola secuencia abriendo las tomas en modo no-bloqueo y usa epoll o selecciona para procesar solo aquellas conexiones que han recibido datos. Desde Linux kernel 2.4, Linux tiene un excelente soporte para la escalabilidad (también recomiendo que estudies los archivos mapeados en memoria) continuamente mejorados en versiones posteriores.

Nota: El uso de E/S asíncronas ayuda mucho más que con un "lenguaje rápido": es mejor escribir un proceso impulsado por epoll para 1000 conexiones escritas en Perl que ejecutar 1000 procesos escritos en C. Si lo hace bien, puedes saturar una conexión de 100Mb con procesos escritos en perl.

A partir de la respuesta original: La desventaja de este enfoque es que va a tener que implementar la especificación HTTP a sí mismo en una forma asíncrona (no soy consciente de una biblioteca reutilizable que hace esto). Es mucho más fácil hacer esto con el protocolo HTTP/1.0 más simple que el protocolo HTTP/1.1 moderno. Probablemente no se beneficie de las ventajas de HTTP/1.1 para los navegadores normales de todos modos, por lo que este puede ser un buen lugar para ahorrar algunos costos de desarrollo.

Editar cinco años después: Hoy en día, hay una gran cantidad de tecnología de código abierto/libre disponible para ayudarlo con este trabajo. Personalmente me gusta el http implementation asíncrono de node.js --- le ahorra todo el trabajo mencionado en el párrafo original anterior. Por supuesto, hoy en día también hay muchos módulos disponibles para los otros componentes que necesita en su araña. Tenga en cuenta, sin embargo, que la calidad de los módulos de terceros puede variar considerablemente. Debes verificar lo que uses. [Información de antigüedad:] Recientemente, escribí una araña usando node.js y encontré la fiabilidad de los módulos de npm para el procesamiento de HTML para la extracción de enlaces y datos insuficientes. Para este trabajo, "subcontraté" este proceso a un proceso escrito en otro lenguaje de programación. Pero las cosas están cambiando rápidamente y en el momento de leer este comentario, este problema puede ya una cosa del pasado ...

Dividir el trabajo a lo largo de varios servidores

Un equipo no puede seguir el ritmo de arañando toda la WWW. Debe distribuir su trabajo en varios servidores e intercambiar información entre ellos. Sugiero asignar ciertos "rangos de nombres de dominio" a cada servidor: mantener una base de datos central de nombres de dominio con una referencia a una computadora spider.

Extraiga las URL de las páginas web recibidas en lotes: ordénelas de acuerdo con sus nombres de dominio; eliminar duplicados y enviarlos a la computadora araña responsable. En esa computadora, mantenga un índice de las URL que ya se han obtenido y obtenga las URL restantes.

Si mantiene una cola de URL esperando a ser captadas en cada computadora spider, no tendrá cuellos de botella de rendimiento. Pero es una gran cantidad de programación para implementar esto.

ver los estándares de

he mencionado varias normas (HTTP/1.x, Robots.txt, galletas). Tómese su tiempo para leerlos e implementarlos. Si solo sigue ejemplos de sitios que conoce, cometerá errores (olvide las partes del estándar que no son relevantes para sus muestras) y causará problemas a los sitios que usan estas funciones adicionales.

Es un dolor leer el documento estándar HTTP/1.1. Pero todos los pequeños detalles se agregaron porque alguien realmente necesita ese pequeño detalle y ahora lo usa.

Answer 2

No estoy seguro exactamente a qué se refería el autor original del comentario, pero puedo adivinar que wget es lento como una araña, ya que parece usar solo un único hilo de ejecución (al menos por lo que tiene mostrado).

Las arañas "reales" como heritrix utilizan un montón de paralelismos y trucos para optimizar su velocidad de rastreo, a la vez que son agradables al sitio web que están rastreando. Por lo general, esto significa limitar las visitas a un sitio a una velocidad de 1 por segundo (más o menos) y rastrear varios sitios web al mismo tiempo.

De nuevo, esto es solo una suposición basada en lo que sé de las arañas en general, y lo que publicaste aquí.

Answer 3

Desafortunadamente, muchas de las arañas web 'reales' más conocidas son de código cerrado y, de hecho, binarias cerradas. Sin embargo, hay una serie de técnicas básicas que wget falta:

• Paralelismo; nunca podrá mantenerse al día con toda la Web sin recuperar varias páginas a la vez
• Priorización; algunas páginas son más importantes para araña que otras
• Limitación de la velocidad; se te prohibirá rápidamente si sigues bajando páginas lo más rápido que puedas
• Guardando en algo que no sea un sistema de archivos local; la Web es lo suficientemente grande como para que no se ajuste a un único árbol de directorios
• Repetición de revisiones periódicas de las páginas sin reiniciar todo el proceso; en la práctica, con una araña real, querrá volver a consultar las páginas 'importantes' para las actualizaciones con frecuencia, mientras que las páginas menos interesantes pueden durar meses.

También hay varias otras entradas que se pueden utilizar como mapas de sitio y similares. El punto es que wget no está diseñado para arañar toda la web, y no es algo que se pueda capturar en una pequeña muestra de código, ya que es un problema de toda la técnica en general, en lugar de una sola subrutina pequeña que está mal para la tarea.

Answer 4

No voy a entrar en detalles sobre cómo arañar Internet, creo que el comentario de wget está relacionado con arañar un sitio web que todavía es un desafío serio.

• Como una araña que tiene que averiguar cuándo parar, no entrar en recursivo se arrastra sólo porque la URL cambia como fecha = 1/1/1900 al 01/02/1900 y así
• reto aún mayor para ordenar la reescritura de URL (no tengo ni idea de qué modo Google o cualquier otro maneja esto). Es un gran desafío arrastrarse lo suficiente, pero no demasiado. ¿Y cómo se puede reconocer automáticamente la reescritura de URL con algunos parámetros aleatorios y cambios aleatorios en el contenido?
• Necesitas analizar Flash/Javascript, al menos hasta cierto nivel
• Es necesario tener en cuenta algunos problemas HTTP locas como base de etiqueta. Incluso analizar el HTML no es fácil, ya que la mayoría de los sitios web no son XHTML y los navegadores son muy flexibles en la sintaxis.

No sé cuánto de estos implementado o considerado en wget, pero es posible que desee echar un vistazo a httrack para comprender los desafíos de esta tarea.

Me encantaría darle algunos ejemplos de código pero estas son grandes tareas y una araña decente será de aproximadamente 5000 loc sin bibliotecas de terceros.

+ Algunos de ellos ya se ha explicado por @ yaakov-eructo así que no voy a escribir de nuevo