9. 웹 로봇

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

• 방식에 따라 크롤러, 스파이더, 웜, 봇 등 다양한 이름으로 불림.

• ex) 주식 그래프 로봇, 웹 통계 조사 로봇, 검색엔진 로봇, 가격 비교 로봇

크롤러와 크롤링

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

• 웹을 따라 기어다니기(crawl) 때문에 크롤러, 또는 스파이더라고 부름.

• 이 문서들은 검색 가능한 데이터베이스로 만들어짐 (검색 엔진 크롤러).

크롤러의 시작점

• 크롤러가 방문을 시작하는 URL들의 초기 집합을 루트 집합(root set)이라고 부름.
💡
URL은 게이트웨이 애플리케이션임.

• 루트 집합을 고를 때 웹페이지들의 대부분을 가져올 수 있도록 충분히 다른 장소에서 URL을 선택해야 함.

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

• 이에 따라 루트 집합에 새 페이지나 잘 알려지지 않은 페이지들이 추가되고 시간이 지남에 따라 성장하며 새로운 크롤링을 위한 시드 목록이 됨.

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

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

• 또한 간단한 HTML 파싱을 통해 이들 링크들을 추출하고 상대 링크를 절대 링크로 변환할 필요가 있음.

순환 피하기

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



• a가 b를 링크하고 b가 c를 링크하고 c가 a를 링크하면 a, b, c를 계속 가져오게 되는 순환에 빠짐.

• 이를 방지하기 위해 반드시 로봇이 어디에 방문했는지 알아야 함.

루프와 중복

• 순환은 다음과 같은 이유로 크롤러에게 해로움.
1. 크롤러가 무한 루프에 빠지면 네트워크 대역폭을 다 차지하여 어떤 페이지도 가져올 수 없게 됨.
2. 크롤러가 같은 페이지를 반복해서 가져오면 고스란히 웹 서버의 부담됨. 웹 사이트를 압박할 수 있고 실제 사용자도 접근을 못할 경우가 생김. 이런 서비스 방해 행위는 법적 문제제기의 근거가 될 수 있음.
3. 비록 루프 자체가 문제가 되지 않더라도, 크롤러는 많은 수의 중복된 페이지들을 가져오게 됨. 이로 인해 크롤러의 애플리케이션은 쓸모없는 중복된 콘텐츠로 넘쳐나게 될 것임.

빵 부스러기의 흔적

• 방문한 곳을 지속적으로 추적하는 것은 쉽지 않음.

• 만약 전 세계 웹 콘텐츠의 상당 부분을 크롤링하려 한다면, 속도와 메모리 면에서 효과적이어야 함. 따라서 복잡한 자료 구조를 사용해야 함.
• 트리와 해시 테이블
• 느슨한 존재 비트맵
• 공간 사용을 최소화하기 위해, 존재 비트 배열(presence bit array) 자료구조를 사용함.
• 존재 비트란 URL이 해시 함수에 의해 고정된 크기의 숫자로 변환되고 배열 안에 대응되는 것을 말함.
• URL이 크롤링되었을 때 해당하는 존재 비트가 만들어짐.
• 존재 비트가 이미 존재한다면 크롤러는 그 URL을 이미 크롤링 했다고 간주함.
💡
거의 희박하지만 충돌할 잠재적인 가능성이 존재함.
• 체크포인트
• 로봇 프로그램이 갑작스럽게 중단될 경우를 대비해, 방문한 URL의 목록이 디스크에 저장되었는지 확인함.
• 파티셔닝
• 웹이 성장하면서 한 대의 컴퓨터가 감당하기 힘들어짐.
• 그래서 각각이 한 대의 컴퓨터인 로봇들이 동시에 일하는 농장(farm)을 이용함.



• 개별 로봇들은 URL을 이리저리 넘겨주거나, 오동작하는 동료를 도와주거나, 활동 조정을 위한 커뮤니케이션을 함.

별칭(alias)과 로봇 순환

• 올바른 자료 구조를 갖추었더라도 URL이 별칭을 가질 수 있는 이상 어떤 페이지를 이전에 방문했는지 알기 쉽지 않을 때도 있음.

URL 정규화하기

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

• 로봇은 다음과 같은 방식으로 URL을 정규화된 형식으로 변환함.
1. 포트 번호가 명시되지 않았다면, 호스트명에 ':80'을 추가한다.
2. 모든 %xx 이스케이핑된 문자들을 대응되는 문자로 변환한다.
3. # 태그들을 제거한다.

• 이 단계들은 위 표의 a~c까지 보여진 문제를 제거할 수 있음.

