[9장] 웹 로봇

janjanee·2022년 8월 1일
HTTP 완벽가이드http웹 로봇
0

[스터디] HTTP 완벽 가이드

목록 보기
9/14
post-thumbnail

2020.12.13 작성글 이전

9장 웹 로봇

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

  • 크롤러, 스파이더, 웜, 봇 등 다양한 이름으로 불린다.

웹 로봇의 몇 가지 예를 들어보자.

  • 주식시장 서버에 매 분 HTTP GET 요청을 보내고, 얻은 데이터를 활용해 주가 추이 그래프를 생성하는 주식 그래프 로봇
  • 월드 와이드 웹의 규모와 진화에 대한 통계 정보를 수집하는 웹 통계 조사 로봇
  • 검색 데이터베이스를 만들기 위해 발견한 모든 문서를 수집하는 검색엔진 로봇
  • 상품에 대한 가격 데이터베이스를 만들기 위해 온라인 쇼핑몰의 카탈로그에서 웹 페이지를 수집하는 가격비교 로봇

9.1 크롤러와 크롤링

웹 크롤러
웹 페이지 한 개 -> 한 개가 가리키는 모든 웹페이지 -> 모든 웹페이지가 가리키는 모든 웹페이지를 따라
웹 링크를 재귀적으로 따라가는 로봇 (크롤러 혹은 스파이더)

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

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

  • 루트 집합을 고를 때, 모든 링크를 크롤링하면 결과적으로 관심 있는 웹 페이지들의 대부분을 가져올 수 있도록

    충분히 다른 장소에서 URL들을 선택해야 한다.

  • 일반적으로 좋은 루트 집합은 크고 인기있는 웹 사이트(www.google.com), 새로 생성된 페이지들의 목록,

    자주 링크되지 않는 잘 알려지지 않은 페이지들의 목록으로 구성

  • 대규모 크롤러 제품들은 사용자들이 루트 집합에 새 페이지나 잘 알려지지 않는 페이지들을 추가하는 기능을 제공한다.

    시간이 지남에 따라 성장하며 새로운 크롤링을 위한 시드 목록이된다.

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

  • 크롤러는 웹을 돌아다니며 HTML 문서를 검색한다.
    • 검색한 각 페이지 안에 있는 URL 링크들을 파싱해서 크롤링할 페이지들의 목록에 추가한다.
  • 크롤링을 진행하면서 탐색해야 할 새 링크를 발견하면, 이 목록은 급속히 확장된다.
  • HTML을 파싱해서 이들 링크들을 추출하고 상대 링크를 절대 링크로 변환해야 한다.

9.1.3 순환 피하기

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

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

9.1.4 루프와 중복

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

  1. 크롤러를 루프에 빠뜨린다. 루프에 빠져 어떤 페이지도 가져오지 못할 수 있다.
  2. 같은 페이지를 계속 가져오면 웹 서버 부담이 된다.
  3. 크롤러는 많은 수의 중복된 페이지들을 가져오게 된다.

9.1.5 빵 부스러기의 흔적

대규모 웹 크롤러가 그들이 방문한 곳을 관리하기 위해 사용하는 유용한 기법 몇 가지를 살펴보자.

  • 트리와 해시 테이블
    • 검색 트리나 해시 테이블을 사용
    • URL을 훨씬 빨리 찾아볼 수 있게 해주는 소프트웨어 자료구조다.
  • 느슨한 존재 비트맵
    • 존재 비트 배열(presence bit array)과 같은 느슨한 자료구조를 사용한다.
    • 각 URL은 해시 함수에 의해 고정된 크기의 숫자로 변환되고 배열 안에 대응하는 '존재 비트(presence bit)'를 갖는다.
    • URL이 크롤링 되었을 때, 해당하는 존재 비트가 생성
      • 이미 존재한다면, 크롤러는 그 URL이 이미 크롤링 되었다고 간주
  • 체크포인트
    • 로봇이 갑자기 중단될 경우를 대비해, 방문한 URL의 목록이 디스크에 저장되었는지 확인
  • 파티셔닝
    • 웹의 성장으로 인해 컴퓨터 한 대에서 크롤링을 완수하는 건 불가능해짐
    • 몇몇 대규모 웹 로봇은 각각이 분리된 한 대의 컴퓨인 로봇들이 동시에 일하고 있는 '농장'을 이용한다.
    • 각 로봇엔 URL들의 특정 '한 부분'이 할당되어 그에 대한 책임을 진다.

