[HTTP 완벽 가이드] 9장 웹로봇

공효은·2025년 1월 6일
http
0

http

목록 보기
1/1

웹로봇

웹 로봇은 사람과의 상호작용 없이 연속된 웹 트랜잭션들을 자동으로 수행하는 소프트웨어 프로그램이다.
많은 로봇이 웹 사이트에서 다른 웹 사이트로 떠돌아다니면서, 콘텐츠를 가져오고, 하이퍼링크를 따라가고, 그들이 발견한 데이터를 처리한다.

예시)

  • 주식시장 서버에 매 분 HTTP GET 요청을 보내고, 여기서 얻은 데이터를 활용해 주가 추이 그래프를 생성하는 주식 그래프 로봇
  • 검색 데이터베이스를 만들기 위해 발견한 모든 문서를 수집하는 검색엔진 로봇.

9.1 크롤러와 크롤링

웹 크롤러는, 먼저 웹페이지를 한개 가져오고, 그 다음 그 페이지가 가리키는 모든 웹페이지를 가져오고, 다시 그 페이지들을 가리키는 모든 웹페이지들을 가져오는 일을 재귀적으로 반복하는 방식으로 웹을 순회하는 로봇이다.

웹 링크를 재귀적으로 따라가는 로봇을 크롤러 혹은 스파이더라고 부르는데, HTML 하이퍼링크들로 만들어진 웹을 따라 '기어다니기(crawl)' 때문이다.

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

크롤러가 방문을 시작하는 URL들의 초기 집합은 루트 집합(root set) 이라고 불린다.

일반적으로 좋은 루트 집합은 크고 인기 있는 웹사이트, 새로 생성된 페이지들의 목록, 그리고 자주 링크되지 않는 잘 알려져 있지 않은 페이지들의 목록으로 구성되어있다.

인터넷 검색엔진에서 쓰이는 것과 같은 많은 대규모 크롤러 제품들은 사용자들이 루트 집합에 새 페이지나 잘 알려지지 않은 페이지들을 추가하는 기능을 제공한다.
이 루트 집합은 시간이 지남에 따라 성장하며 새로운 크롤링을 위한 시드 목록이 된다.

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

크롤러는 웹을 돌아다니면서 꾸준히 HTML 문서를 검색한다. 크롤러는 검색한 각 페이지 안에 들어있는 URL 링크들을 파싱해서 크롤링할 페이지들의 목록에 추가해야한다. 크롤러가 크롤링을 진행하면서 탐색해야 할 새 링크를 발견함에 따라 이 목록은 급속히 확장된다.

9.1.3 순환 피하기

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

  • 그림 9-2a 에서, 로봇은 페이지 A를 가져와서 B가 A에 링크되어 있는 것을 보고 B를 가져온다.
  • 그림 9-2b에서, 로봇은 페이지 B를 가져와서 C가 B에 링크되어 있는 것을 보고 C를 가져온다.
  • 그림 9-2c에서, 로봇은 페이지 C를 가져와서 A가 C에 링크되어 있는 것을 본다.
    만약 로봇이 A를 다시 가져온다면 A,B,C,A,B,C,A..를 계속 가져오게 되는 순환에 빠진다.

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

9.1.4 루프와 중복

  • 순환은 크롤러를 루프에 빠뜨려서 꼼짝 못하게 만들 수 있다.
  • 크롤러가 같은 페이지를 반복해서 가져오면 고스란히 웹 서버의 부담이 된다. 만약 크롤러의 네트워크 접근 속도가 충분히 빠르다면, 웹 사이트를 압박하여 어떤 사용자도 사이트에 접근할 수 없도록 막아버릴 수 있다.
  • 크롤러는 중복된 페이지를 가져오게 되는데. 자신을 쓸모없게 만드는 중복된 콘텐츠로 넘쳐나게 될것이다.

9.1.5 빵 부스러기의 흔적