• 그러나 d~f는 웹 서버에 대한 지식 없이 중복을 피할 수 있는 좋은 방법은 없음.
• d : 웹 서버가 대소문자를 구분하는지 알아야 함.
• e : URL이 같은 리소스를 가리키는지 알려면 디렉터리에 대한 웹 서버의 색인 페이지 설정을 알아야 함.
• f : URL의 IP 주소가 같은 물리적 컴퓨터를 참조하는지, 웹 서버가 가상 호스팅을 하도록 설정되어 있는지 알아야 함.

파일 시스템 링크 순환

• 파일 시스템의 심벌링 링크는 사실상 아무것도 존재하지 않음에도 끝없이 깊어지는 디렉터리 계층을 만들 수 있기 때문에 매우 교묘한 종류의 순환을 유발할 수 있음.

• 그림 b의 문제는, subdir/이 /로 링크되어 있기 때문에 순환되는 것이지만 URL이 달라보이기 때문에 로봇은 URL만으로는 문서가 같다는 것을 모름.

• 이를 악의적으로 만들 수 있고, 그렇지 않을 수도 있음.
• ex) 같은 서버에 있는 가상의 URL에 대한 링크를 포함한 HTML을 만듦, 다음 달로 링크를 걸어주는 CGI 기반의 달력 프로그램.

루프와 중복 피하기

• 모든 순환을 피하는 완벽한 방법은 없지만, 웹에서 로봇이 더 올바르게 동작하기 위해 사용하는 기법들은 다음과 같음.
• URL 정규화
• URL을 표준 형태로 변환함으로써, 같은 리소스를 가리키는 중복된 URL이 생기는 것을 일부 회피함.
• 너비 우선 크롤링
• 로봇 함정을 건드려도 해당 페이지를 받아오기 전 다른 웹 사이트들에서 수십만 개의 페이지들을 받아올 수 있음.
• 스로틀링
• 로봇이 웹 사이트에서 일정 시간 가져올 수 있는 페이지 숫자를 제한함.
• URL 크기 제한
• 로봇은 일정 길이(보통 1KB)를 넘는 URL의 크롤링을 거부할 수 있음.
• 하지만 이 방법은 긴 URL 크롤링을 실패할 가능성이 있음.
• 그래서 이 기법은 요청 URL이 특정 크기에 도달할 때마다 에러 로그를 남김.
• URL/사이트 블랙리스트
• 사람이 직접 크롤링 되는 것을 원치않는 특정 사이트를 피하기 위해 사용함.
• 패턴 발견
• 반복되는 구성요소를 가진 URL이 잠재적인 순환으로 보고 크롤링을 거절함.
• 콘텐츠 지문
• 지문처럼 페이지의 콘텐츠에서 몇 바이트를 얻어내어 체크섬 계산함.
• 지문 생성용으로는 MD5와 같은 메시지 요약 함수가 있음.
• 사람의 모니터링
• 웹은 거친 곳이기 때문에 거대한 데이터 집합을 크롤링하기 위한 좋은 스파이더 휴리스틱을 만드는 작업은 언제나 현재진행형임.
 

로봇의 HTTP

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

• 로봇은 콘텐츠 요청을 위한 HTTP를 최소한으로만 구현하려고 하기 때문에 요구사항이 적은 HTTP/1.0 요청을 보냄.

요청 헤더 식별하기

• 로봇 개발자들은 로봇의 능력, 신원, 출신을 알려주는 다음과 같은 신원 식별 헤더(특히 User-Agent HTTP 헤더)를 사이트에 보내주는 것이 좋음.
• User-Agent: 서버에게 요청을 만든 로봇의 이름을 알려줌.
• From: 로봇의 사용자/관리자의 이메일 주소를 제공함.
• Accept: 서버에게 어떤 미디어 타입을 보내도 되는지 말해줌.
• Referer: 현재의 요청 URL을 포함한 문서의 URL을 제공함. 어떻게 로봇이 그들 사이트의 콘텐츠에 대한 링크를 발견했는지 알아내고 싶은 사이트 관리자들에게 매우 유용함.

가상 호스팅

• 로봇 개발자들은 Host 헤더를 지원할 필요가 있다. 만약 요청에 이 헤더를 포함하지 않으면 로봇이 어떤 URL에 대해 잘못된 콘텐츠를 찾게 만듦.

• 서버는 두 사이트 모두를 운영하도록 설정되어 있기는 하지만, 기본적으로는 조의 하드웨어를 운영함. 이때 크롤러는 조의 하드웨어에서 받은 콘텐츠를 www.foo.com에서 온 것으로 생각할 것임.

조건부 요청

• 로봇들은 때때로 극악한 양의 요청을 시도할 수도 있기 때문에, 로봇이 검색하는 콘텐츠의 양을 최소화하면 좋음.

