teklog

☼

HTTP 완벽 가이드 - 6 프록시

2025/03/02

n°66

category : HTTP

img

Cloudflare를 자주 쓰면서도, 공식 문서의 이 글을 읽고 표면적으로만 이해할 수 있었다. 이번 챕터에서 프록시를 자세하게 다루었다. 궁금증이 들 때마다 다시 읽어보면 좋겠다.

웹 중개자

  • 웹 프록시 서버는 클라이언트의 입장에서 트랜잭션을 수행하는 중개인.

    • 프록시 없이 클라이언트는 서버와 직접 대화

    • 있다면 클라이언트는 프록시와 대화

  • 프록시는 웹 서버이면서 웹 클라이언트이기도 하다

  • 서버처럼 클라이언트에서 요청과 커넥션을 다루고 응답을 보내며, 클라이언트처럼 서버로 요청을 보내고 응답을 받는다.

  • 따라서 HTTP 클라이언트와 서버 양쪽 규칙을 준수해야한다

개인 프록시와 공유 프록시

  • 프록시 서버는 하나의 클라이언트가 독점적으로 사용할 수도, 여러 클라이언트가 공유할 수도 있다.

  • 개인 프록시 / 공용 프록시로 나뉜다.

공용 프록시

  • 대부분의 프록시는 공용이며 공유된다

  • 중앙 집중형 프록시를 관리하는 것이 더 비용효율이 높고 쉽다

  • 캐시 프록시 서버와 같은 몇몇 프록시는 공용이 유리하다. 여러 사용자들의 공통된 요청에서 이득을 볼 수 있기 때문이다.

개인 프록시

  • 흔하지 않지만 꾸준히 사용됨

  • 용도: 브라우저의 기능을 확장, 성능을 개선, 무료 ISP 서비스 등등..

  • 추가: 사용자의 컴퓨터를 익명으로 유지, 원치 않는 사이트 접근을 차단,

** ISP 서비스 (Internet Service Provider)
인터넷 서비스 제공자 서비스

프록시 vs 게이트웨이

  • 프록시: 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결

  • 게이트웨이: 서로 다른 프로토콜을 사용하는 둘 이상을 연결. 클라이언트와 서버가다른 프로토콜로 말하더라도 서로 간의 트랜잭션을 완료할 수 있도록 해주는 프로토콜 변환기처럼 동작
    이전 글 참조*

  • 때때로 프록시에서 SSL 보안 프로토콜, SOCKS 방화벽, FTP 접근 등 웹 기반 애플리케이션 지원을 위해 게이트웨이를 구현하여 경계가 모호할 때도 있다.

왜 사용하는가?

  • 실용적이고 유용한 기능을 위해. 보안, 성능, 비용 개선을 포함

  • 모든 프록시 서버는 HTTP 트래픽을 읽고 수정할 수 있기에 부가가치 창출을 위해 사용됨.

다음 예시를 살펴보자.

어린이 필터 (필터링)

  • 어린이에게 안전하지 않은 사이트만 차단하는 필터링 프록시를 사용할 수 있음.

  • 부적절한 사이트 접근은 프록시를 통해 강제로 거부할 수 있음

문서 접근 제어자

  • 프록시는 많은 웹 서버들과 웹 리소스에 대한 단일한 접근 제어 전략을 구현하고 감사 추적(audit trail)을 위해 사용될 수 있다.

  • 중앙화된 접근 프록시 서버를 통해 여러 클라이언트, 서버를 일일히 제어할 필요없이 프록시 한 곳에서 접근 제어를 설정할 수 있다.

  • 대기업 환경, 분산된 관료 조직 등에서 유용함

  • ex) 클라이언트 A에게는 제약 없이 뉴스 웹사이트 접근 만을 허용, B에게는 제약 없이 인터넷 컨텐츠 허용, C에게는 서버 B에 접근하기 전 비밀번호를 요구. 이러한 설정을 프록시에서 한번에 할 수 있다.

보안 방화벽

  • 종종 보안을 강화하기 위해 사용.

  • 조직 안에 들어오거나 나가는 응용 레벨 프로토콜 흐름을 네트워크 한 지점에서 통제.

  • 바이러스를 제거하는 웹, 이메일 프록시는 트래픽을 세심히 살펴볼 수 있는 웹훅을 제공함

