웹 로봇과 HTTP 2.0

[ 2016.11.09 - HTTP Study 9~10 ]

09 Web Robot

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

● 로봇의 예○ 주식 그래프 로봇○ 웹 통계 조사로봇○ 검색엔진 로봇

○ 가격비교 로봇

● 방식에 따라 다양한 이름○ 크롤러, 스파이더, 웜, 봇 등

9.1 크롤러와 크롤링*Crawl : 기어다니다

● 웹페이지를 가져오고 그 페이지의 링크를 따라가서 다시 웹 페이지를 가져오는

것을 반복하는 방식으로 웹을 순회하는 로봇

● 루트집합에서 탐색시작

● 페이지에서 링크 추출 및 다음 순회목록에 추가

● 상대링크를 절대링크로 변환

● 순환을 피하기 위해 방문페이지 저장

순환

A

B E

C

D

A

B E

C

D

A

B E

C

D

그림 9-2 하이퍼링크의 웹을 크롤링하기

순환이 해로운 이유● 크롤러를 루프에 빠뜨려서 시간과 자원을 허비하게 만듬● 웹 서버에 부담을 가중시킴● 쓸모없는 중복된 크롤링 결과

순환을 피하기 위한 방법● 어떤 URL을 방문하였는지 빠르게 판단하기 위해서 복잡한 자료구조가 필요 함

○ 속도와 메모리 사용면에서 효과적이어야 함○ 트리와 해시테이블

■ URL을 훨씬 빨리 찾아볼 수 있게 해주는 소프트웨어 자료구조○ 느슨한 존재 비트맵

■ 각 URL은 해시 함수에 의해 고정된 크기의 숫자로 변환되고 배열 안에 대응하는 ‘존재 비트

(presence bit)’를 갖는다. URL이 크롤링이 되었을 때, 해당하는 존재 비트가 만들어진다 . 만약 존재 비트가 이미 존재하다면 , 크롤러는 그 URL을 이미 크롤링 되었다고 간주한다.*

○ 체크포인트

■ 로봇 프로그램이 갑작스럽게 중단될 경우를 대비해, 방문한 URL의 목록이 디스크에 저장되었는지 확인

○ 파티셔닝

■ 각 로봇엔 URL들의 특정 ‘한 부분'이 할당되어 그에 대한 책임을 진다.

URL 정규화● 별칭(alias)과 로봇 순환: 주소는 다르지만 같은 리소스를 가짐

● URL 정규화를 통해 alias를 회피○ 포트번호 추가, 이스케이핑 문자를 대응되는 문자로 대체, # 태그 제거○ 해결할 수 없는 문제: 대소문자, 색인정보, 가상호스팅

파일 시스템 링크 순환파일 시스템의 심벌릭 링크는 사실상 아무것도 존재하지 않으면서 끝없이 깊어지는 디렉터리 계층을 만들 수 있음

서버 관리자가 실수로 만들게 되는 것이 보통이지만, 로봇을 함정에 빠뜨리기 위해 악의적으로 만들기도 함

루프와 중복 피하기● 완벽한 방법은 없음● 잘 설계된 로봇은 휴리스틱 집합 사용

○ 휴리스틱은 유효한 컨텐츠를 필터링하는 문제가 있음

● 올바르게 동작하기위해 사용하는 기법들○ URL 정규화 : 같은 리소스를 가리키는 중복된 URL이 생기는 것을 일부 회피

○ 너비우선 크롤링 : 요청을 더 분산시켜서 특정 서버가 압박 받지 않도록 해줌, 한 로봇이 한 서버의 자원을 최소로 사용하도록 유지

○ 스로틀링 : 일정 시간동안 가져올 수 있는 페이지 수 제한○ URL 크기제한○ URL/사이트 블랙리스트○ 패턴발견

○ 콘텐츠 지문 : 체크섬 검사○ 사람의 모니터링