• 시간, 엔티티 태그를 비교함으로써 그들이 받아간 마지막 버전 이후에 업데이트 된 것이 있는지 알아보는 조건부 HTTP 요청을 구현함.
• HTTP 캐시의 로컬 사본 유효성 검사 방법과 비슷.

응답 다루기

• 단순히 GET 메서드로 콘텐츠를 요청하는 대다수의 로봇들은 응답 다루기라고 부를 만한 일을 거의 하지 않지만, 종종 HTTP의 조건부 요청과 같은 특정 몇몇 기능을 사용하는 로봇들 또는 웹 탐색이나 서버와의 상호작용을 더 잘 해보려고 하는 로봇들은 여러 종류의 HTTP 응답을 다룰줄 알아야 함.
• 상태 코드
• 200, 400 정도는 이해해야 함.
• 엔터티
• HTTP 헤더에 임베딩된 정보를 따라 로봇들은 엔터디 자체의 정보를 찾을 수 있음.
• ex) <meta http-equiv="Refresh" content="1;URL=index.html">
• http-equiv 태그 자체는 콘텐츠 저자가 콘텐츠를 다루는 서버가 제공할 수도 있는 헤더를 덮어쓰기 위한 수단임.

User-Agent targeting

• 웹 관리자들은 많은 로봇이 자신의 사이트를 방문하게 될 것임을 명심하고, 그 로봇들로부터의 요청을 다루기 위한 전략을 세워야 함.

• ex) 특정 브라우저의 기능이 지원되는 것을 전제하여 콘텐츠를 개발하는 대신, 풍부한 기능을 갖추지 못한 브라우저나 로봇 등 다양한 클라에 잘 대응하는 유연한 페이지 개발.

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

• 로봇들이 저지르는 실수 몇 가지와 그로 인해 초래되는 경우가 있음.

• 폭주하는 로봇
• 만약 로봇이 논리적인 에러를 갖고 있거나 순환에 빠졌다면 웹 서버에 극심한 부하를 안겨줄 수 있음.

• 길고 잘못된 URL
• 순환이나 프로그램명 상의 오류로 인해 로봇은 웹 사이트에게 크고 의미없는 URL을 요청할 수 있다.음 이러한 문제는 웹 서버 처리 능력에 영향을 주고, 접근 로그를 어지럽게 채울 수 있음.

• 호기심이 지나친 로봇
• 사적인 데이터에 대한 URL을 얻어 그 데이터를 인터넷 검색엔진이나 기타 애플리케이션을 통해 쉽게 접근할 수 있도록 만들 수도 있음.
• 인터넷에 링크가 존재하는한 진정한 의미의 사적인 리소스는 없음.
• 하지만 비밀번호 파일이나 신용카드 정보 등 민감한 데이터를 포함할 경우 사생활 침해라고 여겨질 수도 있음.

• 동적 게이트웨이 접근
• 게이트웨이 애플리케이션의 콘텐츠에 대한 URL로 요청을 할수도 있음. 이런 경우는 특수 목적을 위한 것일 테고 처리 비용이 많이 들 것임.

로봇 차단하기

• 1994년, 로봇이 맞지 않는 장소에 들어오지 않게 하고, 웹 마스터에게 로봇의 동작을 잘 제어할 수 있는 메커니즘을 제공하는 방법이 제안됨.

• 이 표준은 Robots Exclustion Standard, robots.txt라고 불림.

• 웹 서버의 문서 루트에 해당 이름이 붙은 선택적인 파일을 제공함. 이 파일은 어떤 로봇이 서버의 어떤 부분에 접근할 수 있는지에 대한 정보가 담겨있음.

• ex) 특정 URL을 다운 받기 전 robots.txt를 가져와서 대상 파일을 크롤링하기 전에 접근해도 되는지 확인함.

로봇 차단 표준

• 로봇 차단 표준에는 세 가지 버전이 존재함.

• 오늘날 대부분의 로봇들은 v0.0이나 v1.0을 채택함.

웹 사이트와 robots.txt 파일들

• 웹 마스터는 웹 사이트의 모든 콘텐츠에 대한 차단 규칙을 종합적으로 기술한 robots.txt 파일을 생성할 책임이 있음.

• robots.txt 가져오기
• 로봇은 HTTP GET 메서드를 이용해 robots.txt 리소스를 가져옴.

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

robots.txt 파일 포맷

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

User-Agent: * 
Disallow:

• robots.txt의 줄들은 레코드로 구분됨.

• 레코드는 어떤 로봇이 이 레코드에 영향을 받는지 지정하는 하나 이상의 User-Agent 줄로 시작하며 뒤이어 이 로봇들이 접근할 수 있는 URL들을 말해주는 Allow 줄과 Disallow 줄이 옴.

