프록시(proxy)서버 작동 원리
글쓴이: park712 / 작성시간: 목, 2005/12/08 - 10:08오후
적당히 질문 올릴때 없어서 여기 올립니다.
책봐도 뭐가 뭔지?
A Host -- 프록시 --- 서버(야후라 가정)
A 호스트에서 www.yahoo.co.kr 하면 프록시 통해서 야후 서버로 질의 합니다.(프록시는 현재의 야후 홈을 캐쉬함)
이후 A 호스트 익스플러에 야후 화면이 나옵니다.
1분후 다른 호스트 B에서 다시 www.yahoo.co.kr 하면 프록시에 캐쉬된 야후 화면이 호스트 B에 나오는지 아니면 호스트 B가 야후를 질의 했을때도 프록시는 서버에 쿼리 날리는지요?
(당연히 날리겠지요?)
왜냐하면 야후 top화면 뉴스나 광고가 계속변경됩니다.
프록시가 계속 서버로 요청을 안하면 호스트 B에 호스트 A와 동일한 화면이 나옵니다.
하지만 실제 야후 서버는 계속 변경되겠지요
그렇다면 프록시는 이 상태에서는 필요없는 기능을 하는거 맞는지요? (여기서는 보안문제 별론)
결론
호스트 A와 호스트 B가 1분 단위로 동일한 질의에 대해
프록시는 어떻게 작동하는지요?(야후 홈이나 야후 뉴스기사기준)
설마 호스트 A에서 요청할때 프록시는 서버에서 요청하고 결과를 A에 보내고 프록시 자신이 야후를 캐쉬하고 다시 호스트 B가 요청할때 야후 서버에 다시 요청하고 결과를 호스트 B에 알려주고 자신도 다시 캐쉬하고 이렇게 무식하게 작동하는 것은 아니겠지요?
그렇다면 프록시는 필요 없는데요(프록시를 이용한 보안기능은 별론으로 함)
감사합니다
Forums:
뱀발부터 하나 내밀자면... 엄밀하게 말해서 프록시와 캐시는 별개입니다.
뱀발부터 하나 내밀자면... 엄밀하게 말해서 프록시와 캐시는 별개입니다. 프록시 기능만 하는 서버(예: DansGuardian)가 있을 수도 있고, 서버 바로 앞에 붙어서 서버의 부하를 줄여주는 리버스 캐시 서버가 있을 수도 있고, 클라이언트측 네트워크의 입구에서 프록싱과 캐싱을 함께 수행하는 서버(예: Squid)가 있을 수도 있습니다. 질문에서처럼 캐싱 기능을 가진 프록시 서버를 가정하도록 하겠습니다.
요즘 HTTP 프로토콜을 공부하신다니 :twisted: HTTP 헤더의 Cache-Control 필드를 이미 알고 계실 수도 있겠습니다. 이 필드의 값이 캐싱 여부에 영향을 끼칩니다. 그 외에 Pragma 필드나 Expires 필드의 값도 캐싱 여부에 영향을 줄 수 있습니다. 대부분의 포털의 경우 메인 페이지에는 "Cache-Control: no-cache"가 붙어서 오는 게 보통입니다. 따라서 캐싱 자체가 이루어지지 않습니다.
A에서 요청한 데이터가 별탈없이 캐싱된 경우에도 그 후의 일이 단순하지만은 않습니다. 1분 후에 B가 같은 데이터를 요청했다고 하면, 캐시 서버는 대략 다음과 같은 내용들을 살펴볼 수 있습니다.
- 응답 데이터 HTTP 헤더의 Expires 필드가 지정하고 있는 시각이 지났는지 여부 (B가 요청을 하기 전에 유효 시간이 만료되었다면 캐시 서버가 그 데이터를 이미 삭제한 후일 가능성이 높습니다.)
- B가 If-Modified-Since 필드를 사용한 경우(브라우저는 로컬 캐시에 데이터가 있는 경우 이렇게 잔머리를 써줍니다), 응답 데이터 HTTP 헤더의 Modified-At 필드와 비교
- B가 ETag 필드를 사용한 경우, 응답 데이터 HTTP 헤더의 If-Match, If-None-Match 필드와 비교 => 정정: B가 If-Match, If-None-Match 필드를 사용한 경우, 응답 데이터 HTTP 헤더의 ETag 필드와 비교
인즉, 웬만한 프록시 캐시 서버는 무식하게 작동하지 않습니다 :)[/]$PWD `date`
답변 감사합니다. 위에 Etag 질문도 있는데요그것도 알려주면 안되나
답변 감사합니다. 위에 Etag 질문도 있는데요
그것도 알려주면 안되나요? 님께서 답변하시기는 클라이언트 측에서
Etag 필드를 사용한다 했는데 실제 인터넷 찾아보니 응답할때 etag 를
사용하더군요.
후회없이 살자
댓글 달기