CS Repo/HTTP 완벽 가이드

프록시

조금씩 차근차근 2025. 4. 8. 20:39

본 내용은 "HTTP 완벽 가이드" 내용을 참고하여 기록한 정리본입니다.

프록시 - 웹 중개자

프록시란?

  • 트랜잭션을 수행하는 중개자이다.
  • 프록시 서버에 추가적인 서비스를 삽입할 수 있다.
  • 웹 서버이자 웹 클라이언트의 역할을 동시에 수행한다.
    • 따라서, HTTP 클라이언트와 HTTP 서버 양쪽의 규칙을 모두 준수해야 한다.

프록시의 분류

개인 프록시와 공유 프록시

  • 공용 프록시
    • 여러 클라이언트가 함께 사용하는 프록시이다.
    • 캐시 프록시로 동작할 수 있다.
  • 개인 프록시
    • 단일 클라이언트를 위해 사용되는 프록시이다.
    • SSH 터널링을 지원할 때 사용하거나,
    • 섀도삭스와 같은 프로그램에서 사용한다.

프록시 vs 게이트웨이

프록시의 형태

  • 프록시
    • 동일한 프로토콜을 사용하는 두 개 이상의 애플리케이션을 연결한다.
    • 단순 중개자의 역할을 수행한다.

게이트웨이의 형태

  • 게이트웨이
    • 서로 다른 프로토콜을 사용하는 두 개 이상의 애플리케이션을 연결한다.
    • 프로토콜 변환기의 역할을 수행한다.
  • 실제로 두 개념 간의 차이는 모호하다.
    • 프록시도 약간의 프로토콜 변환을 수행한다.
      • 프록시가 SSL 보안 프로토콜을 지원하기도 한다.
      • 프록시가 SOCKS 방화벽으로 동작한다.
      • 프록시가 FTP 접근을 가능하게 한다.

프록시를 쓰는 이유

  • 용례를 작성해둔 것이니, 가볍게 읽어보면 된다.

어린이 필터

  • 유해 콘텐츠 차단기로 동작한다.

문서 접근 제어자

  • 중앙화된 접근 제어 기능을 제공한다.
  • 감사 추적을 수행한다.
  • 예시
    • 클라이언트 1에게는 제약 없이 서버의 뉴스 페이지 접근을 허용한다.
    • 클라이언트 2에게는 제약 없이 인터넷 접근을 허용한다.
    • 클라이언트 3이 서버 B에 접근하기 전에는 암호를 요구한다.

보안 방화벽

  • 방화벽 기능을 수행하는 프록시이다.
  • 바이러스 검사를 진행한다.

웹 캐시

  • 웹 캐시 용도로 프록시를 사용한다.

대리 프록시

  • 리버스 프록시로도 잘 알려져 있다.
  • 웹 서버인 것처럼 위장한다.
  • 원 서버에 데이터를 요청한다.
  • 바로 아래의 콘텐츠 라우팅 기능과 결합된다.
    • 주문형 복제 콘텐츠의 분산 네트워크를 구성하기 위해 사용된다.

콘텐츠 라우터

  • 프록시가 트래픽 조건과 콘텐츠 종류에 따라 특정 웹 서버로 유도한다.
  • 유료 구독자의 요청인 경우, 구독자에게 높은 성능을 제공하기 위해 복제 캐시로 요청을 전달한다.
  • 맞춤형 콘텐츠 라우팅 기능을 수행한다.

트랜스코더

프록시를 거쳐, 적절한 언어로 번역된다.

  • 트랜스코딩이란?
    • 데이터의 표현 방식을 자유롭게 변환하는 것
  • 프록시를 이용해 콘텐츠를 클라이언트에게 전달하기 전에 본문의 포맷을 수정하기도 한다.
  • 국제화(i18n) 시에도 사용된다.

익명화 프록시 (Anonymizer)

  • 개인정보 보호와 익명성 보장을 위해 사용된다.
    • User-Agent 헤더에서 사용자의 컴퓨터와 OS 정보를 제거한다.
    • From 헤더에서 사용자의 이메일 주소 정보를 제거한다.
    • Referer 헤더를 제거하여 어느 사이트를 거쳐 방문했는지 파악하기 어렵게 한다.
    • Cookie 헤더를 제거하여 프로필과 신원 정보를 삭제한다.

