Domanda

La frase successiva ha attirato la mia attenzione nel manuale di 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 che le seguenti righe di codice siano rilevanti per l'opzione spider 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)

Vorrei vedere le differenze nel codice, non in astratto.Adoro gli esempi di codice.

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

È stato utile?

Soluzione

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 ragno dovrebbe ricevere dati da poche migliaia di server in parallelo, al fine di utilizzare in modo efficiente della larghezza di banda di connessione. (Presa asincrono I / O).
  • È necessario più computer che Spider in parallelo al fine di coprire la grande quantità di informazioni sul WWW (clustering; Partizione del lavoro)
  • Hai bisogno di essere educati ai siti web spider:
    • Rispettare i file robots.txt.
    • Non prendere un sacco di informazioni troppo in fretta: questo sovraccarichi i server
    • .
    • Non recuperare i file che davvero non hanno bisogno. (Ad esempio iso immagini disco; tgz pacchetti per il download del software ...)
  • Hai a che fare con i biscotti / ID di sessione: Molti siti attribuiscono ID di sessione uniche per gli URL per identificare le sessioni client. Ogni volta che si arriva al sito, si ottiene un nuovo ID di sessione e un nuovo mondo virtuale di pagine (con lo stesso contenuto). A causa di questi problemi, i motori di ricerca primi ignorati contenuti dinamici. I moderni motori di ricerca hanno imparato quali sono i problemi e come trattare con loro.
  • Devi rilevare e ignorare i dati fastidioso:. Collegamenti che forniscono una quantità apparentemente infinita di dati o connessioni che sono troppo lenti per terminare
  • Oltre a seguire i link, si consiglia di analizzare Sitemaps per ottenere gli URL delle pagine.
  • Si consiglia di valutare quali informazioni sono importanti per voi e per le modifiche di frequente per essere aggiornato più frequentemente di altre pagine. Nota: Un ragno per tutto il WWW riceve un sacco di dati --- si paga per la larghezza di banda. Si consiglia di utilizzare le richieste HTTP HEAD di indovinare se una pagina è cambiata oppure no.
  • Oltre a ricevere, si desidera elaborare le informazioni e conservarlo. Google costruisce indici che elencano per ogni parola le pagine che lo contengono. Potrebbe essere necessario computer di storage separati e un'infrastruttura per collegarli. basi di dati relazionali tradizionali non tenere il passo con le esigenze del volume dei dati e prestazioni di memorizzazione / indicizzazione tutto il WWW.

Questo è un sacco di lavoro. Ma se l'obiettivo è più modesto che leggere l'intero WWW, si può saltare alcune delle parti. Se si desidera solo per scaricare una copia di un wiki, ecc si arriva fino alle specifiche di wget.

Nota: se non credete che sia tanto lavoro, si consiglia di leggere su come Google ha reinventato la maggior parte delle ruote di calcolo (in cima al kernel di Linux di base) per costruire buone ragni. Anche se si taglia un sacco di curve, si tratta di un sacco di lavoro.

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

Connessioni parallele / asincrono comunicazione socket

È possibile eseguire diversi programmi di ragno in processi paralleli o thread. Ma avete bisogno di circa 5000-10000 collegamenti in parallelo al fine di fare buon uso della connessione di rete. E questa quantità di processi paralleli / discussioni produce troppo sovraccarico.

Una soluzione migliore è asincrono di input / output: processo circa 1000 connessioni parallele in un unico filo aprendo le prese in modalità non-bloccante e utilizzando epoll oppure selezionare elaborare solo quelle connessioni che hanno ricevuto i dati. Dal momento che il kernel Linux 2.4, Linux ha un eccellente supporto per la scalabilità (vi consiglio anche di studiare file mappati in memoria) continuamente migliorato nelle versioni successive.

Nota: L'uso I / O asincrono aiuta molto di più rispetto all'utilizzo di un "linguaggio veloce": E 'meglio scrivere di un processo epoll-guidato per 1000 connessioni scritti in Perl che correre 1000 processi scritti in C. Se lo fate a destra , si può saturare un collegamento 100Mb con i processi scritto in perl.

Dalla risposta originale: Il lato negativo di questo approccio è chesi dovrà implementare la specifica HTTP se stessi in una forma asincrono (io non sono a conoscenza di una libreria riutilizzabile che fa questo). E 'molto più facile fare questo con il semplice protocollo HTTP / 1.0 che il moderno 1.1 protocollo / HTTP. Probabilmente non beneficerebbero dei vantaggi di HTTP / 1.1 per i browser normali in ogni caso, quindi questo potrebbe essere un buon posto per salvare alcuni costi di sviluppo.

