HTTP 완벽 가이드 9~10장을 정리한 자료입니다.

1. 웹 로봇과 HTTP 2.0
[ 2016.11.09 - HTTP Study 9~10 ]

2. 09 Web Robot

3. 9. 웹 로봇이란?
사람과의 상호작용 없이 연속된 웹 트랜잭션들을 자동으로 수행하는 프로그램
● 로봇의 예
○ 주식 그래프 로봇
○ 웹 통계 조사로봇
○ 검색엔진 로봇
○ 가격비교 로봇
● 방식에 따라 다양한 이름
○ 크롤러, 스파이더, 웜, 봇 등

4. 9.1 크롤러와 크롤링
*Crawl : 기어다니다
● 웹페이지를 가져오고 그 페이지의 링크를 따라가서 다시 웹 페이지를 가져오는
것을 반복하는 방식으로 웹을 순회하는 로봇
● 루트집합에서 탐색시작
● 페이지에서 링크 추출 및 다음 순회목록에 추가
● 상대링크를 절대링크로 변환
● 순환을 피하기 위해 방문페이지 저장

5. 순환
A
B E
C
D
A
B E
C
D
A
B E
C
D
그림 9-2 하이퍼링크의 웹을 크롤링하기

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

7. 순환을 피하기 위한 방법
● 어떤 URL을 방문하였는지 빠르게 판단하기 위해서 복잡한 자료구조가 필요 함
○ 속도와 메모리 사용면에서 효과적이어야 함
○ 트리와 해시테이블
■ URL을 훨씬 빨리 찾아볼 수 있게 해주는 소프트웨어 자료구조
○ 느슨한 존재 비트맵
■ 각 URL은 해시 함수에 의해 고정된 크기의 숫자로 변환되고 배열 안에 대응하는 ‘존재 비트
(presence bit)’를 갖는다. URL이 크롤링이 되었을 때, 해당하는 존재 비트가 만들어진다.
만약 존재 비트가 이미 존재하다면, 크롤러는 그 URL을 이미 크롤링 되었다고 간주한다.*
○ 체크포인트
■ 로봇 프로그램이 갑작스럽게 중단될 경우를 대비해, 방문한 URL의 목록이 디스크에
저장되었는지 확인
○ 파티셔닝
■ 각 로봇엔 URL들의 특정 ‘한 부분'이 할당되어 그에 대한 책임을 진다.

8. URL 정규화
● 별칭(alias)과 로봇 순환: 주소는 다르지만 같은 리소스를 가짐
● URL 정규화를 통해 alias를 회피
○ 포트번호 추가, 이스케이핑 문자를 대응되는 문자로 대체, # 태그 제거
○ 해결할 수 없는 문제: 대소문자, 색인정보, 가상호스팅

9. 파일 시스템 링크 순환
파일 시스템의 심벌릭
링크는 사실상
아무것도 존재하지
않으면서 끝없이
깊어지는 디렉터리
계층을 만들 수 있음
서버 관리자가 실수로
만들게 되는 것이
보통이지만, 로봇을
함정에 빠뜨리기 위해
악의적으로 만들기도
함

10. 루프와 중복 피하기
● 완벽한 방법은 없음
● 잘 설계된 로봇은 휴리스틱 집합 사용
○ 휴리스틱은 유효한 컨텐츠를 필터링하는 문제가 있음
● 올바르게 동작하기위해 사용하는 기법들
○ URL 정규화 : 같은 리소스를 가리키는 중복된 URL이 생기는 것을 일부 회피
○ 너비우선 크롤링 : 요청을 더 분산시켜서 특정 서버가 압박 받지 않도록 해줌, 한 로봇이 한
서버의 자원을 최소로 사용하도록 유지
○ 스로틀링 : 일정 시간동안 가져올 수 있는 페이지 수 제한
○ URL 크기제한
○ URL/사이트 블랙리스트
○ 패턴발견
○ 콘텐츠 지문 : 체크섬 검사
○ 사람의 모니터링