어떤 URL을 방문했는지 빠르게 판단하기 위해서는 복잡한 자료 구조를 사용할 필요가 있다. 이 자료 구조는 속도와 메모리 사용 면에서 효과 적이여야한다.

트리와 해시 테이블

복잡한 로봇이라면 방문한 URL을 추적하기 위해 검색 트리나 해시 테이블을 사용했을 수도 있다. 이들은 URL을 훨씬 빨리 찾아볼 수 있게 해주는 소프트웨어 자료 구조다.

느슨한 존재 비트맵

공간 사용을 최소화 하기 위해, 몇몇 대규모 크롤러들은 존재 비트 배열(presence bit array)과 같은 느슨한 자료구조를 사용한다. 각 URL은 해시 함수에 의해 고정된 크기의 숫자로 변환 되고 배열 안에 대응하는 '존재 비트(presence bit)'를 갖는다.
URL이 크롤링 되었을 때, 해당하는 존재 비트가 만들어진다. 만약 존재 비트가 이미 존재한다면 그 URL을 이미 크롤링 되었다고 간주한다.

파티셔닝

몇몇 대규모 웹 로봇은, 각각이 분리된 한 대의 컴퓨터인 로봇들이 동시에 일하고 있는 농장(farm)을 이용한다. 각 로봇엔 URL들의 특정 '한 부분'이 할당되어 그에 대한 책임을 진다.

9.1.6 별칭(alias)과 로봇 순환

한 URL이 또 다른 URL에 대한 별칭이라면, 그 둘이 서로 달라 보이더라도 사실은 같은 리소스를 가리키고 있다.

9.1.7 URL 정규화 하기

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

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

  3. 태그들을 제거한다.

하지만 각 웹서버에 대한 지식 없이 로봇이 d~f 같은 중복을 피할 수 는 엇다.
d -> 웹서버가 대소문자를 구분하는지 알아야함
e -> 이 디렉터리에 대한 웹 서버의 색인 페이지 설정을 알아야함
f -> 첫번째 URL의 호스트 명과 두 번째 URL의 IP 주소가 같은 물리적 컴퓨터를 참조한다는 것뿐 아니라, 웹 서버가 가상 호스팅을 하도록 설정되어 있는지도 알아야한다

9.1.9 동적 가상 웹 공간

의도적으로

평범한 파일처럼 보이지만 사실은 게이트웨이 애플리케이션인 URL을 만드는것은 쉬운 일이다.
이 애플리케이션은 같은 서버에 있는 가상의 URL에 대한 링크를 포함한 HTML을 즉석에서 만들어 낼 수 있다. 이 끔찍한 서버는 저 가상의 URL로 요청을 받으면 새로운 가상 URL을 갖고 있는 새 HTML 페이지를 날조 해서 만들어 낸다.
악의적인 웹 서버는 로봇을 무한한 가상 웹 공간 너머에 있는 이상한 나라로 보내 버린다.

의도치 않게

자신도 모르게 심벌링 링크나 동적 콘텐츠를 통한 크롤러 함정을 만든다.
예를 들어 한달 치 달력을 생성하고 그 다음 달로 링크를 걸어주는 CGI 기반의 달력 프로그램을 생각해보라. 실제 사용자라면 영원히 다음 달 링크만 누르고 있지는 않겠지만, 콘텐츠의 동적 성질을 이해하지 못하는 로봇이라면 무한히 다음 달 달력을 요청할 수도 있다.

9.1.10 루프와 중복 피하기

URL 정규화

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

너비 우선 크롤링

방문할 URL들을 웹 사이트들 전체에 걸쳐 너비 우선으로 스케줄링하면, 순환의 영향을 최소화 할 수 있다. 혹여 로봇 함정을 건드려도 여전히 그 순환에서 페이지를 받아오기 전에 다른 웹 사이트들에서 수십만 개의 페이지들을 받아 올 수 있다.

스로틀링

로봇이 웹 사이트에서 일정 시간 동안 가져올 수 있는 페이지의 숫자를 제한한다.

