[HTTP] 웹 로봇 2

로봇의 HTTP

 로봇들은 다른 HTTP 클라이언트 프로그램과 다르지 않다. 그들 또한 HTTP 명세의 규칙을 지켜야 한다. HTTP 요청을 만들고 스스로를 HTTP/1.1 클라이언트라고 광고하는 로봇은 적절한 HTTP 요청 헤더를 사용해야 한다. 

 하지만 많은 로봇들은 그들이 찾는 콘텐츠를 요청하기 위해 필요한 HTTP를 최소한으로만 구현하려고 한다. 그래서 요구사항이 적은 HTTP/1.0으로 요청을 보내는 경우가 많다. 

 

요청 헤더 식별하기

로봇 개발자들이 구현하도록 권장되는 기본적인 신원 식별 헤더들에는 다음과 같은 것이 있다.

 

- User-Agent

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

 

- From 

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

 

- Accept

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

 

- Referer

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

 

가상 호스팅

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

참고: https://stackoverflow.com/questions/43156023/what-is-http-host-header

 

조건부 요청

 때때로 로봇들이 극악한 양의 요청을 시도한다는 것을 고려할 때, 로봇이 검색하는 콘텐츠의 양을 최소화하는 것은 상당히 의미 있는 일이다. 수십억 개의 웹페이지를 다운로드하게 될 수도 있는 인터넷 검색엔진 로봇과 같은 경우, 오직 변경되었을 때만 콘텐츠를 가져오도록 하는 것은 의미가 있다. 

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

 

응답 다루기

대다수 로봇들은 주 관심사가 단순히 GET 메서드로 콘텐츠를 요청해서 가져오는 것이기 때문에, 응답 다루기라고 부를 만한 일은 거의 하지 않는다. 그러나 HTTP의 특정 몇몇 기능(조건부 요청 등)을 사용하는 로봇들이나, 웹 탐색이나 서버와 상호작용을 더 잘해보려고 하는 로봇들은 여러 종류의 HTTP 응답을 다룰 줄 알아야 한다.

 

상태 코드

일반적으로 로봇들은 최소한 일반적인 상태 코드나 예상할 수 있는 상태 코드를 다룰 수 있어야 한다. 하지만 모든 서버가 언제나 적절한 에러 코드를 반환하지 않는다는 걸 알아두는 게 중요하다.

 

엔터티

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

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

 

User-Agent Targeting

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

많은 웹 사이트들은 브라우저의 종류를 감지하여 그에 맞게 콘텐츠를 최적화한다. 이것을 함으로써 사이트는 로봇에게 콘텐츠 대신 "Your browser doesn't support frames"라는 에러 페이지를 제공해 버린다.

따라서 사이트 관리자들은 로봇의 요청을 다루기 위한 전략을 세워야 하며, 다양한 클라이언트에 잘 대응하는 유연한 페이지를 개발해야 한다. 최소한 로봇이 그들의 사이트에 방문했다가 콘텐츠를 얻을 수 없어 당황하는 일이 없도록 해야 한다.

 

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

로봇들이 저지르는 실수와 그로 인해 초래되는 몇 가지 결과를 보자.

 

폭주하는 로봇

로봇은 웹 서핑을 하는 사람보다 훨씬 빠르게 HTTP 요청을 만들 수 있다. 로봇들이 논리적인 에러를 갖고 있거나 순환에 빠졌다면 웹 서버에 극심한 부하를 안겨줄 수 있으며, 이것이 서버에 과부하를 유발하여 다른 누구에게도 서비스를 못하게 만드는 일도 분명히 있을 수 있다. 

 

오래된 URL

몇몇 로봇은 URL 목록을 방문하며, 그 목록은 오래되었을 수도 있다. 만약 웹 사이트각 그들의 콘텐츠를 많이 바꾸었다면, 로봇들은 존재하지 않는 URL에 대한 요청을 많이 보낼 수 있다. 이것은 존재하지 않는 문서에 대한 접근 요청으로 에러 로그가 채워지거나, 에러 페이지를 제공하는 부하로 인해 웹 서버의 요청에 대한 수용 능력이 감소될 수 있다.

 

길고 잘못된 URL 

 크고 의미 없는 URL은 웹 서버의 접근 로그를 어지럽게 채우고, 심지어 허술한 웹 서버라면 고장을 일으킬 수도 있다.

 

호기심이 지나친 로봇

 어떤 로봇들은 사적인 데이터에 대한 URL을 얻어 그 데이터를 인터넷 검색엔진이나 기타 애플리케이션을 통해 쉽게 접근할 수 있도록 만들 수도 있다(사실 인터넷에 링크가 존재하는 한 진정한 의미의 사적인 리소스는 거의 없다). 또한 비밀번호 파일이나 심지어 신용카드 정보들을 로봇들은 검색할 수도 있다. 이러한 콘텐츠를 무시하는 (그리고 검색 색인이나 아카이브에서 제거하는) 메커니즘은 명백히 중요하다. 

구글의 검색 결과를 보더라도 "저장된 페이지"라는 이름으로 크롤링한 페이지들을 그대로 보관하기 때문에 콘텐츠가 제거되더라도 일정 시간 동안에는 여전히 검색되고 접근 가능하다.

 

동적 게이트웨이 접근

로봇들이 그들이 접근하고 있는 것에 대해 언제나 잘 알고 있는 것은 아니기 때문에 게이트웨이 애플리케이션의 콘텐츠에 대한 URL로 요청을 할 수도 있다. 이 경우 얻은 데이터는 아마도 특수 목적을 위한 것일 테고 처리 비용이 많이 들것이다. 

 

로봇 차단하기

네이버 지식iN - robots.txt

 로봇에 의한 웹 사이트 접근이 유발할 수 있는 문제 때문에 로봇을 차단할 수 있다. 가장 기본적인 방식은 1994년에 발표된 REP (Robots Exclusion Standard Protocol)라는 표준을 따르는 것이다. 로봇의 접근을 제어하는 정보를 저장하는 파일의 이름을 따서 종종 robots.txt라고 불린다.

 robots.txt의 아이디어는 단순하다. 웹 서버의 문서 루트에 robots.txt라고 이름을 붙인 파일을 제공하는 것이다. 이 파일은 어떤 로봇이 서버의 어떤 부분에 접근할 수 있는지에 대한 정보가 담겨있다. 위에 있는 예시 이미지처럼 말이다. 어떤 로봇이 이 자발적인 표준에 따른다면, 웹 사이트의 어떤 리소스에 접근하기 전에 우선 robots.txt를 요청할 것이다. 그리고 권한이 있는지 확인 후에 접근이 허용된다면 요청을 계속 진행하게 된다. 

 하지만 이것은 '자발적인 표준'이라는 것이다. 즉 강제성은 없다. 구글 같은 대형 검색엔진은 이를 철저하게 준수하지만, 작은 로봇들은 이를 지키지 않을 수 있다.