HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
📖
공부한 책
/
1%의 네트워크 원리
1%의 네트워크 원리
/5장 서버측의 LAN에는 무엇이 있는가?/
🏬
캐시 서버를 이용한 서버의 부하 분산(프록시)
🏬

캐시 서버를 이용한 서버의 부하 분산(프록시)

 
캐시 서버 이용 시 장점캐시 서버의 동작 (리버스 프록시)데이터가 캐시에 저장되어 있는 경우데이터가 캐시에 저장되어 있지 않은 경우프록시포워드 프록시설정 방법 & 설정 시 변경되는 점리버스 프록시 ( 포워드 프록시를 개량 )포워드 프록시 🆚 리버스 프록시트랜스페어런트 프록시

캐시 서버 이용 시 장점

  • 웹 서버는 URL을 점검하거나, 액세스 권한을 점검하거나, 페이지 안에 데이터를 내장하는 등의 처리를 내부에서 실행하기 위해 페이지의 데이터를 클라이언트에 송신할 때 다소 시간이 걸림. 캐시 서버는 보존해 둔 데이터를 읽어서 송신만 해서 더 빨리 데이터 전송이 가능
  • 동적인 반환 값은 캐시 서버에서 갖고 있을 수 없지만 일정 부분이라도 캐시 서버에서 처리하면 전체 성능이 향상된다고 생각하는 것임

캐시 서버의 동작 (리버스 프록시)

notion image
  • DNS 서버에 웹 서버 대신 캐시 서버를 등록함 ⇒ 클라이언트는 웹 서버가 아닌 캐시 서버에 리퀘스트 메시지를 전송
  • 캐시 서버는 프록시라는 구조를 사용하여 데이터를 캐시에 저장하는 서버임. 웹 서버와 클라이언트 사이에 들어가서 웹 서버에 대한 액세스 동작을 중개하는 역할을 함 — 프록시 ( 대리자 )

데이터가 캐시에 저장되어 있는 경우

notion image
  1. 사용자로부터 도착한 리퀘스트 메시지를 받아 캐시에 저장되었는지 조사
  1. 웹 서버측에서 데이터가 변경되었는지를 조사하기 위한 ‘If-Modified-Since’ 라는 헤더 필드를 추가하여 웹 서버에 전송
    1. 변경이 없으면 304 Not Modified를 반환함. 웹 서버에서 최종 갱신 일시만 조사하고 반환하기에 부담이 적어짐
    2. 데이터 변경된 경우는 캐시에 데이터가 저장되어 있지 않은 경우와 같음

데이터가 캐시에 저장되어 있지 않은 경우

notion image
 
notion image
  1. 사용자로부터 도착한 리퀘스트 메시지를 받아 캐시에 저장되었는지 조사
  1. 캐시 서버가 리퀘스트 메시지에 그림 5-6의 (b) (2)와 같이 캐시 서버를 경유한 것을 나타내는 ‘Via’라는 헤더 필드를 추가하여 웹 서버에 리퀘스트 전송
      • 이 때, 어느 웹 서버에 리퀘스트 메시지를 전송해야 할지 판단해야 함
      • 여러대 서버 있을 시, 리퀘스트 메시지의 내용에 따라 전송 대상의 웹 서버를 판단하는 것 같은 방법이 필요 (리퀘스트 메시지의 URI에 쓰여있는 디렉토리를 보고 판단하는 방법)
  1. 웹 서버에 대해 캐시 서버가 클라이언트가 되어 리퀘스트 전송 후 응답 받음 ( [그림 5-5]의 (a) (3), [그림 5-6]의 (c) )
  1. 클라이언트에게 응답 메시지를 보낼 때 캐시 서버를 경유한 것을 나타내는 ‘Via’ 헤더 필드 부가해서 메시지 전송함
  1. 응답 메시지를 캐시에 저장 & 저장한 일시를 기록 ( [그림 5-5]의 (a) (4)’)

프록시