웹 캐시

  • 프록시 캐시는 인기있는 문서의 로컬 사본을 관리하고 해당 문서에 대한 요청이 오면 빠르게 제공할 수 있음

  • 클라이언트와 더 가까운 위치에서 캐시를 제공하여 빠르고 저렴하게 리소스를 보낼 수 있음

대리 프록시 (Surrogate)

  • 웹 서버인 것처럼 위장하는 프록시. 대리 혹은 리버스 프록시, 서버 가속기라고도 불린다.

  • 요청을 받지만 요청 받은 컨텐츠의 위치를 찾아내기 위해 다른 서버와 커뮤니케이션을 시작한다.

  • 공용 컨텐츠에 대한 느린 웹 서버의 성능을 개선하기 위해 사용될 수 있다. 이런 식으로 사용하는 대리 프록시를 서버 가속기라고부른다.

  • 컨텐츠 라우팅 기능과 결합되어 주문형 복제 컨텐츠의 분산 네트워크를 만들기 위해 사용될 수 있음

  • 추가: 예시로 Cloudflare CDN이 리버스 프록시를 사용한다

컨텐츠 라우터

  • 인터넷 트래픽 조건과 컨텐츠 종류에 따라 요청을 특정 웹 서버로 유도하는 컨텐츠 라우터로 동작할 수 있음

  • 컨텐츠 라우터는 여러 맞춤형 서비스를 구현하는데 사용될 수 있다.

  • ex) 더 높은 성능을 위해 돈을 지불했다면, 컨텐츠 라우터는 요청을 더 가까운 복제 캐시로 전달.

  • ex2) 필터링 서비스에 가입했다면 HTTP 요청이 필터링 프록시를 통과하도록 할 수 있다.

트랜스코더

  • 컨텐츠를 클라이언트에 전달하기 전에 본문 포맷을 수정할 수 있다.

  • 데이터 표현방식을 자연스럽게 변환하는 것을 트랜스코딩이라고 부른다

  • ex) 트랜스코딩 프록시는 크기를 줄이기 위해 자신을 거쳐가는 GIF 이미지를 jpeg로 변환할 수 있다. 이미지의 크기를 줄이거나 색을 변환하는 등. 텍스트 파일을 압축하거나 스마트폰같은 작은 기기에 맞게 작은 텍스트로 수정할 수 있다.

익명화 프록시 (Anonymizer)

  • 익명화 프록시는 HTTP 메시지에서 신원을 식별할 수 있는 특성을 적극적으로 제거하여 개인정보 보호와 익명성 보장에 기여할 수 있다.

  • 제거 대상 : 클라이언트 IP 주소, From 헤더, User-Agent 헤더, Referer헤더, 쿠키, URI 세션 아이디 등등

어디에 있는가?

  • 어떻게 프록시가 네트워크 아키텍처 상 어디에 배치되는가

  • 어떻게 프록시의 연쇄가 계층을 이루는가

프록시 서버 배치

  • 사용처에 따라 프록시는 어디에든 배치할 수 있다.

출구(Egress) 프록시

  • 로컬 네트와크와 더 큰 인터넷 사이를 오가는 트래픽을 제어하기 위해 프록시를 로컬 네트워크의 출구에 둘 수 있다.

  • ex) 회사 밖의 악의적인 해커들을 막는 방화벽을 제공하거나, 인터넷 요금을 절약하고 트래픽 성능을 개선하기 위해 출구 프록시를 사용할 수 있다

  • ex2) 초등학교에서 부적잘한 컨텐츠를 브라우징하는 것을 막기 위한 필터링 출구 프록시

접근(입구) 프록시

  • 고객으로부터 모든 요청을 종합적으로 처리하기 위해 ISP 접근 지점에 위치하기도 한다

  • ISP는 사용자들의 다운로드 속도를 개선하고, 인터넷 대역폭 비용을 줄이기 위해 캐시 프록시를 사용

