[HTTP 완벽가이드] 09. 웹 로봇

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

많은 로봇이 웹 사이트에서 다른 웹 사이트로 떠돌아다니면서, 콘텐츠를 가져오고, 하이퍼링크를 따라가고, 그들이 발견한 데이터를 처리한다. 이러한 종류의 로봇들은 그들의 동작 방식에 따라 '크롤러', '스파이더', '웜', '봇' 등 다양한 이름으로 불린다.

크롤러와 크롤링

웹 크롤러는 웹 페이지를 한 개 가져오고, 그 다음 페이지가 가리키는 모든 웹 페이지를 가져오는 일을 재귀적으로 반복하는 방식으로 웹을 순회하는 로봇이다. 이러한 로봇을 크롤러라고 부른다. HTML 하이퍼링크들로 만들어진 웹을 따라 '기어다니기(crawl)' 때문이다.

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

크롤링을 시작하기 전, 크롤러에게 출발지점을 주어야 한다. 크롤러가 방문을 시작하는 URL의 초기 집합을 '루트 집합'이라고 부른다.

루트 집합을 고를 때, 모든 링크를 크롤링하면 결과적으로 관심 있는 웹페이지들의 대부분을 가져오게 될 수 있도록 충분히 다른 장소에서 URL들을 선택해야 한다.

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

크롤러는 웹을 돌아다니면서 꾸준히 HTML 문서를 검색한다. 크롤러는 검색한 각 페이지 안에 들어있는 URL 링크들을 파싱해서 크롤링할 페이지들의 목록에 추가해야 한다.

크롤러들은 간단한 HTML 파싱을 해서 이들 링크들을 추출하고, 상대 링크를 절대 링크로 변환할 필요가 있다.

순환 피하기

로봇이 웹을 크롤링할 때, 루프에 빠지지 않도록 조심해야 한다.

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

루프와 중복

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

순환은 크롤러를 루프에 빠뜨려서 꼼짝 못하게 만들 수 있다. 루프에 빠진 크롤러가 네트워크 대역폭을 다 차지하고 그 어떤 페이지도 가져올 수 없게 되어버릴 수 있다.
크롤러가 같은 페이지를 반복해서 가져오는 것은 웹 서버에 부담이 될 수 있다.
루프 자체가 문제가 되지 않더라도, 크롤러는 많은 수의 중복된 페이지들을 가져오게 되어 크롤러의 애플리케이션은 자신을 쓸모 없게 만드는 중복된 콘텐츠로 넘쳐나게 될 것이다.

빵 부스러기의 흔적

전 세계의 웹 콘텐츠는 매우 방대하기 때문에, 방문한 곳을 지속적으로 추적하기 위해서는 복잡한 자료구조를 사용해야 한다. 이 자료구조는 속도와 메모리 사용 면에서 효과적이어야 한다.

대규모 웹 크롤러가 그들이 방문한 곳을 관리하기 위해 사용하는 유용한 기법들은 다음과 같다.

트리와 해시 테이블
복잡한 로봇이라면 방문한 URL을 추적하기 위해 검색 트리나 해시 테이블을 사용했을 수 있다.
이들은 URL을 훨씬 빠르게 찾아볼 수 있게 해주는 자료구조다.
느슨한 존재 비트맵
공간 사용을 최소하하기 위해, 몇몇 대규모 크롤러들은 존재 비트 배열과 같은 느슨한 자료구조를 사용한다.
각 URL은 해시 함수에 의해 고정된 크기의 숫자로 변환되고, 배열 안에 대응하는 '존재 비트'를 갖는다.
URL이 크롤링 되었을 때, 해당 하는 존재 비트가 만들어진다. 만약 존재 비트가 이미 존재한다면, 크롤러는 그 URL을 이미 크롤링되었다고 간주한다. (물론 존재비트는 유한하기 때문에, 충돌이 발생할 위험이 존재한다)
체크포인트
로봇 프로그램이 갑작스럽게 중단될 경우를 대비해, 방문한 URL의 목록이 디스크에 저장되었는지 확인한다.
파티셔닝
웹이 성장하면서, 한 대의 컴퓨터에서 하나의 로봇이 크롤링을 완수하는 것은 불가능해졌다. 크롤링을 완수하기엔 한 대의 컴퓨터로는 메모리, 디스크 공간, 연산 능력, 네트워크 대역폭이 충분하지 못할 수 있다.
몇몇 대규모 웹 로봇은 각각이 분리된 한 대의 컴퓨터인 로봇들이 동시에 일하고 있는 농장을 이용한다.

