[HTTP] 웹 로봇

 

#1. 크롤러와 크롤링

웹 크롤러는 웹 링크를 재귀적으로 따라가는 로봇이다. 인터넷 검색엔진은 웹을 돌아다니면서 그들이 만나는 모든 문서를 끌어오기 위해 크롤러를 사용한다. 이 문서들은 나중에 처리되어 검색 가능한 데이터베이스로 만들어지는데 이는 사용자들이 특정 단어를 포함한 문서를 찾을 수 있게 해준다.

---

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

크롤러가 방문을 시작하는 URL들의 초기 집합은 루트 집합이라고 부른다.

모든 페이지에 도달하려면 루트 집합이 필요하다.

일반적으로 좋은 루트 집합은 크고 인기 있는 웹 사이트, 새로 생성된 페이지들의 목록, 그리고 자주 링크되지 않는 잘 알려지지 않은 페이지들의 목록으로 구성되어 있다. 인터넷 검색엔진에서 쓰이는 것과 같은 많은 대규모 크롤러 제품들은 사용자들이 루트 집합에 새 페이지나 잘 알려지지 않은 페이지들을 추가하는 기능을 제공한다. 이 루트 집합은 시간이 지남에 따라 성장하며 새로운 크롤링을 위한 시드 목록이 된다.

---

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

크롤러가 크롤링을 진행하면서 탐색해야 할 새 링크를 발견함에 따라 이 목록은 보통 급속히 확장된다. 

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

---

순환 피하기

로봇이 웹을 크롤링 할 때에는 루프나 순환에 빠지지 않도록 매우 조심해야 한다.

하이퍼링크의 웹을 크롤링하기

로봇들은 순환을 피하기 위해 반드시 그들이 어디를 방문했는지 알아야 한다. 순환은 로봇을 함정에 빠뜨려서 멈추게 하거나 진행을 느려지게 한다.

---

루프와 중복

순환은 3개의 이유로 인해 크롤러에게 해롭다.

• 크롤러를 루프에 빠뜨려서 멈추게 만든다. 이러한 크롤러가 네트워크 대역폭을 다 차지하고 그 어떤 페이지도 가져올 수 없게 만들 수 있다.
• 같은 페이지를 반복해서 가져오면서 웹 서버의 부담이 된다. 사용자가 사이트에 접근할 수 없도록 막을 수도 있다.
• 크롤러의 애플리케이션은 자신을 쓸모없게 만드는 중복된 콘텐츠로 넘쳐나게 될 것이다.

---

웹 크롤러 방문 관리하기 위한 유용한 기법

만약 전 세계 웹 콘텐츠의 상당 부분을 크롤링하려 한다면 수십억 개의 URL을 방문할 준비가 필요할 것이다. 만약 평균 URL이 40바이트의 길이이고, 웹 로봇이 5억개의 URL을 크롤링 했다면 검색 데이터 구조는 이 URL들을 유지하기 위해 20GB 이상의 메모리를 요구할 것이다.

• 트리와 해시 테이블 : 검색 트리나 헤시 테이블을 사용, UTL을 빨리 찾아볼 수 있게 해주는 소프트웨어 자료 구조
• 느슨한 존재 비트맵 : 존재 비트 배열과 같은 느슨한 자료구조 사용, 존재 비트가 존재하면 이미 크롤링 간주
• 체크포인트 : 크롤러가 갑자기 중단될 경우, 방문한 URL의 목록이 디스크에 저장되었는지 확인
• 파티셔닝 : 각 로봇엔 URL들의 특정 한 부분이 할당되어 그에 대한 책임을 짊. 로봇들은 서로 도와 웹을 크롤링

---

URL 정규화하기

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

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

URL 정규화는 기본적인 문법의 Alias(별칭)을 제거할 수 있지만, 로봇들은 URL을 표준 형식으로 변환하는 것만으로는 제거할 수 없는 다른 URL Alias도 만나게 될 것이다.

---

파일 시스템 링크 순환

파일 시스템의 심벌릭 링크는 사실상 아무것도 존재하지 않으면서도 끝없이 깊어지는 디렉터리 계층을 만들 수 있기 때문에 매우 교묘한 종류의 순환을 유발할 수 있다. 심벌릭 링크 순환은 서버 관리자가 실수로 만들게 되는 것이 보통이지만 로봇을 함정에 빠뜨리기 위해 악의적으로 만들기도 한다.

심버릭 링크 사이클

subdir/ 이 /로 링크되어 있기 때문에 순환되는 것이지만 URL이 달라 보이기 때문에 로봇은 URL만으로는 문서가 같다는 것을 모른다. 루프를 발견하지 못한다면 URL의 길이가 로봇이나 서버의 한계를 넘을 때까지 이 순환은 계속된다.

---

루프와 중복 피하기

• URL 정규화 : 같은 리소스를 가리키는 중복된 URL이 생기는 것을 일부 회피
• 너비 우선 크롤링 : 깊이보다 너비 우선으로 스케줄링하면 순환의 영향을 최소화할 수 있다.
• 스로틀링 : 로봇이 웹사이트에서 일정 시간 동안 가져올 수 있는 페이지의 숫자를 제한
• URL 크기 제한 : 일정 길이(보통 1KB)를 넘는 URL의 크롤링은 거부할 수 있다.
• URL/사이트 블랙리스트 : 악의적인 사이트 블랙리스트, 사람의 손을 필요로 한다.
• 패턴 발견 : 반복되는 구성요소를 가진 URL을 크롤링하는 것을 거절한다.
• 콘텐츠 지문 : 로봇이 이전에 보았던 체크섬을 가진 페이지를 가져온다면 그 페이지의 링크는 크롤링하지 않는다.
• 사람의 모니터링 : 사람이 쉽게 로봇의 진행상황을 모니터링해서 특이한 일이 일어나면 인지하도록 반드시 진단과 로깅을 포함하도록 설계되어야 한다.

