빅데이터, 데이터마이닝, 공공데이터, 오픈데이터 - 그 어느때보다 데이터 분석 및 활용이 중요해진 이 시기에 웹 상의 수많은 공개된 자료를 직접 수집할 수 있는 웹 스크래핑/크롤링 기술은 데이터 수집 및 활용 능력에 큰 도움이 됩니다.
이 강의에서는 크롤링 프레임웍을 사용하지 않고 HTTP, DOM, concurrency를 담당하는 기본적인 라이브러리만을 사용해 직접 웹 스크래퍼를 처음부터(from scratch) 작성해 봄으로써, 언제든 자유도 높은 동시성 크롤러를 직접 구현할 수 있도록 작동 원리를 이해할 수 있도록 합니다.
시연에서 작성된 전체 소스코드는 아래 링크에서 보실 수 있습니다.
https://gist.github.com/cornchz/0ec0c3f5ca69bac2b625
빅데이터, 데이터마이닝, 공공데이터, 오픈데이터 - 그 어느때보다 데이터 분석 및 활용이 중요해진 이 시기에 웹 상의 수많은 공개된 자료를 직접 수집할 수 있는 웹 스크래핑/크롤링 기술은 데이터 수집 및 활용 능력에 큰 도움이 됩니다.
이 강의에서는 크롤링 프레임웍을 사용하지 않고 HTTP, DOM, concurrency를 담당하는 기본적인 라이브러리만을 사용해 직접 웹 스크래퍼를 처음부터(from scratch) 작성해 봄으로써, 언제든 자유도 높은 동시성 크롤러를 직접 구현할 수 있도록 작동 원리를 이해할 수 있도록 합니다.
시연에서 작성된 전체 소스코드는 아래 링크에서 보실 수 있습니다.
https://gist.github.com/cornchz/0ec0c3f5ca69bac2b625
Durante el primer trimestre del período escolar 2016-2017 la escuela Jesús Maestro ha realizado en conjunto con la ayuda de Fe y Alegría Nacional la remodelación de los baños del plantel, aquí unas evidencias con fecha de 06/12/2016
El taller práctico: 10 claves para la implementación de tendencias y enfoques innovadores, tiene como propósito que los docentes identifiquen el cambio paradigmático que se requiere para atender al desafío pedagógico que implica incorporar las Tecnologías de la Información y la Comunicación (TIC) al aula y al currículo escolar.
Brotherhood of the Cross and Star: love is the key to eternal lifeGeorge Morales
1-888-958-5813 NATIONAL PRAYER LINE 24/7 (Brotherhood of the Cross and Star) "LOVE ONE ANOTHER AS CHRIST LOVED US." We can also give free gospels at no cost to you. The everlasting teachings of Christ are always for the sake of salvation therefore, they must always remain free.
Basic of web ref.웹을지탱하는기술_01
1. 웹 이전의 인터넷 : 전자메일, FTP, Telnet, Gopher
2. 팀버너스리에 의해 웹이 탄생, Mosaic 브라우저를 통해 사용자 증가
3. 표준화의 필요성 > IETF, W3C등
4. SOAP vs REST 분쟁
드랍박스, nDrive 등과 같은 클라우드 스토리지 서비스들은 데이터를 어떻게 저장하는지에 대한 이론적 내용과 실제 구현 내용을 살펴봅니다. 이 발표에서는 OpenStack 의 swift라는 Object Storage 를 이용하여 이론이 어떻게 구현되어있는지 알아봅니다.
어느날 우연히 스위처 소방수로 참여해서 2달 동안 수행한 일들을 공유합니다. 그 첫번재 이야기 ‘기본을 지키자’ 입니다.
전체를 리드하면서 업무를 진행해본 첫 경험이기도 했고, 유저가 증가하며 서비스되고 있는 프로젝트를 A to Z로 혼자 감당해본 첫 경험이기도 했습니다.
새로운 서버를 설계하고 개발하면서, 레거시 안정화 및 이슈 응대를 모두 병행하는게 쉬운 일은 아니었지만, 핑계대지 않고 하나하나 기본을 다져 보았습니다!
아직 갈길이 멀었지만, 성장해가는 아이오(스위처)의 소프트웨어 이야기를 하나씩 하나씩 풀어보려 합니다 ;)
3. 9. 웹 로봇이란?
사람과의 상호작용 없이 연속된 웹 트랜잭션들을 자동으로 수행하는 프로그램
● 로봇의 예
○ 주식 그래프 로봇
○ 웹 통계 조사로봇
○ 검색엔진 로봇
○ 가격비교 로봇
● 방식에 따라 다양한 이름
○ 크롤러, 스파이더, 웜, 봇 등
4. 9.1 크롤러와 크롤링
*Crawl : 기어다니다
● 웹페이지를 가져오고 그 페이지의 링크를 따라가서 다시 웹 페이지를 가져오는
것을 반복하는 방식으로 웹을 순회하는 로봇
● 루트집합에서 탐색시작
● 페이지에서 링크 추출 및 다음 순회목록에 추가
● 상대링크를 절대링크로 변환
● 순환을 피하기 위해 방문페이지 저장
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 타켓팅 : 웹 관리자는 많은 로봇의 방문과 요청을 예상해야 함
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)
○ 웹 마스터가 자신의 사이트가 검색엔진 상위에 노출되도록 편법을 사용하는 것
○ 로봇 구현자들은 이런 방법을 걸러내도록 주의해야 함
24. 10.1 HTTP/2.0의 등장 배경
● HTTP1.1
○ 메시지 포맷은 단순성과 접근성에 주안점을 두고 최적화
○ 커넥션 하나를 통해 요청 하나를 보내고 그에 대해 응답 하나만을 받는 방식
○ 심각한 회전 지연(latency)을 피할 수 없음
■ 병렬 커넥션, 파이프라인 커넥션이 도입되었지만 근본적인 해결책은 되지 못 함
● SPDY by Google (2009)
○ 헤더를 압축하여 대역폭을 절약
○ 하나의 TCP 커넥션에 여러 요청을 동시에 보내 회전 지연을 줄이는 것이 가능
○ 클라이언트가 요청을 보내지 않아도 서버가 능동적으로 리소스를 푸시하는 기능도 갖춤
○ SPDY의 초안을 그대로 가져와서 HTTP/2.0 초안을 만들기 시작 (2012.10.03.)
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.)