Jacob's Development Blog

로봇의 HTTP 로봇들은 다른 HTTP 클라이언트 프로그램과 다르지 않다. 그들 또한 HTTP 명세의 규칙을 지켜야 한다. HTTP 요청을 만들고 스스로를 HTTP/1.1 클라이언트라고 광고하는 로봇은 적절한 HTTP 요청 헤더를 사용해야 한다. 하지만 많은 로봇들은 그들이 찾는 콘텐츠를 요청하기 위해 필요한 HTTP를 최소한으로만 구현하려고 한다. 그래서 요구사항이 적은 HTTP/1.0으로 요청을 보내는 경우가 많다. 요청 헤더 식별하기 로봇 개발자들이 구현하도록 권장되는 기본적인 신원 식별 헤더들에는 다음과 같은 것이 있다. - User-Agent 서버에게 요청을 만든 로봇의 이름을 말해준다. - From 로봇의 사용자/관리자의 이메일 주소를 제공한다. - Accept 서버에게 어떤 미디어 타입을 보..

웹 로봇은 사람과의 상호작용 없이 연속된 웹 트랜잭션들을 자동으로 수행하는 소프트웨어 프로그램이다. 그리고 각각의 방식에 따라 '크롤러', '스파이더', '웜', '봇' 등 여러 가지 이름으로 불린다. 크롤러와 크롤링 웹 크롤러는 먼저 웹페이지를 한 개 가져오고, 그 다음 페이지가 가리키는 모든 웹페이지를 가져오고 하는 이 과정을 재귀적으로 반복하는 방식으로 웹을 순회하는 로봇이다. 이렇게 웹 링크를 재귀적으로 따라가는 로봇을 크롤러 혹은 스파이더라고 부르는데, HTML 하이퍼링크들로 만들어진 웹을 따라 "기어 다니기(crawl)" 때문이다. 인터넷 검색엔진은 웹을 돌아다니면서 그들이 만나는 모든 문서를 끌어오기 위해 크롤러를 사용한다. 이 문서들은 나중에 처리되어 검색 가능한 데이터베이스로 만들어지는데..

실제 상용 프락시 캐시는 매우 복잡하지만, 일단 기본적인 HTTP GET 메시지 하나를 처리하는 절차를 알아보겠다. 캐시 처리 단계 1. 요청받기 캐시는 네트워크 커넥션에서 활동을 감지하고 도착한 요청 메시지를 읽는다. 고성능 캐시는 여러 개의 들어오는 커넥션들로부터 데이터를 동시에 읽어 들이고 메시지 전체가 도착하기 전에 트랜잭션 처리를 시작한다. 2. 파싱 캐시는 메시지를 파싱 하여 URL과 헤더들을 추출한다. 여기서 파서는 헤더 부분에 대해 대소문자나 날짜 형식의 차이와 같은 중요하지 않은 차이점이 모두 무시되도록 정규화할 책임을 갖고 있다. 3. 검색 캐시는 로컬 복사본이 있는지 검사하고, 사본이 없다면 사본을 받아오며, 로컬에 저장한다. 다시 말해 캐시는 URL을 알아내고 그에 해당하는 로컬 사..

토폴로지(topology) - 컴퓨터 네트워크의 요소들(링크, 노드 등)을 물리적으로 연결해 놓은 것, 또는 그 연결 방식. 출처: 위키백과 개인 전용 캐시(private cache) - 한 명에게만 할당된 캐시, 한 명의 사용자가 자주 찾는 페이지를 담는다. 공용 캐시(public cache) - 사용자 집단에게 자주 쓰이는 페이지를 담는다. 개인 전용 캐시 개인 전용 캐시는 많은 에너지나 저장 공간을 필요로 하지 않으므로, 작고 저렴할 수 있다. 웹 브라우저는 개인 전용 캐시를 내장하고 있다. 대부분의 브라우저는 자주 쓰이는 문서를 개인용 컴퓨터의 디스크와 메모리에 캐시해 놓고, 사용자가 캐시 사이즈와 설정을 수정할 수 있도록 허용한다. 캐시에 어떤 것들이 들어있는지 확인하기 위해 브라우저 안을 들여..