---

#2. 로봇의 HTTP

로봇들도 다른 HTTP 클라이언트 프로그램과 다르지 않다. 그들 또한 HTTP 명세의 규칙을 지켜야 한다. 많은 로봇들은 HTTP를 최소한으로만 구현하려고 한다. 그 이유로 많은 로봇이 요구사항이 적은 HTTP/1.0 요청을 보낸다.

---

1.요청 헤더 식별하기

로봇의 능력, 신원, 출신을 알려주는 기본적인 몇 가지 헤더를 사이트에 보내주는 것이 좋다. 그 이유는 잘못된 크롤러의 소유자를 찾아낼 때와 서버에게 로봇이 어떤 종류의 콘텐츠를 다룰 수 있는지에 대한 약간의 정보를 주려 할 때 유용한 정보이다.

• User-Agent : 서버에게 요청을 만든 로봇의 이름을 말해준다.
• From : 로봇의 사용자/관리자의 이메일 주소를 제공한다.
• Accept : 서버에게 어떤 미디어 타입을 보내도 되는지 말해준다. 로봇이 관심 있는 유형의 콘텐츠 확인
• Referer : 현재의 요청 URL을 포함한 문서의 URL을 제공한다.

2.가상 호스팅

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

3.조건부 요청

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

이는 HTTP 캐시가 전에 받아온 리소스의 로컬 사본이 유효성을 검사하는 방법과 매우 비슷하다.

4.응답 다루기

웹 탐색이나 서버와의 상호작용을 더 잘해보려고 하는 로봇들은 HTTP 응답을 다룰 줄 알 필요가 있다.

• 최소한의 상태코드나 예상할 수 있는 상태코드를 다룰 수 있어야 한다. (200 OK, 404 Not Found)
• http-equiv 태그와 같은 엔터티 장체의 정보에 대한 이해

5.User-Agent 타기팅

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

---

#3. 부적절하게 동작하는 로봇들

• 로봇이 논리적인 에러를 갖고 있거나 순환에 빠졌다면 웹 서버에 극심한 부하를 안겨줄 수 있다. 이것은 서버에 과부하를 유발하여 다른 누구에게도 서비스를 못하게 만드는 일이 생길 수 있다.
• 웹 사이트가 그들의 콘텐츠를 많이 바꾸었다면 로봇들은 존재하지 않은 URL에 대한 요청을 보낼 수 있다. 이로 인해 에러 로그가 채워지거나 웹 서버의 요청에 대한 수용 능력이 감소하기도 한다.
• 순환이나 프로그래밍상의 오류로 로봇은 웹 사이트에게 크고 의미 없는 URL을 요청할 수 있다. 이는 웹 서버의 처리 능력에 영향을 주고 웹 서버의 접근 로그를 어지럽게 채운다.
• 사적인 데이터에 대한 URL을 얻어 그 데이터를 인터넷 검색엔진이나 기타 애플리케이션을 통해 쉽게 접근할 수 있도록 만든다. 

---

#4. 로봇 차단하기

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

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

---

웹 사이트와 robots.txt 파일들

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

로봇은 어떤 웹 사이트든 반드시 robots.tst를 찾아보고 검색결과에 따라 다르게 동작한다.

• 서버가 성공(2xx 상태코드)으로 응답하면 로봇은 차단 규칙을 얻고 그 규칙을 따른다.
• 404 상태코드로 응답하면 로봇은 차단 규칙이 존재하지 않는다고 가정하고 제약없이 그 사이트에 접근한다.
• 서버가 접근 제한(401 or 403 상태코드)으로 응답한다면 사이트로의 접근은 완전히 제한된다.
• 요청 시도 일시적으로 실패(503 상태코드)했다면 그 사이트의 리소스를 검색하는 것은 뒤로 미루어야 한다.
• 서버 응답이 리다이렉션(3xx 상태코드)를 의미한다면 리소스가 발견될 때까지 리다이렉트를 따라가야 한다.

robots.txt에 대한 관련 사이트 : https://www.robotstxt.org/

The Web Robots Pages

---

#5. 검색엔진

웹 로봇을 가장 광범위하게 사용하는 것은 인터넷 검색엔진이다. 웹 크롤러들은 검색엔진에게 웹에 존재하는 문서들을 가져다 주어서 검색엔진이 어떤 문서에 어떤 단어들이 존재하는지에 대한 색인을 생성할 수 있게 한다.

 

---

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

오늘날 검색엔진들은 그들이 갖고 있는 전 세계의 웹페이지들의 대해 '풀 텍스트 색인(full-text indexes)'이라고 하는 복잡한 로컬 데이터베이스를 생성한다. 검색엔진 크롤러들은 웹페이지들을 수집하여 풀 텍스트 색인에 추가한다. 동시에 검색엔진 사용자들은 구글과 같은 웹 검색 게이트웨이를 통해 풀 텍스트 색인에 대한 질의를 보낸다.

크롤러와 질의 게이트웨이의 협업을 포함한 상용 검색엔진

 

---

풀 텍스트 색인(full-text-indexes)

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

---

질의 보내기

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

검색 질의 요청의 예

---

 

참고 자료

• HTTP완벽가이드 , 인사이트