별칭(alias)과 로봇 순환

올바른 자료구조를 갖추었더라도 URL이 별칭을 가질 수 있다면, 두 URL이 달라보이더라도 같은 리소스를 가리킬 수 있다.

다음은 같은 문서를 가리키는 다른 URL들에 대한 예시이다.

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

URL 정규화하기

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

로봇은 다음과 같은 방식으로 모든 URL을 정규화된 형식으로 변환할 수 있다.

포트 번호가 명시되지 않은 경우, 호스트명에 :80을 추가한다.
모든 %xx 이스케이핑된 문자들을 대응되는 문자로 변환한다.
# 태그들을 제거한다.

URL 정규화는 기본적인 문법의 별칭들만 제거할 수 있다.

파일 시스템 링크 순환

파일 시스템의 심벌릭 링크는 아무것도 존재하지 않으면서 끝없이 깊어지는 디렉터리 계층을 만들 수 있으므로, 매우 교묘한 종류의 순환을 유발할 수 있다.

심벌릭 링크 순환은 서버 관리자가 실수로 만들게 되는 것이 보통이지만, 때때로 누군가가 로봇을 함정에 빠뜨리기 위해 악의적으로 만들기도 한다.

a에서 subdir은 보통의 디렉터리이다.
b에서 subdir는 /을 가리키는 심벌릭 링크다.
두 경우 모두 /index.html 파일은 subdir/index.html을 가리키는 하이퍼링크를 담고 있다.

두 경우에서 웹 크롤러의 동작을 살펴보도록 하자.

a의 상황에서 크롤러의 동작

GET http://www.foo.com/index.html
/index.html을 가져와서, subdir/index.html로 이어지는 링크를 발견한다.
GET http://www.foo.com/subdir/index.html
subdir/index.html을 가져와서, subdir/logo.gif로 이어지는 링크를 발견한다.
GET http://www.foo.com/subdir/logo.gif
subdir/logo.gif를 가져오고, 더 이상 링크가 없으므로 여기서 완료된다.

b의 상황에서 크롤러의 동작

GET http://www.foo.com/index.html
/index.html을 가져와서, subdir/index.html로 이어지는 링크를 발견한다.
GET http://www.foo.com/subdir/index.html
subdir/index.html을 가져왔지만 같은 index.html로 되돌아간다.
GET http://www.foo.com/subdir/subdir/index.html
subdir/subdir/index.html을 가져온다.
GET http://www.foo.com/subdir/subdir/subdir/index.html
subdir/subdir/subdir/index.html을 가져온다.

여기서 문제는 subdir/이 /로 링크되어 있기 때문에 순환되는 것이다. 하지만 URL이 다르므로, 로봇은 URL 만으로 문서가 같다는 것을 모른다. 이 부분이 루프가 발생하는 지점이 될 가능성이 높다.

루프와 중복 피하기

웹은 로봇이 문제를 일으킬 가능성으로 가득 차 있다. 이러한 웹에서 로봇이 더 올바르게 동작하기 위해 사용하는 기법들은 다음과 같다.