9.1.6 별칭(alias)과 로봇 순환

URL이 별칭을 가질 수 있는 이상 어떤 페이지를 이전에 방문했는지 말해주는게 쉽지 않을 수 있다.
한 URL이 또 다른 URL에 대한 별칭이라면, 그 둘이 달라보여도 사실은 같은 리소스를 가리키고 있다.

다음은 다른 URL이 같은 리소스를 가리키게 되는 몇 가지 상황이다.

// 기본 포트가 80일 떄
http://www.foo.com/bar.html
http://www.foo.com:80/bar.html

// %7F이 ~와 같을 때
http://www.foo.com/~fred
http://www.foo.com/%7Ffred

// 태그에 따라 페이지가 바뀌지 않을 때
http://www.foo.com/x.html#early
http://www.foo.com/x.html#middle

// 서버가 대소문자 구분하지 않을 때
http://www.foo.com/readme.html
http://www.foo.com/README.HTML

// 기본 페이지가 index.html 일 때
http://www.foo.com/index.html
http://www.foo.com/

9.1.7 URL 정규화하기

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

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

9.1.8 파일 시스템 링크 순환

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

(a)의 파일시스템을 사용해, 웹 크롤러는 다음의 동작을 수행한다.

(b)의 파일시스템 에서는 다음과 같은 일이 벌어진다.

(b)의 문제는 로봇이 심벌릭 링크 순환을 알아차리지 못하고 URL이 달라서 루프로 빠져들 위험이 있다.

9.1.9 동적 가상 웹 공간

악의적인 누군가가 로봇들을 함정으로 빠뜨리기 위해 의도적으로 복잡한 크롤러 루프를 만드는 경우도 있다.
또는, 나쁜 뜻이 없음에도 자신도 모르게 심벌릭 링크나 동적 콘텐츠를 통한 크롤러 함정을 만들 수 있다.

9.1.10 루프와 중복 피하기

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

  • URL 정규화

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

  • 너비 우선 크롤링

    • 방문할 URL들을 웹 사이트들 전체에 걸쳐 너비 우선으로 스케줄링하면, 순환의 영향을 최소화 할 수 있음
    • 깊이 우선 방식으로 운용하여 웹 사이트 하나에 성급하게 뛰어들어 순환을 건드리는 경우, 영원히 다른 사이트로 빠져나올 수 없음

  • 스로틀링

    • 로봇이 웹 사이트에서 일정 시간 동안 가져올 수 있는 페이지의 숫자를 스로틀링을 이용해 제한

  • URL 크기 제한

    • 로봇은 일정 길이(보통 1KB)를 넘는 URL의 크롤링은 거부할 수 있음
    • URL이 순환으로 인해 길어지면, 결국에는 길이 제한으로 중단될 수 있음
    • 주의할 점은 이 기법을 적용하면 가져오지 못하는 콘텐츠들도 틀림없이 있을 수 있음

  • URL/사이트 블랙리스트

    • 로봇 순환을 만들어 내거나 함정인 것으로 알려진 사이트와 URL 목록을 만들어 관리하고 그들을 피함

  • 패턴 발견

    • 파일 시스템의 심벌릭 링크를 통한 순환과 그와 비슷한 오설정들은 일정 패턴을 따름
    • 따라서 몇몇 로봇은 몇 가지 다른 주기의 반복 패턴을 감지

  • 콘텐츠 지문(fingerprint)

    • 페이지의 콘텐츠에서 몇 바이트를 얻어내어 체크섬을 계산

    • 이전에 보았던 체크섬을 발견하면 그 페이지의 링크는 크롤링하지 않음

    • 어떤 웹 서버들은 동적으로 그때그때 페이지를 수정하므로, 로봇들은 때때로 웹페이지 콘텐츠에 임베딩된 링크와

      같은 특정 부분들을 체크섬 계산에서 빠뜨림

  • 사람의 모니터링

    • 로봇은 결국 자신에게 적용된 어떤 기법으로 해결할 수 없는 문제에 봉착하게 됨
    • 따라서, 사람이 쉽게 로봇의 진행 상황을 모니터링해서 즉각 인지할 수 있게 반드시 진단과 로깅을 포함해야 함

