bluecandle37

[HTTP 완벽 가이드] 9장 웹 로봇 9.3 부적절하게 동작하는 로봇들 9.4 로봇 차단하기 9.3 부적절하게 동작하는 로봇들 폭주하는 로봇 로봇이 사람보다 훨씬 빠르게 HTTP 요청을 만들 수 있고, 주로 빠른 네트워크 연결을 갖춘 빠른 컴퓨터 위에서 동작하기 때문에, 로봇 자체에 논리적 오류가 있거나 로봇이 순환에 빠지면 웹 서버에 극심한 부하를 줄 수 있음. 오래된 URL 오래되어서 존재하지 않는 URL에 대한 요청을 많이 보낼 수 있는데, 존재하지 않는 문서에 대한 접근 요청으로 에러 로그가 채워지거나, 에러 페이지를 제공하는 부하가 발생 가능. 길고 잘못된 URL 순환이나 프로그래밍 오류로 인해 로봇이 웹사이트에 크고 의미 없는 URL을 요청할 수 있음. 근데, 그 URL이 웹 서버의 처리 능..

9.2 로봇의 HTTP 로봇도 다른 HTTP 클라와 다르지 않음. 많은 로봇은 찾는 콘텐츠를 요청하기 위해 필요한 HTTP를 최소한으로만 구현하려고 하는데, 이런 형태가 문제 발생 가능성이 있기는 하지만 별로 바뀔 것 같지는 않고(책 집필 시점에 그랬다고 하니, 지금은 어떨까?), 결국 그래서 많은 로봇이 HTTP/1.0 요청을 보냄. HTTP/1.0은 요구사항이 적기 때문에. 9.2.1 요청 헤더 식별하기 아무리 최소한으로 구현하려고 한다지만, 로봇의 능력, 신원, 출신을 알려주는 기본적인 몇 가지 헤더는 사이트에 보내줌. 잘못된 크롤러의 소유자를 찾아낼 때와 서버에게 로봇이 어떤 종류의 콘텐츠를 다룰 수 있는지 정보를 주려고 할 때 판단 기준이 되는 유용한 정보. User-Agent : 로봇 이름 F..

9.1.7 URL 정규화하기 대부분 웹 로봇들이 URL을 표준 형식으로 정규화하여, 다른 URL과 같은 리소스를 가리키고 있음이 확실한 것들을 미리 제거하려고 시도함. 포트 번호 명시되지 않았다면 호스트 명에 :80 추가 모든 %xx 이스케이프 된 문자들을 대응되는 문자로 변환 # 태그 제거. 근데, 이렇게 한다고 하더라도 각 웹 서버에 대한 정보를 알지 못하는 이상, 정규화할 수 없는 URL들도 만나긴 한다. 9.1.8 파일 시스템 링크 순환 파일 시스템 심벌릭 링크를 통해 사실 아무것도 존재하지 않는 곳에 끝없이 깊어지는 디렉토리 계층 만들기가 가능한데, 이로 인한 순환이 발생할 수도 있음. root(/) 아래에 index.html , subdir 이 존재한다고 가정하자. 근데, subdir 이 ..

[HTTP 완벽 가이드] 9장 웹 로봇 > 9.1 크롤러와 크롤링 서론 웹 로봇 = 스스로 움직이는 사용자 에이전트. 사람과의 상호작용 없이 연속된 웹 트랜잭션들을 자동으로 수행하는 소프트웨어 프로그램 웹 사이트 to 웹 사이트 떠돌아다니며 콘텐츠 가져오고, 하이퍼링크 따라가고, 발견한 데이터 처리하는 주체. '크롤러', '스파이더', '웜', '봇' 등의 이름으로 불림. 9.1 크롤러와 크롤링 웹 크롤러는, 일단 웹 페이지 하나 가져오고, 그 페이지가 가리키는 모든 웹 페이지를 다시 가져오는 과정을 반복하면서 웹을 순회하는 로봇. 웹 링크를 재귀적으로 따라가는 로봇을 크롤러 혹은 스파이더라고 부르는데, 하이퍼링크들로 만들어진 웹을 따라 기어 다니기(crawl) 때문. 검색엔진은 웹에서 만나는 모든 문서..

[HTTP 완벽가이드] 8장 통합점: 게이트웨이, 터널, 릴레이 > 8.6 릴레이 8.6 릴레이 HTTP 릴레이는 HTTP 명세를 완전히 준수하지는 않는 간단한 HTTP 프록시. 릴레이는 커넥션을 맺기 위한 HTTP 통신을 한 다음, 바이트를 맹목적으로 전달함. 맹목적으로 전달한다는게 무슨말이지?? 커넥션 상태에 상관없이 무조건 전달한다는 의미인가?? 이후 내용 살펴보니, 무지성 전달이 더 맞는 표현인듯! 무슨 뜻인지 모르지만 일단 그냥 다 전달 ㄱㄱㄱ 이런 느낌. 어쨌든 이렇게 모든 헤더와 메소드 로직을 수행하지 않고 맹목적으로 트래픽을 전달하는 간단한 프록시 방식이 유용할 때가 있음. 단순 필터링이나 진단 혹은 컨텐츠 변환을 하는데 사용되기도 함. 근데, 잠재적으로 심각한 운용 문제를 가지고 있기 때..

