6장. [HTTP - 아키텍쳐] 프락시

• 웹 프락시 서버는 중개자다.
• 클라이언트와 서버 사이에 위치해 HTTP 메시지를 정리하고 전달한다.
• 이 절에서는 프락시의 개념, 배치 방식, 동작 차이, 설정 방법, 메시지 추적, 접근 제어, 프로토콜/버전 조정 등을 다룬다.

❐ 6.1 웹 중개자

---

6-1. 프락시는 중개자다

프락시는 클라이언트 대신 서버와 대화한다.

• 웹 프락시 서버는 클라이언트의 입장에서 트랜잭션을 수행하는 중개인이다.
• 프락시가 없다면 클라이언트는 HTTP 서버와 직접 통신한다.
• 프락시가 있다면 클라이언트는 서버 대신 프락시와 통신한다.
• 트랜잭션을 완료하는 주체는 여전히 클라이언트지만, 프락시가 제공하는 추가 서비스를 이용하게 된다.

6-2. 프락시는 서버이면서 동시에 클라이언트다

프락시는 양쪽 규칙을 모두 지켜야 한다.

• 프락시는 HTTP 요청을 받는 입장에서는 웹 서버처럼 동작한다.
  • 요청 메시지를 받고
  • 적절한 응답을 반환한다.
• 동시에 서버로 요청을 전달하는 입장에서는 HTTP 클라이언트처럼 동작한다.
  • 요청을 생성해 서버로 전송하고
  • 서버의 응답을 받아 처리한다.
• 따라서 프락시를 직접 구현한다면:
  • HTTP 서버 규칙
  • HTTP 클라이언트 규칙 두 가지를 모두 정확히 따라야 한다.

📌 그림 6-1 핵심

• 프락시는 클라이언트 쪽에서는 서버처럼, 서버 쪽에서는 클라이언트처럼 동작한다.

x

6-3. 개인 프락시와 공유 프락시

프락시는 사용 범위에 따라 구분된다.

1. 공유 프락시
   • 대부분의 프락시는 공유 프락시다.
   • 중앙 집중형으로 관리하면:
   • 비용 효율이 높고
   • 운영이 쉽다. - 특히 캐시 프락시 서버는 사용자 수가 많을수록 유리하다.
   • 여러 사용자의 공통 요청을 재사용할 수 있기 때문이다.
2. 개인 프락시
   • 한 클라이언트만을 위한 전용 프락시
   • 흔하지는 않지만 꾸준히 사용된다.
   • 보통 클라이언트 컴퓨터에서 직접 실행된다.
   • 사용 사례:
   • 브라우저 기능 확장
   • 성능 개선
   • 무료 ISP 서비스에서 광고 삽입 목적
   • 작은 로컬 프락시 실행

6-4. 프락시 대 게이트웨이

같은 프로토콜이면 프락시, 다른 프로토콜이면 게이트웨이

• 엄밀한 정의:

  구분	역할
  프락시	같은 프로토콜을 사용하는 두 애플리케이션 연결
  게이트웨이	서로 다른 프로토콜을 사용하는 두 애플리케이션 연결

• 프락시: HTTP ↔ HTTP
• 게이트웨이: HTTP ↔ POP, HTTP ↔ FTP 등
  • 게이트웨이는 일종의 프로토콜 변환기처럼 동작한다.

🔹 HTTP/HTTP 프락시 (그림 6-2a)

• 클라이언트와 서버 모두에게 HTTP로 통신
• 전형적인 웹 프락시

구조 예시:

브라우저 → HTTP → 웹 프락시 → HTTP → 웹 서버

🔹 HTTP/POP 게이트웨이 (그림 6-2b)

• 프론트엔드는 HTTP
• 백엔드는 POP (이메일 프로토콜)

구조 예시:

브라우저 → HTTP → 웹/이메일 게이트웨이 → POP → 이메일 서버

• 웹 트랜잭션을 적절한 POP 트랜잭션으로 변환
• 사용자가 HTTP를 통해 이메일을 읽을 수 있게 해준다.
• 웹 기반 이메일 서비스(예: 과거 MSN 핫메일 등)가 대표적 사례

6-5. 현실에서의 프락시와 게이트웨이

실제 환경에서는 경계가 모호하다.

• 브라우저와 서버는 서로 다른 HTTP 버전을 구현하기도 한다.
• 이 경우 프락시는 약간의 프로토콜 변환을 수행한다.
• 상용 프락시 서버는 다음 기능도 함께 제공한다:
  • SSL 보안 프로토콜 지원
  • SOCKS 방화벽
  • FTP 접근
  • 웹 기반 애플리케이션 지원
• 따라서 많은 상용 프락시는 게이트웨이 기능까지 포함한다.

프락시와 게이트웨이는 이론적으로는 구분되지만,
현실의 제품에서는 두 기능이 혼합되어 구현되는 경우가 많다.