HTTP

HTTP 완벽 가이드 스터디 (9)

kchabin 2025. 3. 10. 22:55

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이 같은 리소스를 가리키고 있음 → 표준 형식으로 정규화

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

위와 같이 표준 형식을 해도 다른 확인이 필요한 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
  • 상속