프록시는 어디에 있는가?

프록시 서버 배치

출구 프록시

클라이언트 - 로컬 네트워크 - 프록시 - ISP - 인터넷 - 웹 서버

  • 로컬 네트워크의 출구에 배치된다.
  • 회사 외부의 악의적인 해커를 차단한다.
  • 부적절한 콘텐츠를 필터링한다.

입구 프록시

클라이언트 - 로컬 네트워크 - ISP - 프록시 - 인터넷 - 웹 서버

  • ISP 접근 지점에서 고객의 모든 요청을 처리한다.
  • 캐시 프록시로 동작한다.

대리 프록시(리버스 프록시)

클라이언트 - 로컬 네트워크 - ISP - 인터넷 - 프록시 - 웹 서버

  • 웹 서버 앞에서 필요할 때만 웹 서버에 자원 요청을 수행한다.
  • 웹 서버에 보안 기능을 추가한다.
  • 모든 요청을 대신 처리하는 프록시 서버이다.

네트워크 교환 프록시

  • 인터넷 교차로의 혼잡을 완화한다.
  • 트래픽 흐름을 감시한다.
  • 현대 환경에서는 다음과 같은 특징을 가진다.
    • 요즘에는 많이 사용되지 않는다.
    • 예전만큼 대역폭 비용이 높지 않다.
    • CDN으로 대체가 가능하다.
    • HTTPS로 충분히 대응할 수 있다.

프록시 계층

  • 부모 프록시
    • 인바운드 프록시라고도 불린다.
    • 서버에 가까운 방향의 프록시이다.
  • 자식 프록시
    • 아웃바운드 프록시로 알려진다.
    • 클라이언트에 가까운 방향의 프록시이다.

프록시 계층 콘텐츠 라우팅

  • 프록시 계층은 정적이다.
  • 하지만, 반드시 정적으로 호출되어야 할 필요는 없다.
    • 기존 계층을 건너뛰고, 부모 프록시가 아닌 즉시 원 서버로 라우팅할 수 있다.
    • 이를 “동적 콘텐츠 라우팅” 이라고 한다.
  • 동적 콘텐츠 라우팅의 예
    • 로드 밸런싱을 수행한다.
    • 지리적 인접성을 근거로 라우팅한다.
    • 프로토콜 또는 타입에 따라 라우팅한다.
      • URI 기반 라우팅을 수행한다.
      • 특정 프로토콜 또는 타입으로 처리한다.
    • 유료 서비스 가입자를 위한 라우팅을 실시한다.

프록시의 트래픽 처리 방법

클라이언트 수정

  • 웹 클라이언트의 수동 또는 자동 프록시 설정을 사용한다.
  • 하단의 "클라이언트 프록시 설정" 내용을 참고하자.

네트워크 수정

  • 웹 트래픽을 스위칭 장비나 라우팅 장비 등 인프라 장비를 통해 클라이언트가 인지하지 못하는 방식으로 프록시로 라우팅한다.

DNS Name 수정

  • 리버스 프록시(대리 프록시)가 웹 서버의 이름과 IP 주소를 대신 사용된다.
  • 모든 요청은 서버 대신 리버스 프록시로 도착된다.
  • 실제 서버의 IP 주소와 이름은 변경되며, 리버스 프록시가 해당 원본 IP 주소와 이름을 사용한다.

웹 서버 수정

  • 웹 서버가 직접 프록시로 리다이렉트하는 방식이다.
  • 305 Use Proxy 상태 코드가 사용된다.
  • 클라이언트가 명시적으로 프록시 설정을 관리할 수 있도록 하는 방식이 선호되어 해당 기능은 사양되었다.

클라이언트 프록시 설정

수동 설정

  • 프록시 사용을 명시적으로 설정한다.
  • 브라우저 설정을 통해 구성할 수 있다.

브라우저 기본 설정

  • 브라우저 벤더가 기본 프록시를 지정한다.
  • 수동 설정이 없는 경우, 브라우저가 기본적으로 특정 프록시를 사용한다.