URL 정규화
URL을 표준 형태로 변환함으로써, 같은 리소스를 가리키는 중복된 URL이 생기는 것을 일부 회피한다.
너비 우선 크롤링
방문할 URL들을 웹 사이트들 전체에 걸쳐 너비 우선으로 스케줄링하면, 순환의 영향을 최소화할 수 있다.
스로틀링
로봇이 웹 사이트에서 일정 시간 동안 가져올 수 있는 페이지의 숫자를 제한한다.
스로틀링을 이용해 그 서버에 대한 접근 횟수와 중복의 총 횟수를 제한할 수 있을 것이다.
URL 크기 제한
로봇은 일정 길이를 넘는 크롤링을 거부할 수 있다.
만약 순환으로 인해 URL이 계속해서 길어진다면 결국에는 길이 제한으로 인해 순환이 중단될 것이다.
이 기법을 적용하면 가져오지 못하는 콘텐츠들도 존재할 수 있다.
URL/사이트 블랙리스트
로봇 순환을 만들어내거나 함정인 것으로 알려진 사이트와 URL의 목록을 만들어 관리하는 방식이다.
패턴 발견
파일 시스템의 심벌릭 링크를 통한 순환과 그와 비슷한 오설정들은 일정 패턴을 따르는 경향이 있다.
몇몇 로봇은 반복되는 구성 요소를 가진 URL을 잠재적인 순환으로 보고, 둘 혹은 셋 이상의 반복된 구성요소를 갖고 있는 URL을 크롤링하는 것을 거절한다.
콘텐츠 지문(fingerprint)
지문은 더욱 복잡한 웹 크롤러들이 중복을 감지하기 위해 사용하는 방법이다.
콘텐츠 지문을 사용하는 로봇들은 페이지의 콘텐츠에서 몇 바이트를 얻어내어 체크섬을 계산한다. 이 체크섬은 그 페이지 내용의 간략한 표현이다. 만약 로봇이 이전에 보았던 체크섬을 가진 페이지를 가져온다면, 그 페이지의 링크는 크롤링하지 않는다. 로봇이 그 페이지의 콘텐츠를 이전에 본 것이므로, 그 페이지의 링크들은 이미 크롤링이 시작된 상태이기 때문이다.
어떤 웹 서버는 동적으로 페이지를 수정하기 때문에, 로봇들은 때때로 웹페이지 콘텐츠에 임베딩된 링크와 같은 특정 부분들을 체크섬 계산에서 빠뜨린다. 또한, 서버 측의 동적인 동작은 중복 감지를 방해할 수 있다.
사람의 모니터링
모든 상용 수준의 로봇은 사람이 쉽게 로봇의 진행 상황을 모니터링해서 특이사항이 발생하면 즉각 인지할 수 있게끔 반드시 진단과 로깅을 포함하도록 설계되어야 한다.

로봇의 HTTP

로봇들은 다른 HTTP 클라이언트 프로그램과 다르지 않기 때문에, HTTP 명세의 규칙을 지켜야 한다.

요청 헤더 식별하기

로봇들이 HTTP를 최소 한도로만 지원하려고 함에도 불구하고, 그들 대부분은 약간의 신원 식별 헤더(User-Agent HTTP 헤더)를 구현하고 전송한다. 로봇 구현자들은 로봇의 능력, 신원, 출신을 알려주는 몇가지 헤더를 사이트에게 보내주는 것이 좋다.

로봇 개발자들이 구현을 하도록 권장되는 기본적인 신원 식별 헤더

User-Agent
서버에게 요청을 만든 로봇의 이름을 말해준다.
From
로봇의 사용자/관리자의 이메일 주소를 제공한다.
Accept
서버에게 어떤 미디어 타입을 보내도 되는지 말해준다.
이 헤더는 로봇이 관심 있는 유형의 콘텐츠(텍스트, 이미지 등)만 받게 될 것임을 확신하는데 도움을 준다.
Referer
현재의 요청 URL을 포함한 문서의 URL을 제공한다.

가상 호스팅

로봇 구현자들은 Host 헤더를 지원할 필요가 있다. 요청에 Host 헤더를 포함하지 않으면 로봇이 어떤 URL에 대해 잘못된 콘텐츠를 찾게 만든다. 이러한 이유로 HTTP/1.1은 Host 헤더를 사용할 것을 요구한다.

대부분의 서버들은 기본적으로 특정 사이트 하나를 운영하도록 설정되어 있다. 따라서 Host 헤더를 포함하지 않은 크롤러는 두 개의 사이트를 운영하는 서버에 2개의 요청(www.joes-hardware.com / www.foo.com)을 보낼 수도 있다. 만약 서버가 기본적으로 www.joes-hardware.com을 제공하도록 설정되어 있고 Host 헤더를 요구하지 않는다면 www.foo.com 페이지에 대한 요청은 크롤러가 조의 하드웨어 사이트에 대한 콘텐츠를 얻게 만든다.