• 구성 요소
• User-Agent
• 상위 예시처럼 로봇의 이름을 지정하거나 전체를 허용할 수 있음.
• 만약 해당 키워드가 없다면 모두가 접근할 수 있음.
• 이때 대소문자를 구분하지 않으니 주의 해야 함.
• ex) bot과 매치되는 경우 - Bot , Robot , Bottom-Feeder , Spambot , Dont-Bother-Me .
• Disallow, Allow
• 특정 로봇에 대해 어떤 URL 경로가 명시적으로 금지되어 있고 허용되는지 기술함.
• 첫 번째로 맞은 것이 사용되고 어떤 것도 맞지 않으면 그 URL은 허용됨.
• 접두어가 매칭될 때 규칙이 실행됨.

• 접두 매칭은 꽤 잘 동작하지만, 어떤 경로 밑에 있느냐와 상관없이 특정 이름의 디렉터리에 대해서는 크롤링을 하지 못하게 하고 싶을 수 있는데, robots.txts는 이를 표현할 수단을 제공하지 않음.

• 추가로 v0.0은 Allow를 지원하지 않음. 로봇은 자신이 이해하지 못하는 필드는 무시하기 때문에 0.0의 명세만 구현하고 Allow는 무시함. 이런 경우 로봇은 보수적으로 동작하기에 허용되는 URL도 탐색하지 않을 수 있음.

robots.txt의 캐싱과 만료

• 로봇은 매 파일 접근마다 robots.txt 파일을 새로 가져오는 것이 아닌, 주기적으로 파일을 가져와서 그 결과를 캐시해야 함.

• 캐시된 사본은 robots.txt 파일이 만료될 때까지 로봇에 의해 사용됨.

• 로봇 명세 초안은 Cache-Control 지시자가 존재하는 경우 7일간 캐싱하도록 하고 있지만, 실무 기준 긴 편이기에 기간 설정에 주의해야 함.
• 몇몇 대규모 웹 크롤러는 웹을 활발히 크롤링하는 기간 동안에는 robots.txt를 매일 새로 가져온다는 규칙을 따름.

HTML 로봇 제어 META 태그

• robots.txt 파일은 웹 사이트 관리자가 이를 소유하기 때문에 개개인이 로봇의 접근을 막는 방법으로 HTML 문서에 직접 로봇 제어 태그를 추가하는 것이 있음.

• 로봇 META 지시자
• 무시하는 키워드
• NOINDEX
• NOFOLLOW
• NONE
• NOARCHIVE
• 인식하게 하는 키워드
• INDEX
• FOLLOW
• ALL

<html> 
 <head> 
 <meta name="robots" content="noindex,nofollow"> 
 <title>...</title> 
 </head> 
 <body> 
 ... 
 </body> 
</html>

• name, content는 대소문자를 구분하지 않음.

• 지시자들이 서로 충돌하거나 중복되면 안됨.

로봇 에티켓

• 신원 확실하게 밝히고 감시 잘하고 효율적으로 만들고 분석하고 대응 잘해라.

검색엔진

• 웹 로봇을 가장 광범위하게 사용하는 것은 인터넷 검색엔진임.

• 복잡한 질의 엔진이 필요한 것과 마찬가지로, 검색엔진은 수십억 개의 웹페이지들을 검색하기 위해 복잡한 크롤러를 사용해야 함.

• 크롤러의 요청이 0.5초가 걸린다고 가정할 때 십억 개의 문서에 대해 0.5 seconds X (1,000,000,000) / ((60 sec/day) X (60 min/hour) X (24 hour /day))가 걸림

• full-text-indexes
• 단어 하나를 입력받아 그 단어를 포함하고 있는 문서를 즉각 알려줄 수 있는 데이터베이스.

• 질의 보내기



• 사용자는 drills를 폼에 입력하고 브라우저는 이를 질의 매개변수를 URL의 일부로 포함하는 GET 요청으로 번역함.
• 죠의 하드웨어 웹 서버는 이 질의를 받아서 검색 게이트웨이 애플리케이션에게 넘겨주면, 게이트웨이 웹 서버에게 문서의 목록을 결과로 돌려주고, 웹 서버는 이 결과를 사용자를 위한 HTML 페이지로 변환함.
• 많은 웹페이지가 주어진 단어를 포함할 수 있기 때문에, 검색엔진은 결과에 순위를 매기기 위해 알고리즘을 사용함.
• 관련도 랭킹(relevancy ranking)은 검색 결과의 목록에 점수를 매기고 정렬하는 과정임.
• 이 과정을 더 잘 지원하기 위해, 인기도 등 다양한 지표를 활용함.

• 스푸핑
• 가짜 페이지가 크롤러를 더 잘 속이고, 이에 따라 크롤러도 진화하는 끊없는 싸움을 스푸핑이라 함.