웹 크롤러

웹 크롤러(Web crawler)는 월드 와이드 웹을 체계적으로 탐색하는 인터넷 봇으로, 일반적으로 웹 인덱싱(웹 스핑딩)을 목적으로 검색 엔진에 의해 작동됩니다.^[1]

웹 검색 엔진 및 일부 다른 웹 사이트는 웹 크롤링 또는 스패닝 소프트웨어를 사용하여 웹 콘텐츠 또는 다른 사이트의 웹 콘텐츠 색인을 업데이트합니다. 웹 크롤러는 사용자가 보다 효율적으로 검색할 수 있도록 다운로드한 페이지를 색인화하는 검색 엔진으로 페이지를 복사합니다.

크롤러는 방문한 시스템에서 리소스를 소비하고 종종 사전 예방 없이 사이트를 방문합니다. 많은 양의 페이지 모음에 액세스하면 일정, 로드 및 "예의" 문제가 발생합니다. 이를 크롤링 에이전트에게 알리기 위해 크롤링을 원하지 않는 공공 사이트에 대한 메커니즘이 존재합니다. 예를 들어, a를 포함하여 robots.txt 파일은 봇에게 웹 사이트의 일부만 색인화하도록 요청하거나 전혀 색인화하지 않을 수 있습니다.

인터넷 페이지의 수는 매우 많습니다. 가장 큰 크롤러도 완전한 지수를 만들기에는 부족합니다. 이러한 이유로, 검색 엔진들은 2000년 이전의 월드 와이드 웹 초기에 관련 검색 결과를 제공하는 데 어려움을 겪었습니다. 오늘날 관련 결과는 거의 즉시 제공됩니다.

크롤러는 하이퍼링크와 HTML 코드를 검증할 수 있습니다. 웹 스크래핑 및 데이터 기반 프로그래밍에도 사용할 수 있습니다.

명명법

웹 크롤러는 거미,^[2] 개미, 자동 인덱싱 또는 ^[3](FOAF 소프트웨어 컨텍스트에서) 웹 스캐터라고도 합니다.^[4]

개요

웹 크롤러는 방문할 URL 목록으로 시작합니다. 그 첫 번째 URL을 씨앗이라고 합니다. 크롤러가 이러한 URL을 방문할 때 해당 URL에 응답하는 웹 서버와 통신함으로써 검색된 웹 페이지의 모든 하이퍼링크를 식별하여 크롤러 프론티어라고 불리는 방문할 URL 목록에 추가합니다. 프론티어의 URL은 정책 집합에 따라 재귀적으로 방문됩니다. 크롤러가 웹 사이트 보관(또는 웹 보관)을 수행하는 경우 정보를 복사하고 저장합니다. 아카이브는 일반적으로 라이브 웹에 있는 것처럼 보고, 읽고, 탐색할 수 있는 방식으로 저장되지만 '스냅샷'으로 보존됩니다.^[5]

아카이브는 저장소로 알려져 있으며 웹 페이지 모음을 저장하고 관리하도록 설계되었습니다. 리포지토리에는 HTML 페이지만 저장되며 이 페이지는 별개의 파일로 저장됩니다. 리포지토리는 현대 데이터베이스와 같이 데이터를 저장하는 다른 시스템과 유사합니다. 유일한 차이점은 리포지토리가 데이터베이스 시스템에서 제공하는 모든 기능을 필요로 하지 않는다는 것입니다. 저장소에는 크롤러가 검색한 웹 페이지의 최신 버전이 저장됩니다.^{[citation needed]}

볼륨이 크다는 것은 크롤러가 주어진 시간 내에 제한된 수의 웹 페이지만 다운로드할 수 있음을 의미하므로 다운로드의 우선 순위를 정해야 합니다. 변경률이 높다는 것은 페이지가 이미 업데이트되었거나 삭제되었을 수 있음을 의미할 수 있습니다.

서버측 소프트웨어에 의해 생성되는 가능한 URL의 수는 웹 크롤러가 중복 콘텐츠를 검색하는 것을 피하기 어렵게 만들었습니다. HTTP GET(URL-based) 매개 변수의 끝없는 조합이 존재하며, 그 중 작은 선택만이 실제로 고유 콘텐츠를 반환합니다. 예를 들어 간단한 온라인 사진 갤러리는 URL의 HTTP GET 매개 변수를 통해 지정된 대로 사용자에게 세 가지 옵션을 제공할 수 있습니다. 이미지를 정렬하는 네 가지 방법, 썸네일 크기의 세 가지 선택, 두 가지 파일 형식, 사용자가 제공하는 콘텐츠를 비활성화하는 옵션이 있다면 48개의 다른 URL을 사용하여 동일한 콘텐츠 세트에 액세스할 수 있습니다. 이 모든 것은 사이트에서 연결될 수 있습니다. 이 수학적 조합은 크롤러가 고유한 콘텐츠를 검색하기 위해 상대적으로 사소한 스크립트 변경의 끝없는 조합을 정렬해야 하기 때문에 문제를 발생시킵니다.