프록시 자동 설정(PAC)

  • 수동 프록시 설정은 단순하지만 유연성이 떨어진다.
    • 해당 한계를 극복하기 위해 나온 기능
  • 자바스크립트로 작성된 PAC 파일의 URI를 제공한다.
  • 자바스크립트 코드를 통해 적절한 프록시를 결정한다.
  • 20장을 참고하자.

WPAD 프록시 발견

  • Web Proxy AutoDiscovery Protocol을 사용한다.
    • 웹 프록시 자동발견 프로토콜이다.
  • "설정 서버"를 자동으로 찾는 프로토콜이다.
    • 설정 서버는 자동 설정 파일을 다운로드할 수 있는 서버이다.

클라이언트의 WPAD를 이용한 프록시 탐색 과정

  • PAC URI를 찾기 위해 WPAD를 사용한다.
  • 지정된 URI에서 PAC 파일을 가져온다.
  • PAC 파일을 실행한다.
  • 확인된 프록시 서버를 통해 요청을 처리한다.

정식 WPAD 명세

  • DHCP
    • 동적 호스트 발견 규약이다.
  • SLP
    • 서비스 위치 규약이다.
  • DNS의 잘 알려진 호스트 명을 사용한다.
  • DNS SRV 레코드를 활용한다.
  • DNS TXT 레코드 내의 서비스 URI를 사용한다.
  • 20장을 참고하자.

프록시의 주요 특징

서버 요청과 프록시 요청의 URI 차이점

프록시 URI는 서버 URI와 다르다

  • 클라이언트의 프록시 사용 여부에 따라 전송되는 요청의 URI가 달라진다.

클라이언트가 원 서버에 요청을 보낼 때의 형식. 부분 URI를 전송한다.

  • 클라이언트에서 서버로 전송하는 URI는 부분 URI이다.

클라이언트가 프록시에 요청을 보낼 때의 형식. 완전 URI를 전송한다.

  • 클라이언트에서 프록시로 전송하는 URI는 완전한 URI이다.
  • 그 이유는 다음과 같다.
    • 클라이언트는 서버에 요청할 때 불필요한 정보를 생략하기 위해 스킴과 호스트가 없는 부분 URI만 사용한다.
      • Host 헤더로 필요한 정보를 모두 전달할 수 있다.
      • 기본 정보는 이미 정해져 있다.
    • 클라이언트는 프록시에 요청을 보낼 때
      • 프록시가 서버와 커넥션을 맺어야 하기 때문에
      • 프록시와 원 서버가 연결될 수 있도록 완전한 URI를 전송한다.

이 문제는 가상 호스팅과 유사하다

  • 프록시의 '스킴/호스트/포트번호 누락' 문제는 가상 호스팅된 웹 서버가 직면하는 문제와 동일하다.
    • 접근하려는 웹 서버의 호스트명을 정확히 확인해야 한다.
  • 5장의 docroot와 18장의 가상 호스팅을 참고하자.

인터셉트 프록시와 리버스 프록시는 서버 호스트 정보를 알아내기 어렵게 만든다

  • 앞서 설명한 바와 같이, 프록시 URI는 원 서버 URI와 다르다.
  • 그러나 리버스 프록시는 원 서버와 유사하게 부분 URI를 수신한다.

리버스 프록시에(클라이언트는 리버스 프록시에 보내는 줄 모르지만) 요청을 보낼 때

  • 인터셉트 프록시 또한 원 서버와 유사하게 부분 URI를 수신한다.

인터셉트 프록시(클라이언트는 원 서버에 보내는 줄 알지만)에 요청을 보낼 때

  • 이 내용이, 해당 챕터의 내용을 어렵게 만드는 요인이다.

프록시 요청과 서버 요청의 구분

다목적 프록시는 프록시 요청과 서버 요청을 모두 지원해야 한다

  • 프록시는 완전한 URI와 부분 URI 모두를 지원할 수 있어야 한다.