대리(리버스) 프록시

  • 네트워크의 가장 끝에 있는 웹 서버들의 바로 앞에 위치하여 웹 서버로 향하는 모든 요청을 처리하고 필요할 때만 서버에 자원을 요청한다.

  • 보안 기능을 추가하거나, 웹 서버 캐시를 느린 웹 서버 앞에 두어 성능을 개선할 수 있다.

  • 일반적으로 웹 서버의 이름과 IP 주소로 스스로를 가장하기 때문에, 모든 요청은 서버가 아닌 이 프록시로 간다.

  • 추가 자료: 역방향 프록시는 하나 이상의 웹 서버 앞에 위치하여 클라이언트의 요청을 가로채는 서버입니다. 이것은 프록시가 클라이언트 앞에 위치하는 정방향 프록시와 다릅니다. 역방향 프록시를 사용하면 클라이언트가 웹 사이트의 원본 서버에 요청을 보낼 때 역방향 프록시 서버가 네트워크 에지에서 해당 요청을 가로챕니다. 그런 다음 역방향 프록시 서버가 원본 서버에 요청을 보내고 응답을 받습니다. 정방향 프록시와 역방향 프록시의 차이는 미묘하지만, 중요합니다. 요약하면 정방향 프록시는 클라이언트 앞에 위치하며 원본 서버가 해당 특정 클라이언트와 직접 통신하지 못하도록 하는 것입니다. 반면에 역방향 프록시는 원본 서버 앞에 위치하며 어떤 클라이언트도 원본 서버와 직접 통신하지 못 하도록 합니다.

  • 참고 자료 : https://www.cloudflare.com/ko-kr/learning/cdn/glossary/reverse-proxy/

네트워크 교환 프록시

  • 캐시를 이용해 인터넷 교차로의 혼잡을 완화, 트래픽 흐름을 감시하기 위해, 충분한 처리 능력을 갖춘 프록시가 네트워크 사이의 인터넷 피어링 교환 지점들에 놓일 수 있다.

프록시 계층

  • 프록시 계층이라고 불리는 연쇄를 구성할 수 있음

  • 메시지는 최종적으로 원 서버에 도착할 때까지 프록시들을 거쳐 이동, 클라이언트로 돌아갈 때도 마찬가지

  • 계층에서 부모와 자식 관계를 갖는다. 인바운드 프락시(서버에 가까운 쪽)를 부모, 아웃바운드(클라이언트에 가까운 쪽)을 자식으로 부른다.

프록시 계층 컨텐츠 라우팅

  • 프록시 계층은 정적이다.

  • 정적 계층 : 프록시 자식은 항상 부모 프록시에게로 메시지를 보낸다.

  • 동적 부모 선택 : 하지만 여러 판단 근거에 의해 메시지를 다양하고 유동적인 프록시나 원 서버들의 집합으로 보낼 수 있다.

  • ex) 요청된 객체가 컨텐츠 분산을 위해 돈을 지불한 웹 서버에 속한 경우, 프록시는 요청을 가까운 캐시 서버에 보내 캐시된 객체를 반환하거나 캐시가 없을 때 원 서버에서 가져오게 함

  • ex2) 요청이 특정 종류의 이미지인 경우, 접근 프록시는 그 요청을 특화된 압축 프록시에 보내어 느린 모뎀으로 접속했더라도 빠르게 클라이언트가 다운로드할 수 있게함

동적 부모 선택의 예시는 다음이 있다.

부하 균형

  • 자식 프록시는 부하를 분산하기 위해 현재 부모들의 작업량 수준에 근거하여 부모 프록시를 고를 수 있다

지리적 인접성에 근거한 라우팅

  • 자식 프록시는 원 서버의 지역을 담당하는 부모를 선택할 수 있다

프로토콜/타입 라우팅

  • 어떤 자식 프록시는 URI에 근거하여 다른 부모나 원 서버로 라우팅 할 수 있다.

  • 어떤 특정 종류의 URI를 갖고 있는 요청의 경우, 특별한 프록시 서버로 보내져 특별한 프로토콜로 처리될 수 있다

유료 서비스 가입자를 위한 라우팅

  • 웹 서비스 운영자가 빠른 서비스를 위해 추가금을 지불했다면, 대형 캐시나 성능 개선을 위한 압축 엔진으로 라우팅 될 수 있다.

