draw io 링크
https://drive.google.com/file/d/167HQ62wDCphDnZMXvpzEriPhy1KMUWH3/view?usp=drive_link
웹 로봇 : 연속된 웹 트랜잭션들을 자동으로 수행하는 sw 프로그램
- 크롤러, 스파이더, 웜, 봇
루프를 피하기 위한 방문한 곳 흔적 추적
- 복잡한 자료구조 필요 → 검색 트리나 해시 테이블
대규모 웹 크롤러가 사용하는 방문 url 관리 기법
트리와 해시 테이블
느슨한 존재 비트맵
- 공간 사용 최소화 → 존재 비트 배열(1과0만 들어있는 배열) 같은 느슨한 자료 구조
- 각 URL은 해시 함수에 의해 고정된 크기의 숫자로 변환된다.
- 배열 안에 대응하는 존재비트(presence bit)를 갖는다.
- 존재 비트가 이미 있다 → 이미 크롤링된 url
체크포인트
- 로봇 프로그램의 갑작스러운 중단 대비
- 방문한 url의 목록이 디스크에 저장되었는지 확인
파티셔닝
- 하나의 로봇으로는 크롤링 완수 불가능
- 농장(farm) - 분리된 한 대의 컴퓨터인 로봇들
- 각 로봇들에 URL의 한 부분이 할당되어 그에 대한 책임을 짐
- 이리저리 넘겨주거나 오동작하는 동료를 도와주거나 → 커뮤니케이션
별칭(alias)과 로봇 순환
URL이 별칭을 가지면 서로 달라 보여도 실제로는 같은 리소스를 가진다.
URL 정규화
다른 URL이 같은 리소스를 가리키고 있음 → 표준 형식으로 정규화
- 포트 번호가 명시되지 않았다면, 호스트 명에 :80 을 추가한다.
- 모든 %xx 이스케이핑된 문자들을 대응되는 문자로 변환한다.
- '#' 태그들을 제거한다.
위와 같이 표준 형식을 해도 다른 확인이 필요한 URL들도 있다 → 정규화로 다 되는 건 아님
파일 시스템 링크 순환
심볼릭 링크 - 아무것도 존재하지 않으면서도 끝없이 깊어지는 디렉터리 계층을 만들 수 있음. → 매우 교묘한 종류의 순환
- 서버 관리자의 실수
- 사악한 웹 마스터 → 로봇 함정 → 루프 발견 못함
동적 가상 웹 공간
사실은 게이트웨이 애플리케이션인 URL
- 가상의 URL에 대한 요청을 받으면 새로운 가상 URL을 갖고 있는 새 HTML 페이지를 날조하여 만들어냄
- 다음 달 링크를 걸어주는 달력 프로그램
루프와 중복 회피 방안
- url 정규화
- BFS너비 우선 크롤링 : 순환 영향 최소화. 깊이 우선 탐색 시 순환 걸림
- DFS : 한 방향으로 갈 수 있을 때까지 계속 가다가 더 이상 갈 수 없게 되면 다시 가장 가까운 갈림길로 돌아와서 이곳으로부터 다른 방향으로 다시 탐색을 진행하는 방법
- 넓게 탐색하기 전 깊게 탐색
- 모든 노드를 방문
- 너비 우선 탐색에 비해 느리나 간단함
- 자기 자신을 호출
- 어떤 노드를 방문했었는지 반드시 검사 → 무한 루프 위험
- url 길이 제한 : 일정 길이를 넘는 url의 크롤링은 거부
- 길이 제한으로 순환 중단
- 순환에 빠진 로봇은 서버와 충돌을 일으킴 → 서비스 거부 공격자로 오해받게됨
- 이 기법을 적용하면 가져오지 못하는 콘텐츠들도 존재
- 많은 사이트 → 사용자 상태 관리 URL ex) 사용자 아이디를 페이지에서 참조하고 있는 url들에 저장
- 요청 url이 특정 크기에 도달할 때마다 에러 로그를 남김 → 특정 사이트에서 어떤 일이 벌어지는지 감시하는 사용자에겐 훌륭한 신호 제공
robots.txt
Disallow/Allow 프리픽스 매칭
- 어떤 경로에 규칙이 적용되려면, 그 경로의 시작부터 규칙 경로의 길이만큼의 문자열이 규칙 경로와 같아야 한다.
규칙 경로 URL 경로 매치 여부 설명
/tmp | /tmp | o | 규칙 경로 == url 경로 |
/tmp | /tmpfile.html | o | 접두어 |
/tmp | /tmp/a.html | o | 접두어 |
/tmp/ | /tmp | x | 접두어가 아님 |
README.TXT | o | 빈 문자열은 모든 것에 매치됨 | |
/~kch/hi.html | %7Ekch/hi.html | o | %7E는 ~과 같은 것으로 취급 |
%7ekch/hi.html | %7Ekch/hi.html | o | 이스케이핑된 문자는 대소문자 구분 x |
/~kch/hi.html | ~kch%2Fhi.html | x | %2는 빗금(/)이 맞긴 하지만, 빗금은 정확하게 매치되어야 한다. |
- 어떤 경로 밑에 있느냐와 상관없이 특정 이름의 디렉터리에 대해서는 크롤링을 못하게 하고 싶어도 robots.txt에서는 이를 표현할 수단을 제공하지 않는다.
그 외 알아둘 점
robots.txt 파싱할 때 지켜할 규치
- 발전한 명세에 따라 모르는 필드가 포함됨 → 이해하지 못하는 필드는 무시해야 함
- 주석은 파일의 어디에서는 허용됨. → 선택적인 공백 문자와 뒤이은 주석 # ~ 줄바꿈 문자
- 로봇 차단 표준 버전 0.0은 Allow 줄 지원하지 않음. → 보수적인 로봇, 허용되는 URL도 탐색하지 않을 수 있음.
robots.txt의 캐싱과 만료
매 파일 접근마다 robots.txt 파일을 새로 가져옴 → 덜 효율적, 웹 서버 부하 두배
- 표준 HTTP 캐싱 메커니즘을 따름 → 서버, 로봇 양쪽에 적용됨
- 대부분의 로봇이 http/1.1 클라이언트가 아님 → 캐시 지시자를 이해하지 못할수도있음
- cache-control 지시자가 존재하는 경우 일반적으로 7일간 캐싱하도록 하고 있음
- 이를 모르는 웹 서버 관리자 → 로봇이 방문할 때마다 새로 만들어 응답
- robots.txt가 없는 상태가 1주일 동안 캐시 → 새로 만든 robots.txt는 의미 없어짐
- 이 때문에 몇몇 대규모 웹 크롤러는 웹을 활발하게 크롤링하는 기간 동안엔 robots.txt를 매일 새로 가져온다는 규칙을 따른다.
HTML 로봇 제어 META 태그
- 로봇 차단 태그가 존재하면 로봇들은 그 문서를 무시함
- 인터넷 검색 엔진 → 검색 색인에 그 문서를 추가하지 않을 것
<META NAME="ROBOTS" CONTENT=directive-list>
<META NAME="ROBOTS" CONTENT="NOINDEX">
<META NAME="ROBOTS" CONTENT="NOFOLLOW">
- NOINDEX : 이 페이지를 처리하지 말고 무시해라
- NOFOLLOW : 이 페이지가 링크한 페이지를 크롤링하지 말라고 말해줌
- FOLLOW : 이 페이지가 링크한 페이지를 크롤링해도 된다.
- INDEX : 이 콘텐츠를 인덱싱해도 된다.
- NOARCHIVE : 캐시를 위한 사본 생성 안된다.
- ALL : index, follow와 같음
- NONE : noindex, nofollow와 같음
로봇 에티켓
마틴 코스터 - 로봇 제작자들을 위한 가이드라인
질의 보내기
HTML 폼을 사용자가 채워넣는다.
GET이나 POST 요청을 이용해서 게이트웨이로 보낸다.
게이트웨이 프로그램은 검색 질의를 추출하고 웹 UI 질의를 풀텍스트 색인을 검색할 때 사용되는 표현식으로 변환한다.
- 사용자가 ‘drills’ 라는 단어를 폼에 타이핑한다.
- 브라우저는 이를 질의 매개변수인 ‘drills’를 일부로 포함하는 GET 요청으로 번역한다.
- GET /search.html?query=drills HTTP/1.1
- 웹 서버는 이 질의를 받아서 검색 게이트웨이 애플리케이션에게 넘겨준다.
- 게이트웨이는 웹 서버에게 문서의 목록을 결과로 돌려준다.
- 웹 서버는 이 결과를 사용자를 위한 HTML 페이지로 변환한다.
Page Rank
넷스케이프, 야후(구글 이전)
- 래리 페이지가 만든 알고리즘 → 획기적인 검색 방법
우리 페이지를 사용자들이 더 방문하도록 → 구글이 크롤링을 잘 할 수있도록 함 → SEO(Search Engine Optimize)
- 한 url에 여러가지 url → 동적 가상 웹 공간 처럼
- bfs 사용 / dfs 사용
여러 링크를 거쳐오면 점수가 좀 낮음
robots.txt가 있는데 악의적으로 크롤링 → 소송
- 절대적으로 막아주는 건 아니고, 검색 매너의 일종
요즘 서비스
- 사용자가 직접 get해서 가져가야하는 페이지 → jwt 토큰 등
- 최근에는 메인페이지, 홍보페이지 이외에는 웹 크롤러가 가져갈수 없도록 함.
3xx
- 리다이렉션 url을 따라서 재요청 반복 → robots.txt를 찾음
크롤러를 개발할 때 어떤 규칙, 제약 조건이 있는지 → 크롤러 개발 설명서
클라우드 → aws guard duty, L4(동일한 클라이언트 몇 번 요청 = block) → 루프 발생 로봇 차단
- 서버에는 부하를 안 주고, 로봇도 효율적으로 개발
- 예의상
- 컴플라이언스의 문제
알고리즘 문제(방문 흔적)
- hashmap → url을 해시 키로 잡아서
- count =1
- checksum
- 스로틀링 → 타임 윈도우를 만들어놓고, 내가 들어갔던 사이트가 있는지 없는지
- bfs → 레디스 해시키 사이트 url 저장 ⇒ 가장 효율적인 방법
구글,bing 등의 검색엔진 조회 → 상위 10개 정도 (가장 신뢰가능한) → rag 데이터소스로 공급
- 임베딩이 사실 검색엔진
- elastic search
- n-gram을 어떻게 설정할지
AI용 small 검색엔진
- 웹 검색으로 확장
jvm 기반 문제
- oop
- 상속
'HTTP' 카테고리의 다른 글
HTTP 완벽 가이드 (11) : 클라이언트 식별과 쿠키 (0) | 2025.03.15 |
---|---|
HTTP 완벽 가이드 스터디 (10) (0) | 2025.03.15 |
HTTP 완벽 가이드 스터디 (8) (0) | 2025.03.06 |
HTTP 완벽 가이드 스터디 (7) (2) | 2025.03.06 |
HTTP 완벽 가이드 스터디 (6) (0) | 2024.10.08 |