9장 웹 로봇

웹 로봇은 사람과의 상호작용 없이 연속된 웹 트랜잭션들을 자동으로 수행하는 소프트웨어 프로그램이다.

9.1 크롤러와 크롤링

• 웹 크롤러는 먼저 웹페이지를 한 개 가져오고, 그 다음 페이지가 가리키는 모든 페이지를 가져오는 재귀적 방식의 웹 순회 로봇이다.
• 재귀적으로 따라가기 때문에 크롤러 혹은 스파이더라고 불린다.
• 인터넷 검색엔진은 모든 문서를 끌어서 검색 가능한 데이터베이스로 저장하기 위해 크롤러를 사용한다.

9.1.1 어디에서 시작하는가: '루트 집합'

• 크롤러에게 출발지점이 주어져야 하는데, 크롤러가 방문을 시작하는 URL들의 초기 집합은 루트 집합 이라고 불린다.
• 웹의 대부분을 커버하기 위해 루트 집합에 너무 많은 페이지가 있을 필요는 없다.
• 일반적으로 좋은 루트 집합은 크고 인기 있는 웹사이트, 새로 생성된 페이지들의 목록, 자주 링크되지 않는 페이지들의 목록으로 구성되어 있다.

9.1.2 링크 추출과 상대 링크 정상화

• 크롤러는 웹을 돌아다니면서 꾸준히 HTML 문서를 검색한다.
• 이들은 간단한 HTML 파싱을 해서 이들 링크를 추출하고 상대 링크를 절대 링크로 변환할 필요가 있다.

9.1.3 순환 피하기

• 로봇들은 순환을 피하기 위해 반드시 그들이 어디를 방문했는지 기억해야 한다.

9.1.4 루프와 중복

순환은 최소한 다음 세 가지 이유로 크롤러에게 해롭다.

• 순환은 크롤러를 루프에 빠뜨려서 크롤러가 네트워크 대역폭을 다 차지하고 어떤 페이지도 가져오지 못하게 할 수 있다.
• 크롤러의 네트워크 접근 속도가 매우 빠르다고 가정했을 때, 같은 페이지를 반복해서 가져오면 이 부담이 웹 서버에 가해져 실제 사용자가 사이트에 접근하지 못하도록 막을 수 있다.
• 크롤러는 많은 수의 중복된 페이지들을 가져오게 되고, 크롤러의 애플리케이션은 쓸모없는 중복된 콘텐츠로 넘쳐나게 된다.

9.1.5 빵 부스러기의 흔적

• 어떤 URL을 방문했는지 빠르게 판단하기 위해서는 속도와 메모리 사용면에서 효과적인 자료구조를 사용해야 한다.
• 빠른 속도를 위해서는 검색 트리나 해시테이블이 필요하다.
• 수억개의 URL 을 저장하기 위해 20GB 이상의 메모리가 요구된다. (URL 당 40 byte * 5억 URL)

느슨한 존재 비트맵

• 공간 사용을 최소화하기 위해 존재 비트 배열과 같은 느슨한 자료 구조를 사용한다.
• 각 URL은 해시 함수에 의해 고정된 크기의 숫자로 변환되고, 배열 안 존재 비트를 갖는다.
• 만약 존재 비트가 존재한다면, 크롤러는 이 URL 을 이미 크롤링되었다고 간주한다.

체크 포인트

• 로봇 프로그램이 갑자기 중단될 경우를 대비하여, 방문한 URL의 목록이 디스크에 저장되었는지 확인한다.

파티셔닝

• 한 대의 컴퓨터에서 하나의 로봇이 크롤링을 완수 할 수 없다.
• 몇몇 대규모 로봇은 각각이 분리된 한 대의 컴퓨터인 로봇들이 동시에 일하는 농장을 이용하며, 이들은 서로 도와 웹을 크롤링한다.

