Webrobot - Web crawler

Arkitektur av en webcrawler

En webcrawler , noen ganger kalt en edderkopp eller spiderbot og ofte forkortet til crawler , er en internettbot som systematisk surfer på World Wide Web , vanligvis betjent av søkemotorer for webindeksering ( webspidering ).

Websøkemotorer og noen andre nettsteder bruker programvare for webgjennomsøking eller spidering for å oppdatere webinnholdet eller indeksene for andre nettsteders webinnhold. Webcrawlere kopierer sider for behandling av en søkemotor, som indekserer de nedlastede sidene slik at brukerne kan søke mer effektivt.

Robotsøkeprogrammer bruker ressurser på besøkte systemer og besøker ofte sider uten forespørsel. Spørsmål om plan, belastning og "høflighet" spiller inn når du får tilgang til store samlinger sider. Det finnes mekanismer for offentlige nettsteder som ikke ønsker å bli gjennomsøkt for å gjøre dette kjent for gjennomsøkingsagenten. For eksempel kan det å inkludere en robots.txtfil be om at roboter bare indekserer deler av et nettsted, eller ingenting i det hele tatt.

Antallet internettsider er ekstremt stort; selv de største robotsøkeprogrammene mangler å lage en komplett indeks. Av denne grunn slet søkemotorer med å gi relevante søkeresultater i de første årene av World Wide Web, før 2000. I dag gis relevante resultater nesten umiddelbart.

Crawlers kan validere hyperkoblinger og HTML -kode. De kan også brukes til webskraping og datadrevet programmering .

Nomenklatur

En webcrawler er også kjent som en edderkopp , en maur , en automatisk indekser eller (i FOAF -programvarekonteksten) en web -scutter .

Oversikt

En webcrawler starter med en liste over nettadresser som skal besøkes, kalt frøene . Når søkeroboten besøker disse nettadressene, identifiserer den alle hyperkoblingene på sidene og legger dem til i listen over nettadresser som skal besøkes, kalt gjennomsøkingsgrensen . Nettadresser fra grensen besøkes rekursivt i henhold til et sett med retningslinjer. Hvis søkeroboten arkiverer nettsteder (eller webarkivering ), kopierer og lagrer den informasjonen etter hvert. Arkivene er vanligvis lagret på en slik måte at de kan sees, leses og navigeres som om de var på live -nettet, men bevares som 'øyeblikksbilder'.

Arkivet er kjent som depotet og er designet for å lagre og administrere samlingen av websider . De depotet bare lagrer HTML -sider, og disse sidene er lagret som egne filer. Et depot ligner alle andre systemer som lagrer data, som en moderne database. Den eneste forskjellen er at et depot ikke trenger all funksjonalitet som tilbys av et databasesystem. Depotet lagrer den nyeste versjonen av websiden hentet av søkeroboten.

Det store volumet innebærer at søkeroboten bare kan laste ned et begrenset antall websider innen en gitt tid, så den må prioritere nedlastingene. Den høye endringshastigheten kan innebære at sidene allerede kan ha blitt oppdatert eller til og med blitt slettet.

Antall mulige nettadresser som gjennomsøkes som genereres av programvare på serversiden, har også gjort det vanskelig for webcrawlere å unngå å gjenopprette duplisert innhold . Det finnes uendelige kombinasjoner av HTTP GET (URL-baserte) parametere, hvorav bare et lite utvalg faktisk vil returnere unikt innhold. For eksempel kan et enkelt online fotogalleri tilby tre alternativer for brukere, som spesifisert gjennom HTTP GET -parametere i URL -en. Hvis det finnes fire måter å sortere bilder på, tre valg av miniatyrstørrelse , to filformater og et alternativ for å deaktivere innhold fra brukeren, kan du få tilgang til det samme settet med 48 forskjellige nettadresser, som alle kan kobles til siden. Denne matematiske kombinasjonen skaper et problem for søkeroboter, ettersom de må sortere gjennom endeløse kombinasjoner av relativt små skriptendringer for å kunne hente unikt innhold.

Som Edwards et al. bemerket, "Gitt at båndbredden for gjennomføring av gjennomsøkelser verken er uendelig eller gratis, blir det avgjørende å gjennomsøke nettet på en ikke bare skalerbar, men effektiv måte hvis et rimelig mål på kvalitet eller friskhet skal opprettholdes." En søkerobot må nøye velge på hvert trinn hvilke sider du vil besøke neste.