[HTTP 완벽가이드] 8장 통합점: 게이트웨이, 터널, 릴레이 > 8.5 터널 8.5 터널 HTTP의 또 다른 사용 방식인 웹 터널 : HTTP 프로토콜을 지원하지 않는 어플리케이션에 HTTP 어플리케션을 사용해 접근하는 방법 제공. => HTTP 커넥션을 통해서 HTTP가 아닌 트래픽을 전송할 수 있고, 다른 프로토콜을 HTTP 위에 올릴 수 있음. 웹 터널을 사용하는 가장 일반적인 이유는 HTTP 커넥션 안에 HTTP가 아닌 트래픽을 얹기 위함. => 웹 터널을 사용하면 웹 트래픽만을 허락하는 방화벽이 있더라도 HTTP가 아닌 트래픽을 전송할 수 있음. 8.5.1 CONNECT로 HTTP 터널 커넥션 맺기 웹 터널은 HTTP의 CONNECT 메서드를 사용하여 커넥션 맺음. CONNECT 메서드는 터..

[HTTP 완벽가이드] 8장 통합점: 게이트웨이, 터널, 릴레이 > 8.3 리소스 게이트웨이 - 8.4 어플리케이션 인터페이스와 웹 서비스 8.3 리소스 게이트웨이 게이트웨이의 가장 일반적인 형태인 어플리케이션 서버는 목적지 서버와 게이트웨이를 한 개의 서버로 결합. 어플리케이션 서버는 HTTP를 통해 클라와 통신하고, 서버 측에 있는 어플리케이션 프로그램에 연결하는 서버 측 게이트웨이. (아래 그림 1 참조) 그림 1을 보면, 두 개의 클라가 HTTP를 사용하여 어플리케이션 서버로 연결함 > 하지만, 서버로부터 파일 전송 대신에, 어플리케이션 서버에서 게이트웨이의 API(Application Programming Interface)를 통해 > 서버에 동작중인 어플리케이션에 요청 전달. 어플리케이션 게이..

[HTTP 완벽가이드] 8장 통합점: 게이트웨이, 터널, 릴레이 > 8.1 게이트웨이 - 8.2 프로토콜 게이트웨이 서론 시간이 지나면서 사람들이 온라인에서 복잡한 리소스를 공유하기를 원함. 근데, 브라우저 같은 HTTP 어플리케이션은 인터넷상의 컨텐츠에 접근하는 통일된 방법을 제공. HTTP 위에 다른 프로토콜을 얹으려고 하는 개발자들에게는 HTTP가 기본 구성 요소. (예를 들어, HTTP만 허용하는 방화벽이 있는 회사에서 다른 프로토콜로 통신하는 트래픽을 HTTP 로 감싸서 터널링, 릴레이 하는 것) 그래서, 리소스 접근에 HTTP 가 어떻게 쓰이고, 다른 프로토콜이나 어플리케이션 간 통신에 HTTP를 어떻게 사용하는가? 다룰 내용 게이트웨이 : 서로 다른 프로토콜과 어플리케이션 간의 HTTP 인터..

[HTTP 완벽가이드] 7장 캐시 > 7.9 캐시 제어 문서가 만료되기 전까지 얼마나 오랫동안 캐시될 수 있게 할 것인지 서버가 설정할 수 있는 방법들 존재. 서버는 아래 우선순위대로, 옵션을 응답 헤더에 포함시킬 수 있음. Cache-Control: no-store Cache-Control: no-cache Cache-Control: must-revalidate Cache-Control: max-age Expires 혹은 아무 정보도 주지 않고 캐시가 스스로 체험적인(휴리스틱) 방법으로 정하도록 할 수도 있음. 근데, 그러면 각각 위 옵션들이 무슨 의미이냐?? 그게 이번 장 내용. 7.9.1 no-cache 와 no-store 응답 헤더 캐시가 검증되지 않은 캐시된 객체로 응답하는 것을 막는 역할 Ca..

[HTTP 완벽가이드] 7장 캐시 > 7.8 사본을 신선하게 유지하기 신선하게... 단어 참 신기하네. 캐시된 데이터가 서버의 original 데이터와 일치하도록 관리 필요. 결론적으로, 어떤 캐시가 사본을 갖고 있는지 서버 입장에서 기억하지 않아도 캐시된 사본이 서버의 original 데이터와 충분히 일치하도록 유지하는 방법 있음. 7.8.1 문서 만료 HTTP는 Cache-Control과 Expires라는 헤더를 이용해서 원 서버가 각 문서에 유효기간을 붙일 수 있게 함. 이 헤더 값들이 컨텐츠가 얼마나 신선한 (= original 데이터와 같은지) 상태로 보일 수 있는지 나타냄. 캐시 문서 만료 전에, 필요할 경우 서버 다녀오지 않고 사본 제공 가능. 물론, 클라 입장에서 캐시되었거나 검사되지 않은..