URL 크기 제한

로봇은 일정 길이(보통 1KB)를 넘는 URL의 크롤링은 거부할 수 있다.

URL/사이트 블랙리스트

패턴 발견

콘텐츠 지문

콘텐츠 지문을 사용하는 로봇들은 페이지의 콘텐츠에서 몇 바이트 얻어내어 체크섬을 계산한다.
이 체크섬은 그 페이지 내용의 간략한 표현이다. 만약 로봇이 이전에 보았던 체크섬을 가진 페이지를 가져온다면, 그 페이지의 링크는 크롤링하지 않는다.

사람의 모니터링

모든 상용 수준의 로봇은 사람이 쉽게 로봇의 진행 상황을 모니터링해서 뭔가 특이한 일이 일어나면 즉각 인지할 수 있게끔 반드시 진단과 로깅을 포함하도록 설계되어야한다.

9.4 로봇 차단하기

이 표준은 "Robots Exclusion Standard" 라고 이름 지어졌지만, 로봇의 접근을 제어하는 정보를 저장하는 파일의 이름을 따서 robots.txt라고 불린다.

이 파일은 어떤 로봇이 서버의 어떤 부분에 접근할 수 있는지에 대한 정보가 담겨 있다. 만약 어떤 로봇이 이 자발적인 표준에 따른다면, 그것은 웹 사이트의 어떤 다른 리소스에 접근하기 전에 우선 그 사이트의 robots.txt를 요청할 것이다.

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

웹 사이트의 어떤 URL을 방문하기 전에, 그 웹 사이트에 robots.txt 파일이 존재한다면 로봇은 반드시 그 파일을 가져와서 처리해야 한다.
웹 마스터는 웹 사이트의 모든 콘텐츠에 대한 차단 규칙을 종합적으로 기술한 robots.txt 파일을 생성할 책임이 있다.

robots.tsx 가져오기

  • 로봇은 웹 서버의 여느 파일들과 마찬가지로 HTTP GET 메서드를 이용해 robots.txt 리소스를 가져온다.
  • 그 robots.txt 가 존재한다면 서버는 그 파일을 text/plain 본문으로 반환한다.
  • 만약 서버가 404 Not Found HTTP 상태 코드로 응답한다면 로봇은 그 서버는 로봇의 접근을 제한하지 않는 것으로 간주하고 어떤 파일이든 요청한다.
  • 로봇은 사이트 관리자가 로봇의 접근을 추적할 수 있도록 From 이다 User-Agent 헤더를 통해 신원 정보를 넘겨야 한다.

응답 코드

  • 200 응답: 로봇은 반드시 그 응답의 콘텐츠를 파싱하여 차단 규칙을 얻고, 그 사이트에서 무언가를 가져오려 할 때 그 규칙에 따라야한다.

  • 404 응답: 로봇은 활성화된 차단 규칙이 존재하지 않는다고 가정하고 robots.txt의 제약 없이 사이트에 접근할 수 있다.

  • 401, 403 응답: 로봇은 그 사이트로의 접근은 완전히 제한되어 있다고 가정해야한다.

  • 503 응답: 요청이 일시적으로 실패했다면 로봇은 그 사이트의 리소스를 검색하는 것을 뒤로 미루어야한다.

  • 3XX 응답: 만약 서버 응답이 리다이렉션을 의미한다면 로봇은 리소스가 발견될 때까지 리다이렉트를 따라가야한다.

9.4.3 robots.txt 파일포맷

robots.txt 파일은 매우 단순한 줄 기반 문법을 갖는다. robots.txt 각 줄은 빈줄, 주석 줄, 규칙 줄의 세 가지 종류가 있다.
규칙줄은 HTTP 헤더처럼 생겼고(<필드>:<값>) 패턴 매칭을 위해 사용된다.

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

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

User-Agent: *
Disallow:

User-Agent 줄