프록시 라는 것이 대리인, 중개자라는 뜻이니까, 포워드 프록시는 클라이언트 측에서 중개해주는 역할, 리버스 프록시는 서버측에서 중개해주는 역할을 한다라고 이해하면 될듯함

포워드 프록시

notion image
  • 캐시 서버에서 이용하는 프록시라는 구조는 원래 클라이언트측에 두는 방법에서 시작되었음
    • 이 유형이 프록시의 원형으로, 포워드 프록시 라고 함
  • 포워드 프록시가 처음 등장했을 때, 캐시를 이용하는 것 + 방화벽을 실현한다 는 목적이 있었음
    • 프록시에서 리퀘스트 메시지를 일단 받아서 내용을 조사한 후 전송하므로 리퀘스트의 내용에 따라 액세스가 가능한지 판단할 수 있음
  • 브라우저에 대한 설정이 꼭 필요하고 이것이 포워드 프록시의 특징임
    • 브라우저의 설정이 번거롭고 잘못 설정할 경우에는 브라우저가 제대로 작동하지 않는 장애의 원인이 되기도 함

설정 방법 & 설정 시 변경되는 점


  • 브라우저의 설정 화면에 준비되어 있는 프록시 서버라는 항목에 포워드 프록시의 IP 주소를 설정함
    • 설정하지 않으면, 브라우저는 URL 입력 상자에 입력된 주소에서 액세스 대상의 웹 서버 계산 & 여기에 리퀘스트 메시지를 보냄
    • 설정하면, URL의 내용에 상관 없이 리퀘스트를 전부 포워드 프록시에 보냄
  • 리퀘스트 메시지의 내용도 조금 변경됨
    • 설정하지 않으면, URL에서 웹 서버의 이름을 제외하고 파일, 프로그램의 경로명의 일부를 추출하여 이것을 리퀘스트 URI 부분에 기록
    • 설정하면, http://…. 라는 URL을 그대로 리퀘스트의 URL에 기록함

리버스 프록시 ( 포워드 프록시를 개량 )

  • 리퀘스트 메시지의 URI에 쓰여 있는 디렉토리명과 전송 대상의 웹 서버를 대응시켜서 URI 부분에 http:// … 라고 쓰여있지 않은 보통의 리퀘스트 메시지를 전송할 수 있도록 함

포워드 프록시 🆚 리버스 프록시

포워드 프록시와 리버스 프록시 도식도
포워드 프록시와 리버스 프록시 도식도
  • 전송 대상의 웹 서버를 판단하는 부분이 서로 다름
    • 포워드 프록시 사용할 경우에는 URI 부분에 http:// … 라는 URL이 그대로 쓰여있으므로 URL(웹 서버)이 전송 대상이 됨 → 어떠한 웹 서버라도 전송이 가능함
    • 서버측에 두는 캐시 서버(리버스 프록시), 전송 대상의 웹 서버를 사전에 설정해 두어야 함 → 사전에 설정해 둔 웹 서버에만 전송이 가능함
    • 트랜스페어런트 프록시 : ip 헤더를 통해 판단

트랜스페어런트 프록시

  • 패킷의 맨 앞에 있는 IP 헤더에는 수신처 IP 주소가 기록되어 있으므로 이것을 조사하면 액세스 대상 웹 서버가 어디에 있는지 알 수 있는데, 이 방법을 트랜스페어런트 프록시라 함
    • 이 방법이면 보통의 리퀘스트 메시지를 전송할 수 있으므로 포워드 프록시처럼 브라우저에 설정 필요 x
    • 전송 대상을 캐시 서버에 설정할 필요도 없음
    • 어느 웹 서버에나 전송 가능
설치 방법

  • 브라우저에서 웹 서버로 리퀘스트 메시지가 흘러가는 길에 트랜스페어런트 프록시를 설치
    • 메시지가 트랜스페어런트 프록시를 통과할 때 그것을 가로챔
    • 리퀘스트 메시지가 흐르는 길이 많으면 전부 설치할 수 없으니 길이 한개로 수렴하는 형태로 만들고 수렴되는 곳에 트랜스페어런트 프록시를 설치함