동적 부모 라우팅 로직은 제품(설정 파일, 스크립트 언어, 동적으로 실행 가능한 플러그인 등)마다 다르게 구현된다.

어떻게 프록시가 트래픽을 처리하는가

  • 클라이언트는 보통 서버와 직접 대화하기 때문에, 어떻게 HTTP 트래픽이 프록시로 향하는 길을 찾아내는지 설명할 필요가 있다.

  • 클라이언트 트래픽이 프록시로 가는 방법은 4가지가 있다

클라이언트 수정하기

  • 구글 크롬, 엣지 등 브라우저를 포함한 많은 클라이언트는 수동 혹은 자동 프록시 설정을 지원함

  • 클라이언트가 프록시를 사용하도록 설정되어 있다면, HTTP 요청을 의도적으로 원서버가 아닌 프록시로 보낸다

네트워크 수정하기

  • 클라이언트를 모르고, 간섭할 수 없는 상태에서 네트워크 인프라를 가로채 웹 트래픽을 프록시로 가도록 조정하는 방법. 일반적으로 인터셉트 프록시라고 부름

  • 이 가로챔은 일반적으로 HTTP 트래픽을 지켜보고 가로채어 클라이언트 모르게 트래픽을 프록시로 보내는 스위칭, 라우팅 장치를 필요로함

DNS name space 수정하기

  • 대리(리버스) 프록시는 웹 서버의 이름과 IP 주소를 자신이 직접 사용

  • 모든 요청은 서버 대신 대리 프록시로 간다

  • DNS 이름 테이블을 수동으로 편집하거나, 사용할 적절한 프록시나 서버를 계산해주는 동적 DNS 서버를 이용해 조정될 수 있음

웹 서버 수정하기

  • HTTP 리다이렉션 명령(상태코드 305)를 클라이언트에게 돌려주어 클라이언트 요청을 프록시로 리다이렉트하게 설정할 수 있다. 리다이렉트를 받는 즉시 프록시와 트랜잭션을 시작한다

클라이언트 프록시 설정

종류

수동 설정

  • 프록시를 사용한다고 명시적으로 설정

  • 많은 웹 클라이언트는 프록시를 수동으로 설정하도록 함

  • 구글 크롬: 설정 > 고급 설정 표시 > 프록시 설정 변경.. 에서 프록시를 설정함

  • 다른 브라우저도 아이디어는 동일하다. 프록시의 호스트와 포트 지정.

  • 단순하지만 유연하지 못함. 모든 컨텐츠를 위해 단 하나의 프록시 서버만 지정할 수 있고, 장애 시 대체 작동에 대한 지원이 없음

브라우저 기본 설정

  • 브라우저 벤더, 배포자는 브라우저를 소비자에게 전달하기 전에 프록시를 미리 설정해 놓을 수 있음

프록시 자동설정 (PAC)

  • 자바스크립트 프록시 자동 설정 파일에 대한 URI를 제공할 수 있음

  • 클라이언트는 프록시를 써야하는지, 어떤 프록시 서버를 써야 하는지 판단하기 위해 JS 파일을 가져와 실행

  • PAC 차일은 츠록시 설정에 대한 동적인 해결책. 그때그때 상황에 맞게 계산해주는 작은 자바스크립트 프로그램

  • 문서에 접근할 때마다 스크립트가 적절한 프록시 서버를 선택한다

  • PAC 파일을 사용하기 위해선 PAC 파일의 URI를 브라우저에 설정해야함. '자동 설정'에 URI를 입력

  • 브라우저는 URI로부터 PAC 파일을 가져와 매 접근마다 적절한 프록시 서버 계산하기 위해 이 파일을 이용

  • .pac 확장자, MIME 타입은 'application/x-ns-proxy-autoconfig'이다.

  • 각 PAC 파일은 FindProxyForUrl(url, host) 함수를 정의해야함.

  • 반환 값

  • "DIRECT" 프록시 없이 직접 연결,

  • "PROXY host:port" 지정한 프록시 사용. ex: "PROXY ftp-proxy.example.com:8080"

  • "SOCKS host:port" 지정한 SOCKS 서버 사용.