Edwards et al. 은 "크롤을 수행하는 대역폭이 무한하지도 않고 자유롭지도 않다는 점을 감안할 때, 품질이나 신선도에 대한 합리적인 측정이 유지되려면 확장 가능할 뿐만 아니라 효율적인 방법으로 웹을 크롤링하는 것이 중요해지고 있습니다."^[6]라고 언급했습니다. 크롤러는 각 단계에서 다음에 방문할 페이지를 신중하게 선택해야 합니다.

크롤링 정책

웹 크롤러의 동작은 다음과 같은 정책 조합의 결과입니다.^[7]

• 다운로드할 페이지를 명시하는 선택 정책,
• 언제 페이지의 변경 사항을 확인해야 하는지를 명시하는 재visit 정책,
• 웹 사이트에 과부하가 걸리는 것을 피하는 방법을 명시한 예의범절 정책
• 분산된 웹 크롤러를 조정하는 방법을 설명하는 병렬화 정책

선택정책

웹의 현재 크기를 고려할 때, 큰 검색 엔진도 공개적으로 사용 가능한 부분의 일부만 포함합니다. 2009년 연구에 따르면 대규모 검색 엔진 인덱스도 색인 가능한 웹의 40~70%를 넘지 않는 것으로 나타났습니다.^[8] 스티브 로렌스와 리 자일스의 이전 연구에 따르면 1999년에는 웹의 16%를 초과하는 색인을 생성한 검색 엔진이 없었습니다.^[9] 크롤러는 항상 웹 페이지의 일부만 다운로드하므로 다운로드된 일부는 웹의 임의 샘플이 아니라 가장 관련성이 높은 페이지를 포함하는 것이 매우 바람직합니다.

이를 위해서는 웹 페이지의 우선순위를 정하는 중요도 메트릭이 필요합니다. 페이지의 중요성은 고유한 품질, 링크 또는 방문 측면에서의 인기, 심지어 URL의 기능입니다(후자는 단일 최상위 도메인으로 제한된 수직 검색 엔진 또는 고정 웹 사이트로 제한된 검색 엔진의 경우). 올바른 선택 정책을 설계하는 데는 추가적인 어려움이 있습니다. 크롤링하는 동안 웹 페이지의 전체 집합을 알 수 없기 때문에 부분적인 정보를 사용해야 합니다.

조정후 등은 크롤링 스케쥴링 정책에 대한 최초의 연구를 하였습니다. 그들의 데이터 세트는 도메인에서 180,000 페이지를 스크롤하는 것이었고, 여기서 크롤링 시뮬레이션은 다양한 전략으로 수행되었습니다.^[10] 테스트한 순서 메트릭은 너비 우선, 백링크 수 및 부분 페이지 순위 계산이었습니다. 결론 중 하나는 크롤러가 크롤링 과정에서 초기에 높은 페이지 랭크를 가진 페이지를 다운로드하기를 원한다면 부분적인 페이지 랭크 전략이 더 낫고, 그 다음으로 폭 우선 및 백링크 카운트가 뒤따른다는 것이었습니다. 그러나 이러한 결과는 단일 도메인에 대한 것입니다. 조 씨는 또한 스탠포드 대학에서 박사 학위 논문을 웹 크롤링에 썼습니다.^[11]

나조크와 위너는 폭 우선 순서를 사용하여 3억 2천 8백만 페이지에 달하는 실제 크롤링을 수행했습니다.^[12] 그들은 폭 우선의 크롤이 크롤 초기에 페이지 랭크가 높은 페이지를 캡처한다는 것을 발견했습니다(그러나 그들은 이 전략을 다른 전략과 비교하지 않았습니다). 이 결과에 대한 저자들의 설명은 "가장 중요한 페이지들은 수많은 호스트들로부터 많은 링크들을 가지고 있으며, 이러한 링크들은 크롤이 어느 호스트나 페이지에서 시작되느냐에 관계없이 조기에 발견될 것입니다."라는 것입니다.

아비테불은 OPIC(On-line Page Importance Computation)이라는 알고리즘을 기반으로 크롤링 전략을 설계했습니다.^[13] OPIC에서 각 페이지에는 해당 페이지가 가리키는 페이지 간에 동일하게 분배되는 "현금"의 초기 합계가 제공됩니다. 페이지 랭크 계산과 비슷하지만 더 빠르고 한 단계로만 수행됩니다. OPIC 구동 크롤러는 먼저 크롤링 프론티어의 페이지를 더 많은 양의 "현금"으로 다운로드합니다. 실험은 인링크의 멱법칙 분포가 있는 100,000 페이지 합성 그래프에서 수행되었습니다. 하지만 실제 웹에서는 다른 전략이나 실험과 비교가 되지 않았습니다.

볼디 외. 도메인에서 4천만 페이지, 웹베이스 크롤에서 1억 페이지로 구성된 웹의 하위 집합에 대한 시뮬레이션을 사용하여 깊이 우선, 무작위 순서 및 전지적 전략에 대해 폭 우선 테스트를 수행했습니다. 비교는 부분 크롤에서 계산된 페이지 랭크가 실제 페이지 랭크 값과 얼마나 근사한지를 기준으로 했습니다. 페이지 순위를 매우 빠르게 누적하는 일부 방문(특히 너비 우선 및 전지적 방문)은 매우 빈약한 점진적 근사치를 제공합니다.^[14][15]