9.2 로봇의 HTTP● 로봇은 필요한 HTTP를 최소한으로 구현 → 대부분 요구사항이 적은 HTTP/1.0 사용

● 요청 헤더 식별하기○ User-Agent : 서버에게 요청이 만든 로봇의 이름을 말해 줌○ From : 로봇의 사용자/관리자의 이메일 주소를 제공○ Accept : 서버에게 어떤 미디어 타입을 보내도 되는지 말해 줌○ Referer : 현재의 요청 URL을 포함한 문서의 URL을 제공

● 가상 호스팅 : 요청에 host 헤더를 포함하지 않으면 로봇이 URL의 잘못된 컨텐츠 받음

● 조건부 요청 : 변경되었을 때만 가져오기(캐싱과 비슷함)● 응답 다루기 : 상태코드, 엔터티● User-Agent 타켓팅 : 웹 관리자는 많은 로봇의 방문과 요청을 예상해야 함

가상 호스팅

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

○ 서버에 과부하 유발, 폭주 방지를 위한 보호 장치 설계 필요

● 오래된 URL○ 존재하지 않는 URL에 요청해 에러 및 자원 낭비

● 길고 잘못된 URL○ 크고 의미 없는 URL을 요청, 웹 서버의 처리 능력에 영향을 주고 접근 로그를 어지럽힘

● 호기심이 지나친 로봇 ○ 사적 데이터 수집에 주의

● 동적 게이트웨이 접근○ 사이트에 계산부하 가중 → 처리 비용 증가

9.4 로봇 차단하기 ● robots.txt

○ Robot Exclusion Standard (a.k.a. robots.txt)■ 버전 v0.0 v.1.0 v.2.0 이 있지만 대부분 v0.0, v1.0 사용

○ 로봇은 서버 접속 시 robots.txt를 읽어 권한 확인○ 어떤 로봇이 서버의 어떤 부분에 접근할 수 있는지 명시○ HTTP 응답 코드에 따라 다른 반응을 해야 함

■ 2xx : 응답 된 콘텐츠를 파싱하여 차단 규칙을 얻고 이를 준수■ 404 : 차단 규칙이 존재하지 않는 다고 가정하고 robot.txt의 제약 없이 그 사이트에 접근■ 401 or 403 : 서버 접근 제한, 그 사이트로의 접근은 완전히 제한되어 있다고 가정■ 503 : 요청 시도 일시적 실패, 검색을 뒤로 미룸■ 3xx : 리다이렉션 , 리소스가 발견될 때까지 리다이렉트를 따라가야 함

● User-Agent : 규칙적용 로봇 이름 명시○ 명시하지 않는 다면 접근에 어떤 제한도 없음

● Disallow : 접근 금지 할 폴더 규칙● Allow: 접근 허용할 폴더 규칙

● 로봇은 자신이 이해하지 못한 필드는 무시해야 함● robots.txt는 만료시기까지 caching 해야 함

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

User-Agent: slurpUser-Agent: webcrawlerDisallow: /private

HTML 로봇 제어 META 태그● robots.txt는 개별 페이지에 대해 제어하기 어려움

○ HTML 로봇제어 META태그 사용

● 로봇 META 지시자○ <META NAME=”ROBOTS” CONTENT=directive-list>○ NOINDEX, NOFOLLOW, INDEX, FOLLOW, NOARCHIVE, ALL, NONE

● 개별 HTML 문서에 robot 제어 지정● HEAD 섹션에 나타나야 함● 지시들이 중복되거나 충돌되면 안됨

○ <META NAME=”ROBOTS” CONTENT=”NOINDEX, INDEX”> (X)

9.5 로봇 에티켓● Guidelines for Robot Writers by Martjin Koster (1993)

1. 신원식별■ 로봇의 신원을 밝히라, 기계의 신원을 밝히라, 연락처를 밝히라

2. 동작■ 긴장하라, 대비하라, 감시와 로그, 배우고 조정하라