요청에 Host 헤더가 없는 경우, 가상 docroot가 문제를 일으키는 예시

조건부 요청

수십억 개의 웹페이지를 다운 받게 될 수 있는 인터넷 검색엔진 로봇의 경우, 페이지가 변경되었을 때만 콘텐츠를 받아오도록 하는 것은 의미가 있다.

이들 로봇 중의 몇몇은 시간이나 엔티티 태그를 비교함으로써 그들이 받아간 마지막 버전 이후에 업데이트된 것이 있는지 알아보는 조건부 HTTP 요청을 구현한다.

응답 다루기

대다수 로봇은 주 관심사가 단순히 GET 메서드로 콘텐츠를 요청해서 가져오는 것이므로 응답 다루기 작업을 거의 하지 않는다.

그러나 HTTP의 특정 기능(조건부 요청)을 사용하는 로봇들이나 웹 탐색이나 서버와의 상호작용을 더 잘해보려고 하는 로봇들은 여러 종류의 HTTP 응답을 다룰 줄 알아야 한다.

상태 코드

일반적으로, 로봇들은 일반적인 상태 코드들을 다룰 수 있어야 한다.

엔티티

HTTP 헤더에 임베딩된 정보를 따라 로봇들은 엔터티 자체의 정보를 찾을 수 있다.

메타 http-equiv 태그와 같은 메타 HTML 태그는 리소스에 대해 콘텐츠 저자가 포함시킨 정보다. http-equiv 태그 자체는 콘텐츠 저자가 콘텐츠를 다루는 서버가 제공할 수도 있는 헤더를 덮어쓰기 위한 수단이다.

메타 HTML 태그는 콘텐츠 저자들이 로봇의 동작과 그들이 검색한 문서들로 무엇을 할지 제어하는데 사용할 수 있는 추가적인 메타 지시자를 나열한다. 이런 기능은 서버가 헤더를 설정하지 못하는 상황에서 콘텐츠 저자가 HTML 문서 자체적으로 이를 보완할 수 있게 하지만, 현대 웹에서는 `<meta http-equiv>` 태그보다 서버 측에서 헤더를 명시적으로 설정하는 것이 더 권장된다.

<meta http-equiv="Refresh" content="1; URL=index.html">

이 태그는 수신자가 문서를 마치 그 문서의 HTTP 응답 값이 "1; URL=index.html"인 Refresh HTTP 헤더를 포함하고 있는 것처럼 다루게 한다.

User-Agent 타기팅

웹 관리자들은 많은 로봇이 그들의 사이트를 방문하게 될 것임을 명심하고, 그 로봇들로부터의 요청을 예상해야 한다.

많은 웹사이트들은 여러 기능들을 지원하기 위해 브라우저의 종류를 감지하여 콘텐츠를 최적화한다. 이를 통해, 사이트는 로봇에게 콘텐츠 대신 에러 페이지를 제공하게 된다. 때문에, 사이트 관리자들은 로봇의 요청을 다루기 위한 전략을 세워야 한다. 예를 들어 특정 브라우저의 기능이 지원되는 것을 전제하여 콘텐츠를 개발하는 대신, 풍부한 기능을 갖추지 못한 브라우저나 로봇 등 다양한 클라이언트에 잘 대응하는 유연한 페이지를 개발할 수 있을 것이다.

사이트 관리자들은 로봇이 그들의 사이트에 방문했다가 콘텐츠를 얻을 수 없게 되는 일이 없도록 대비해야 한다.

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

로봇들이 저지르는 실수들