웹 캐시는 자주 쓰이는 문서의 사본을 자동으로 보관하는 HTTP 장치다. 웹 요청이 캐시에 도착했을 때, 캐시 된 로컬 사본이 존재한다면, 그 문서는 원 서버가 아니라 그 캐시로부터 제공된다. 캐시의 장점 불필요한 데이터 전송을 줄여서, 네트워크 요금으로 인한 비용을 줄여준다. 네트워크 병목을 줄여준다. 많은 네트워크가 원격 서버보다 로컬 네트워크 클라이언트에 더 넓은 대역폭을 제공하기 때문에 캐싱을 이용하면 대역폭을 늘리지 않고도 페이지를 빨리 불러올 수 있다. 원 서버에 대한 요청을 줄여준다. 서버는 부하를 줄일 수 있으며 더 빨리 응답할 수 있게 된다. 페이지를 먼 곳에서 불러올수록 시간이 많이 걸리는데, 캐시는 거리로 인한 지연을 줄여준다. Flash Crowds(갑자기 요청이 몰리는 일) 대응이..

Web Proxy Server Web proxy server(이하 '웹 프락시 서버')는 중개자이다. 클라이언트와 서버 사이에 위치하여 그들 사이의 HTTP 메시지를 정리하는 중개인 역할을 한다. 클라이언트 입장에서 트잭잭션을 수행한다. 만약 웹 프락시 서버가 없다면, 클라이언트는 HTTP 서버와 직접 통신해야 하고, 있다면 웹 프락시 서버를 통해 통신하면 된다. 둘 다 트랜잭션을 완료하는 것이 클라이언트라는 점은 변하지 않지만, 프락시 서버가 제공하는 여러 서비스를 이용할 수 있게 된다. HTTP Proxy Server HTTP 프락시 서버는 웹 서버이면서 웹 클라이언트이다. HTTP 요청을 받게 되므로, 반드시 웹 서버처럼 요청과 커넥션을 적절히 다루고 응답을 돌려줘야 한다. 동시에 요청을 서버로 요..

웹 서버(Web Server)란, 웹 서버 소프트웨어와 이를 제공하는 물리적 서버 양쪽 모두를 가리키며, HTTP 요청을 처리하고 응답을 제공한다. 크기나 기능, 형태 등은 다양하며, 코드 몇 줄로 구현할 수 있는 서버가 있는 반면에, 몇 십 메가바이트의 안전한 상용 엔진 등도 있다. 하지만 기능은 달라도 모든 웹 서버는 리소스에 대한 HTTP 요청을 받아서 콘텐츠를 클라이언트에게 보내준다. 아래에서의 웹서버는 소프트웨어 적인 관점 위주로 설명하겠다. 웹 서버의 구현 웹 서버는 HTTP 및 HTTP 프로토콜을 구현하고 웹 리소스를 관리하며, 웹 서버 관리 기능을 제공한다. 즉 HTTP 및 그와 관련된 TCP 처리를 구현한 것이다. 그리고 웹 서버는 TCP 커넥션 관리에 대한 책임을 운영체제와 나눠 갖는다..

HTTP 메시지를 보기전에 몇가지 개념을 짚고 넘어 가겠다. Proxy(프락시) 클라이언트와 서버 사이에 위치한 HTTP 중개자로서, 프락시 서버는 웹 보안, 애플리케이션 통합, 성능 최적화 등의 역할을 수행한다. 또한 프락시는 요청과 응답을 필터링한다. 클라이언트와 서버 사이에는 다수의 프락시가 존재할 수 있다. Upstream vs DownStream 1 -> 2의 순서로 일이 진행되고 있고, C는 B에 의존하고, B는 A에 의존한다. 이때 빨간색 방향을 Downstream이라고 하며, 보라색 방향으로의 진행을 Upstream이라고 한다. 여기서 B는 A가 존재하지 않았다면 당연히 존재할 수 없을 것이다. C의 경우도 마찮가지이다. 어떤 것이 다른 것에 가치를 더하거나 다른 방식으로 의존한다면, Do..

HTTP는 웹 트래픽을 어떻게 전송할까? 하루에도 수십억 개의 이미지, HTML 페이지, 텍스트 파일, 동영상 파일 등이 인터넷을 통해 전 세계 사람들의 웹브라우저로 전달된다. 모두 HTTP를 사용해서 통신하여 인터넷의 공용어라고도 할 수 있다. 그렇다면 HTTP는 웹 트래픽을 어떻게 전송하는 것일까? 우선 항상 정보를 요청하는 웹 클라이언트와 내가 원하는 정보를 가지고 있는 웹 서버가 있다. 클라이언트는 서버에게 HTTP 요청을 보내고 서버는 요청된 데이터를 HTTP 응답으로 돌려준다. 이게 월드 와이드 웹(www)의 기본 요소이다. 여기서 말하는 클라이언트는 웹브라우저를 의미하며, 우리가 흔히 사용하고 있는 크롬(Chrome)이나 인터넷 익스플로러다. 그리고 웹브라우저는 HTTP 객체를 요청하고 사용..