function FindProxyForURL (url, host) {
	if(url.substring(0,5) === "http:") {
		return "PROXY http-proxy.example.com:8080"
	}
	if(url.substring(0,4) === "ftp:") {
		return "PROXY ftp-proxy.example.com:8080"
	}
	return "DIRECT"
}

WPAD 프록시 발견

  • 대부분의 브라우저는 자동설정 파일을 다운받을 수 있는 '설정 서버'를 자동으로 찾아주는 웹 프록시 자동발견 프로토콜을 제공한다.

  • 브라우저에게 알맞은 PAC 파일을 자동으로 찾아주는 알고리즘

  • WAPD가 구현된 클라이언트가 하는 일 : PAC URI를 찾기 위해 WAPD를 사용 -> 주어진 URI에서 PAC 파일을 가져옴 -> 프록시 서버를 알아내기 위해 PAC 파일을 실행 -> 알아낸 프록시 서버를 이용해 요청을 처리

  • WPAD는 올바른 PAC 파일을 알아내기 위한 몇가지 기법을 사용한다. WPAD 명세는 다음 기법을 성공할 때까지 시도한다.

  • 동적 호스트 발견 규약 DHCP

  • 서비스 위치 규약 SLP

  • DNS 잘 알려진 호스트 명

  • DNS SRV 레코드

  • DNS TXT 레코드 안의 서비스 URI

미묘한 특징들

프록시 서버 요청의 미묘하고 오해하기 쉬운 측면들을 설명한다

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

  • 클라이언트가 프록시 대신 서버로 요청을 보내면 요청의 URI이 달라진다

  • 원래 HTTP 설계에서 클라이언트는 단일한 서버와 직접 대화했다. 가상 호스팅은 없었고, 프록시에 대한 대비도 없었다.

  • 단일 서버는 자신의 호스트명과 포트번호를 알고 있고, 클라이언트는 불필요한 정보 발송을 피하기위해 스킴과 호스트가 없는 부분 URI만 보냈다

  • 프록시가 부상하면서 부분 URI가 문제가 되었다. 프록시는 목적지 서버와 커넥션을 맺어야 하기 때문에 서버의 이름을 알 필요가 있다.

  • 또한 프록시 기반 게이트웨이는 스킴과 연결하기 위해 URI의 스킴을 알 필요가 있었다.

  • 서버로는 부분 URI를, 프록시는 완전한 URI를 보낼 필요가 있다.

  • 명시적으로 설정된 클라이언트 프록시의 경우, 클라이언트는 어떻게 요청을 보내야 하는지 알고 있다.

가상 호스팅에서 일어나는 같은 문제

  • 프록시의 '스킴/호스트/포트번호 누락' 문제는 가상으로 호스팅되는 웹 서버가 직면한것과 같은 문제

  • 가상으로 호스팅 되는 웹 서버는 여러 웹 사이트가 같은 물리적 웹 서버를 공유

  • 요청 하나가 부분 URI /index.html로 오면, 가상으로 호스팅 되는 웹 서버는 그 요청이 접근하고자 하는 웹 사이트의 호스트 명을 알아야함

  • 프록시와 같은 문제이지만, 각각 다른 방법으로 해결되었다.

  • 프록시 : 요청 메시지에 완전한 URI를 갖도록 함

  • 가상 호스팅: 호스트와 포트에 대한 정보가 담겨있는 Host 헤더를 요구

인터셉트 프로시는 부분 URI를 받는다

  • 클라이언트는 자신이 프록시와 대화하고 있음을 모를 때도 있다. -> 완전한 URI 보내지 못할 수 있음

  • 클라이언트에 프록시 사용이 설정되어 있지 않더라도, 클라이언트 트래픽은 대리 프록시나 인터셉트 프록시를 지날 수 있다.

  • 대리 프록시: 앞서 살펴본 바와 같이 원서버의 호스트 명과 아이피 주소를 사용해 원서버를 대신함

  • 인터셉트: 서버로 가는 트래픽을 가로채 캐시된 응답을 돌려주는 등의 일을 한다. 그렇기 때문에 부분 URI를 얻게 될 것이다.