9.1.6 별칭과 로봇 순환

	첫 번째 URL	두 번째 URL	어떤 경우에 같은 URL을 가리키게 되는가
a	http://www.foo.com/bar.html	http://www.foo.com:80/bar.html	기본 포트가 80번일 때
b	http://www.foo.com/~fred	http://www.foo.com/%7Ffred	%7F와 ~가 같을 때
c	http://www.foo.com/x.html#early	http://www.foo.com/x.html#middle	태그에 따라 페이지가 바뀌지 않을 때
d	http://www.foo.com/readme.html	http://www.foo.com/README.HTML	서버가 대소문자를 구분하지 않을 때
e	http://www.foo.com/	http://www.foo.com/index.html	기본 페이지가 index.html일 때
f	http://www.foo.com/index.html	http://209.231.87.45/readme.html	www.foo.com이 이 IP주소를 가질 때

9.1.7 URL 정규화하기

대부분의 웹 로봇은 URL을 표준 형식으로 정규화함으로써 다른 URL 과 같은 리소스를 가리키고 있음이 확실한 것을 미리 제거한다.

1. 포트 번호가 명시되지 않았다면, 호스트명에 :80을 추가한다.
2. 모든 %xx 이스케이핑된 문자들은 대응되는 문자로 변환한다.

3. 태그들을 제거한다.

9.1.6에서 각 웹서버 지식이 없다면 로봇이 d,e,f 같은 중복을 피할 좋은 방법이 없다.

9.1.8 파일 시스템 링크 순환

• 파일 시스템의 심벌릭 링크는 끝없이 깊어지는 디렉터리 계층을 만들 수 있어서 교묘한 종류의 순환을 유발할 수 있다.
• 예를 들어 파일 /index.html 이 파일 /subdir/index.html을 가리키는 하이퍼링크를 담고 있고, /subdir 은 /을 가리키는 심벌릭 링크라고 하였을 때 아래와 같은 상황이 이루어진다.
  1. /index.html 을 가져와서 subdir/index.html로 이어지는 링크를 발견한다.
  2. subdir/index.html 을 가져왔지만 index.html로 되돌아간다.
  3. subdir/subdir/index.html 을 가져온다.
  4. subdir/subdir/subdir/index.html
• 위처럼 순환이 반복되지만 URL 이 달라보여서 로봇은 URL 만으로는 문서가 같다는 것을 모른다.

9.1.9 동적 가상 웹 공간

• 악의적인 웹 마스터들이 로봇들을 함정으로 빠뜨리기 위해 의도적으로 복잡한 크롤러 루프를 만들 수 있다.

9.1.10 루프와 중복 피하기

• 모든 순환을 피하는 완벽한 방법은 없다. 일부는 의심스러워보이지만 유효한 콘텐츠를 걸러버리게 되는 일도 일어날 수 있기 때문이다.

URL 정규화

• URL을 표준형태로 변환함으로써 같은 리소스를 가리키는 중복된 URL이 생기는 것을 일부 회피한다.

너비 우선 크롤링

• 너비 우선 스케줄링으로 순환 함정을 건드려도, 순환 페이지를 받아오기 전 다른 웹사이트 들에서 수십만개의 페이지를 받아올 수 있다.

스로틀링

• 일정 시간 동안 가져올 수 있는 페이지 숫자를 제한한다.
• 그 서버에 대한 접근 횟수와 중복의 총 횟수를 제한할 수 있다.

URL 크기 제한

• 일정 길이(1KB)를 넘는 URL의 크롤링은 거부할 수 있다.
• 주의해야할 점은 가져오지 못하는 콘텐츠가 반드시 존재한다.
• 이 기법은 요청 URL 이 특정 크기에 도달할 때마다 에러 로그를 남김으로써 특정 사이트에서 어떤 일이 벌어지는지 감시하는 사용자에게는 훌륭한 신호가 될 수 있다.

URL/사이트 블랙리스트