정확한 프록시의 URI 사용 규칙

  • 완전한 URI가 제공되면 프록시는 이를 그대로 사용해야 한다.
  • 부분 URI가 제공되고 Host 헤더가 존재하면, Host 헤더를 통해 원 서버의 이름과 포트 번호를 확인해야 한다.
  • 부분 URI가 제공되었으나 Host 헤더가 없는 경우, 다음 규칙에 따라 원 서버를 식별해야 한다.
    • 프록시가 리버스 프록시인 경우,
      • 프록시 설정에 실제 서버의 주소와 포트 번호가 포함될 수 있다.
    • 과거에 인터셉트 프록시가 가로챈 트래픽인 경우,
      • 인터셉트 프록시가 원 IP 주소와 포트 번호를 전달했을 것이다.
      • 해당 IP 주소와 포트 번호를 사용해야 한다.
    • 모든 방법이 실패하면,
      • 원 서버를 식별할 수 없으므로 에러 메시지를 반환해야 한다.

URI 수정에 대한 규칙

  • 프록시는 임의로 URI를 변경해서는 안 된다.
    • 다운스트림과의 상호 운용성에 치명적인 문제가 발생할 수 있다.
  • 프록시 서버는 HTTP 프로토콜에 대해 가능한 관대한 태도를 유지해야 한다.
    • 프로토콜 경찰처럼 깐깐하게 동작해서는 안 된다.
  • 특히, URI 전달 시 절대경로를 수정하는 것은 금지된다.
    • 포트 번호 추가도 금지된다.
    • 잘못된 예약 글자 이스케이프도 금지된다.
  • 단, 빈 경로는 '/'로 대체하는 것은 허용된다.

프록시는 브라우저의 smart URI 자동완성 및 호스트명 확장 기능에 영향을 미친다

브라우저의 smart URI 자동완성 및 호스트명 확장

  • 브라우저는 검색엔진에 직접 연결하는 것을 제외하고,
    • ctrl + Enter를 누르면 www. 접두사와 .com 접미사를 자동으로 추가한다.
  • 해석할 수 없는 URI는 서드파티 사이트로 전달된다.
  • 시스템의 DNS 설정에 따라 단순 호스트명만 입력해도 도메인 이름이 자동 완성된다.
    1. 예를 들어, "oreilly.com" 도메인 환경에서는
    2. 단순히 "host7"만 입력해도,
    3. DNS는 이를 완전한 호스트명으로 인식하지 않고 기본 도메인인 "oreilly.com"을 뒤에 추가하여
    4. "host7.oreilly.com"으로 변환한다.
    • 이 기능은 DNS 접미사 검색(DNS Suffix Search)이라 한다.
      • 해당 접미사는 DHCP 서버에서 받아오거나 임의로 설정할 수 있다.
      • 일반적으로 ISP가 임의로 설정한다.

ipconfig 을 입력하면 보이는 DNS 접미사

cf. 도메인 환경이란?

  • 회사 내에서 컴퓨터가 중앙 서버에 의해 관리받을 때 활용된다.
  • 해당 도메인에 속하면 DNS 접미사가 자동으로 해당 도메인으로 변경된다.

관리자 권한을 통해, 도메인이나 작업 그룹에 가입 가능하다.

프록시 없는 URI 분석 (URI Resolution)

  • 프록시 설정이 없는 경우, 클라이언트는 다양한 호스트명 가능성을 탐색한다.
    • 이는 앞서 설명한 호스트명 자동 확장 기능을 사용하는 것을 의미한다.

명시적인 프록시 사용 시의 URI 분석

  • 명시적으로 프록시 사용이 설정되면 부분 호스트명 자동 확장이 발생하지 않는다.

  • 일부 프록시는 자동 확장을 시도하나, 위에서 설명한 이유로 자동 확장은 허용되지 않는다.

인터셉트 프록시를 이용한 URI 분석

  • 인터셉트 프록시는 실제 원 서버처럼 동작하여 URI 호스트명 자동 확장 기능을 사용한다.
  • 이는 프록시가 장애 허용 측면에서 중요한 역할을 수행함을 의미한다.
    • 인터셉트 프록시가 원 서버와 연결에 실패하면 직접 다른 IP 주소를 탐색하거나 잘못된 응답을 반환해야 한다.

메시지 추적 방법

메시지 추적이 필요한 이유

  • 메시지 추적은 디버깅에 필요하다.
  • IP 패킷의 흐름을 추적할 필요가 있다.

Via 헤더

Via 헤더란?

  • 중간 노드를 순차적으로 기록하는 헤더이다.

Via 헤더에 쉼표(,)를 통해 다양한 프록시들이 중간 노드로 기록되어 있다.

  • 관련 문법을 차례대로 이해해보자.