Gjennomgangspolitikk

Oppførselen til en webcrawler er resultatet av en kombinasjon av retningslinjer:

  • en valgpolicy som angir sidene som skal lastes ned,
  • en policy for gjenbesøk som angir når du skal se etter endringer på sidene,
  • en høflighetspolicy som sier hvordan du unngår overbelastning av nettsteder .
  • en parallelliseringspolicy som sier hvordan du koordinerer distribuerte webcrawlere.

Valgpolicy

Gitt den nåværende størrelsen på nettet, dekker selv store søkemotorer bare en del av den offentlig tilgjengelige delen. En studie fra 2009 viste at selv store søkemotorer indekserer ikke mer enn 40-70% av det indekserbare nettet; en tidligere studie av Steve Lawrence og Lee Giles viste at ingen søkemotor indekserte mer enn 16% av nettet i 1999. Ettersom en crawler alltid bare laster ned en brøkdel av websidene , er det svært ønskelig at den nedlastede brøkdelen inneholder mest relevante sider og ikke bare et tilfeldig utvalg av Internett.

Dette krever en metrik av betydning for prioritering av websider. Betydningen av en side er en funksjon av dens iboende kvalitet, dens popularitet når det gjelder lenker eller besøk, og til og med nettadressen (sistnevnte er tilfelle for vertikale søkemotorer begrenset til et enkelt toppnivådomene eller søkemotorer begrenset til et fast nettsted). Det er ekstra vanskelig å designe en god valgpolicy: den må fungere med delvis informasjon, ettersom det komplette settet med websider ikke er kjent under gjennomsøking.

Junghoo Cho et al. gjort den første studien om retningslinjer for gjennomgang av planlegging. Datasettet deres var en gjennomsøking på 180 000 sider fra stanford.edudomenet, der en gjennomgangssimulering ble utført med forskjellige strategier. Bestillingsberegningene som ble testet, var bredde-først , tilbakekoblingstall og delvis PageRank- beregninger. En av konklusjonene var at hvis søkeroboten ønsker å laste ned sider med høy Pagerank tidlig under gjennomsøkingsprosessen, så er den delvise Pagerank-strategien den bedre, etterfulgt av bredde-først og tilbakekobling. Disse resultatene er imidlertid bare for et enkelt domene. Cho skrev også sin doktorgradsavhandling ved Stanford om webcrawling.

Najork og Wiener utførte en faktisk gjennomsøking på 328 millioner sider ved å bruke den første bestillingen. De fant ut at en bredde-første gjennomsøking fanger sider med høy Pagerank tidlig i gjennomgangen (men de sammenlignet ikke denne strategien med andre strategier). Forklaringen fra forfatterne til dette resultatet er at "de viktigste sidene har mange lenker til dem fra mange verter, og disse koblingene vil bli funnet tidlig, uavhengig av hvilken vert eller side gjennomsøkelsen kommer fra."

Abiteboul designet en gjennomgangsstrategi basert på en algoritme kalt OPIC (On-line Page Importance Computation). I OPIC får hver side en innledende sum av "kontanter" som fordeles likt mellom sidene den peker til. Det ligner på en PageRank -beregning, men den er raskere og gjøres bare i ett trinn. En OPIC-drevet robotsøkeprogram laster først ned sidene i krypgrensen med større mengder "kontanter". Eksperimenter ble utført i en 100.000-siders syntetisk graf med en maktlovsfordeling av koblinger. Imidlertid var det ingen sammenligning med andre strategier eller eksperimenter på det virkelige nettet.

Boldi et al. brukte simulering på undersett av nettet på 40 millioner sider fra .itdomenet og 100 millioner sider fra WebBase-gjennomgangen, testet bredde-først mot dybde-først, tilfeldig rekkefølge og en allvitende strategi. Sammenligningen var basert på hvor godt PageRank beregnet på en delvis gjennomsøking tilnærmer seg den sanne PageRank -verdien. Overraskende nok gir noen besøk som samler PageRank veldig raskt (spesielt bredde-først og det allvitende besøket) svært dårlige progressive tilnærminger.