폭주하는 로봇
로봇은 웹 서핑하는 사람보다 빠르게 HTTP 요청을 만들 수 있기 때문에, 웹 서버에 극심한 부하를 저지를 수 있다.
오래된 URL
몇몇 로봇은 URL의 목록을 방문하는데, 목록이 오래되었을 수 있다. 만약 웹사이트가 콘텐츠를 많이 바꾼 경우, 로봇은 존재하지 않은 URL에 대한 요청을 많이 보낼 수 있다. 이것은 존재하지 않은 문서에 대한 접근 요청으로 에러로그가 채워질 수 있고, 에러 페이지를 제공하는 부하가 생길 수 있다.
길고 잘못된 URL
순환이나 프로그래밍 상 오류로 인해 로봇은 웹 사이트에게 크고 의미없는 URL을 요청할 수 있다.
동적 게이트웨이 접근
로봇은 게이트웨이 애플리케이션의 콘텐츠에 대한 URL로 요청을 할 수 있다. 이 경우, 얻은 데이터는 아마도 특수 목적을 위한 것일테고 처리 비용이 많이 들 것이다.

로봇 차단하기

로봇이 그들에게 맞지 않는 장소에 들어오지 않도록 하고 관리자에게 로봇의 동작을 더 잘 제어할 수 있는 메커니즘을 제공하는 기법이 제안되었고, 이는 "Robots Exclusion Standard"라고 정해졌다. 이 명칭은 로봇의 접근을 제어하는 정보를 저장하는 파일의 이름을 따서 robots.txt 라고도 불린다.

아이디어는 다음과 같다.

어떤 웹 서버는 서버의 문서 루트에 robots.txt라는 선택적인 파일을 제공할 수 있다. 이 파일은 어떤 로봇이 서버의 어떤 부분에 접근할 수 있는지에 대한 정보가 담겨 있다.

만약 로봇이 이 자발적인 표준에 따른다면 웹 사이트에 다른 리소스에 접근하기 전 해당 사이트의 robots.txt를 먼저 요청한다. robots.txt 파일은 로봇을 차단하지 않으므로, 로봇은 그 페이지를 가져오게 된다.

robots.txt를 가져와서 대상 파일을 크롤링하기 전에 접근해도 되는지 확인하기

로봇 차단 표준

로봇 차단 표준은 임시방편으로 만들어진 표준이다.

로봇 차단 표준에는 3가지 버전이 존재하며, 대부분의 로봇들은 v0.0이나 v1.0 표준을 채택했다.

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

웹사이트와 robots.txt 파일들

웹 사이트의 어떤 URL을 방문하기 전에, 웹사이트에 robots.txt 파일이 존재한다면 로봇은 반드시 그 파일을 가져와서 처리해야 한다.

호스트명과 포트번호에 의해 정의되는 어떤 웹 사이트가 있을 때, 사이트 전체에 대한 robots.txt 파일을 하나만 존재한다. (만약 가상 호스팅된다면 가상 docroot에서 서로 다른 robots.txt가 있을 수 있다)

robots.txt 가져오기

로봇은 HTTP GET 메서드를 이용해 robots.txt 리소스를 가져온다. robots.txt가 존재한다면 서버는 그 파일을 text/plain 본문으로 반환한다. 만약 서버가 404 NotFound HTTP 상태 코드로 응답한다면 로봇은 서버가 로봇의 접근을 제한하지 않는 것으로 간주한다.

로봇은 사이트 관리자가 로봇의 접근을 추적할 수 있도록 From이나 User-Agent 헤더를 통해 신원 정보를 넘기고, 사이트 관리자가 로봇에 대해 문의나 불만사항이 있는 경우를 위해 연락처를 제공해야 한다.

HTTP 크롤러 요청의 예시

GET /robots.txt HTTP/1.0
HOST: www.joes-hardware.com
User-Agent: Slurp/2.0
Date: Wed Oct 3 20:22:48 EST 2001

응답 코드

많은 웹 사이트가 robots.txt를 갖고 있지 않지만 로봇은 그 사실을 모른다. 로봇은 어떤 웹 사이트든 반드시 robots.txt를 찾아본다. 로봇은 robots.txt 검색 결과에 따라 다르게 동작한다.