• 로봇 순환을 만들거나 함정인 것으로 알려진 사이트나 URL 목록을 관리하고 블랙리스트에 추가한다.

패턴 발견

• 파일 시스템/심벌릭 링크를 통한 순환과 비슷한 오설정들은 일정 패턴을 따르는 경향이 있다.
• 단, 패턴 주기가 2 이상인 반복이 있을 수 있으므로 몇 가지 다른 주기의 반복 패턴을 감지해야 한다.

콘텐츠 지문

• 콘텐츠에서 몇 바이트 얻어내 체크섬을 계산한다.
• 이전에 보았던 체크섬을 가진 페이지가 온다면, 그 페이지 링크는 크롤링하지 않는다.

9.2 로봇의 HTTP

9.2.1 요청 헤더 식별하기

• 로봇들은 신원 식별 헤더를 구현하고 전송한다.

  User-Agent

  서버에게 요청을 만든 로봇 이름을 말해준다.

From

로봇의 사용자/관리자의 이메일 주소를 제공한다.

Accept

서버에게 어떤 미디어 타입을 보내도 되는지 말해준다. 이 헤더는 로봇이 관심 있는 유형의 콘텐츠만 받게 될 것임을 확신하는데 도움을 준다.

Referer

현재의 요청 URL을 포함한 문서의 URL을 제공한다.

9.2.2 가상 호스팅

• 로봇 구현자들은 Host 헤더를 지원할 필요가 있다.
• 요청에 Host 헤더를 포함하지 않으면 로봇이 어떤 URL에 대해 잘못된 콘텐츠를 찾게 만든다.(ex. 서버가 두 사이트 운영할 경우)

9.2.3 조건부 요청

• 로봇이 검색하는 콘텐츠 양을 최소화하는 것은 상당히 의미있는 일이다.
• 몇몇 로봇은 시간이나 엔터티 태그를 비교함으로써 마지막 버전 이후 업데이트 된 것이 있을 때 알아보는 조건부 HTTP 요청을 구현한다.

9.2.4 응답 다루기

상태 코드

• 200OK 혹은 404 Not Found 와 같은 상태코드를 이해한다.

9.2.5 User-Agent 타기팅

• 많은 웹 사이트들은 그들의 여러 기능을 지원할 수 있도록 브라우저의 종류를 감지하여 그에 맞게 콘텐츠를 최적화해야한다.

9.3 부적절하게 동작하는 로봇들

폭주하는 로봇들

• 논리적 에러를 갖거나 순환에 빠졌다면 극심한 부하를 안겨주고, 다른 사용자가 서비스를 못하게 만든다.

오래된 URL

• 존재하지 않는 URL 로 요청을 많이 보낼 수 있다.
• 에러 페이지를 제공하는 부하로 인해 웹 서버의 요청에 대한 수용 능력이 감소된다.

길고 잘못된 URL

• 순환이나 프로그래밍 상 오류로 인해 로봇은 웹 사이트에게 크고 의미 없는 URL 을 전달할 수 있다.
• 웹 서버 접근 로그를 어지럽게 채운다.

호기심이 지나친 로봇

• 사적인 데이터에 대한 URL을 얻어 그 데이터를 인터넷 검색 엔진이나 기타 애플리케이션을 통해 쉽게 접근할 수 있도록 만들 수 있다.

동적 게이트웨이 접근

• 로봇은 게이트웨이 애플리케이션의 콘텐츠에 대한 URL로 요청할 수도 있다.

9.4 로봇 차단하기

9.4.1 로봇 차단 표준