배자-예이츠 외. 과 도메인에서 3백만 페이지의 웹의 두 부분집합에 대한 시뮬레이션을 사용하여 몇 가지 크롤링 전략을 테스트했습니다.^[16] 그들은 OPIC 전략과 사이트별 대기열의 길이를 사용하는 전략이 폭 우선 크롤링보다 더 낫다는 것을 보여주었고, 사용 가능할 때 이전 크롤링을 사용하여 현재의 것을 안내하는 것도 매우 효과적이라는 것을 보여주었습니다.

Daneshpajouh 등은 좋은 씨앗을 발견하기 위한 커뮤니티 기반 알고리즘을 설계했습니다.^[17] 그들의 방법은 다른 커뮤니티의 페이지 랭크가 높은 웹 페이지를 무작위 시드에서 시작하는 크롤과 비교하여 더 적은 반복으로 크롤링합니다. 이 새로운 방법을 사용하여 이전에 작성된 웹 그래프에서 좋은 시드를 추출할 수 있습니다. 이 씨앗을 사용하면 새로운 크롤링이 매우 효과적일 수 있습니다.

후속 링크 제한

크롤러는 HTML 페이지를 검색하고 다른 모든 MIME 유형을 피하기만 원할 수 있습니다. HTML 리소스만을 요청하기 위해 크롤러는 GET 요청으로 전체 리소스를 요청하기 전에 웹 리소스의 MIME 유형을 결정하기 위해 HTTP HEAD 요청을 수행할 수 있습니다. 수많은 HEAD 요청을 피하기 위해 크롤러는 URL을 검사하고 URL이 .html, .htm, .asp, .aspx, .php, .jsp, .jsp 또는 슬래시와 같은 특정 문자로 끝나는 경우에만 리소스를 요청할 수 있습니다. 이 전략은 많은 HTML 웹 리소스를 의도치 않게 건너뛸 수 있습니다.

일부 크롤러는 크롤러가 웹 사이트에서 무한한 수의 URL을 다운로드하게 할 수 있는 스파이더 트랩을 피하기 위해 "?"를 포함하는 리소스를 요청하는 것을 피할 수도 있습니다. 사이트가 URL 재작성을 사용하여 URL을 단순화하는 경우 이 전략은 신뢰할 수 없습니다.

URL 정규화

크롤러는 일반적으로 동일한 리소스를 두 번 이상 크롤링하지 않기 위해 URL 정규화를 수행합니다. URL 정규화라고도 하는 URL 정규화란 일관된 방식으로 URL을 수정하고 표준화하는 과정을 말합니다. URL을 소문자로 변환하고, "." 및 "." 세그먼트를 제거하고, 비어 있지 않은 경로 구성 요소에 후행 슬래시를 추가하는 등 여러 유형의 정규화를 수행할 수 있습니다.^[18]

경로 상승 크롤링

일부 크롤러는 특정 웹 사이트에서 가능한 한 많은 리소스를 다운로드/업로드하려고 합니다. 따라서 각 URL의 모든 경로로 올라가는 경로 상승 크롤러가 도입되었습니다.^[19] 예를 들어 http://llama.org/hamster/monkey/page.html, 의 시드 URL이 주어지면 /hamster/monkey/, /hamster/ 및 /를 크롤링하려고 시도합니다. Cothey는 경로 상승 크롤러가 고립된 리소스 또는 일반 크롤러에서 인바운드 링크가 발견되지 않은 리소스를 찾는 데 매우 효과적이라는 것을 발견했습니다.

포커스 크롤링

크롤러에 대한 페이지의 중요성은 주어진 질의에 대한 페이지의 유사성의 함수로 표현될 수도 있습니다. 서로 유사한 페이지를 다운로드하려는 웹 크롤러를 포커스 크롤러 또는 화제 크롤러라고 합니다. 주제 및 집중 크롤링의 개념은 Filippo Menczer와^[20][21] Soumen Chakrabarti 등에 의해 처음 소개되었습니다.^[22]

포커스 크롤링의 주요 문제는 웹 크롤러의 맥락에서, 우리는 실제로 페이지를 다운로드하기 전에 주어진 페이지의 텍스트와 쿼리의 유사성을 예측할 수 있기를 원한다는 것입니다. 가능한 예측 변수는 링크의 앵커 텍스트입니다. 이것은 웹 초기의 첫 번째 웹 크롤러에서 핑커튼이^[23] 취한 접근 방식입니다. Exciliousi et al.^[24] 에서는 드라이빙 쿼리와 아직 방문하지 않은 페이지 간의 유사성을 추론하기 위해 이미 방문한 페이지의 전체 내용을 사용할 것을 제안합니다. 포커스 크롤링의 성능은 주로 검색되는 특정 주제의 링크의 풍부함에 따라 달라지며, 포커스 크롤링은 일반적으로 시작점을 제공하기 위해 일반적인 웹 검색 엔진에 의존합니다.

학업에 집중한 크롤러