Baeza-Yates et al. brukte simulering på to undersett av nettet på 3 millioner sider fra .grog .cl-domenet, og testet flere gjennomsøkingsstrategier. De viste at både OPIC-strategien og en strategi som bruker lengden på per-side-køene er bedre enn bredde-først- gjennomgang, og at det også er veldig effektivt å bruke en tidligere gjennomsøking, når den er tilgjengelig, for å veilede gjeldende en.

Daneshpajouh et al. designet en samfunnsbasert algoritme for å oppdage gode frø. Metoden deres gjennomsøker websider med høy PageRank fra forskjellige lokalsamfunn i mindre iterasjon i sammenligning med gjennomsøking fra tilfeldige frø. Man kan trekke ut godt frø fra en tidligere gjennomsøkt webgraf ved hjelp av denne nye metoden. Ved bruk av disse frøene kan en ny gjennomgang være veldig effektiv.

Begrensning av fulgte lenker

En søkerobot vil kanskje bare søke etter HTML -sider og unngå alle andre MIME -typer . For å be om bare HTML -ressurser, kan en robotsøkeprogram sende en HTTP HEAD -forespørsel for å bestemme MIME -typen for en nettressurs før den ber om hele ressursen med en GET -forespørsel. For å unngå å sende mange HEAD -forespørsler, kan en crawler undersøke nettadressen og bare be om en ressurs hvis URL -enden slutter med visse tegn som .html, .htm, .asp, .aspx, .php, .jsp, .jspx eller et skråstrek . Denne strategien kan føre til at mange HTML -webressurser utilsiktet hoppes over.

Noen robotsøkeprogrammer kan også unngå å be om ressurser som har "?" i dem (er dynamisk produsert) for å unngå edderkoppfeller som kan føre til at søkeroboten laster ned et uendelig antall nettadresser fra et nettsted. Denne strategien er upålitelig hvis nettstedet bruker URL -omskriving for å forenkle nettadressene.

URL -normalisering

Crawlers utfører vanligvis en slags URL -normalisering for å unngå å gjennomgå den samme ressursen mer enn én gang. Begrepet URL -normalisering , også kalt URL -kanonikalisering , refererer til prosessen med å endre og standardisere en URL på en konsekvent måte. Det er flere typer normalisering som kan utføres, inkludert konvertering av nettadresser til små bokstaver, fjerning av "." og ".." segmenter, og legge til etterfølgende skråstreker til den ikke-tomme banekomponenten.

Stigende kryp

Noen søkeroboter har til hensikt å laste ned/laste opp så mange ressurser som mulig fra et bestemt nettsted. Så banen-stigende crawler ble introdusert som ville stige til hver bane i hver URL som den har tenkt å gjennomsøke. For eksempel, når den får en frø -URL til http://llama.org/hamster/monkey/page.html, vil den prøve å crawl/hamster/monkey/,/hamster/og/. Cothey fant ut at en stigende robotsøkeprogram var veldig effektiv for å finne isolerte ressurser, eller ressurser som det ikke ville blitt funnet noen inngående kobling for ved vanlig gjennomsøking.

Fokusert gjennomgang

Betydningen av en side for en søkerobot kan også uttrykkes som en funksjon av likheten til en side med et gitt søk. Webcrawlers som prøver å laste ned sider som ligner på hverandre, kalles fokusert crawler eller aktuelle crawlers . Konseptene aktuell og fokusert gjennomgang ble først introdusert av Filippo Menczer og av Soumen Chakrabarti et al.

Hovedproblemet i fokusert gjennomsøking er at vi i sammenheng med en webcrawler ønsker å kunne forutsi likheten mellom teksten på en gitt side og spørringen før vi faktisk laster ned siden. En mulig prediktor er ankerteksten til lenker; dette var tilnærmingen som ble tatt av Pinkerton i den første web -søkeroboten i internettets tidlige dager. Diligenti et al. foreslå å bruke hele innholdet på sidene som allerede er besøkt for å anta likheten mellom spørresøket og sidene som ikke har blitt besøkt ennå. Ytelsen til en fokusert gjennomsøking avhenger hovedsakelig av rike koblinger i det spesifikke emnet det søkes på, og en fokusert gjennomsøking er vanligvis avhengig av en generell nettsøkemotor for å gi utgangspunkt.

Akademisk fokusert robotsøkeprogram