성공적으로 응답하면(HTTP 2xx), 그 응답의 콘텐츠를 파싱하여 차단 규칙을 얻고, 그 사이트에서 무언가를 가져오려 할 때 규칙을 지켜야 한다.
리소스가 없다고 응답한 경우(HTTP 404), 로봇은 차단 규칙이 없다고 생각하여 제약 없이 해당 사이트에 접근한다.
접근 제한으로 응답한 경우(HTTP 401, 403), 로봇은 그 사이트로의 접근은 완전히 제한되어 있다고 가정해야 한다.
요청 시도가 일시적으로 실패한 경우(HTTP 503), 로봇은 그 사이트의 리소스를 검색하는 것을 뒤로 미뤄야 한다.
서버 응답이 리다이렉션을 의미한다면(HTTP 3XX), 로봇은 리소스가 발견될 때까지 리다이렉트를 따라가야 한다.

robots.txt 파일 포맷

robots.txt 파일은 매우 단순한 줄 기반 문법을 갖는다.

각 줄은 빈 줄, 주석 줄, 규칙 줄 3 가지 종류가 있다. 규칙 줄은 HTTP 헤더처럼 생겼고, 패턴 매칭을 위해 사용된다.

robots.txt 예시

# 이 robots.txt 파일은 Slurp와 Webcrawler가 우리 사이트의 공개된
# 영역을 크롤링하는 것을 허락한다. (다른 로봇들은 안된다)

User-Agent: slurp
User-Agent: webcrawelr
Disallow: /private

User-Agent: *
Disallow:

robots.txt의 이 줄들은 레코드로 구분된다.

각 레코드는 특정 로봇들의 집합에 대한 차단 규칙의 집합을 기술한다. 이 방법을 통해 로봇 별로 각각 다른 차단 규칙을 적용할 수 있다.

각 레코드는 규칙 줄들의 집합으로 되어 있으며, 빈 줄이나 파일 끝(EOF) 문자로 끝난다. 레코드는 어떤 로봇이 이 레코드에 영향을 받는지 지정하는 하나 이상의 User-Agent 줄로 시작하고 로봇들이 접근할 수 있는 URL을 설정하기 위한 Allow 줄과 Disallow 줄이 온다.

User-Agent 줄

각 로봇의 레코드는 하나 이상의 User-Agent 줄로 시작한다.

robots.txt 파일을 처리한 로봇은 다음의 레코드에 반드시 복종해야 한다.

로봇 이름이 자신 이름의 부분 문자열이 될 수 있는 레코드들 중 첫 번째 것
로봇 이름이 "*"인 레코드들 중 첫 번째 것

Disallow와 Allow 줄들

Disallow와 Allow 줄은 로봇 차단 레코드의 User-Agent 줄들 다음에 온다. 이 줄들은 특정 로봇에 대해 어떤 URL 경로가 명시적으로 금지되어 있고, 허용되는지 기술한다.

URL과 맞는 하나의 Allow/Disallow 줄에 대해 규칙 경로는 반드시 맞춰보고자 하는 경로의 대소문자를 구분하는 접두어야야 한다.

예를 들어 'Diallow: /tmp'는 다음의 모든 URL에 대응된다.

http://www.joes-hardware.com/tmp
http://www.joes-hardware.com/tmp/
http://www.joes-hardware.com/tmp/pliers.html
http://www.joes-hardware.com/tmpspc/stuff.txt

그 외에 알아둘 점

robots.txt 파일은 명세가 발전함에 따라 여러 필드를 포함할 수 있지만 로봇은 자신이 이해하지 못하는 필드는 무시해야 한다.
하위 호환성을 위해, 한 줄을 여러 줄로 나누는 것은 허용되지 않는다.
주석은 파일의 어디서든 허용된다.
로봇 차단 표준 버전 0.0은 Allow 줄을 지원하지 않았다. 몇몇 로봇은 오직 0.0 버전의 명세만을 구현하고 Allow 줄들은 무시한다. 이런 경우 로봇은 보수적으로 동작할 것이므로 허용되는 URL도 탐색하지 않을 수 있다.

robots.txt 캐싱과 만료