11. 9.2 로봇의 HTTP
● 로봇은 필요한 HTTP를 최소한으로 구현 → 대부분 요구사항이 적은 HTTP/1.0
사용
● 요청 헤더 식별하기
○ User-Agent : 서버에게 요청이 만든 로봇의 이름을 말해 줌
○ From : 로봇의 사용자/관리자의 이메일 주소를 제공
○ Accept : 서버에게 어떤 미디어 타입을 보내도 되는지 말해 줌
○ Referer : 현재의 요청 URL을 포함한 문서의 URL을 제공
● 가상 호스팅 : 요청에 host 헤더를 포함하지 않으면 로봇이 URL의 잘못된
컨텐츠 받음
● 조건부 요청 : 변경되었을 때만 가져오기(캐싱과 비슷함)
● 응답 다루기 : 상태코드, 엔터티
● User-Agent 타켓팅 : 웹 관리자는 많은 로봇의 방문과 요청을 예상해야 함

12. 가상 호스팅

13. 9.3 부적절하게 동작하는 로봇들
● 폭주하는 로봇
○ 서버에 과부하 유발, 폭주 방지를 위한 보호 장치 설계 필요
● 오래된 URL
○ 존재하지 않는 URL에 요청해 에러 및 자원 낭비
● 길고 잘못된 URL
○ 크고 의미 없는 URL을 요청, 웹 서버의 처리 능력에 영향을 주고 접근 로그를 어지럽힘
● 호기심이 지나친 로봇
○ 사적 데이터 수집에 주의
● 동적 게이트웨이 접근
○ 사이트에 계산부하 가중 → 처리 비용 증가

14. 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 : 리다이렉션, 리소스가 발견될 때까지 리다이렉트를 따라가야 함

15. ● User-Agent : 규칙적용 로봇 이름 명시
○ 명시하지 않는 다면 접근에 어떤 제한도 없음
● Disallow : 접근 금지 할 폴더 규칙
● Allow: 접근 허용할 폴더 규칙
● 로봇은 자신이 이해하지 못한 필드는 무시해야 함
● robots.txt는 만료시기까지 caching 해야 함
Robots.txt 파일 포맷
# 이 robots.txt 파일은 Slurp과 Webcrawler가 우리 사이트의
공개된
# 영역을 크롤링 하는 것을 허락한다. 그러나 다른 로봇은 안
된다.
User-Agent: slurp
User-Agent: webcrawler
Disallow: /private

16. 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)

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

18. 9.6 검색엔진
● 웹 크롤러는 검색엔진에 웹 문서 제공
● 검색엔진은 받은 문서에 대한 색인 생성
● 인터넷의 큰 규모로 인해 웹 전체를 크롤링 하는 것은 쉽지 않음
○ ex) 10억개의 문서를 크롤링 (페이지당 0.5s라고 가정하면)
■ 0.5초 x (1,000,000,000) / ((60초/일) x (60분/시간) x (24시간/일)) = 약 5,700일

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

20. 풀 텍스트 색인
● 단어 하나를 입력 받아 그 단어를 포함하고 있는
문서를 즉시 알려 줄 수 있는 DB
● 이 문서들은 색인이 생성된 후에는 검색할
필요가 없음
● ex)
○ 단어 ‘a’는 문서 A와 B에 들어있다.
○ 단어 ‘best’는 문서 A와 C에 들어있다.
○ 단어 ‘drill’은 문서 A와 B에 들어있다.
○ 단어 ‘the’는 세 문서 A,B,C 모두에 들어있다.

21. 질의 보내기
● HTML 폼을 사용자가 채워넣고
브라우저가 그 폼을 HTML
GET이나 POST 요청을 이용해서
게이트웨이로 보내는 식
● 게이트웨이 프로그램은 검색
질의를 추출하고 웹 UI 질의를 풀
텍스트 색인을 검색할 때 사용되는
표현식으로 반환

22. 검색결과 및 스푸핑
● 검색결과를 정렬하고 보여주기
○ 검색 된 문서들을 사용자가 원하는 문서순으로 정렬 필요
○ 예) 연관이 많은 순 정렬(관련도 랭킹 활용), 인기도 활용
● 스푸핑(Spoofing)
○ 웹 마스터가 자신의 사이트가 검색엔진 상위에 노출되도록 편법을 사용하는 것
○ 로봇 구현자들은 이런 방법을 걸러내도록 주의해야 함