Et eksempel på de fokuserte søkerobotene er akademiske crawlers, som søker gjennom akademisk relaterte dokumenter med fri tilgang, for eksempel citeseerxbot , som er søkeroboten til CiteSeer X- søkemotoren. Andre akademiske søkemotorer er Google Scholar og Microsoft Academic Search etc. Fordi de fleste vitenskapelige artikler publiseres i PDF -formater, er en slik robotsøkeprogram spesielt interessert i å gjennomsøke PDF , PostScript -filer, Microsoft Word inkludert zip -formater. På grunn av dette må generelle åpen kildekode -robotsøkeprogrammer , for eksempel Heritrix , tilpasses for å filtrere ut andre MIME -typer , eller en mellomvare brukes til å trekke ut disse dokumentene og importere dem til den fokuserte gjennomsøkingsdatabasen og depotet. Å identifisere om disse dokumentene er akademiske eller ikke, er utfordrende og kan gi en betydelig overhead til gjennomsøkingsprosessen, så dette utføres som en etter -gjennomsøkingsprosess ved hjelp av maskinlæring eller algoritmer for vanlige uttrykk . Disse akademiske dokumentene er vanligvis hentet fra hjemmesider til fakulteter og studenter eller fra publikasjonssiden til forskningsinstitutter. Fordi akademiske dokumenter bare tar en liten brøkdel på hele nettsidene, er et godt frøvalg viktig for å øke effektiviteten til disse webcrawlerne. Andre akademiske robotsøkeprogrammer kan laste ned ren tekst og HTML -filer, som inneholder metadata for akademiske artikler, for eksempel titler, artikler og sammendrag. Dette øker det totale antallet papirer, men en betydelig brøkdel gir kanskje ikke gratis PDF -nedlastinger.

Semantisk fokusert crawler

En annen type fokuserte robotsøkeprogrammer er semantisk fokusert robotsøkeprogram, som bruker domeneontologier for å representere aktuelle kart og lenke websider med relevante ontologiske konsepter for valg og kategorisering. I tillegg kan ontologier oppdateres automatisk i gjennomsøkingsprosessen. Dong et al. introduserte en slik ontologi-læringsbasert crawler som bruker støttevektormaskin for å oppdatere innholdet i ontologiske konsepter ved gjennomgang av websider.

Re-visit policy

Nettet har en veldig dynamisk karakter, og det kan ta uker eller måneder å gjennomgå en brøkdel av nettet. Når en web -søkerobjekt er ferdig med gjennomsøkingen, kan mange hendelser ha skjedd, inkludert kreasjoner, oppdateringer og slettinger.

Fra søkemotorens synspunkt er det en kostnad forbundet med å ikke oppdage en hendelse, og dermed ha en utdatert kopi av en ressurs. De mest brukte kostnadsfunksjonene er friskhet og alder.

Friskhet : Dette er et binært mål som indikerer om den lokale kopien er korrekt eller ikke. Friskheten til en side p i depotet på tidspunktet t er definert som:

Alder : Dette er et mål som angir hvor utdatert den lokale kopien er. Alderen til en side p i depotet, på tidspunktet t er definert som:

Coffman et al. jobbet med en definisjon av målet for en webcrawler som tilsvarer friskhet, men bruker en annen formulering: de foreslår at en crawler må minimere brøkdelen av tid sider forblir utdaterte. De bemerket også at problemet med webgjennomsøking kan modelleres som et avstemningssystem med flere køer, én server, som Web-søkeroboten er serveren på og nettstedene er køene. Sidemodifikasjoner er kundenes ankomst, og overgangstider er intervallet mellom sidetilgang til et enkelt nettsted. I henhold til denne modellen tilsvarer gjennomsnittlig ventetid for en kunde i avstemningssystemet gjennomsnittsalderen for web -søkeroboten.

Målet med søkeroboten er å holde gjennomsnittlig ferskhet på sider i samlingen så høy som mulig, eller å holde gjennomsnittsalderen på sider så lav som mulig. Disse målene er ikke likeverdige: i det første tilfellet er søkeroboten bare opptatt av hvor mange sider som er utdatert, mens i det andre tilfellet er søkeroboten opptatt av hvor gamle de lokale kopiene av sidene er.

Evolusjon av friskhet og alder i en webcrawler