초점을 맞춘 크롤러의 예로는 CiteSeer^X 검색 엔진의 크롤러인 Citeserxbot과 같이 자유롭게 액세스할 수 있는 학술 관련 문서를 크롤러하는 학술 크롤러가 있습니다. 다른 학술 검색 엔진은 Google Scholar와 Microsoft Academic Search 등입니다. 대부분의 학술 논문이 PDF 형식으로 출판되기 때문에 이러한 종류의 크롤러는 특히 크롤링 PDF, 포스트스크립트 파일, 마이크로소프트 워드(ziped format) 등에 관심이 있습니다. 이 때문에 Heritrix와 같은 일반 오픈 소스 크롤러는 다른 MIME 유형을 필터링하도록 사용자 정의되거나 미들웨어를 사용하여 이러한 문서를 추출하여 집중 크롤 데이터베이스 및 저장소로 가져옵니다.^[25] 이러한 문서들이 학술적인지 아닌지를 식별하는 것은 어렵고 크롤링 프로세스에 상당한 오버헤드를 추가할 수 있으므로, 이는 기계 학습 또는 정규 표현 알고리즘을 사용하여 포스트 크롤링 프로세스로 수행됩니다. 이러한 학술 문서는 일반적으로 학부 및 학생의 홈페이지 또는 연구 기관의 출판 페이지에서 가져옵니다. 학술 문서는 모든 웹 페이지의 극히 일부만을 구성하기 때문에 좋은 시드 선택은 이러한 웹 크롤러의 효율성을 높이는 데 중요합니다.^[26] 다른 학술 크롤러는 제목, 논문 및 초록과 같은 학술 논문의 메타데이터를 포함하는 일반 텍스트 및 HTML 파일을 다운로드할 수 있습니다. 이렇게 하면 전체 논문 수가 증가하지만, 상당 부분이 무료 PDF 다운로드를 제공하지 못할 수 있습니다.

의미 집중 크롤러

포커스 크롤러의 또 다른 유형은 시맨틱 포커스 크롤러로, 도메인 온톨로지를 사용하여 주제 맵을 표현하고 웹 페이지를 선택 및 분류 목적으로 관련 온톨로지 개념과 연결합니다.^[27] 또한 온톨로지는 크롤링 과정에서 자동으로 업데이트할 수 있습니다. Dong et al.^[28] 은 이러한 온톨로지 학습 기반 크롤러를 지원 벡터 머신을 이용하여 웹 페이지를 크롤링할 때 온톨로지 개념의 내용을 업데이트하는 방법을 도입하였습니다.

재방문정책

웹은 매우 역동적인 특성을 가지고 있으며 웹의 일부를 기어 다니는 데는 몇 주 또는 몇 달이 걸릴 수 있습니다. 웹 크롤러가 크롤링을 완료할 때까지 생성, 업데이트 및 삭제를 포함한 많은 이벤트가 발생할 수 있습니다.

검색 엔진의 관점에서는 이벤트를 감지하지 못해 리소스의 오래된 복사본을 갖는 것과 관련된 비용이 발생합니다. 가장 많이 사용되는 비용 기능은 신선도와 연령입니다.^[29]

신선도: 로컬 복사본이 정확한지 여부를 나타내는 이진 척도입니다. 시간 t에서 리포지토리에 있는 페이지 p의 새로움은 다음과 같이 정의됩니다.

