Come si differenziano gli spider web dallo spider di Wget?

Question

La frase successiva catturato la mia attenzione nel manuale 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. 

trovo le seguenti righe di codice rilevanti per l'opzione di ragno in 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) 

Mi piacerebbe vedere le differenze nel codice, non in modo astratto. Adoro gli esempi di codice.

In che modo differiscono gli spider Web dallo spider di Wget nel codice?

Answer 1

Un vero ragno è un sacco di lavoro

Scrivi ragno per tutto il WWW è piuttosto un compito --- si deve prendere cura di tanti "piccoli dettagli" come:

• Ogni computer spider dovrebbe ricevere dati da qualche migliaio di server in parallelo al fine di sfruttare in modo efficiente la larghezza di banda della connessione. (I/o socket asincrono).
• avete bisogno di diversi computer che Spider in parallelo al fine di coprire la grande quantità di informazioni sul WWW (clustering; Partizione del lavoro)
• Devi essere gentile con i siti web spider:
  • Rispetto i file robots.txt.
  • Non recuperare molte informazioni troppo rapidamente: questo sovraccarico i server.
  • Non recuperare file che non sono realmente necessari (ad esempio immagini del disco iso, pacchetti tgz per il download del software ...).
• È necessario gestire cookie/identificativi di sessione: molti siti associano ID di sessione univoci agli URL per identificare le sessioni client. Ogni volta che arrivi al sito, ottieni un nuovo ID di sessione e un nuovo mondo virtuale di pagine (con lo stesso contenuto). A causa di tali problemi, i primi motori di ricerca ignoravano il contenuto dinamico. I moderni motori di ricerca hanno imparato quali sono i problemi e come affrontarli.
• È necessario rilevare e ignorare i dati problematici: connessioni che forniscono una quantità apparentemente infinita di dati o connessioni che sono troppo lenti per terminare.
• Oltre ai seguenti collegamenti, è possibile che si desideri analizzare sitemaps per ottenere gli URL delle pagine.
• È possibile valutare quali informazioni sono importanti per l'utente e le modifiche devono essere aggiornate più frequentemente rispetto ad altre pagine. Nota: uno spider per l'intero WWW riceve molti dati --- si paga per quella larghezza di banda. Potresti voler utilizzare le richieste HTTP HEAD per indovinare se una pagina è stata modificata o meno.
• Oltre a ricevere, si desidera elaborare le informazioni e memorizzarle. Google crea indici che elencano per ogni parola le pagine che lo contengono. Potrebbe essere necessario disporre di computer di archiviazione separati e un'infrastruttura per collegarli. Le basi di dati relazionali tradizionali non tengono il passo con il volume di dati e i requisiti prestazionali di archiviazione/indicizzazione dell'intero WWW.

Questo è un sacco di lavoro. Ma se il tuo obiettivo è più modesto rispetto alla lettura dell'intero WWW, puoi saltare alcune parti. Se vuoi solo scaricare una copia di un wiki, ecc., Vai alle specifiche di wget.

Nota: se non credi che sia così tanto lavoro, potresti voler leggere come Google ha re-inventato la maggior parte delle ruote informatiche (in cima al kernel di base di Linux) per costruire buoni spider. Anche se tagli un sacco di angoli, è molto lavoro.

Mi permetto di aggiungere un paio di osservazioni tecniche su tre punti

parallela connessioni/presa asincrono comunicazione

È possibile eseguire diversi programmi di ragno in processi paralleli o thread. Ma hai bisogno di circa 5000-10000 connessioni parallele per fare un buon uso della tua connessione di rete. E questa quantità di processi/thread paralleli produce troppo overhead.

Una soluzione migliore è l'input/output asincrono: elaborare circa 1000 connessioni parallele in un singolo thread aprendo gli zoccoli in modalità non bloccante e utilizzare epoll o selezionare per elaborare solo quelle connessioni che hanno ricevuto dati. Dato che il kernel 2.4 di Linux, Linux ha un eccellente supporto per la scalabilità (consiglio anche di studiare i file mappati in memoria) continuamente migliorato nelle versioni successive.

Nota: l'utilizzo di I/O asincrono aiuta molto di più che usare un "linguaggio veloce": è meglio scrivere un processo basato su epoll per 1000 connessioni scritte in Perl piuttosto che eseguire 1000 processi scritti in C. Se lo si fa giusto, puoi saturare una connessione a 100 Mb con i processi scritti in perl.

Dalla risposta originale: Il lato negativo di questo approccio è che si dovrà implementare la specifica HTTP se stessi in una forma asincrono (Non sono a conoscenza di una libreria riutilizzabile che fa questo). È molto più semplice farlo con il protocollo HTTP/1.0 più semplice rispetto al moderno protocollo HTTP/1.1. Probabilmente non trarrai vantaggio dai vantaggi di HTTP/1.1 per i normali browser, quindi questo potrebbe essere un buon posto per risparmiare alcuni costi di sviluppo.