3. 스스로를 제한■ URL을 필터링 하라, 동적 URL을 필터링 하라, Accept 관련 헤더로 필터링, robots.txt에 따르라,

스스로를 억제하라4. 루프와 중복 견뎌내기, 그 외의 문제들

■ 모든 응답 코드 다루기, URL 정규화하기, 적극적으로 순환 피하기, 함정을 감시하라, 블랙리스크를 관리하라

5. 확장성■ 공간 이해하기, 대역폭 이해하기, 시간 이해하기, 분할 정복

6. 신뢰성■ 철저하게 테스트하라, 체크포인트, 실패에 대한 유연성

7. 소통■ 준비하라, 이해하라, 즉각 대응하라

9.6 검색엔진● 웹 크롤러는 검색엔진에 웹 문서 제공● 검색엔진은 받은 문서에 대한 색인 생성● 인터넷의 큰 규모로 인해 웹 전체를 크롤링 하는 것은 쉽지 않음

○ ex) 10억개의 문서를 크롤링 (페이지당 0.5s라고 가정하면)■ 0.5초 x (1,000,000,000) / ((60초/일) x (60분/시간) x (24시간/일)) = 약 5,700일

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

● 검색엔진은 웹 페이지들에 대해 풀 텍스트 색인(로컬 디비) 생성● 웹 페이지들은 변화하기 때문에 색인은 특정 순간의 스냅샷에 불과함

풀 텍스트 색인● 단어 하나를 입력 받아 그 단어를 포함하고 있는 문서를 즉시 알려 줄 수 있는 DB

● 이 문서들은 색인이 생성된 후에는 검색할 필요가 없음

● ex)○ 단어 ‘a’는 문서 A와 B에 들어있다.○ 단어 ‘best’는 문서 A와 C에 들어있다.○ 단어 ‘drill’은 문서 A와 B에 들어있다.○ 단어 ‘the’는 세 문서 A,B,C 모두에 들어있다.

질의 보내기

● HTML 폼을 사용자가 채워넣고 브라우저가 그 폼을 HTML GET이나 POST 요청을 이용해서 게이트웨이로 보내는 식

● 게이트웨이 프로그램은 검색 질의를 추출하고 웹 UI 질의를 풀 텍스트 색인을 검색할 때 사용되는 표현식으로 반환

검색결과 및 스푸핑● 검색결과를 정렬하고 보여주기

○ 검색 된 문서들을 사용자가 원하는 문서순으로 정렬 필요○ 예) 연관이 많은 순 정렬(관련도 랭킹 활용), 인기도 활용

● 스푸핑(Spoofing)○ 웹 마스터가 자신의 사이트가 검색엔진 상위에 노출되도록 편법을 사용하는 것○ 로봇 구현자들은 이런 방법을 걸러내도록 주의해야 함

10 HTTP 2.0

10.1 HTTP/2.0의 등장 배경● HTTP1.1

○ 메시지 포맷은 단순성과 접근성에 주안점을 두고 최적화○ 커넥션 하나를 통해 요청 하나를 보내고 그에 대해 응답 하나만을 받는 방식○ 심각한 회전 지연(latency)을 피할 수 없음

■ 병렬 커넥션, 파이프라인 커넥션이 도입되었지만 근본적인 해결책은 되지 못 함

● SPDY by Google (2009)○ 헤더를 압축하여 대역폭을 절약○ 하나의 TCP 커넥션에 여러 요청을 동시에 보내 회전 지연을 줄이는 것이 가능○ 클라이언트가 요청을 보내지 않아도 서버가 능동적으로 리소스를 푸시하는 기능도 갖춤○ SPDY의 초안을 그대로 가져와서 HTTP/2.0 초안을 만들기 시작 (2012.10.03.)

10.2 개요● 프레임

● 스트림과 멀티플렉싱● 헤더 압축● 서버 푸시