23. 10 HTTP 2.0

24. 10.1 HTTP/2.0의 등장 배경
● HTTP1.1
○ 메시지 포맷은 단순성과 접근성에 주안점을 두고 최적화
○ 커넥션 하나를 통해 요청 하나를 보내고 그에 대해 응답 하나만을 받는 방식
○ 심각한 회전 지연(latency)을 피할 수 없음
■ 병렬 커넥션, 파이프라인 커넥션이 도입되었지만 근본적인 해결책은 되지 못 함
● SPDY by Google (2009)
○ 헤더를 압축하여 대역폭을 절약
○ 하나의 TCP 커넥션에 여러 요청을 동시에 보내 회전 지연을 줄이는 것이 가능
○ 클라이언트가 요청을 보내지 않아도 서버가 능동적으로 리소스를 푸시하는 기능도 갖춤
○ SPDY의 초안을 그대로 가져와서 HTTP/2.0 초안을 만들기 시작 (2012.10.03.)

25. 10.2 개요
● 프레임
● 스트림과 멀티플렉싱
● 헤더 압축
● 서버 푸시

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

27. 10.3 HTTP/1.1과의 차이점
● 헤더 압축
○ 헤더의 크기가 회전 지연과 대역폭 양쪽 모두에 실질적인 영향을 끼침
● 서버 푸시
○ 서버가 클라이언트에서 어떤 리소스를 요구할 것인지 미리 알 수 있는 상황에서 유리
■ HTML 문서 요청을 받았다면, 그 문서가 링크하고 있는 이미지, CSS, JS 파일 등
○ 리소스 푸시하려는 서버는 먼저 PUSH_PROMISE 프레임을 보내어 미리 알려 줌
■ 서버가 푸시하려고 하는 자원을 클라이언트가 별도로 또 요청하게 되는 상황을 피하기
위함
○ 클라이언트에서 RST_STREAM을 보내어 푸시를 거절할 수 있음
■ RST_STEAM을 보내게 되면 그 스트림은 즉각 닫힘
■ 트림이 닫히기 전까지는 클라이언트는 서버가 푸시하려는 리소스를 요청해서는 안 됨

28. 서버 푸시 주의 사항
● 중간에 프락시 서버로부터 받은 추가 리소스를 클라이언트에게 전달하지 않을
수 있으며, 반대로 아무런 추가 리소스를 서버로 부터 받지 않았음에도
클라이언트에게 추가 리소스를 전달 할 수도 있다.
● 서버는 오직 안전하고, 캐시 가능하고, 본문을 포함하지 않은 요청에 대해서만
푸시를 할 수 있다.
● 푸시할 리소스는 클라이언트가 명시적으로 보낸 요청과 연관된 것이어야 한다.
서버가 보내는 PUSH_PROMISE 프레임은 원 요청을 위해 만들어진 스트림을
통해 보내진다.
● 클라이언트는 반드시 서버가 푸시한 리소스를 동일 출처 정책(Same-origin
policy)에 따라 검사해야 한다.
● 서버 푸시를 끄고 싶다면, SETTING_ENABLE_PUSH를 0으로 설정하면 된다.

29. 10.4 알려진 보안 이슈
● 중개자 캡슐화 공격(Intermediary Encapsulation Attacks)
○ HTTP/2.0 메시지를 중간 프락시가 HTTP/1.1 메시지로 변환할 때 메시지의 의미가 변질될
가능성이 있음
○ HTTP/1.1 메시지를 HTTP/2.0 메시지로 번역하는 과정에서는 이런 문제가 발생하지 않음
● 긴 커넥션 유지로 인한 개인정보 누출 우려
○ HTTP/2.0은 사용자가 요청을 보낼 때 회전 지연을 줄이기 위해 클라이언트와 서버 사이의
커넥션을 오래 유지하는 것을 염두에 두고 있음

30. 참고
● 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.)

31. Dev. Division / Hyejin Oh
ohyejin@mymusictaste.com
THANK YOU!
www.mymusictaste.com