Modifica cinque anni più tardi: Oggi c'è un sacco di tecnologia gratuita/open source disponibile per aiutarvi con questo lavoro. Personalmente mi piace ilasincrono dello node.js asincrono --- ti salva tutto il lavoro menzionato nel precedente paragrafo originale. Certamente, oggi ci sono anche molti moduli prontamente disponibili per gli altri componenti di cui hai bisogno nel tuo spider. Si noti, tuttavia, che la qualità dei moduli di terze parti può variare notevolmente. Devi controllare qualsiasi cosa tu usi. [Aging info:] Recentemente, ho scritto uno spider utilizzando node.js e ho trovato l'affidabilità dei moduli npm per l'elaborazione HTML per il collegamento e l'estrazione dei dati insufficienti. Per questo lavoro, ho "esternalizzato" questa elaborazione a un processo scritto in un altro linguaggio di programmazione. Ma le cose stanno cambiando velocemente e dal momento in cui leggerete questo commento, questo problema può già una cosa del passato ...

Partizione del lavoro su diversi server

Un computer non può tenere il passo con spidering l'intero WWW. Devi distribuire il tuo lavoro su diversi server e scambiare informazioni tra loro. Suggerisco di assegnare determinate "gamme di nomi di dominio" a ciascun server: mantenere un database centrale di nomi di dominio con un riferimento a un computer ragno.

Estrarre gli URL dalle pagine Web ricevute in lotti: ordinarli in base al loro nome di dominio; rimuovere i duplicati e inviarli al computer ragno responsabile. Su quel computer, mantieni un indice di URL che sono già stati recuperati e recupera gli URL rimanenti.

Se si mantiene una coda di URL in attesa di essere recuperati su ogni spider computer, non si verificheranno colli di bottiglia nelle prestazioni. Ma è un bel po 'di programmazione per implementare questo.

consultare le normative di

ho citato diversi standard (HTTP/1.x, robots.txt, biscotti). Prenditi il ​​tuo tempo per leggerli e implementarli. Se segui semplicemente esempi di siti che conosci, commetterai degli errori (dimenticarti di parti dello standard che non sono rilevanti per i tuoi campioni) e creerai problemi per quei siti che utilizzano queste funzionalità aggiuntive.

È difficile leggere il documento standard HTTP/1.1. Ma tutti i piccoli dettagli sono stati aggiunti perché qualcuno ha davvero bisogno di quei piccoli dettagli e ora lo usa.

Answer 2

Non so esattamente a cosa si riferiva l'autore originale del commento, ma posso indovinare che wget è lento come uno spider, dal momento che sembra utilizzare solo un singolo thread di esecuzione (almeno per quello che si ha mostrato).

I ragni "reali" come heritrix utilizzano un sacco di parallelismi e trucchi per ottimizzare la velocità di scansione, mentre allo stesso tempo sono piacevoli al sito Web che stanno esplorando. Ciò significa in genere limitare gli hit a un sito a una velocità di 1 al secondo (o così) e la scansione di più siti Web contemporaneamente.

Anche in questo caso si tratta solo di un'ipotesi basata su ciò che so degli spider in generale e su ciò che hai postato qui.

Answer 3

Sfortunatamente, molti degli spider web "reali" più noti sono closed-source, e in effetti closed-binary. Tuttavia ci sono un certo numero di tecniche di base mancanti:

• Parallelismo; non sarai mai in grado di stare al passo con l'intero web senza recuperare più pagine alla volta
• Priorità; alcune pagine sono più importanti per gli spider di altre
• Limitazione di velocità; sarai bannato rapidamente se continui a tirare giù le pagine il più velocemente possibile
• Salvataggio in qualcosa di diverso da un filesystem locale; il Web è abbastanza grande da non adattarsi a un singolo albero di directory
• Controllare nuovamente le pagine periodicamente senza riavviare l'intero processo; in pratica, con un vero spider vorrete ricontrollare frequentemente le pagine "importanti" per gli aggiornamenti, mentre le pagine meno interessanti possono durare mesi.

Ci sono anche vari altri input che possono essere utilizzati come sitemaps e simili. Il punto è che wget non è progettato per spiderare l'intero web, e non è davvero una cosa che può essere catturata in un piccolo campione di codice, poiché è un problema dell'intera tecnica generale usata, piuttosto che qualsiasi piccola subroutine che si sbaglia per il compito.

Answer 4

Non ho intenzione di entrare nei dettagli di come spider internet, penso che il commento di wget riguardi il ragionamento di un sito web che è ancora una seria sfida.

• Come un ragno è necessario capire quando smettere, non andare in ricorsiva indicizzazione solo perché l'URL è cambiato come data = 1/1/1900 al 1900/01/02 e così
• Ancora più grande sfida per riordinare l'URL Riscrivi (non ho idea di cosa sia mai stato così come google o altro). È una sfida abbastanza grande da portare a galla abbastanza ma non troppo. E come si può riconoscere automaticamente la riscrittura dell'URL con alcuni parametri casuali e modifiche casuali nel contenuto?
• È necessario analizzare Flash/JavaScript, almeno fino a un certo livello
• È necessario prendere in considerazione alcuni problemi HTTP folli come di base tag. Anche l'analisi dell'HTML non è facile, considerando che la maggior parte dei siti Web non sono XHTML e che i browser sono così flessibili nella sintassi.

Non so quanto di questi siano stati implementati o considerati in wget ma si potrebbe voler dare un'occhiata a httrack per comprendere le sfide di questo compito.

Mi piacerebbe darvi alcuni esempi di codice, ma questo è un grosso problema e un ragno decente sarà circa 5000 loc senza librerie di terze parti.

+ Alcuni di loro già spiegato da @ Yaakov-rutto quindi non ho intenzione di digitare di nuovo