9.2 로봇의 HTTP

9.2.1 요청 헤더 식별하기

로봇의 능력, 신원, 출신을 알려주는 기본적인 몇 가지 헤더를 사이트에게 보내주는 것이 좋다.
로봇 개발자들이 구현을 하도록 권장되는 기본적인 신원 식별 헤더들은 다음과 같다.

  • User-Agent
    • 서버에게 요청을 만든 로봇의 이름
  • From
    • 로봇의 사용자/관리자의 이메일 주소 제공
  • Referer
    • 현재의 요청 URL을 포함한 문서의 URL을 제공

9.2.2 가상 호스팅

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

9.2.3 조건부 요청

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

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

9.2.4 응답 다루기

대다수 로봇은 GET 메소드로 콘텐츠 요청을 하기 때문에, 응답 다루기라고 부를 만한 일은 거의 하지 않는다.
그러나, 웹 탐색이나 서버와 상호작용을 더 잘 해보려는 로봇들은 HTTP 응답을 다룰 필요가 있다.

  • 상태 코드
    • 최소한 일반적인 상태 코드나 예상할 수 있는 상태 코드를 다룰 수 있어야 한다.
    • 모든 로봇은 200 OK나, 404 Not Found와 같은 상태 코드를 이해해야 한다.
  • 엔터티
    • HTTP 헤더에 임베딩된 정보를 따라 로봇들은 엔터티 자체의 정보를 찾을 수 있다.

9.2.5 User-Agent 타기팅

  • 웹 관리자들은 많은 로봇이 그들의 사이트를 방문할 것을 명심하고, 그 로봇들로부터의 요청을 예상해야 한다.
  • 사이트 관리자들은 로봇의 요청을 다루기 위한 전략을 세워야 한다.
    • 예) 다양한 클라이언트에 잘 대응하는 유연한 페이지를 개발

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

  • 폭주하는 로봇
    • 로봇이 논리적 에러를 갖고 있거나 순환에 빠졌다면 웹 서버에 부하를 줄 수 있다.
  • 오래된 URL
    • 오래된 URL의 콘텐츠가 많이 바뀌었다면 로봇들은 존재하지 않는 URL에 대한 요청을 많이 보낼 수 있다.
  • 길고 잘못된 URL
    • 순환 및 프로그래밍 오류로 로봇은 크고 의미 없는 URL을 요청할 수 있다.
      • 웹 서버의 처리 능력에 영향을 주고, 웹 서버 접근 로그를 어지럽게 채우고, 허술한 웹 서버라면 장애를 일으킬 수 있다.
  • 호기심이 지나친 로봇
    • 사적인 데이터에 대한 URL을 얻어 그 데이터를 검색엔진이나 기타 애플리케이션을 통해 쉽게 접근할 수 있도록 할 수 있다.
  • 동적 게이트웨이 접근
    • 로봇은 게이트웨이 애플리케이션의 콘텐츠에 대한 URL로 요청할 수도 있다.
      • 여기서 얻은 데이터는 아마도 특수 목적을 위한 것일테고 처리 비용이 많이 들 것이다.

9.4 로봇 차단하기

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

예를 들어, 어떤 로봇이 http://www.gies-hardware.com/specials/test.html을 다운받는 요청을
하기 전에 먼저 해당 페이지를 가져올 수 있는 권한이 있는지 robots.txt 파일을 통해 검사한다.

9.4.1 로봇 차단 표준