각 로봇의 레코드는 하나 이상의 User-Agent 줄로 시작하며 형식은 다음과 같다.

User-Agent: <robot-name>
User-Agent: *

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

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

로봇 이름을 대소문자를 구분하지 않는 부분 문자열과 맞춰보므로, 의도치 않게 맞는 경우에 주의해아한다.
'User-Agent:bot' 은 Bot, Robot, Bottom-Feeder, Spambot, Dont-Bother-Me에 매치됨.

Disallow와 Allow 줄들

이 줄들은 특정 로봇에 대해 어떤 URL 경로가 명시적으로 금지외어 있고 명시적으로 허용되는지 기술한다.

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

URL과 맞는 하나의 Allow/Disallow 줄에 대해, 규칙 경로는 반드시 그 맞춰보고자 하는 경로의 대소문자를 구분하는 접두어야야한다.
예를들어 'Disallow: /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

9.6 검색 엔진

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

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

오늘날 검색엔진들은 그들이 갖고 있는 전 세계의 웹페이지들에 대해 '풀 텍스트 색인(full-text indexes)'이라고 하는 복잡한 로컬 데이터베이스를 생성한다.

검색 엔진 크롤러들은 웹페이지들을 수집하여 집으로 가져와서, 이 풀 텍스트 색인에 추가한다. 동시에, 검색엔진 사용자들은 구글과 같은 웹 검색 게이트 웨이를 통해 풀 텍스트 색인에 대한 질의를 보낸다.
(크롤링을 한번 하는데 걸리는 시간이 상당한 데 비해 웹 페이지들은 매 순간 변화하기 때문에, 풀 텍스트 색인은 기껏 해봐야 웹의 특정 순간에 대한 스냅숏에 불과하다.)

9.6.3 풀 텍스트 색인

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

  • 단어 'a'는 문서 A와 B에 들어있다.
  • 단어 'best' 는 문서 A와 C에 들어있다.
  • 단어 'drill'은 문서 A와 B에 들어있다.
  • 단어 'the'는 세문서 A,B,C 모두에 들어있다.

9.6.4 질의 보내기

사용자가 질의를 웹 검색엔진 게이트웨이로 보내는 방법은, HTML폼을 사용자가 채워 넣고 브라우저가 폼을 HTTP GET이나 POST 요청을 이용해서 게이트웨이로 보내는 식이다.

사용자는 'drills'를 검색 상자 폼에 타이핑하고 브라우저는 이를 질의 매개변수를 URL의 일부로 포함하는 GET 요청으로 번역한다.
웹서버는 이 질의를 받아서 검색 게이트웨이 애플리케이션에게 넘겨주면, 게이트웨이는 웹 서버에게 문서의 목록의 결과로 돌려주고, 웹 서버는 이 결과를 사용자를 위한 HTML 페이지로 변환한다.

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

질의의 결과를 확인하기 위해 검색엔진이 색인을 한번 사용했다면, 게이트웨이 애플리케이션은 그 결과를 이용해 최종 사용자를 위한 결과 페이지를 즉석에서 만들어낸다.
많은 웹페이지가 주어진 단어를 포함할 수 있기 때문에, 검색 엔진은 결과에 순위를 매기기 위해 알고리즘을 사용한다.

예를들어 복수개의 문서에 단어 'best'가 나타나고 있을때. 검색엔진은 그 문서들이 주어진 단어와 가장 관련이 많은 순서대로 결과 문서에 나타날 수 있도록 문서들 간의 순서를 알 필요가 있다. 이것을 관련도 랭킹이라고 하며 검색 결과의 목록에 점수를 매기고 정렬하는 과정이다.

예를들어 어떤 주어진 페이지를 가리키는 링크들이 얼마나 많은지 세는 것은 그 문서의 인기도를 판별하는데 도움이된다.
(정렬 순서에 대한 가중치로 사용될 수 있다.)

profile
공효은
잼나게 코딩하면서 살고 싶어요 ^O^/

0개의 댓글