로봇은 주기적으로 robots.txt 파일을 가져와서 결과를 캐시해야 한다. robots.txt의 캐시된 사본은 robots.txt 파일이 만료될 때까지 로봇에 의해 사용된다. robots.txt 파일의 캐싱을 제어하기 위해 표준 HTTP 캐시 제어 메커니즘이 원 서버와 로봇 양쪽 모두에 의해 사용된다. 로봇은 HTTP 응답의 Cache-Control과 Expires 헤더에 주의를 기울여야 한다.

검색 엔진

웹 로봇을 가장 광범위하게 사용하는 것은 인터넷 검색엔진이다. 인터넷 검색엔진은 사용자가 전 세계의 어떤 주제에 대한 문서라도 찾을 수 있게 해준다.

웹 크롤러들은 마치 먹이를 주듯 검색엔진에게 웹에 존재하는 문서들을 가져다 주어 검색엔진이 어떤 문서에 어떤 단어들이 존재하는지에 대한 색인을 생성할 수 있게 한다.

넓게 생각해라

웹이 초창기였을 때, 검색엔진들은 사용자들이 웹 상에서 문서의 위치를 알아내는 것을 돕는 단순한 데이터베이스였다.

웹에서 수십 억, 수백 억 개의 페이지들이 접근 가능한 오늘날, 인터넷 사용자들의 정보 찾기를 도와주는 검색 엔진은 필수가 되었고, 검색 엔진은 진화하였다.

검색 엔진은 수십억 개의 웹 페이지를 검색하기 위해 복잡한 크롤러를 사용해야 한다.

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

오늘날 검색 엔진들은 그들이 갖고 있는 전 세계의 웹페이지들에 대해 "풀 텍스트 색인"이라고 하는 복잡한 로컬 데이터베이스를 생성한다. 이 색인은 웹의 모든 문서에 대한 일종의 카탈로그처럼 동작한다.

검색 엔진 크롤러들은 웹페이지를 수집하여 가져와서 풀 텍스트 색인에 추가한다. 동시에 검색엔진 사용자들은 핫봇이나 구글과 같은 웹 검색 게이트웨이를 통해 풀 텍스트 색인에 대한 질의를 보낸다.

크롤링을 한 번하는데 걸리는 시간이 상당한데 비해 웹 페이지들은 매순간 변화하기 때문에, 풀 텍스트 색인은 기껏 해봐야 웹의 특정 순간에 대한 스냅숏에 불과하다.

풀 텍스트 색인

풀 텍스트 색인은 단어 하나를 입력받아 그 단어를 포함하고 있는 문서를 즉각적으로 알려줄 수 있는 데이터베이스이다. 이 문서들은 색인이 생성된 후에는 검색할 필요가 없다.

질의 보내기

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

질의 보내기 예시

사용자는 "drills"를 검색 상자 폼에 타이핑하고 브라우저는 이를 질의 매개변수를 URL의 일부로 포함하는 GET 요청으로 번역한다.

웹 서버는 이 질의를 받아서 검색 게이트웨이 애플리케이션에게 넘겨주면 게이트웨이는 웹 서버에게 문서의 목록을 결과로 돌려주고, 웹 서버는 이 결과를 사용자를 위한 HTML 페이지로 변환한다.

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

질의의 결과를 확인하기 위해 검색엔진이 색인을 사용했다면, 게이트웨이 애플리케이션은 그 결과를 이용해 최종 사용자를 위한 결과 페이지를 즉석에서 만들어낸다.

많은 웹페이지가 주어진 단어를 포함할 수 있기 때문에 검색엔진은 결과에 순위를 매기기 위해 똑똑한 알고리즘을 사용한다. 이 알고리즘을 관련도 랭킹이라고 부르며, 검색 결과의 목록에 점수를 매기고 정렬하는 과정이다.

'CS지식 > 네트워크' 카테고리의 다른 글

[HTTP 완벽가이드] 10. HTTP/2.0 (0)	2024.11.17
[HTTP 완벽가이드] 08. 통합점: 게이트웨이, 터널, 릴레이 (6)	2024.11.03
[HTTP 완벽가이드] 07. 캐시 (1)	2024.10.18
[HTTP 완벽가이드] 06. 프락시 (1)	2024.10.13
[HTTP 완벽가이드] 05. 웹 서버 (2)	2024.10.04