• 로봇 차단 표준은 임시방편으로 마련된 표준이다.
• 로봇 차단 표준에는 버전 이름이 잘 정의되어 있지 않지만, 세 가지 버전이 존재한다.

  버전	이름과 설명	날짜
  0.0	로봇 배제 표준-Disallow 지시자를 지원하는 마틴 코스터의 오리지널 robots.txt 메커니즘	1994.06
  1.0	웹 로봇 제어 방법-Allow 지시자의 지원이 추가된 마틴 코스터의 IETF 초안	1996.11
  2.0	로봇 차단을 위한 확장 표준-정규식과 타이밍 정보를 포함한 숀 코너의 확장.	1996.11

9.4.2 웹 사이트와 robots.txt 파일들

robots.txt 가져오기

• 어떤 URL 방문 전, 그 웹사이트에 robots.txt 파일이 존재하면 로봇은 반드시 그 파일을 가져와서 처리해야 한다.
• 서버가 robots.txt 가 존재하면 그 파일을 text/plain 본문으로 반환한다.
• 서버가 404 NotFound 상태 코드로 응답한다면 로봇 접근을 제한하지 않는 것으로 간주하고 어떤 파일이든 요청한다.

응답 코드

• 서버가 2xx 코드를 응답하면 로봇은 콘텐츠를 파싱하여 차단 규칙을 얻고, 무언가 가져올 때도 규칙에 따른다.
• 404 면 제약이 없다고 가정한다.
• 401 또는 403 이라면 로봇은 그 사이트 접근이 완전히 제한되었다고 가정한다.
• 503 이라면 그 사이트 리소스 검색을 뒤로 미룬다.
• 3xx 라면 리소스가 발견될 때까지 리다이렉트를 따라간다.

9.4.3 robots.txt 파일 포맷

• 매우 단순한 줄 기반 문법을 갖는다.
• 규칙 줄은 HTTP 헤더처럼 생겼고, 패턴 매칭을 위해 사용된다.
• 이 줄들은 레코드로 구분되며, 레코드는 규칙 줄들의 집합으로 되어있다.
• 레코드는 User-Agent 로 시작하며 로봇들이 접근할 수 있는 URL을 말해주는 Allow 줄과 Disallow 줄이 온다.

User-Agent 줄

• robots.txt 파일을 처리하여 자신의 이름에 대응하는 User-Agent 줄을 찾거나 User-Agent: * 줄을 찾아 규칙을 준수한다.
• 대응하는 레코드가 없다면 어떤 접근 제한도 없다.

Disallow/Allow 줄들

• 요청하려고 하는 URL을 차단 레코드의 모든 Disallow와 Allow 규칙에 순서대로 맞춰 보아야하고, 첫 번째로 맞은 것이 사용된다.
• 만약 어떤 것도 맞지 않으면, 그 URL은 허용된다.

Disallow/Allow 접두 매칭

• Disallow나 Allow 규칙이 어떤 경로에 적용되려면, 그 경로의 시작부터 규칙 경로의 길이만큼의 문자열이 규칙 경로와 같아야 한다.(대소문자 차이도 없어야 한다.)
• 규칙 경로나 URL 경로의 이스케이핑된 문자들(%XX)은 비교 전에 원래대로 복원된다.
• 빗금의 %2F는 예외로, 반드시 그대로 매칭된다.
• 만약 어떤 규칙 경로가 빈 문자열이라면, 그 규칙은 모든 URL 경로와 매치된다.

9.4.4 그 외 알아둘 점

• robots.txt. 파일에서 로봇은 자신이 이해하지 못하는 필드는 무시한다.
• 하위 호환성을 위해, 한 줄을 여러 줄로 나누어 적는 것은 허용되지 않는다.
• 주석은 파일의 어디에서든 허용된다.

9.4.5 robots.txt 캐싱과 만료

• 매 파일 접근마다 robots.txt 파일을 새로 가져오는 것이 아니라, 주기적으로 파일을 가져와서 결과를 캐시해야 한다.
• robots.txt 파일의 캐싱을 제어하기 위해 표준 HTTP 캐시 제어 매커니즘이 원 서버와 로봇 양쪽 모두에 의해 사용된다.
• 로봇은 HTTP 응답의 Cache-Control, Expires 헤더에 주의를 기울인다.