로봇 차단 표준에는 버전의 이름이 잘 정의되어 있지 않지만 세 가지 버전이 존재한다.

  • 0.0 (1994년 6월)
    • 로봇 배제 표준-Disallow 지시자를 지원하는 마틴 코스터의 오리지널 robots.txt 메커니즘
  • 1.0 (1996년 11월)
    • 웹 로봇 제어 방법-Allow 지시자의 지원이 추가된 마틴 코스터의 IETF 초안
  • 2.0 (1996년 11월)
    • 로봇 차단을 위한 확장 표준-정규식과 타이밍 정보를 포함한 숀 코노의 확장. 널리 지원되지 않음.

오늘날 대부분의 로봇은 v0.0이나 v1.0표준을 채택했다.
널리 사용되고 v0.0과 완전 호환이 되는 v1.0표준에 초점을 맞추어 설명한다.

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

  • 어떤 웹 사이트에 robots.txt 파일이 존재한다면 로봇은 반드시 그 파일을 가져와서 처리해야 한다.
  • 만약 웹 사이트가 가상 호스팅 된다면, 각각의 가상 docroot에 다른 robots.txt가 있을 수 있다.

robots.txt 가져오기

  • HTTP GET 메소드를 이용해 robots.txt 리소스를 가져온다.
  • 만약 서버가 404 Not Found HTTP 상태 코드로 응답한다면 로봇은 그 서버는 로봇의 접근을 제한하지 않는 것으로 간주
  • 로봇은 사이트 관리자가 로봇의 접근을 추적할 수 있도록 From이나 User-Agent 헤더를 통해 신원정보를 남김

다음은 상용 웹 로봇이 보낼 수 있는 HTTP 크롤러 요청의 예다.

GET /robots.txt HTTP/1.0
Host: www.joes-hardware.com
User-Agent: Slurp/2.0
...

응답 코드

로봇은 robots.txt의 검색 결과에 따라 다르게 동작한다.

  • 서버가 (200)으로 응답하면 로봇은 반드시 그 응답의 콘텐츠를 파싱하여 차단 규칙을 얻고, 요청 시 그 규칙을 따른다.
  • 서버가 robots.txt 리소스가 존재하지 않는(404)로 응답하면 로봇은 제약없이 그 사이트에 접근한다.
  • 서버가 접근제한(401, 403)으로 응답하면 로봇은 그 사이트로의 접근을 완전히 제한됐다고 가정한다.
  • 요청 시도가 일시적 실패(503)라면 로봇은 그 사이트의 리소스 검색을 뒤로 미룬다.
  • 서버 응답이 리다이렉션(3XX) 이라면 로봇은 리소스가 발견될 때까지 리다이렉트를 따라간다.

9.4.3 robots.txt 파일 포맷

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

User-Agent: *
Disallow:

  • robots.txt의 이 줄들은 레코드로 구분된다. 각 레코드는 특정 로봇들의 집합에 대한 차단 규칙의 집합을 기술한다.

  • 각 레코드는 빈 줄이나 파일끝(end-of-file) 문자로 끝난다.

  • 어떤 로봇이 이 레코드에 영향을 받는지 지정하는 하나 이상의 User-Agent 줄로 시작하며 뒤이어 접근할 수 있는

    URL정보인 Allow줄과 Disallow줄이 온다.

위의 예는 robots.txt 파일이 Slurp과 Webcraweler 로봇들이 사적인 하위 디렉토리 안에 있는 것을 제외한
어떤 파일이든 접근할 수 있도록 허용한 것을 보여준다.
또한, 다른 로봇들이 이 사이트의 그 무엇에도 접근할 수 없도록 막는다.

User-Agent 줄

User-Agent: <robot-name>

or

User-Agent: *
  • 로봇의 이름(로봇 구현자에 의해 정해진)은 로봇의 HTTP GET 요청 안의 User-Agent 헤더를 통해 보내진다.

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

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

만약, 위의 두 조건의 줄을 찾지 못했다면, 대응하는 레코드가 없는 것이므로 접근에 어떠한 제한도 없다.

Disallow와 Allow 줄들

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