To enkle gjenbesøkende politikker ble studert av Cho og Garcia-Molina:

  • Uniform policy: Dette innebærer å besøke alle sidene i samlingen på nytt med samme frekvens, uavhengig av endringshastigheten.
  • Proporsjonal politikk: Dette innebærer å besøke sidene som endres oftere, oftere. Besøksfrekvensen er direkte proporsjonal med (estimert) endringsfrekvens.

I begge tilfeller kan den gjentatte gjennomsøkingsrekkefølgen på sider gjøres enten i en tilfeldig eller en bestemt rekkefølge.

Cho og Garcia-Molina beviste det overraskende resultatet at når det gjelder gjennomsnittlig friskhet, overgår den ensartede politikken proporsjonalpolitikken både i et simulert web og en ekte webgjennomsøkelse. Intuitivt er begrunnelsen at ettersom webcrawlere har en grense for hvor mange sider de kan gjennomsøke i en gitt tidsramme, (1) vil de tildele for mange nye gjennomsøkelser til sider som raskt endres på bekostning av sjeldnere oppdatering av sider, og (2) ferskheten på sider som raskt endres varer i en kortere periode enn sidene som endres sjeldnere. Med andre ord, en proporsjonal policy tildeler flere ressurser til å gjennomgå sider som oppdateres ofte, men opplever mindre generell friskhetstid fra dem.

For å forbedre friskheten bør søkeroboten straffe elementene som endres for ofte. Den optimale politikken for gjenbesøk er verken ensartet politikk eller proporsjonal politikk. Den optimale metoden for å holde gjennomsnittlig friskhet høy inkluderer å ignorere sidene som endres for ofte, og det optimale for å holde gjennomsnittsalderen lav er å bruke tilgangsfrekvenser som monotonisk (og sub-lineært) øker med endringshastigheten på hver side. I begge tilfeller er det optimale nærmere den ensartede politikken enn proporsjonalpolitikken: som Coffman et al. Vær oppmerksom på at "for å minimere den forventede foreldelsestiden, bør tilgangene til en bestemt side holdes så jevnt fordelt som mulig". Eksplisitte formler for politikken for gjenbesøk er generelt sett ikke oppnåelige, men de oppnås numerisk, ettersom de er avhengige av fordelingen av sideendringer. Cho og Garcia-Molina viser at den eksponentielle fordelingen passer godt for å beskrive sideendringer , mens Ipeirotis et al. vise hvordan du bruker statistiske verktøy for å oppdage parametere som påvirker denne fordelingen. Vær oppmerksom på at retningslinjene for gjenbesøk som er vurdert her, betrakter alle sider som homogene når det gjelder kvalitet ("alle sider på nettet er verdt det samme"), noe som ikke er et realistisk scenario, så ytterligere informasjon om kvaliteten på websiden bør være inkludert for å oppnå en bedre gjennomgangspolitikk.

Politikk for høflighet

Crawlers kan hente data mye raskere og større dybde enn menneskelige søkere, slik at de kan ha en ødeleggende innvirkning på ytelsen til et nettsted. Hvis en enkelt crawler utfører flere forespørsler per sekund og/eller laster ned store filer, kan en server ha vanskelig for å følge med forespørsler fra flere crawlers.

Som nevnt av Koster, er bruken av webcrawlere nyttig for en rekke oppgaver, men kommer med en pris for det generelle samfunnet. Kostnadene ved bruk av webcrawlere inkluderer:

  • nettverksressurser, ettersom robotsøkeprogrammer krever betydelig båndbredde og opererer med høy grad av parallellitet over lang tid;
  • serveroverbelastning, spesielt hvis tilgangsfrekvensen til en gitt server er for høy;
  • dårlig skrevet crawlers, som kan krasje servere eller rutere, eller som laster ned sider de ikke kan håndtere; og
  • personlige robotsøkeprogrammer som, hvis de distribueres av for mange brukere, kan forstyrre nettverk og webservere.

En delvis løsning på disse problemene er robotens eksklusjonsprotokoll , også kjent som robots.txt -protokollen som er en standard for administratorer for å angi hvilke deler av webserverne som ikke bør nås av crawlers. Denne standarden inkluderer ikke et forslag til intervallet for besøk til den samme serveren, selv om dette intervallet er den mest effektive måten å unngå overbelastning av serveren. Nylig kommersielle søkemotorer som Google , Ask Jeeves , MSN og Yahoo! Søk kan bruke en ekstra "Gjennomsøkingsforsinkelse:" -parameter i robots.txt- filen for å angi antall sekunder det skal gå mellom forespørslene.