9.4.7 HTML 로봇제어 META 태그

• robots.txt 파일 단점 중 하나는 그 파일을 콘텐츠의 작성자 개개인이 아닌 웹 사이트 관리자가 소유한다는 것이다.
• HTML 페이지 저자는 문서에 직접 로봇 제어 태그를 추가하여 로봇의 접근 제어를 직접적으로 관리할 수 있다.
• 로봇 제어 HTML 태그에 따르는 로봇들은 여전히 문서를 가져올 순 있지만, 로봇 차단 태그가 존재하면 그들은 그 문서를 무시한다.

로봇 META 지시자

1. NOINDEX: 로봇에게 이 페이지를 처리하지 말고 무시하라고 한다.
2. NOFOLLOW: 로봇에게 이 페이지가 링크한 페이지를 크롤링하지 말라고 말해준다.
3. INDEX: 로봇에게 이 페이지의 콘텐츠를 인덱싱해도 된다고 말해준다.
   (생략)

검색엔진 META 태그

• 모든 로봇 META 태그는 name="robots" 속성을 포함한다.
• 표준 META 데이터 이름

9.5 로봇 에티켓

Guideline for Robot Writers

9.6 검색 엔진

9.6.1 넓게 생각하라

• 검색엔진은 수십억개의 웹페이지들을 검색하기 위해 복잡한 크롤러를 사용해야 한다.
• 검색 색인이 필요로 하는 페이지들을 검색하기 위해 수십억 개의 HTTP 질의를 생성하는 상용 웹 크롤러를 생각하면 대략 5,700일이 걸린다.
• 따라서 많은 장비를 사용해서 병렬로 수행해야 한다.

9.6.2 현대적인 검색엔진의 아키텍처

• 풀 텍스트 색인 이라고 하는 복잡한 로컬 데이터 베이스를 오늘날 검색엔진들은 생성한다.
• 검색엔진 크롤러들은 웹페이지들을 수집하여 이 풀 텍스트 색인에 추가한다.

9.6.3 풀 텍스트 색인

• 풀 텍스트 색인은 단어 하나를 입력받아서 그 단어를 포함하고 있는 문서를 즉각 알려줄 수 있는 데이터베이스이다.

9.6.4 질의 보내기

• 사용자가 질의를 웹 검색엔진 게이트웨이로 보내는 방법은 HTML 폼을 사용자가 채워넣고 브라우저가 그 폼을 GET 이나 POST 로 HTTP 요청을 이용해서 게이트웨이에 보내는 식이다.
• 게이트웨이 프로그램은 검색 질의를 추출하고 웹 UI 질의를 풀 텍스트 색인 시 사용되는 표현으로 변환한다.
• 게이트 웨이는 웹 서버에게 문서의 결과를 알려주고, 웹 서버는 사용자를 위한 HTML 페이지로 변환한다.

9.6.5 검색 결과를 정렬하고 보여주기

• 질의 결과를 확인하기 위해 검색 엔진이 색인을 한번 사용했다면, 게이트웨이 애플리케이션은 그 결과를 이용해 최종 사용자를 위한 결과 페이지를 즉석에서 만들어낸다.
• 검색엔진은 문서들이 주어진 단어와 가장 관련이 많은 순서대로 문서에 나타낼 수 있도록 문서들 간 순서를 알 필요가 있다.

9.6.6 스푸핑

• 검색 결과에서 더 높은 순위를 차지하고자 하는 바람으로 자신의 사이트를 눈에 띄게 할 방법을 찾고 있는 사람들이 수많은 키워드들을 나열한 가짜 페이지를 만들거나, 검색 엔진 관련도 알고리즘을 잘 속일 수 있는 가짜 페이지를 생성하는 게이트웨이 어플리케이션을 만들어 사용한다.