10.3 HTTP/1.1과의 차이점● 프레임

○ 모든 메시지는 프레임에 담겨 전송 (최대 16838 byte)

● 스트림과 멀티플렉싱○ 스트림은 HTTP/2.0 커넥션을 통한 교환되는 프레임들의 독립된 양방향 시퀀스○ 한 개의 스트림이 한 쌍의 요청과 응답을 처리○ 하나의 커넥션 위에 여러개의 스트림이 동시에 열릴 수 있음○ 스트림은 우선순위도 가질 수 있음 (ex. html > image), 하지만 보장은 못 함

10.3 HTTP/1.1과의 차이점● 헤더 압축

○ 헤더의 크기가 회전 지연과 대역폭 양쪽 모두에 실질적인 영향을 끼침

● 서버 푸시○ 서버가 클라이언트에서 어떤 리소스를 요구할 것인지 미리 알 수 있는 상황에서 유리

■ HTML 문서 요청을 받았다면, 그 문서가 링크하고 있는 이미지, CSS, JS 파일 등○ 리소스 푸시하려는 서버는 먼저 PUSH_PROMISE 프레임을 보내어 미리 알려 줌

■ 서버가 푸시하려고 하는 자원을 클라이언트가 별도로 또 요청하게 되는 상황을 피하기 위함

○ 클라이언트에서 RST_STREAM을 보내어 푸시를 거절할 수 있음■ RST_STEAM을 보내게 되면 그 스트림은 즉각 닫힘■ 트림이 닫히기 전까지는 클라이언트는 서버가 푸시하려는 리소스를 요청해서는 안 됨

서버 푸시 주의 사항● 중간에 프락시 서버로부터 받은 추가 리소스를 클라이언트에게 전달하지 않을 수 있으며, 반대로 아무런 추가 리소스를 서버로 부터 받지 않았음에도 클라이언트에게 추가 리소스를 전달 할 수도 있다.

● 서버는 오직 안전하고, 캐시 가능하고, 본문을 포함하지 않은 요청에 대해서만 푸시를 할 수 있다.

● 푸시할 리소스는 클라이언트가 명시적으로 보낸 요청과 연관된 것이어야 한다. 서버가 보내는 PUSH_PROMISE 프레임은 원 요청을 위해 만들어진 스트림을 통해 보내진다.

● 클라이언트는 반드시 서버가 푸시한 리소스를 동일 출처 정책(Same-origin policy)에 따라 검사해야 한다.

● 서버 푸시를 끄고 싶다면, SETTING_ENABLE_PUSH를 0으로 설정하면 된다.

10.4 알려진 보안 이슈● 중개자 캡슐화 공격(Intermediary Encapsulation Attacks)

○ HTTP/2.0 메시지를 중간 프락시가 HTTP/1.1 메시지로 변환할 때 메시지의 의미가 변질될 가능성이 있음

○ HTTP/1.1 메시지를 HTTP/2.0 메시지로 번역하는 과정에서는 이런 문제가 발생하지 않음

● 긴 커넥션 유지로 인한 개인정보 누출 우려○ HTTP/2.0은 사용자가 요청을 보낼 때 회전 지연을 줄이기 위해 클라이언트와 서버 사이의 커넥션을 오래 유지하는 것을 염두에 두고 있음

참고

● 9장 웹로봇○ http://www.slideshare.net/cc612/http-9

● 10장 HTTP 2.0○ http://www.slideshare.net/minq1205/http-10-http20-11○ Transitioning from SPDY to HTTP/2 (2016.02.11.)○ Open Source NGINX 1.9.5 Released with HTTP/2 Support (2015.09.22.)○ HTTP/2 Frequently Asked Questions○ 더 빠른 웹을 위해: HTTP/2 (2015.10.17.)

Dev. Division / Hyejin Oh

ohyejin@mymusictaste.com

THANK YOU!

www.mymusictaste.com