프록시는 프록시 요청과 서버 요청 모두 다룰 수 있다

  • 트래픽이 프록시 서버로 리다이렉트 될 수 있는 여러 방법이 존재하기 때문에, 다목적 프록시 서버는 요청 메시지의 완전한 URI와 부분 URI 모두를 지원해야함

  • 명시적인 프록시 요청에 대해선 완전한 URI, 아니면 부분 URI를 사용

  • 웹 서버 요청의 경우에는 가상 Host 헤더를 사용해야함

  • 완전한 헤더가 주어질 시 : 프록시는 이를 사용

  • 부분 URI가 주어지고 Host 헤더가 있을 시 : 프록시는 Host 헤더를 이용해 원서버의 이름과 포트 번호를 알아냄

  • 부분 URI가 주어지고 Host 헤더가 없을 시 :

    • 프록시가 원 서버를 대신하는 대리 프록시라면 실제 서버의 주소와 포트번호가 설정되어있을 것

    • 이전에 어떤 인터셉트 프록시가 가로챘던 트래픽을 받았고, 그 프록시가 원 IP 주소, 포트번호를 사용할 수 있게 해두었다면 그것을 사용

    • 모두 실패시 반드시 에러를 반환

전송 중 URI 변경

  • 프록시 서버는 요청 URI 변경에 매우 신경써야함

  • 사소한 URI 변경이라도 다운스트림 서버와 상호운용성 문제 발생 가능

  • 따라서 프록시는 최대한 관대하게. 프로토콜을 강제하다가 기존의 잘 동작하는 기능을 망가뜨릴 수 있다.

  • HTTP 명세는 일반적인 인터셉트 프록시가 URI를 전달할 때 절대 경로를 고쳐쓰는 것을 금지한다

  • 유일한 예외는 빈 경로를 '/'로 교체하는 것 뿐이다.

URI 클라이언트 자동확장과 호스트 명 분석(Hostname Resolution)

  • 브라우저는 프록시 존재 여부에 따라 요청 URI를 다르게 분석

  • 없다면 사용자가 타이핑한 URI를 가지고 그에 대응하는 IP 주소를 찾는다. 호스트명이 발견되면 그에 대응하는 IP 주소에 연결이 성공할 때까지 시도

  • 호스트가 발견되지 않는다면, 브라우저는 사용자가 호스트 명의 짧은 약어를 타이핑한 것으로 보고 호스트명 확장을 제공하고자 한다.

  • 지난 글의 확장 URL 참조

프록시 없는 URI 분석 URI Resolution

  • 브라우저는 유효한 호스트 명이 발견될 때까지 다양한 호스트 명의 가능성을 검색한다

  • ex) 주소 창에 orielly만 검색했을 시, 브라우저는 https:// 스킴, 포트번호, 경로 /index.html, www. ... com 등을 추가하며 성공할 때까지 연결을 시도한다.

  • 지난 글의 확장 URL 참조

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

  • 명시적인 프록시 사용 시 위와 같은 브라우저의 자동 확장들 중 어느 것도 수행할 수 없다.

  • 브라우저의 URI가 프록시를 지나쳐버리기 때문이다.

  • ex) 주소 창에 oreilly만 검색했을 시, 브라우저는 https:// 스킴과 기본 경로만 추가한다. htts://oreilly/

  • 따라서 몇몇 프록시는 브라우저 확장 기능을 최대한 흉내 내려고 시도한다

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

  • 호스트명 분석은 보이지 않는 인터셉트 프록시에서 차이가 있다.

  • 클라이언트 입장에서 프록시는 존재하지 않는 것이기 때문이다.

  • 앞선 것과 마찬가지로 브라우저는 자동확장을 통해 성공할 때까지 호스트를 찾아보고, IP 주소를 DNS 서버에서 반환 받는다. -> 하지만 어떤 IP는 죽은 것일 수 있다. 그러나 인터셉트 프록시가 있다면, 첫번째 접속 시도는 원서버가 아닌 프록시 서버에 의해 종료된다. 클라이언트는 성공적으로 웹 서버와 대화했다고 믿지만, 웹 서버는 죽은 상태일 수 있다 -> 프록시가 최정적으로 웹 서버와 상호작용할 준비가 됐을 때, 프록시는 그 IP 주소가 다운된 것을 알게된다. -> 이때 브라우저와 동등한 수준의 장애 허용을 제공하기 위해 역방향 DNS, Host 헤더 등을 사용해 다른 IP 주소를 시도해야한다

  • 인터셉트 프록시, 명시적인 프록시 모두 죽은 서버의 DNS 분석에 대한 장애 허용을 지원하는 것이 중요하다

  • 브라우저가 명시적인 프록시 사용 설정이 되어있는 경우 장애 허용이 프록시에 달려있기 때문이다.