Det første foreslåtte intervallet mellom påfølgende sidelaster var 60 sekunder. Men hvis sider ble lastet ned med denne hastigheten fra et nettsted med mer enn 100 000 sider over en perfekt forbindelse med null ventetid og uendelig båndbredde, ville det ta mer enn 2 måneder å bare laste ned hele nettstedet; også bare en brøkdel av ressursene fra den webserveren ville bli brukt. Dette virker ikke akseptabelt.

Cho bruker 10 sekunder som et intervall for tilganger, og WIRE -søkeroboten bruker 15 sekunder som standard. MercatorWeb -søkeroboten følger en adaptiv høflighetspolicy: hvis det tok t sekunder å laste ned et dokument fra en gitt server, viker søkeroboten i 10 t sekunder før den neste siden lastes ned. Dill et al. bruk 1 sekund.

For de som bruker webcrawlere til forskningsformål, er det nødvendig med en mer detaljert kostnads-nytte-analyse, og etiske hensyn bør tas i betraktning når de skal bestemme hvor de skal gjennomsøke og hvor raskt de skal gjennomsøke.

Anekdotiske bevis fra tilgangslogger viser at tilgangsintervaller fra kjente søkeroboter varierer mellom 20 sekunder og 3–4 minutter. Det er verdt å merke seg at selv om de er veldig høflige og tar alle forholdsregler for å unngå overbelastning av webservere, mottas noen klager fra nettserveradministratorer. Brin og Page bemerker at: "... kjører en robotsøkeprogram som kobles til mer enn en halv million servere (...) genererer en god del e-post og telefonsamtaler. På grunn av det store antallet mennesker som kommer på nettet, det er alltid de som ikke vet hva en robotsøkeprogram er, for dette er den første de har sett. "

Parallelliseringspolitikk

En parallellcrawler er en crawler som kjører flere prosesser parallelt. Målet er å maksimere nedlastingshastigheten samtidig som overhead fra parallellisering minimeres og å unngå gjentatte nedlastinger av samme side. For å unngå å laste ned den samme siden mer enn én gang, krever gjennomsøkingssystemet en policy for tildeling av de nye nettadressene som ble oppdaget under gjennomsøkingsprosessen, ettersom den samme nettadressen kan bli funnet av to forskjellige gjennomsøkingsprosesser.

Arkitekturer

Arkitektur på høyt nivå til en standard webcrawler

En crawler må ikke bare ha en god gjennomsøkingsstrategi, som nevnt i de foregående seksjonene, men den bør også ha en svært optimalisert arkitektur.

Shkapenyuk og Suel bemerket at:

Selv om det er ganske enkelt å bygge en langsom søkerobjekt som laster ned noen få sider per sekund i en kort periode, byr det på en rekke utfordringer i systemdesign å bygge et system med høy ytelse som kan laste ned hundrevis av millioner sider over flere uker, I/O og nettverkseffektivitet, og robusthet og håndterbarhet.

Webcrawlere er en sentral del av søkemotorer, og detaljer om algoritmer og arkitektur blir beholdt som forretningshemmeligheter. Når crawler -design publiseres, er det ofte en viktig mangel på detaljer som forhindrer andre i å reprodusere verket. Det dukker også opp bekymringer for " søkemotorsøppel ", som forhindrer store søkemotorer i å publisere sine rangeringsalgoritmer.

Sikkerhet

Selv om de fleste nettstedseierne er opptatt av at sidene deres skal indekseres så bredt som mulig for å ha sterk tilstedeværelse i søkemotorer , kan webgjennomgang også ha utilsiktede konsekvenser og føre til et kompromiss eller databrudd hvis en søkemotor indekserer ressurser som ikke burde være offentlig tilgjengelig, eller sider som avslører potensielt sårbare versjoner av programvare.

Bortsett fra standard sikkerhetsanbefalinger for webapplikasjoner, kan nettstedseiere redusere eksponeringen for opportunistisk hacking ved å bare la søkemotorer indeksere de offentlige delene av nettstedene (med robots.txt ) og eksplisitt blokkere dem fra å indeksere transaksjonelle deler (påloggingssider, private sider, etc.).