${\displaystyle F_{p}(t)={\begin{case}1&{\rm {if}}~p~{\rm {is~is~equal~to~local~copy~ at~t}~t\0&{\rm {otherwise}}\end{case}}}$

연령: 로컬 복사본이 얼마나 오래되었는지를 나타내는 척도입니다. 저장소에 있는 페이지 p의 시간 t는 다음과 같이 정의됩니다.

${\displaystyle A_{p}(t)={\begin{case}0&{\rm {if}}~p~{\rm {~is~not~modified~ at~t}~t\t-{\rm {modification~time~of}~p&{\rm {otherwise}\end{case}}}$

Coffman et al. 은 신선도와 동일한 웹 크롤러의 목적에 대한 정의를 가지고 작업했지만 다른 표현을 사용했습니다: 그들은 크롤러가 오래된 시간 페이지의 일부를 최소화해야 한다고 제안합니다. 그들은 또한 웹 크롤링의 문제가 웹 크롤링이 서버이고 웹 사이트가 큐인 다중 큐 단일 서버 폴링 시스템으로 모델링될 수 있다고 언급했습니다. 페이지 수정은 고객의 도착이며 전환 시간은 단일 웹 사이트에 대한 페이지 액세스 간격입니다. 이 모델에서 여론조사 시스템에서 고객의 평균 대기 시간은 웹 크롤러의 평균 연령과 같습니다.^[30]

크롤러의 목적은 해당 컬렉션의 페이지 평균 신선도를 가능한 한 높게 유지하거나 페이지 평균 수명을 가능한 낮게 유지하는 것입니다. 이러한 목표는 동등하지 않습니다. 첫 번째 경우에는 크롤러가 페이지의 수가 오래된 것에 관심을 갖는 반면, 두 번째 경우에는 크롤러가 페이지의 로컬 복사본이 얼마나 오래된 것에 관심을 갖는 것입니다.

Cho와 Garcia-Molina는 두 가지 간단한 재방문 정책을 연구했습니다.^[31]

• 균일한 정책: 여기에는 변경률에 관계없이 동일한 빈도로 컬렉션의 모든 페이지를 다시 방문하는 것이 포함됩니다.
• 비례 정책: 여기에는 더 자주 변경되는 페이지를 더 자주 다시 방문하는 것이 포함됩니다. 방문 빈도는 (추정된) 변화 빈도에 정비례합니다.

두 경우 모두 페이지의 반복적인 크롤링 순서는 랜덤 또는 고정 순서로 수행할 수 있습니다.

Cho와 Garcia-Molina는 평균 신선도 측면에서 균일한 정책이 시뮬레이션된 웹과 실제 웹 크롤 모두에서 비례 정책을 능가한다는 놀라운 결과를 증명했습니다. 직관적으로 웹 크롤러는 주어진 시간 내에 몇 페이지를 크롤링할 수 있는지에 제한이 있기 때문에 (1) 페이지를 덜 업데이트하는 대신 빠르게 변경되는 페이지에 너무 많은 새로운 크롤을 할당할 것이라는 추론이 있습니다. 그리고 (2) 빠르게 변하는 페이지의 신선도는 빈도수가 적은 페이지의 신선도보다 짧은 기간 동안 지속됩니다. 즉, 비례 정책은 자주 업데이트되는 페이지에 더 많은 리소스를 할당하지만 전체적인 새로 고침 시간은 더 적게 발생합니다.

신선도를 높이기 위해 크롤러는 너무 자주 바뀌는 요소에 불이익을 주어야 합니다.^[32] 최적의 재방문 정책은 획일적인 정책도 아니고 비례적인 정책도 아닙니다. 평균 신선도를 높게 유지하기 위한 최적의 방법은 너무 자주 변경되는 페이지를 무시하는 것이며, 평균 연령을 낮게 유지하기 위한 최적의 방법은 각 페이지의 변경 속도에 따라 단조적으로(그리고 하위 선형적으로) 증가하는 액세스 주파수를 사용하는 것입니다. 두 경우 모두 최적은 비례 정책보다는 획일적인 정책에 가깝습니다. Coffman et al. 에서는 "예상되는 노후화 시간을 최소화하기 위해 특정 페이지에 대한 액세스는 가능한 균일한 간격으로 유지되어야 합니다."^[30]라고 언급합니다. 재방문 정책에 대한 명시적 공식은 일반적으로 얻을 수 없지만 페이지 변경 내용의 분포에 따라 수치로 얻을 수 있습니다. Cho와 Garcia-Molina는 지수 분포가 페이지 변화를 설명하는 데 적합하다는 것을 보여주는 반면,^[32] Ipeirotis et al. 에서는 통계 도구를 사용하여 이 분포에 영향을 미치는 매개 변수를 찾는 방법을 보여줍니다.^[33] 여기서 고려되는 재방문 정책은 품질 측면에서 모든 페이지를 동일한 것으로 간주합니다("웹의 모든 페이지는 동일한 가치가 있습니다("Web의 모든 페이지는 동일한 가치가 있습니다"). 따라서 보다 나은 크롤링 정책을 달성하기 위해서는 웹 페이지 품질에 대한 추가 정보가 포함되어야 합니다.

공손정책

크롤러는 인간 검색기보다 훨씬 빠르고 깊이 있게 데이터를 검색할 수 있으므로 사이트의 성능에 심각한 영향을 미칠 수 있습니다. 단일 크롤러가 초당 여러 요청을 수행하거나 대용량 파일을 다운로드하는 경우 서버가 여러 크롤러의 요청을 따라잡는 데 어려움을 겪을 수 있습니다.

Koster가 언급한 바와 같이 웹 크롤러의 사용은 여러 작업에 유용하지만 일반 커뮤니티에는 대가가 수반됩니다.^[34] 웹 크롤러 사용 비용은 다음과 같습니다.

• 크롤러는 상당한 대역폭을 필요로 하고 장시간 동안 높은 수준의 병렬로 동작하기 때문에 네트워크 자원.
• 특히 특정 서버에 대한 액세스 빈도가 너무 높은 경우 서버 과부하
• 잘못 작성된 크롤러, 서버나 라우터를 충돌시킬 수 있는, 또는 그들이 처리할 수 없는 페이지를 다운로드하는 것.
• 너무 많은 사용자에 의해 배포될 경우 네트워크 및 웹 서버에 장애가 발생할 수 있는 개인 크롤러.

이러한 문제에 대한 부분적인 해결책은 로봇이라고도 알려진 로봇 제외 프로토콜입니다.관리자가 웹 서버의 어떤 부분에 크롤러가 액세스해서는 안 된다는 것을 나타내기 위한 표준인 txt 프로토콜입니다.^[35] 이 표준에는 서버 과부하를 방지하는 가장 효과적인 방법이지만 동일한 서버에 대한 방문 간격에 대한 제안은 포함되어 있지 않습니다. 구글, 지브에게 물어봐, MSN 그리고 야후와 같은 최근의 상업적인 검색 엔진들. 검색은 로봇에서 추가적인 "크롤-지연:" 파라미터를 사용할 수 있습니다.요청 사이의 지연 시간(초)을 나타내는 txt 파일입니다.

연속 페이지 로드 사이의 첫 번째 제안 간격은 60초였습니다.^[36] 그러나 지연 시간이 없고 대역폭이 무한대인 완벽한 연결을 통해 10만 페이지 이상의 웹 사이트에서 이 속도로 페이지를 다운로드할 경우 해당 웹 사이트 전체를 다운로드하는 데 2개월 이상이 소요되며, 또한 해당 웹 서버의 리소스 중 일부만 사용됩니다.

Cho는 접속 간격으로 10초를 사용하고 ^[31]WIRE 크롤러는 기본으로 15초를 사용합니다.^[37] Mercator Web crawler는 특정 서버에서 문서를 다운로드하는 데 t초가 걸린 경우, crawler는 다음 페이지를 다운로드하기 전에 10t초 동안 기다립니다.^[38] 딜 등. 1초를 사용합니다.^[39]

연구 목적으로 웹 크롤러를 사용하는 사람들의 경우, 보다 상세한 비용-편익 분석이 필요하며, 기어갈 위치와 속도를 결정할 때 윤리적 고려 사항을 고려해야 합니다.^[40]

액세스 로그의 일화적인 증거에 따르면 알려진 크롤러로부터의 액세스 간격은 20초에서 3-4분 사이로 다양합니다. 매우 정중하고 웹 서버에 과부하가 걸리지 않도록 모든 안전 조치를 취할 때도 웹 서버 관리자로부터 일부 불만이 접수된다는 점에 주목할 필요가 있습니다. 세르게이 브린과 래리 페이지는 1998년에 "50만 대 이상의 서버에 연결되는 크롤러를 실행합니다. 상당한 양의 이메일과 전화를 생성합니다. 사람들이 줄을 서는 일이 너무 많아서, 크롤러가 무엇인지 모르는 사람들이 늘 있습니다. 그들이 처음 본 사람이기 때문입니다."^[41]

병렬화정책

병렬 크롤러는 여러 프로세스를 병렬로 실행하는 크롤러입니다. 병렬화로 인한 오버헤드를 최소화하면서 다운로드 속도를 극대화하고 동일한 페이지를 반복적으로 다운로드하지 않도록 하는 것이 목표입니다. 동일한 페이지를 두 번 이상 다운로드하는 것을 피하기 위해 크롤링 시스템은 크롤링 프로세스 중에 발견된 새로운 URL을 할당하는 정책이 필요합니다. 왜냐하면 동일한 URL은 두 개의 다른 크롤링 프로세스에 의해 발견될 수 있기 때문입니다.

건축물

크롤러는 이전 섹션에서 언급한 대로 우수한 크롤링 전략을 가져야 할 뿐만 아니라 매우 최적화된 아키텍처를 가져야 합니다.

Shkapenuk과 Suel은 다음과 같이 언급했습니다.^[42]

짧은 시간 동안 초당 몇 페이지를 다운로드하는 느린 크롤러를 구축하는 것은 상당히 쉽지만, 몇 주 동안 수억 페이지를 다운로드할 수 있는 고성능 시스템을 구축하면 시스템 설계, I/O 및 네트워크 효율성, 견고성 및 관리성 측면에서 많은 문제가 발생합니다.

웹 크롤러는 검색 엔진의 중심 부분이며 알고리즘과 아키텍처에 대한 세부 사항은 비즈니스 비밀로 유지됩니다. 크롤러 디자인이 출판될 때, 종종 다른 사람들이 작품을 재현하지 못하게 하는 중요한 세부 사항이 부족합니다. 주요 검색엔진이 순위 알고리즘을 게시하지 못하게 하는 '검색엔진 스팸'에 대한 우려도 나오고 있습니다.

보안.

대부분의 웹 사이트 소유자들은 검색 엔진에서 강력한 존재감을 갖기 위해 페이지를 가능한 한 넓게 인덱싱하기를 열망하지만, 웹 크롤링은 또한 의도하지 않은 결과를 초래할 수 있으며, 검색 엔진이 공개적으로 사용할 수 없는 리소스를 인덱싱할 경우 손상 또는 데이터 유출로 이어질 수 있습니다. 또는 잠재적으로 취약한 버전의 소프트웨어를 보여주는 페이지입니다.

웹 사이트 소유자는 표준 웹 애플리케이션 보안 권장 사항 외에도 검색 엔진만 웹 사이트의 공용 부분(로봇을 사용하여)을 색인화하여 기회주의적 해킹에 대한 노출을 줄일 수 있습니다.txt) 및 명시적으로 트랜잭션 부분(login 페이지, 개인 페이지 등)을 인덱싱하지 못하도록 차단합니다.

크롤러식별

웹 크롤러는 일반적으로 HTTP 요청의 User-agent 필드를 사용하여 웹 서버를 식별합니다. 웹 사이트 관리자는 일반적으로 웹 서버의 로그를 검사하고 사용자 에이전트 필드를 사용하여 어떤 크롤러가 웹 서버를 방문했는지, 얼마나 자주 방문했는지 확인합니다. 사용자 에이전트 필드는 웹 사이트 관리자가 크롤러에 대한 더 많은 정보를 알아낼 수 있는 URL을 포함할 수 있습니다. 웹 서버 로그를 검사하는 것은 지루한 작업이므로 일부 관리자는 도구를 사용하여 웹 크롤러를 식별, 추적 및 확인합니다. 스팸봇 및 기타 악성 웹 크롤러는 식별 정보를 사용자 에이전트 필드에 배치하지 않거나 브라우저 또는 기타 잘 알려진 크롤러로 식별 정보를 마스킹할 수 있습니다.

웹 사이트 관리자는 필요한 경우 소유자에게 연락할 수 있도록 자신을 식별하는 웹 크롤러를 선호합니다. 경우에 따라 크롤러가 실수로 크롤러 트랩에 갇히거나 웹 서버에 요청이 오버로드되어 소유자가 크롤러를 중지해야 합니다. 식별은 웹 페이지가 특정 검색 엔진에 의해 인덱싱될 것으로 예상할 수 있는 시기를 알고자 하는 관리자에게도 유용합니다.

깊은 거미줄을 기어가기

방대한 양의 웹 페이지가 깊거나 보이지 않는 웹에 놓여 있습니다.^[43] 이러한 페이지는 일반적으로 데이터베이스에 쿼리를 제출해야만 액세스할 수 있으며, 일반 크롤러는 해당 페이지를 가리키는 링크가 없을 경우 이러한 페이지를 찾을 수 없습니다. 구글의 사이트맵 프로토콜과 modoai는^[44] 이러한 심층 웹 리소스를 검색할 수 있도록 하기 위한 것입니다.

딥 웹 크롤링은 또한 크롤링할 웹 링크의 수를 곱합니다. 일부 크롤러는 URL의 일부만 가져갑니다. <a href="URL"> 양식. 구글봇과 같은 경우에는 하이퍼텍스트 내용, 태그 또는 텍스트 안에 포함된 모든 텍스트에 대해 웹 크롤링을 수행합니다.

딥 웹 콘텐츠를 목표로 하는 전략적 접근 방식을 취할 수 있습니다. 스크린 스크래핑이라는 기술을 사용하면 결과 데이터를 집계하려는 의도로 특정 웹 양식에 자동으로 반복적으로 쿼리하도록 특수화된 소프트웨어를 사용자 정의할 수 있습니다. 이러한 소프트웨어는 여러 웹 사이트에 걸쳐 여러 웹 양식을 확장하는 데 사용할 수 있습니다. 하나의 웹 양식 제출 결과에서 추출된 데이터를 다른 웹 양식에 입력으로 받아 적용할 수 있으므로 기존의 웹 크롤러에서는 불가능한 방식으로 딥 웹 전반에 걸쳐 연속성을 확립할 수 있습니다.^[45]

AJAX에 구축된 페이지는 웹 크롤러에 문제를 일으키는 페이지 중 하나입니다. 구글은 로봇이 인식하고 색인할 수 있는 AJAX 호출 형식을 제안했습니다.^[46]

시각적 크롤러 대 프로그래밍 크롤러

웹에서 사용할 수 있는 "비주얼 웹 스크레이퍼/크롤러" 제품은 사용자 요구사항에 따라 페이지를 크롤링하고 데이터를 열과 행으로 구성합니다. 클래식 크롤러와 비주얼 크롤러의 주요 차이점 중 하나는 크롤러를 설정하는 데 필요한 프로그래밍 능력의 수준입니다. 최신 세대의 "비주얼 스크레이퍼"는 웹 데이터를 스크랩하기 위해 크롤을 프로그래밍하고 시작하는 데 필요한 프로그래밍 기술의 대부분을 제거합니다.

시각적 스크래핑/크롤링 방법은 사용자가 크롤러 기술을 "가르쳐" 다음 반구조화된 데이터 소스의 패턴을 따르는 것에 의존합니다. 시각적 크롤러를 가르치는 주된 방법은 브라우저에서 데이터를 강조하고 열과 행을 훈련하는 것입니다. 이 기술은 새로운 것은 아니지만, 예를 들어 Google이 구매한 Needbase의 기반이 되었습니다. (ITA^[47] Labs의 대규모 인수의 일부로) 투자자와 최종 사용자에 의해 이 분야에 대한 지속적인 성장과 투자가 이루어지고 있습니다.^{[citation needed]}

웹 크롤러 목록

다음은 범용 크롤러(집중형 웹 크롤러 제외)를 위한 공개된 크롤러 아키텍처 목록이며, 다양한 구성 요소와 뛰어난 기능에 대한 이름이 포함되어 있습니다.

기록 웹 크롤러

• 월드 와이드 웹 웜은 문서 제목과 URL의 간단한 인덱스를 만드는 데 사용되는 크롤러였습니다. 인덱스는 유닉스 명령어를 사용하여 검색할 수 있습니다.
• Yahoo! Slurp은 Yahoo의 이름이었습니다! 야후가 대신 빙봇을 사용하기로 마이크로소프트와 계약할 때까지 검색 크롤러.

사내 웹 크롤러

• 애플봇은 애플의 웹 크롤러입니다. 시리 및 기타 제품을 지원합니다.^[48]
• 빙봇은 마이크로소프트의 빙 웹크롤러의 이름입니다. Msnbot을 대체했습니다.
• Baiduspider는 Baidu의 웹 크롤러입니다.
• 덕덕봇은 덕덕고의 거미줄 크롤러입니다.
• Googlebot에 대해서는 자세히 설명되어 있지만, 참고문헌은 C++와 Python으로 작성된 아키텍처의 초기 버전에 관한 것일 뿐입니다. 크롤러는 전체 텍스트 인덱싱 및 URL 추출을 위해 텍스트 구문 분석이 수행되었기 때문에 인덱싱 프로세스와 통합되었습니다. 여러 크롤링 프로세스에서 가져올 URL 목록을 전송하는 URL 서버가 있습니다. 구문 분석하는 동안 발견된 URL은 이전에 URL이 표시되었는지 확인하는 URL 서버로 전달되었습니다. 그렇지 않은 경우 URL 서버의 큐에 URL이 추가되었습니다.
• WebCrawler는 웹의 하위 집합 중 최초로 공개적으로 사용 가능한 전체 텍스트 인덱스를 구축하는 데 사용되었습니다. lib-WWWW를 기반으로 페이지를 다운로드하고 웹 그래프의 너비 우선 탐색을 위해 URL을 구문 분석하고 주문하는 다른 프로그램을 기반으로 했습니다. 또한 제공된 쿼리와 앵커 텍스트의 유사성을 기반으로 링크를 따르는 실시간 크롤러도 포함되었습니다.
• WebFountain은 Mercator와 유사하지만 C++로 작성된 분산형 모듈식 크롤러입니다.
• 제논은 정부 세무 당국이 사기를 탐지하기 위해 사용하는 웹 크롤러입니다.^[49][50]

상업용 웹 크롤러

다음 웹 크롤러는 가격에 제공됩니다.

• Diffbot - 프로그래밍 일반 웹 크롤러, API로 이용 가능
• SortSite - Windows 및 Mac OS에서 사용 가능한 웹 사이트 분석용 크롤러
• Swiftbot - Swiftype의 웹 크롤러, 서비스형 소프트웨어로 이용 가능

오픈소스 크롤러

• Apache Nutch는 Java로 작성되고 Apache License로 출시된 확장성이 뛰어난 웹 크롤러입니다. Apache Hadoop을 기반으로 하며 Apache Solr 또는 Elasticsearch와 함께 사용할 수 있습니다.
• GRUB은 Wikia Search가 웹을 기어 다닐 때 사용했던 오픈 소스 분산 검색 크롤러였습니다.
• Heritrix는 웹의 상당 부분에 대한 주기적인 스냅샷을 보관할 수 있도록 설계된 Internet Archive의 아카이브 품질 크롤러입니다. 자바로 쓰여 있었습니다.
• ht://Dig의 인덱싱 엔진에 웹 크롤러가 포함되어 있습니다.
• HTTtrack은 웹 크롤러를 사용하여 오프라인에서 볼 수 있도록 웹 사이트의 거울을 만듭니다. C로 작성되어 GPL로 출시됩니다.
• 노르코넥스 웹 크롤러(Norconex Web Crawler)는 자바로 작성되어 아파치 라이선스로 출시된 확장성이 뛰어난 웹 크롤러입니다. Apache Solr, Elasticsearch, Microsoft Azure Cognitive Search, Amazon CloudSearch 등 많은 리포지토리와 함께 사용할 수 있습니다.
• mnoGoSearch는 C로 작성되고 GPL에 따라 라이센스가 부여된 크롤러, 인덱싱 및 검색 엔진입니다(*NIX 머신만 해당).
• 오픈 서치 서버(Open Search Server)는 GPL 하에 있는 검색 엔진이자 웹 크롤러 소프트웨어 릴리스입니다.
• Python으로 작성된 오픈 소스 웹크롤러 프레임워크인 Scrapy(BSD에 라이선스됨).
• 무료 분산 검색 엔진(AGPL에 따라 라이센스가 부여됨)을 찾습니다.
• Apache License(Apache License)에서 지연 시간이 적고 확장 가능한 웹 크롤러를 구축하기 위한 리소스 모음인 StormCrawler.
• tkWWW 웹 브라우저 기반 크롤러인 tkWW 로봇(GPL에 따라 라이선스됨).
• GNU Wget은 C로 작성되어 GPL로 출시된 명령줄 운영 크롤러입니다. 일반적으로 웹 및 FTP 사이트를 미러링하는 데 사용됩니다.
• 검색 크롤러 엔진인 Xapian은 c++로 작성되었습니다.
• 무료 분산 검색 엔진인 YaCy는 피어 투 피어 네트워크(GPL에 따라 라이선스됨)의 원칙을 기반으로 구축되었습니다.

참고 항목

• 자동 색인화
• 누텔라 크롤러
• 웹 아카이빙
• 웹그래프
• 웹사이트 미러링 소프트웨어
• 검색 엔진 스크래핑
• 웹 스크래핑

참고문헌

더보기

• 조중후, UCLA 컴퓨터 과학부 "웹 크롤링 프로젝트"
• Wiley에서 본 검색 엔진의 역사
• WIVET는 웹 크롤러가 대상 웹사이트의 모든 하이퍼링크를 식별할 수 있는지 측정하는 것을 목표로 하는 OWASP의 벤치마킹 프로젝트입니다.
• Shestakov, Denis, "Current Challenges in Web Crowling" 및 "Intelligent Web Crowling"은 ICWE'13 및 WI-IAT'13에서 제공되는 튜토리얼용 슬라이드입니다.