Disallow와 Allow 접두 매칭(prefix matching)

  • 경로의 시작부터 규칙 경로의 길이만큼의 문자열이 규칙 경로와 같아야 한다.(대소문자 차이 X)
  • User-Agent 줄과 달리 '*' 는 특별한 의미를 갖지 않지만, 대신 빈 문자열을 이용해 모든 문자열에 매치되도록 할 수 있다.
  • 규칙 경로나 URL 경로의 임의의 '이스케이핑된' 문자들(%XX)은 비교 전에 원래대로 복원된다.
    • 빗금(/)을 의미하는 %2F는 예외로, 반드시 그대로 매치되어야 함.
  • 만약 어떤 규칙 경로가 빈 문자열이라면, 그 규칙은 모든 URL 경로와 매치된다.
규칙 경로URL 경로매치?
/tmp/tmpO
/tmp/tmpfile.htmlO
/tmp//tmpX
빈 문자열README.TXTO
/~fred/hi.html%7Efred/hi.htmlO
/~fred/hi.html~fred%2Fhi.htmlX

9.4.4 그 외에 알아둘 점

  • robots.txt 파일은 명세가 발전함에 따라 다른 필드를 포함할 수 있다.
  • 하위 호환성을 위해, 한 줄을 여러 줄로 나누어 적는 것은 불가능
  • 주석은 파일의 어디에서든 허용된다.
  • 로봇 차단 표준 0.0은 Allow를 지원하지 않는다. 몇몇 로봇은 허용되는 URL도 탐색하지 않을 수 있음.

9.4.5 robots.txt의 캐싱과 만료

  • 로봇은 주기적으로 robots.txt를 가져와서 캐싱해야 한다.
  • 로봇은 HTTP응답의 Cache-Control과 Expires 헤더에 주의를 기울여야 한다.

9.4.6 HTML 로봇 제어 META 태그

  • HTML 문서에 직접 로봇 제어 태그를 추가할 수 있다.
  • robots.txt 표준과 마찬가지로 따르는 것이 권장되지만 강제하지는 않는다. 
<META NAME="ROBOTS" CONTENT=directive-list>

로봇 META 지시자

가장 널리 쓰이는 로봇 META 지시자 두 가지는 다음과 같다.

  • NOINDEX
    • 로봇에게 이 페이지를 처리하지 말고 무시하라는 메시지
    • <META NAME="ROBOTS" CONTENT="NOINDEX">
  • NOFOLLOW
    • 로봇에게 이 페이지가 링크한 페이지를 크롤링하지 말라고 전달
    • <META NAME="ROBOTS" CONTENT="NOFOLLOEW">

두 개 이외에 의미가 반대인 INDEX, FOLLOW 지시자와 ALL, NONE 지시자가 있다.

  • INDEX
    • 로봇에게 이 페이지의 콘텐츠를 인덱싱 해도 된다고 전달
  • FOLLOW
    • 로봇에게 이 페이지가 링크한 페이지를 크롤링해도 된다고 전달
  • NOARCHIVE
    • 로봇에게 이 페이지의 캐시를 위한 로컬 사본을 만들어서 안 된다고 전달
  • ALL
    • INDEX, FOLLOW와 같다.
  • NONE
    • NOINDEX, NOFOLLOEW와 같다.

HTML의 HEAD 섹션에 나타나야 하며, name과 content 값은 대소문자를 구분하지 않는다.

검색엔진 META 태그

name=content=설명
DESCRIPTION<텍스트>저자가 웹페이지의 짧은 요약을 정의할 수 있게 해준다.
KEYWORDS<쉼표 목록>키워드 검색을 돕기 위한, 웹페이지를 기술하는 단어를 쉼표로 구분
REVISIT-AFTER<숫자 days>지정된 만큼의 날짜가 지난 이후에 다시 방문해야 한다고 지시(그다지 널리 지원되지 않음)

9.5 로봇 에티켓