메시지 추적

앞서 살펴본 바와 같이 클라이언트와 서버 사이에 프록시 서버가 계층을 이루며 여러 개가 있을 수 있다. 프록시는 여러 벤더에 의해 개발되고, 서로 다른 기능과 버그를 갖을 수 있다. 따라서 프록시를 넘나드는 메시지의 흐름을 추적하고 문제점을 찾아내는 것이 필요해졌다.

Via 헤더

Via: 1.1 proxy-62.example-isp.net, 1.0 cache.example.com

  • Via 헤더 필드는 메시지가 지나는 각 중간 노드(프록시나 게이트웨이)의 정보를 나열

  • 메시지가 또 다른 노드를 지날 때마다, 중간 노드는 Via 목록 끝에 반드시 추가되어야함

  • Via 헤더 필드는 메시지의 전달 추적, 메시지 루프 진단, 모든 메시지 발송자들의 프로토콜을 다루는 능력을 알아보기 위해 사용됨

  • 프록시는 요청을 보내기 전, 자신을 가리키는 유일한 문자열을 Via 헤더에 삽입해야하며, 네트워크에 라우팅 루프가 있는지 탐지하기 위해 이 문자열이 들어온 요청에 있는지 검사해야함

Via 문법

  • 쉼표로 구분된 경유지의 목록. 각 경유지는 개별 프록시 서버, 게이트웨이 홉을 나타냄. 중간 노드의 프로토콜과 주소에 대한 정보를 담음.

  • 프로토콜 이름: 중개자가 받은 프로토콜. HTTP라면 생략 가능. 버전 앞에 /로 구분되어 붙음.

  • 프로토콜 버전: 버전 포맷은 프로토콜에 따라 다르다. HTTP은 1.0, 1.1(표준 포맷)을 사용.

  • 노드 이름: 중개자의 호스트와 포트번호.(선택 사항) 정보 보호를 위해 가명으로 대체 가능

  • 노드 코멘트: 중개자 노드를 서술하는 코멘트. 벤더, 프록시 버전 정보를 명시하며 몇몇 프록시 서버는 장치에서 일어난 이벤트에 대한 진단 정보를 포함하기도 함

  • Via 요청과 응답 경로: 요청 메시지와 응답 메시지 모두 프록시를 지나기에 모두 Via 헤더를 갖는다. 요청은 ABC 프록시를 지난다면, 응답 Via는 CBA. 둘은 항상 반대 순서로 기술

  • Via와 게이트웨이: 몇몇 프록시는 HTTP 외 프로토콜 사용 가능한 게이트웨이 기능을 지원. Via 헤더는 이러한 프로토콜 변환을 기록하므로, 프록시 연쇄에서 프로토콜 변환이 있었는지 확인 가능.

  • Server 헤더와 Via 헤더: 서버 응답 헤더 필드는 원서버에 의해 사용되는 소프트웨어를 알려준다. 프록시는 Server 헤더를 수정해선 안된다. 대신 Via를 사용한다.

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

  • 명시적으로 Via 문자열 안에 정확한 호스트명을 제외하는 동작이 켜져 있지 않은 이상, 프록시 서버가 네트워크 방화벽의 일부인 경우 프록시는 방화벽 뒤에 숨어있는 호스트의 이름과 포트를 전달해서는 안된다.

  • 보안의 이유를 위해 여러 경유지를 하나로 합칠 수 있으나, 모든 프록시가 같은 조직의 통제하에 있고, 호스트가 가명으로 교체되지 않은 이상 함부로 합쳐서는 안된다. 수신된 프로토콜 값이 다른 항목들도 합쳐선 안됨.