Via 문법

이렇게 봐서는 이해하기 어려울 것 같다. 각 요소를 하나씩 분석해보자.

  • 프로토콜 이름
    • 선택적으로 사용된다.
    • 기본값은 HTTP이다.
  • 프로토콜 버전
    • 일반적으로 1.1 또는 1.0이다.
  • 노드 이름
    • 중개자의 호스트와 포트 번호를 나타낸다.
    • 포트 번호가 없으면 현재 프로토콜의 기본 포트가 사용된다.
    • 호스트명은 가명으로 대체할 수 있다.
  • 노드 코멘트
    • 주석처럼 사용된다.
    • 괄호 () 를 통해 표현된다.
    • 벤더나 버전 정보, 장치에서 발생한 이벤트를 기록한다.

Via 요청과 응답 경로

  • 요청과 응답 모두 Via 헤더를 포함한다.
  • 응답의 Via 헤더는 보통 요청의 Via 헤더와 반대 방향으로 기록된다.

요청의 Via 헤더와, 응답의 Via 헤더가 역순이다.

Via와 게이트웨이

  • 게이트웨이는 프로토콜 변환을 수행할 가능성이 있다.
  • Via 헤더는 프로토콜 변환 과정을 기록할 수 있다.

FTP로 프로토콜이 바뀐 과정이 설명되어 있다.

Server 헤더와 Via 헤더

  • Server 헤더는 원 서버의 정보를 나타낸다.
  • 프록시 소프트웨어 정보를 기록하려면 Via 헤더를 사용해야 한다.

Via가 개인정보 보호와 보안에 미치는 영향

  • 프록시 서버가 네트워크 방화벽의 일부로 동작하는 경우,
    • 프록시는 방화벽 뒤에 있는 호스트의 이름과 포트를 노출해서는 안 된다.
  • 같은 도메인 내에서 프로토콜 값이 동일한 경우, 다음과 같이 가명으로 합칠 수 있다.

company.com 도메인 내 두 프록시가 합쳐졌다.

TRACE 메소드

특징

  • TRACE 메소드는 프록시 흐름 디버깅을 위해 사용된다.
  • 홉을 거칠 때마다 메시지 내용의 변화를 관찰한다.
  • 모든 경로를 탐색한다.

Max-Forwards

  • 모든 경로를 탐색하다 보니 무한 루프에 빠질 수 있다.
  • 따라서 지나칠 수 있는 홉 수에 제한을 두어야 한다.

Trace 메소드가 사용되지 않는 이유

  • TRACE 메소드는 보안 헤더가 노출될 위험이 있어 사용되지 않는다.

프록시 인증

  • Proxy-Authenticate 헤더를 사용한다.
  • 자격이 유효하면 요청을 통과시킨다.
  • 자격이 유효하지 않으면 407 응답을 반환한다.
  • 클라이언트가 407 응답을 수신하면, 필요한 자격을 수집해야 한다.
    • 로컬 DB를 확인한다.
    • 사용자에게 자격 정보를 요청한다.

프록시 상호운용성

지원하지 않는 헤더와 메소드 다루기 위한 방법

프록시

  • 이해할 수 없는 헤더 필드는 반드시 그대로 전달해야 한다.
  • 동일한 이름의 헤더 필드가 여러 개 존재할 경우, 그 순서를 반드시 유지해야 한다.
  • 프록시가 특정 메소드에 익숙하지 않더라도, 해당 메시지를 다음 홉으로 전달하도록 시도해야 한다.

OPTIONS 메소드

  • OPTIONS * HTTP/1.1은 서버 전체의 능력을 문의하는 방식이다.
  • OPTIONS http://www.joes-hardware.com/index.html HTTP/1.1은 특정 리소스에 대해 지원되는 기능을 문의하는 방식이다.

Allow 헤더

  • 요청 시에는 새 리소스가 지원되었으면 하는 메소드를 권장한다.
  • 응답 시에는 요청된 리소스에 대해 지원되는 메소드를 열거한다.
  • 프록시는 여기서 지정된 메소드를 임의로 수정해서는 안 된다.
    • 원 서버와 통신하는 다른 경로가 존재할 수 있다.