1993년 웹 로봇 커뮤니티의 개척자인 마틴 코스터는 웹 로봇을 만드는 사람들을 위한 가이드라인 목록을 작성했다.
몇 개는 구식이 되었지만, 대다수는 아직도 유용하다.
링크 :로봇 제작자들을 위한 가이드 라인

  • 신원 식별
    • 로봇의 신원을 밝혀라
    • 기계의 신원을 밝혀라
    • 연락처를 밝혀라
  • 동작
    • 긴장하라
    • 대비하라
    • 감시와 로그
    • 배우고 조정하라
  • 스스로를 제한하라
    • URL을 필터링 하라
    • 동적 URL을 필터링하라
    • Accept 관련 헤더로 필터링
    • robots.txt에 따르라
    • 스스로를 억제하라
  • 루프와 중복을 견뎌내기, 그리고 그 외의 문제들
    • 모든 응답 코드 다루기
    • URL 정규화하기
    • 적극적으로 순환 피하기
    • 함정을 감시하라
    • 블랙리스트를 관리하라
  • 확장성
    • 공간 이해하기
    • 대역폭 이해하기
    • 시간 이해하기
    • 분할 정복
  • 신뢰성
    • 철저하게 테스타하라
    • 체크포인트
    • 실패에 대한 유연성
  • 소통
    • 준비하라
    • 이해하라
    • 즉각 대응하라

자세한 설명은 p.277~279 참조

9.6 검색엔진

9.6.1 넓게 생각하라

수백만 명의 사용자들이 수십억 개의 웹페이지에서 원하는 정보를 찾는 상황에서, 수백만 명의 사용자들이
생성하는 질의로 인한 부하를 다루기 위해 복잡한 질의 엔진이 필요한 것과 마찬가지로,
검색엔진은 수십억 개의 웹페이지들을 검색하기 위해 복잡한 크롤러를 사용해야 한다.

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

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

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

9.6.3 풀 텍스트 색인

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

9.6.4 질의 보내기

  • 사용자는 'drills'를 검색 상자 폼에 타이핑하고 브라우저는 이를 질의 매개변수를 URL의 일부로 포함하는

    GET 요청으로 번역한다.

  • 죠의 하드웨어 웹 서버는 이 질의를 받아서 검색 게이트웨이 애플리케이션에게 넘겨준다.

  • 게이트웨이는 웹 서버에게 문서의 목록을 결과로 돌려주고, 웹 서버는 이 결과를 사용자를 위한 HTML 페이지로 변환한다.

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

많은 웹페이지가 주어진 단어를 포함할 수 있기 때문에, 검색엔진은 결과에 순위를 매기기 위해 똑똑한 알고리즘을 사용한다.

예를 들어, 사용자가 'hello' 를 검색했다면, 검색엔진은 주어진 단어와 관련이 많은 순서대로
결과 문서에 나타날 수 있도록 문서들 간의 순서를 알 필요가 있다.
이것은 관련도 랭킹(relevancy ranking)이라고 불리며 검색 결과의 목록에 점수를 매기고 정렬하는 과정이다.

검색엔진에 사용되는 알고리즘, 크롤링에 대한 팁, 그 외 각종 기교는 검색엔진의 가장 엄격히 감추어진 비밀들이다.

9.6.6 스푸핑

사용자들은 검색 결과 최상위 몇 줄에서 원하는 결과를 얻지 못하면 불만족스러워 해서 사이트의 검색 결과 순서는 중요하다.

검색 결과에 더 높은 순위를 차지하고자 하는 바람으로, 검색엔진과 자신의 사이트를 눈에 띄게 하려는 자들의
끝나지 않는 줄다기리가 만들어졌다.

  • 수많은 키워드들을 나열한 (관련이 없더라도) 가짜 페이지를 만들기
  • 검색엔진의 관련도 알고리즘을 더 잘 속일 수 있는, 특정 단어에 대한 가짜 페이지를 생성하는 게이트웨이 애플리케이션을 만들어 사용
profile
janjanee
얍얍 개발 펀치
이전 포스트

[8장] 통합점: 게이트웽, 터널, 릴레이

다음 포스트

[11장] 클라이언트 식별과 쿠키

0개의 댓글