TRACE 메서드

  • 프록시 서버는 메시지가 전달될 때 메시지를 수정할 수 있음

  • 헤더가 추가, 변경, 삭제되거나 본문이 다른 형식으로 변환되는 등.

  • 프록시가 점차 복잡해지고, 더 많은 프록시가 배치되면서 상호 운용성 문제가 생김

  • 프록시 네트워크를 쉽게 진단하기 위해 HTTP 프록시 네트워크를 통해 홉에서 홉으로 전달될 때마다 메시지 내용이 어떻게 변하는지 쉽게 확인할 방법이 필요

  • 그러한 필요에 의해서 HTTP TRACE 메서드가 사용됨. 프록시 흐름을 디버깅할 때 편리함

  • TRACE가 원서버에 도착시, 요청 메시지를 본문에 담아 그대로 응답으로 보냄

  • 클라이언트는 서버가 받은 메시지와 그 메시지가 지나간 프록시들의 목록을 검사할 수 있음.

  • 응답의 Content-Type은 message/http이며 상태는 200

Max-Forwards

  • TRACE, OPTIONS 메서드의 홉 갯수를 제한하는 헤더

  • 없을 시 모든 프록시를 통과함

  • 메시지가 무한루프에 빠지지 않는지 프록시 연쇄를 테스트, 연쇄 중간의 특정 프록시 서버를 체크할 때 유용

  • OPTIONS 메시지의 전달 횟수도 제한

  • Max-Forwards: 정수. 정수만큼의 홉을 지나도록함. 0이라면 더이상 전달하지 않고 클라이언트로 메시지를 되돌려줌.

  • 모든 프록시, 게이트웨이는 Max-Forwards를 지원해야함

프록시 인증

  • 앞서 살펴본 것처럼 접근 제어 장치로 사용할 수 있다.

  • 유효한 접근 권한 자격을 프록시 서버에 제출하지 않는 한 컨텐츠에 대한 요청을 차단하는 프록시 인증이라는 메커니즘 사용

  • 제한된 컨텐츠에 대한 요청이 프록시 서버에 도착 시, 프록시 서버는 접근 권한을 요구하는 407 Proxy Authorization Required 상태 코드를 자격 제출 방법을 설명하는 Proxy-Authenticate 헤더 필드와 함께 반환

  • -> 클라이언트가 407 응답을 받게되면, 로컬 데이터베이스나 사용자에게 입력을 요구해 자격을 수집

  • -> 자격 획득 시: 클라이언트는 Proxy-Authenticate헤더에 값을 담아 재요청

  • -> 자격 유효 시 프록시는 원 요청을 연쇄를 따라 통과시키고, 아니라면 407 응답을 내림

  • 프록시 연쇄상에 여러개 있을 때는 일반적으로 잘독장하지 않음.

프록시 상호운용성

지원하지 않는 헤더와 메서드 다루기

  • 프록시 서버는 넘어오는 헤더 필드를 모두 이해하지 못할 수 있음 (버전 문제, 사용자 지정 헤더 등)

  • 이해할 수 없는 헤더 필드는 반드시 그대로 전달하며, 상대적인 순서 또한 반드시 유지

  • 프록시는 지원하지 않는 메서드를 통과시켜야함.

OPTIONS: 어떤 기능을 지원하는지 알아보기

  • OPTIONS 메서드는 서버가 지원하는 메서드를 클라이언트(와 프록시)가 알 수 있게 해준다.

  • 서로 다른 기능 수준의 서버와 프록시가 더 쉽게 상호작용하도록 클라이언트는 OPTIONS를 통해 서버 능력을 먼저 확인할 수 있다.

  • 성공 시 서버에서 지원하거나 지정한 리소스에 대해 가능한 선택적인 기능을 서술하는 Allow 헤더 필드를 포함한 200 OK 응답을 반환. 선택적으로 응답 본문을 사용할 수 있으나, 정의된 포맷은 없음

Allow 헤더

  • Allow 엔터티 헤더 필드는, 요청 URI에 의해 식별되는 자원에 대해 지원되는 메서드들이나 서버가 지원하는 모든 메서드를 열거한다.

  • 프록시는 Allow 필드를 수정할 수 없다.