Crawler -identifikasjon

Webcrawlere identifiserer seg vanligvis på en webserver ved å bruke feltet User-agent i en HTTP- forespørsel. Nettstedsadministratorer undersøker vanligvis loggen til deres webservere og bruker brukeragentfeltet til å avgjøre hvilke robotsøkeprogrammer som har besøkt webserveren og hvor ofte. Brukeragentfeltet kan inneholde en URL -adresse der nettstedets administrator kan finne ut mer informasjon om søkeroboten. Å undersøke loggen på webserveren er en kjedelig oppgave, og derfor bruker noen administratorer verktøy for å identifisere, spore og verifisere webcrawlere. Spambots og andre ondsinnede webcrawlere vil neppe plassere identifiserende informasjon i brukeragentfeltet, eller de kan maskere identiteten sin som en nettleser eller annen velkjent søkerobot.

Nettstedsadministratorer foretrekker at webcrawlere identifiserer seg slik at de kan kontakte eieren om nødvendig. I noen tilfeller kan robotsøkeprogrammer ved et uhell bli fanget i en crawlerfelle, eller de kan overbelaste en webserver med forespørsler, og eieren må stoppe søkeroboten. Identifikasjon er også nyttig for administratorer som er interessert i å vite når de kan forvente at nettsidene deres skal indekseres av en bestemt søkemotor .

Gjennomgå det dype nettet

En enorm mengde nettsider ligger i det dype eller usynlige nettet . Disse sidene er vanligvis bare tilgjengelige ved å sende forespørsler til en database, og vanlige søkeroboter kan ikke finne disse sidene hvis det ikke er lenker som peker til dem. Googles Sitemaps -protokollen og mod oai er ment å tillate oppdagelsen av disse dyptnettressurser.

Dyp webgjennomgang multipliserer også antallet nettlenker som skal gjennomsøkes. Noen robotsøkeprogrammer tar bare noen av nettadressene i <a href="URL">form. I noen tilfeller, for eksempel Googlebot , utføres webgjennomgang på all tekst som er inne i hypertekstinnholdet, tagger eller tekst.

Strategiske tilnærminger kan tas for å målrette mot dypt webinnhold. Med en teknikk som kalles skjermskraping , kan spesialisert programvare tilpasses til automatisk og gjentatte ganger å søke etter et gitt webskjema med den hensikt å samle de resulterende dataene. Slik programvare kan brukes til å spenne over flere nettskjemaer over flere nettsteder. Data hentet fra resultatene fra en innsending av et webskjema kan tas og brukes som input til et annet webskjema, og dermed etablere kontinuitet på tvers av Deep Web på en måte som ikke er mulig med tradisjonelle webcrawlere.

Sider bygget på AJAX er blant dem som forårsaker problemer for webcrawlere. Google har foreslått et format for AJAX -anrop som boten deres kan gjenkjenne og indeksere.

Web crawler bias

En nylig studie basert på en storskala analyse av robots.txt -filer viste at visse webcrawlere ble foretrukket fremfor andre, med Googlebot som den mest foretrukne webcrawler.

Visual vs programmatic crawlers

Det finnes en rekke "visual web scraper/crawler" -produkter på nettet som vil gjennomsøke sider og strukturere data i kolonner og rader basert på brukernes krav. En av hovedforskjellene mellom en klassiker og en visuell crawler er nivået på programmeringsevne som kreves for å sette opp en crawler. Den siste generasjonen "visuelle skrapere" fjerner flertallet av programmeringskunnskapene som trengs for å kunne programmere og starte en gjennomgang for å skrape webdata.

Den visuelle skrap/kryp-metoden er avhengig av at brukeren "lærer" et stykke crawler-teknologi, som deretter følger mønstre i semi-strukturerte datakilder. Den dominerende metoden for å lære en visuell crawler er å markere data i en nettleser og trene kolonner og rader. Selv om teknologien ikke er ny, for eksempel den var grunnlaget for Needlebase som har blitt kjøpt av Google (som en del av et større oppkjøp av ITA Labs), er det fortsatt vekst og investeringer på dette området av investorer og sluttbrukere.

Liste over webcrawlere