Modifica cinque anni dopo: Oggi, c'è un sacco di tecnologia libero / open source a disposizione per aiutarvi con questo lavoro. Personalmente, come il http implementazione di node.js --- si risparmia tutto il lavoro di cui al precedente paragrafo originale. Certo, oggi ci sono anche un sacco di moduli prontamente disponibili per gli altri componenti che avete bisogno nel vostro ragno. Si noti, tuttavia, che la qualità di moduli di terze parti può variare considerevolmente. Devi controllare tutto ciò che si usa. [info Invecchiamento:] Di recente, ho scritto un ragno utilizzando node.js e ho trovato l'affidabilità dei moduli NPM per l'elaborazione HTML per il link e l'estrazione di dati insufficienti. Per questo lavoro, io "Outsourced" 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 più server

Un computer non può tenere il passo con spidering tutta WWW. È necessario distribuire il lavoro su più server e lo scambio di informazioni tra di loro. Suggerisco di assegnare certe "gamme di nomi di dominio" per ciascun server: tenere una banca dati centrale di nomi a dominio con un riferimento a un computer ragno.

Estrai URL dalle pagine web ricevute in lotti: ordinarli in base alle loro nomi di dominio; rimuovere i duplicati e li inviano al computer ragno responsabile. Su quel computer, tenere un indice di URL che già sono inverosimile e recuperare i restanti URL.

Se si mantiene una coda di URL in attesa di essere scaricati su ogni computer ragno, non dovreste avere colli di bottiglia delle prestazioni. Ma è un bel po 'di programmazione per implementare questo.

Leggi le norme

ho già detto diverse norme (HTTP / 1.x, robots.txt, Cookies). Prendetevi il tempo per leggerli e implementarli. Se basta seguire gli esempi di siti che si sa, si commettono errori (dimenticare parti della norma che non sono rilevanti per i campioni) e causare problemi per quei siti che utilizzano queste funzionalità aggiuntive.

E 'un dolore per leggere il / 1.1 del documento standard di HTTP. Ma tutti i piccoli dettagli ricevuti aggiunti ad esso perché qualcuno ha davvero bisogno di quel piccolo dettaglio e adesso lo utilizza.

Altri suggerimenti

Non sono sicuro di quello che l'autore originale del commento si riferiva a, ma posso indovinare che wget è lento come un ragno, dal momento che sembra di utilizzare solo un singolo thread di esecuzione (almeno da quello che avete dimostrato ).

"reali" ragni, come Heritrix utilizzano un sacco di parallelismo e trucchi per ottimizzare la loro velocità di scansione, mentre allo stesso tempo essere gentile con il sito web che stanno strisciando. Ciò significa in genere che limita colpi a un sito ad un ritmo di 1 al secondo (o giù di lì), e strisciando più siti web allo stesso tempo.

Ancora una volta tutto questo è solo una supposizione basata su quello che so di ragni in generale, e quello che hai postato qui.

Sfortunatamente, molti dei più noti web spider "reali" sono closed-source e, in effetti, a codice binario chiuso.Tuttavia ci sono una serie di tecniche di base che mancano a wget:

  • Parallelismo;non sarai mai in grado di tenere il passo con l'intero Web senza recuperare più pagine alla volta
  • Priorità;alcune pagine sono più importanti per lo spider di altre
  • Limitazione della velocità;verrai 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 poter essere contenuto in un unico albero di directory
  • Ricontrollare periodicamente le pagine senza riavviare l'intero processo;in pratica, con un vero spider vorrai ricontrollare frequentemente gli aggiornamenti delle pagine "importanti", mentre le pagine meno interessanti possono durare mesi.

Ci sono anche vari altri input che possono essere utilizzati come mappe del sito e simili.Il punto è che wget non è progettato per esplorare l'intero web, e non è proprio qualcosa che può essere catturato in un piccolo esempio di codice, poiché è un problema dell'intera tecnica utilizzata, piuttosto che una singola piccola subroutine sbagliata per il compito.

Non ho intenzione di entrare nei dettagli di come ragno Internet, penso che wget commento è per quanto riguarda per spidering un sito web che è ancora una sfida seria.

  • 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 risolvere URL Rewrite (non ho idea di che cosa così mai come Google o qualsiasi altro gestisce questo). E 'abbastanza grande sfida a strisciare abbastanza ma non troppo. E come si può riconoscere automaticamente URL Rewrite con alcuni parametri casuali e cambiamenti casuali nel contenuto?
  • È necessario analizzare Flash / JavaScript, almeno fino a un certo livello
  • è necessario considerare alcuni aspetti HTTP folli come tag di base . Anche l'analisi del codice HTML non è facile, considerando la maggior parte dei siti web non sono XHTML e browser sono così flessibili nella sintassi.

Non so quanti di questi attuate o considerati in wget, ma si potrebbe desiderare di dare un'occhiata a HTTrack di comprendere le sfide di questo compito.

Mi piacerebbe darvi alcuni esempi di codice, ma questa è una grande attività e un ragno decente sarà di circa 5000 loc senza le biblioteche 3rd party .

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

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top