Følgende er en liste over publiserte robotsøkeprogrammer for robotsøkeprogrammer (unntatt fokuserte webroboter), med en kort beskrivelse som inneholder navnene på de forskjellige komponentene og fremragende funksjoner:

Historiske webcrawlere

  • World Wide Web Worm var en robotsøkeprogram som ble brukt til å bygge en enkel indeks over dokumenttitler og nettadresser. Indeksen kan søkes ved hjelp av grep Unix -kommandoen.
  • Yahoo! Slurp var navnet på Yahoo! Søk i søkeroboten til Yahoo! inngått avtale med Microsoft om å bruke Bingbot i stedet.

Interne web-robotsøkeprogrammer

  • Applebot er Apples webcrawler. Den støtter Siri og andre produkter.
  • Bingbot er navnet på Microsofts Bing webcrawler. Det erstattet Msnbot .
  • Baiduspider er Baidus webcrawler.
  • Googlebot er beskrevet i detalj, men referansen handler bare om en tidlig versjon av arkitekturen, som ble skrevet i C ++ og Python . Robotsøkeprogrammet ble integrert med indekseringsprosessen, fordi tekst analyse ble gjort for fulltekstindeksering og også for URL-ekstraksjon. Det er en URL -server som sender lister over nettadresser som skal hentes av flere gjennomsøkingsprosesser. Under analysen ble nettadressene som ble funnet, sendt til en URL -server som kontrollerte om URL -en er sett tidligere. Hvis ikke, ble URL -adressen lagt til i køen til URL -serveren.
  • WebCrawler ble brukt til å bygge den første offentlig tilgjengelige fulltekstindeksen for et delsett av nettet. Det var basert på lib-WWW for å laste ned sider, og et annet program for å analysere og bestille URL-er for bredde-første utforskning av webgrafen. Den inkluderte også en sanntidsrobot som fulgte lenker basert på likheten mellom ankerteksten og den angitte spørringen.
  • WebFountain er en distribuert, modulær søkerobot som ligner på Mercator, men skrevet i C ++.
  • Xenon er en webcrawler som brukes av statlige skattemyndigheter for å oppdage svindel.

Kommersielle webroboter

Følgende webcrawlere er tilgjengelige, til en pris ::

Open-source-robotsøkeprogrammer

  • Frontera er et webcrawling -rammeverk som implementerer crawl frontier -komponent og tilbyr primer for skalerbarhet for webcrawler -applikasjoner.
  • GNU Wget er en kommandolinje -operert crawler skrevet i C og utgitt under GPL . Det brukes vanligvis til å speile web- og FTP -sider.
  • GRUB var en åpen kildekode for distribuert søk som Wikia Search brukte for å gjennomsøke nettet.
  • Heritrix er Internett- arkivets crawler av høy kvalitet, designet for å arkivere periodiske øyeblikksbilder av en stor del av nettet. Den ble skrevet i Java .
  • ht: // Dig inkluderer en webrobot i indekseringsmotoren.
  • HTTrack bruker en webcrawler til å lage et speil av et nettsted for visning offline. Den er skrevet i C og utgitt under GPL .
  • mnoGoSearch er en crawler, indekser og en søkemotor skrevet i C og lisensiert under GPL (*bare NIX -maskiner)
  • Apache Nutch er en svært utvidbar og skalerbar webcrawler skrevet i Java og utgitt under en Apache -lisens . Den er basert på Apache Hadoop og kan brukes med Apache Solr eller Elasticsearch .
  • Open Search Server er en søkemotor og webcrawler -programvareversjon under GPL .
  • PHP-Crawler er en enkel PHP- og MySQL- basert crawler utgitt under BSD-lisensen .
  • Scrapy , en åpen kildekode -webcrawler -rammeverk, skrevet i python (lisensiert under BSD ).
  • Seeks , en gratis distribuert søkemotor (lisensiert under AGPL ).
  • StormCrawler , en samling ressurser for å bygge lav-latens, skalerbare webcrawlere på Apache Storm ( Apache-lisens ).
  • tkWWW Robot , en robotsøkeprogram basert på tkWWW -nettleseren (lisensiert under GPL ).
  • Xapian , en søkemotormaskin, skrevet i c ++.
  • YaCy , en gratis distribuert søkemotor, bygget på prinsipper for peer-to-peer-nettverk (lisensiert under GPL ).

Se også

Referanser

Videre lesning