프락시

DevSeong2·2021년 8월 5일

http

HTTP

목록 보기

6/7

『HTTP 완벽 가이드』 교재와 다른 레퍼런스를 참고하여 작성하였습니다.

프락시

웹 중개자

웹 프락시 서버는 클라이언트 입장에서 트랜잭션을 수행하는 중개인입니다. 웹 프락시가 없다면, 클라이언트는 HTTP 서버와 직접 이야기합니다. 웹 프락시가 있다면, 클라이언트는 HTTP 서버와 이야기하는 대신, 자신의 자신의 입장에서 서버와 대화해주는 프락시와 이야기합니다.
HTTP 프락시 서버는 웹 서버이기도 하고 웹 클라이언트이기도 합니다. 프락시는 HTTP 클라이언트의 요청을 받게 되므로, 반드시 웹 서버처럼 요청과 커넥션을 적절히 다루고 응답을 돌려줘야 합니다. 동시에 프락시는 요청을 서버로 보내기도 하므로, 요청을 보내고 응답을 받는 올바른 HTTP 클라이언트처럼 동작해야 합니다.

개인 프락시와 공유 프락시

프락시 서버는 하나의 클라이언트가 독점적으로 사용할 수도 있고, 여러 클라이언트가 공유할 수도 있습니다. 하나의 클라이언트만을 위한 프락시를 개인 프락시, 여러 클라이언트가 함께 사용하는 프락시는 공용 프락시라고 부릅니다.

공용 프락시
중앙 집중형 프락시를 관리하는 게 더 비용효율이 높고 쉽기 때문에 대부분의 프락시는 공용이며 공유된 프락시입니다. 캐시 프락시 서버와 같은 몇몇 프락시 애플리케이션은 프락시를 이용하는 사용자가 많을수록 유리한데, 여러 사용자들의 공통된 요청에서 이득을 취할 수 있기 때문입니다.

개인 프락시
어떤 브라우저 보조 제품들은 몇몇 ISP 서비스와 마찬가지로 브라우저의 기능을 확장하거나 성능을 개선하거나 무료 ISP 서비스를 위한 광고를 운영하기 위해 작은 프락시를 사용자의 컴퓨터에서 직접 실행합니다.

프락시 vs 게이트웨이

프락시는 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결하고, 게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결합니다. 게이트웨이는 클라이언트와 서버가 서로 다른 프로토콜로 말하더라도 서로 간의 트랜잭션을 완료할 수 있도록 해주는 프로토콜 변환기처럼 동작합니다.

실질적으로 프락시와 게이트웨이의 차이점은 모호합니다. 브라우저와 서버는 다른 버전의 HTTP를 구현하기 때문에, 프락시는 때때로 약간의 프로토콜 변환을 하기도 합니다. 그리고 상용 프락시 서버는 SSL 보안 프로토콜, SOCKS 방화벽, FTP 접근, 그리고 웹 기반 애플리케이션을 지원하기 위해 게이트웨이 기능을 구현합니다.

왜 프락시를 사용하는가?

프락시 서버는 보안을 개선하고, 성능을 높여주며, 비용을 절약합니다. 모든 HTTP 트래픽을 들여다보고 건드릴 수 있기 때문에, 프락시는 부가적인 가치를 주는 여러 유용한 웹 서비스를 구현하기 위해 트래픽을 감시하고 수정할 수 있습니다.

예	설명
어린이 필터	부적절한 사이트의 접근을 강제로 거부
문서 접근 제어자	많은 웹 서버들과 웹 리소스에 대한 단일한 접근 제어 전략을 구현하고 감사 추적(audit trail) 각기 다른 조직에서 관리되는 다양한 종류의 수많은 웬 서버들에 대한 접근 제어를 수시로 갱신할 필요 없이, 중앙 프락시 서버에서 접근 제어를 설정
보안 방화벽	조직 안에 들어오거나 나가는 응용 레벨 프로토콜의 흐름을 네트워크의 한 지점에서 통제(보안 강화) 트래픽을 세심히 살펴볼 수 있는 후크(hook) 제공
웹 캐시	프락시 캐시는 인기 있는 문서의 로컬 사본을 관리하고 해당 문서에 대한 요청이 오면 빠르게 제공하여, 느리고 비싼 인터넷 커뮤니케이션을 축소
대리 프락시(Surrogate)	진짜 웹 서버 요청을 받지만 웹 서버와는 달리 요청 받은 콘텐츠의 위치를 찾아내기 위해 다른 서버와 커뮤니케이션 공용 콘텐츠에 대한 느린 웹 서버의 성능 개선(서버 가속기) 콘텐츠 라우팅 기능과 결합되어 주문형 복제 콘텐츠의 분산 네트워크를 만들기 위해 사용
콘텐츠 라우터	인터넷 트래픽 조건과 콘텐츠의 종류에 따라 요청을 특정 웹 서버로 유도하는 콘텐츠 라우터로 동작 사용자들에게 제공할 여러 서비스를 구현하는데 사용
트랜스코더	콘텐츠를 클라이언트에게 전달하기 전에 본문 포맷 수정 트랜스코딩: 데이터의 표현 방식을 자연스럽게 변환하는 것
익명화 프락시(Anonymizer)	HTTP 메시지에서 신원을 식별할 수 있는 특성들을 적극적으로 제거함으로써 개인 정보 보호와 익명성 보장

프락시는 어디에 있는가?

프락시 서버 배치

어떻게 사용할지에 따라서 프락시는 어디에든 배치할 수 있습니다.

출구(Egress) 프락시
로컬 네트워크와 더 큰 인터넷 사이를 오가는 트래픽을 제어하기 위해 프락시를 로컬 네트워크의 출구에 박아 넣을 수 있습니다.
예) 방화벽 제공, 인터넷 요금 절약 & 인터넷 트래픽 성능 개선, 필터링 출구 프락시

접근(입구) 프락시
고객으로부터 모든 요청을 종합적으로 처리하기 위해 프락시는 ISP 접근 지점에 위치하기도 합니다. ISP는 사용자들의 다운로드 속도를 개선하고 인터넷 대역폭 비용을 줄이기 위해 캐시 프락시를 사용해 많이 찾는 문서들의 사본을 저장합니다.

대리 프락시
네트워크의 가장 끝에 있는 웹 서버들의 바로 앞에 위치하여 웹 서버로 향하는 모든 요청을 처리하고 필요할 때만 웹 서버에게 자원을 요청할 수 있습니다. 또한 웹 서버에 보안 기능을 추가하거나 빠른 웹 서버 캐시를 느린 웹 서버의 앞에 놓음으로써 성능을 개선할 수도 있습니다.

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

프락시 계층

프락시 계층에서, 메시지는 최종적으로 원 서버에 도착할 때까지 프락시와 프락시를 거쳐 이동합니다. 프락시 계층에서 프락시 서버들은 부모와 자식의 관계를 갖습니다. 다음번 인바운드 프락시(서버에 가까운 쪽)를 부모라고 부르고 다음번 아웃바운드 프락시(클라이언트 가까운 쪽)는 자식이라고 부릅니다.

프락시 계층 콘텐츠 라우팅

프락시 서버는 여러 가지 판단 근거에 의해 메시지를 다양하고 유동적인 프락시 서버와 원 서버들의 집합에게 보낼 수 있습니다.

동적 부모 선택의 예

부하 균형
자식 프락시는 부하를 분산하기 위해 현재 부모들의 작업량 수준에 근거하여 부모 프락시를 고릅니다.
지리적 인접성에 근거한 라우팅
자식 프락시는 원 서버의 지역을 담당하는 부모를 선택할 수 있습니다.
프로토콜/타입 라우팅
어떤 자식 프락시는 URI에 근거하여 다른 부모나 원 서버로 라우팅 할 수 있습니다. 어떤 특정 종류의 URI를 갖고 있는 요청의 경우, 특별한 프락시 서버로 보내져 특별한 프로토콜로 처리될 수도 있습니다.
유료 서비스 가입자를 위한 라우팅
웹 서비스 운영자가 빠른 서비스를 위해 추가금을 지불했다면, 그들의 URI는 대형 캐시나 성능 개선을 위한 압축 엔진으로 라우팅 될 수 있습니다.

동적 부모 라우팅 로직은 제품마다 다르게 구현됩니다.

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

클라이언트는 보통 웹 서버와 직접 대화하기 때문에, 먼저 어떻게 HTTP 트래픽이 프락시로 향하는 길을 찾아내는지 알 필요가 있습니다.

클라이언트를 수정
만약 클라이언트가 프락시를 사용하도록 설정되어 있다면, 클라이언트는 HTTP 요청을 바로 그리고 의도적으로 원 서버가 아닌 프락시로 보냅니다.

네트워크를 수정
클라이언트는 알지도 못하고 간섭도 할 수 없는 상태에서, 네트워크 인프라를 가로채서 웹 트래픽을 프락시로 가도록 조정하는 몇 가지 기법이 있습니다. 이 가로챔은 일반적으로 HTTP 트래픽을 지켜보고 가로채어 클라이언트 모르게 트래픽을 프락시로 보내는 스위칭 장치와 라우팅 장치를 필요로 합니다. 이것을 인터셉트 프락시라고 부릅니다.

DNS 이름공간을 수정
웹 서버 앞에 위치하는 프락시 서버인 대리 프락시는 웹 서버의 이름과 IP 주소를 자신이 직접 사용합니다. 그래서 모든 요청은 서버 대신 대리 프락시로 갑니다. 이는 DNS 이름 테이블을 수동으로 편집하거나 사용할 적절한 프락시나 서버를 계산해주는 특별한 동적 DNS 서버를 이용해서 조정될 수 있습니다.

웹 서버를 수정
몇몇 웹 서버는 HTTP 리다이렉션 명령을 클라이언트에게 돌려줌으로써 클라이언트의 요청을 프락시로 리다이렉트 하도록 설정할 수 있습니다. 리다이렉트를 받는 즉시 클라이언트는 프락시와의 트랜잭션을 시작합니다.

클라이언트 프락시 설정

모든 현대적인 브라우저는 프락시를 사용할 수 있도록 설정할 수 있습니다.

수동 설정
프락시를 사용하겠다고 명시적으로 설정

브라우저 기본 설정
브라우저 벤더나 배포자는 브라우저(혹은 다른 웹 클라이언트)를 소비자에게 전달하기 전에 프락시를 미리 설정해 놓을 수 있습니다.

프락시 자동 설정(Proxy auto-configuration, PAC)
자바스크립트 프락시 자동 설정(PAC) 파일에 대한 URI를 제공할 수 있습니다. 클라이언트는 프락시를 써야 하는지, 만약 그렇다면 어떤 프락시 서버를 써야 하는지 판단하기 위해 그 자바스크립트 파일을 가져와서 실행합니다.

WPAD 프락시 발견
대부분의 브라우저는 자동설정 파일을 다운받을 수 있는 '설정 서버'를 자동으로 찾아주는 웹 프락시 자동발견 프로토콜(Web Proxy Autodiscovery Protocol, WPAD)를 제공합니다.

클라이언트 프락시 설정: 수동

많은 웹 클라이언트가 프락시를 수동으로 설정할 수 있도록 하고 있습니다. 원리는 프락시의 호스트와 포트를 지정하는 것입니다.

클라이언트 프락시 설정: PAC 파일

수동 프락시 설정은 단순하지만 유연하지 못합니다. 모든 콘텐츠를 위해 단 하나의 프락시 서버만을 지정할 수 있고, 장애 시 대체 작동에 대한 지원도 없습니다. 또한, 큰 조직에서는 설정된 브라우저가 매우 많다면 모두 원하는 대로 설정 변경을 하는 것은 어렵거나 불가능합니다.
프락시 자동 설정(PAC) 파일은 프락시 설정에 대한 보다 동적인 해결책인데, 왜냐하면 그들은 프락시 설정을 그때그때 상황에 맞게 계산해주는 작은 자바스크립트 프로그램이기 때문입니다. 자바스크립트 함수가 적절한 프락시 서버를 선택합니다.

PAC 파일은 일반적으로 .pac 확장자를 가지며 MIME 타입은 'application/x-ns-proxy-autoconfig'
각 파일은 반드시 URI에 접근할 때 사용할 적절한 프락시 서버를 계산해주는 FindProxyForUrl(url, host)라는 함수를 정의해야 합니다.

FindProxyForURL 반환값	설명
DIRECT	프락시 없이 연결이 직접 이루어져야 합니다
PROXY host:port	지정한 프락시를 사용해야 합니다
SOCKS host:port	지정한 SOCKS 서버를 사용해야 합니다

클라이언트 프락시 설정: WPAD

WPAD는 여러 발견 메커니즘들의 상승 전략을 이용해 브라우저에게 알맞은 PAC 파일을 자동으로 찾아주는 알고리즘입니다. WPAD 프로토콜이 구현된 클라이언트가 하게 될 일은 다음과 같습니다.

PAC URI를 찾기 위해 WPAD를 사용합니다.
주어진 URI에서 PAC 파일을 가져옵니다.
프락시 서버를 알아내기 위해 PAC 파일을 실행합니다.
알아낸 프락시 서버를 이용해서 요청을 처리합니다.

WPAD는 올바른 PAC 파일을 알아내기 위해 일련의 리소스 발견 기법을 사용합니다. 여러 가지 발견 기법을 사용하게 되는데, 모든 조직이 모든 기법을 사용할 수 있는 것은 아니기 때문입니다. WPAD는 성공할 때까지 각 기법을 하나씩 시도해봅니다.

동적 호스트 발견 규약(DHCP)
서비스 위치 규약(SLP)
DNS 잘 알려진 호스트 명
DNS SRC 레코드
DNS TXT 레코드 안의 서비스 URI

프락시 요청의 미묘한 특징들

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

웹 서버와 웹 프락시 메시지의 문법은 서로 같지만, 한 가지 예외가 있습니다. 클라이언트가 프락시 대신 서버로 요청을 보내면 요청의 URI가 달라집니다.

✔ 클라이언트 ➡ 서버 (스킴, 호스트, 포트번호가 없는 부분 URI)

GET /index.html HTTP/1.0
User-Agent: Mozilla/5.0


✔ 클라이언트 ➡ 프락시 (완전한 URI)

GET http://www.example.com/index.html HTTP/1.0
User-Agent: Mozilla/5.0

원래의 HTTP 설계에서, 클라이언트는 단일한 서버와 직접 대화했습니다. 단일 서버는 자신의 호스트 명과 포트번호를 알고 있으므로, 클라이언트는 불필요한 정보 발송을 피하기 위해 스킴과 호스트(그리고 포트번호)가 없는 부분 URI만 보냈습니다.
프락시가 부상하면서, 부분 URI는 문제가 되었습니다. 프락시는 목적지 서버와 커넥션을 맺어야 하기 때문에, 그 서버의 이름을 알 필요가 있었고, 프락시 기반 게이트웨이는 FTP 리소스나 혹은 그 외의 스킴과 연결하기 위해 URI의 스킴을 알 필요가 있었습니다. 따라서 서버로는 부분 URI를, 프락시로는 완전한 URI를 보낼 필요가 있습니다.

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

프락시의 '스킴/호스트/포트번호 누락' 문제는 가상으로 호스팅 되는 웹 서버가 직면한 것과 같은 문제입니다. 가상으로 호스팅 되는 웹 서버는 여러 웹 사이트가 같은 물리적 웹 서버를 공유합니다. 요청 하나가 부분 URI로 오면, 가상으로 호스팅 되는 웹 서버는 그 요청이 접근하고자 하는 웹 사이트의 호스트 명을 알 필요가 있습니다.
이 문제들은 비슷함에도 불구하고 다음과 같이 각각 다른 방법으로 해결되었습니다.

명시적인 프락시는 요청 메시지가 완전한 URI를 갖도록 함으로써 이 문제를 해결
가상으로 호스팅 되는 웹 서버는 호스트와 포트에 대한 정보가 담겨 있는 Host 헤더를 요구

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

클라이언트가 HTTP를 올바르게 구현했다면, 그들은 명시적으로 설정된 프락시에게는 완전한 URI를 보낼 것입니다. 이것으로 문제의 일부분은 해결되지만, 클라이언트는 자신이 프락시와 대화하고 있음을 항상 알고 있는 않다는 문제가 남아있습니다. 왜냐하면 몇몇 프락시는 클라이언트에게는 보이지 않을 수 있기 때문입니다. 비록, 클라이언트가 프락시를 사용한다고 설정되어 있지 않더라도, 클라이언트의 트래픽은 여전히 대리 프락시나 인터셉트 프락시를 지날 수 있습니다.

대리 프락시
원 서버의 호스트 명과 IP 주소를 사용해 원 서버를 대신하는 프락시 서버

인터셉트 프락시
네트워크 흐름에서 클라이언트에서 서버로 가는 트래픽을 가로채 캐시된 응답을 돌려주는 등의 일을 하는 프락시 서버

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

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

완전 URI와 부분 URI를 사용하는 규칙

완전한 URI가 주어졌다면, 프락시는 그것을 사용해야 합니다.
부분 URI가 주어졌고 Host 헤더가 있다면, Host 헤더를 이용해 원 서버의 이름과 포트 번호를 알아내야 합니다.
부분 URI가 주어졌으나 Host 헤더가 없다면, 다음의 방법으로 원 서버를 알아내야 합니다.
- 대리 프락시라면, 프락시에 실제 서버의 주소와 포트 번호가 설정되어 있을 수 있습니다.
- 이전에 어떤 인터셉트 프락시가 가로챘던 트래픽을 받았고, 그 인터셉트 프락시가 원 IP 주소와 포트번호를 사용할 수 있도록 해두었다면, 그 IP 주소와 포트번호를 사용할 수 있습니다.
- 모두 실패했다면, 반드시 에러 메시지를 반환해야 합니다.

전송 중 URI 변경

프락시 서버는 요청 URI의 변경에 매우 신경을 써야합니다. 무해해 보이는 사소한 URI 변경이라도 다운스트림 서버와 상호운용성 문제를 일으킬 수 있습니다.
일반적으로 프락시 서버는 가능한 한 관대하도록 애써야 합니다. 프로토콜을 엄격하게 준수하도록 강제한다면 기존에 잘 동작하던 기능들을 심각하게 망가뜨리는 결과를 수반할 수 있습니다.

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

브라우저는 프락시의 존재 여부에 따라 요청 URI를 다르게 분석합니다. 프락시가 없다면 사용자가 타이핑한 URI를 가지고 그에 대응하는 IP 주소를 찾고, 만약 호스트명이 발견되면 그에 대응하는 IP 주소들을 연결에 성공할 때까지 시도합니다.
그러나 호스트가 발견되지 않는다면, 많은 브라우저들은 사용자가 호스트 명의 짧은 약어를 타이핑한 것으로 보고 자동화된 호스트 명의 '확장'을 제공하고자 다음과 같이 몇 가지 시도를 합니다.

일반적인 웹 사이트 이름의 가운데 부분만 입력했다면,많은 브라우저는 www. 접두사를 붙이고 .com 접미사를 붙입니다.
몇몇 브라우저는 해석할 수 없는 URI를 서드파티 사이트로 넘기기도 하는데, 이 사이트는 오타 교정을 시도하고 사용자가 의도했을 URI를 제시합니다.
대부분의 시스템에서 DNS는 사용자가 호스트 명의 앞부분만 입력하면 자동으로 도메인을 검색하도록 설정되어 있습니다.

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

(1) 사용자가 'oreilly'를 입력
    브라우저는 'oreilly'를 호스트 명으로 사용하고
    기본 스킴: 'http://', 기본 포트: '80', 기본 경로 '/' 로 간주합니다.
(2a) 브라우저는 DNS를 통해 호스트 'oreilly'를 찾습니다.
 (2b) 실패 - 호스트를 알 수 없습니다.
(3a) 브라우저는 'oreilly'를 'www.oreilly.com'으로 자동 확장합니다.
  (3b) 브라우저는 DNS를 통해 호스트 'www.oreilly.com'을 찾습니다.
   (3c) 성공 - IP 주소 반환
    (4a) 브라우저는 IP 주소들에 대해 성공할 때까지 하나씩 접속을 시도
    (4b) 성공 - 커넥션을 맺습니다.
    (5a) 브라우저는 HTTP 요청을 보냅니다.
    (5b) 브라우저는 HTTP 응답을 받습니다.

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

명시적인 프락시를 사용한다면, 브라우저는 이와 같이 편리한 확장들 중 어느 것도 더 이상 수행할 수 없습니다. 브라우저의 URI가 프락시를 그냥 지나쳐버리기 때문입니다. 브라우저는 명시적인 프락시가 있는 경우 부분 호스트 명을 자동확장하지 않습니다.

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

호스트 명 분석은 보이지 않는 인터셉트 프락시와 함께일 때 약간 달라지는데, 왜냐하면 클라이언트의 입장에서 프락시는 존재하지 않는 것이기 때문입니다. DNS가 성공할 때까지 호스트 명을 자동확장하는 브라우저를 사용할 때, 동작은 프락시가 아닌 서버의 경우와 별 차이가 없지만 서버로의 커넥션이 만들어졌을 때는 분명한 차이가 발생합니다.

(1) 사용자는 브라우저의 URI 위치 창에 'oreilly'라고 타이핑합니다.
(2a) 브라우저는 호스트 'oreilly'를 DNS를 통해 찾아봅니다.
 (2b) 실패 - 호스트를 알 수 없습니다.
(3a) 브라우저는 'oreilly'를 'www.oreilly.com'으로 변환하는 자동확장합니다.
 (3b) 브라우저는 DNS를 통해 호스트 'www.oreilly.com'를 찾아봅니다.
  (3c) 성공 - IP 주소 반환
  (4a). (4b), (5a) 클라이언트는 이미 호스트 이름을 성공적으로 확인했으며 IP 주소 목록이 있습니다. 일반적으로 클라이언트는 성공할 때까지 각 IP 주소에 연결을 시도합니다.
  (5b) 프록시가 실제 원본서버와 상호 작용할 준비가 됩니다.

메시지 추적

오늘날 웹 요청의 상당수가 둘 이상의 프락시를 지나갑니다. 동시에 성능상의 이유로 세계 곳곳에 흩어져 있는 대리 캐시 저장고에 콘텐츠를 복제해두는 방식이 점점 흔해지고 있습니다.

프락시가 점점 더 흔해지면서, 서로 다른 스위치와 라우터를 넘나드는 IP 패킷의 흐름을 추적하는 것 못지않게 프락시를 넘나드는 메시지의 흐름을 추적하고 문제점을 찾아내는 것도 필요한 일이 되었습니다.

Via 헤더

Via 헤더 필드는 메시지가 지나는 각 중간 노드(프락시나 게이트웨이)의 정보를 나열합니다. 메시지가 또 다른 노드를 지날 때마다, 중간 노드는 Via 목록의 끝에 반드시 추가되어야 합니다.
다음의 Via 문자열은 메시지가 두 개의 프락시를 지나갔음을 말해줍니다.
Via: 1.1 proxy-62.irenes-isp.net, 1.0 cache.joes-hardware.com
Via 헤더 필드는 메시지의 전달을 추적하고, 메시지 루프를 진단하고, 요청을 보내고 그에 대한 응답을 돌려주는 과정에 관여하는 모든 메시지 발송자들의 프로토콜을 다루는 능력을 알아보기 위해 사용됩니다. 또한 네트워크의 라우팅 루프를 탐지하기 Via 헤더를 사용할 수 있습니다.

Via 문법

Via 헤더 필드는 쉼표로 구분된 경유지(waypoint)의 목록입니다. 각 경유지는 개별 프락시 서버나 게이트웨이 홉을 나타내며 그들 중간 노드의 프로토콜과 주소에 대한 정보를 담고 있습니다.
Via: [ <protocol-name> "/" ] <protocol-version> <host> [ ":" <port> ]

<protocol-name> - 선택사항. "HTTP" 와 같은 사용된 프로토콜의 이름.
<protocol-version> - "1.1" 과 같이 사용된 프로토콜의 버전.
<host> and <port> - 공용 프록시의 URL 과 port.
<pseudonym> - 내부 프록시의 이름 또는 별칭.

https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Via

Via 요청과 응답 경로

요청 메시지와 응답 메시지 모두 프락시를 지나므로 둘 모두 Via 헤더를 가집니다. 요청과 응답은 보통 같은 TCP 커넥션을 오가므로, 응답 메시지는 요청과 같은 경로를 되돌아갑니다. 즉, 응답의 Via 헤더는 거의 언제나 요청의 Via 헤더와 반대입니다.

Via와 게이트웨이

몇몇 프락시는 서버에게 비 HTTP 프로토콜을 사용할 수 있는 게이트웨이 기능을 제공합니다. Via 헤더는 이러한 프로토콜 변환을 기록하므로 HTTP 애플리케이션은 프락시 연쇄에서 프로토콜 능력과 변환이 있었는지를 알아챌 수 있습니다.

Server 헤더와 Via 헤더

Server 응답 헤더 필드는 원 서버에 의해 사용되는 소프트웨어를 알려줍니다. 응답 메시지가 프락시를 통과할 때, 프락시는 Server 헤더를 수정해서는 안 됩니다. Server 헤더는 원 서버를 위해 존재하는데, 대신 프락시는 Via 항목을 추가해야 합니다.

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

Via 문자열 안에 정확한 호스트 명이 들어가기를 원하지 않는 몇 가지 경우가 있습니다. 보통 명시적으로 이 동작이 켜져 있지 않은 이상, 프락시 서버가 네트워크 방화벽의 일부인 경우 프락시는 방화벽 뒤에 숨어있는 호스트의 이름과 포트를 전달해서는 안 됩니다. 방화벽 뒤의 네트워크 아키텍처에 대한 정보가 악의적인 집단에 의해 이용될 수도 있기 때문입니다.

만약 Via 노드 이름 전달이 가능하지 않다면, 보안 경계선의 일부인 프락시는 호스트 명을 그 호스트에 대한 적당한 가명으로 교체해야 합니다. 강력한 보안 요구사항을 갖고 있는 조직들을 위해, 프락시는 정렬된 일련의 Via 유지 항목들(수신된 프로토콜 값들이 동일한)을 하나로 합칠 수 있습니다.

(단, 여러 경유지들이 모두 같은 조직의 통제하에 있고 호스트가 이미 가명으로 교체되지 않은 이상 그들에 대한 항목들을 합쳐서는 안 됩니다. 수신된 프로토콜 값이 서로 다른 항목들도 합쳐서는 안 됩니다.)

TRACE 메서드

프락시 서버는 메시지가 전달될 때 메시지를 바꿀 수 있습니다. 프락시 네트워크를 쉽게 진단하기 위해, HTTP 프락시 네트워크를 통해 홉에서 홉으로 전달될 때마다 메시지의 내용이 어떻게 변하는지 편리하게 관찰할 방법이 필요합니다.
HTTP/1.1의 TRACE 메서드는 요청 메시지를 프락시의 연쇄를 따라가면서 어떤 프락시를 지나가고 어떻게 각 프락시가 요청 메시지를 수정하는지 관찰/추적할 수 있도록 해줍니다.

TRACE 요청이 목적지 서버에 도착했을 때, 서버는 전체 요청 메시지를 HTTP 응답 메시지의 본문에 포함시켜 송신자에게 그대로 돌려보냅니다.

Max-Forward
일반적으로 TRACE 메시지는 중간에 프락시들이 몇 개나 있든 신경 쓰지 않고 목적지 서버로의 모든 경로를 여행합니다. TRACE와 OPTIONS 요청의 프락시 홉(hop) 개수를 제한하기 위해 Max-Forwards 헤더를 사용할 수 있는데, 이는 전달되는 메시지가 무한 루프에 빠지지 않는지 프락시 연쇄를 테스트하거나 연쇄 중간의 특정 프락시 서버들의 효과를 체크할 때 유용합니다.
Max-Fowards 요청 헤더 필드는 이 요청 메시지가 몇 번 더 다음 홉으로 전달될 수 있는지 말해주는 정수 하나를 담고 있습니다.

Max-Forwards 값	설명
0	수신자는 자신이 원 서버가 아니라 할지라도 TRACE 메시지를 더 이상 전달하지 말고 반드시 클라이언트에게 돌려줘야 합니다
0보다 큰 값	전달될 메시지의 Max-Forwards 필드를 1 감소된 값으로 갱신

모든 프락시와 게이트웨이는 Max-Forwards를 지원해야 합니다.

프락시 인증

프락시는 접근 제어 장치로서 제공될 수 있습니다. HTTP는 사용자가 유효한 접근 권한 자격을 프락시에 제출하지 않는 한 콘텐츠에 대한 요청을 차단하는 프락시 인증이라는 매커니즘을 정의하고 있습니다.

제한된 콘텐츠에 대한 요청이 프락시 서버에 도착했을 때, 프락시 서버는 접근 자격을 요구하는 407 Proxy Authorization Required 상태 코드를 어떻게 그러한 자격을 제출할 수 있는지 설명해주는 Proxy-Authenticate 헤더 필드와 함께 반환할 수 있습니다.
클라이언트는 407 응답을 받게 되면, 로컬 데이터베이스를 확인해서든 사용자에게 물어봐서든 요구되는 자격을 수집합니다.
자격을 획득하면, 클라이언트는 요구되는 자격을 Proxy-Authorization 헤더 필드에 담아서 요청을 다시 보냅니다.
자격이 유효하다면, 프락시는 원 요청을 연쇄를 따라 통과시키고 유효하지 않다면 407 응답을 보냅니다.

프락시 인증은 인증에 참여하는 프락시가 프락시 연쇄상에 여러 개 있을 때는 일반적으로 잘 동작하지 않습니다.

프락시 상호운용성

클라이언트, 서버, 프락시는 HTTP 명세의 여러 버전에 대해 여러 벤더에 의해 만들어지므로 제각각 여러 가지 기능을 지원하며 다른 버그를 갖고 있습니다. 프락시 서버는 서로 다른 프로토콜을 구현했을 수도 있고 골치 아프게 이상한 동작을 할 수도 있는 클라이언트와 서버 사이를 중개해야 합니다.

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

프락시 서버는 넘어오는 헤더 필드들을 모두 이해하지 못할 수도 있습니다. 프락시는 이해할 수 없는 헤더 필드는 반드시 그대로 전달해야 하며, 같은 이름의 헤더 필드가 여러 개 있는 경우에는 그들의 상대적인 순서도 반드시 유지해야 합니다. 프락시는 가능한 한 그 메시지를 다음 홉으로 비슷하게 전달하려 시도해야 합니다.

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

HTTP OPTIONS 메서드는 서버나 웹 서버의 특정 리소스가 어떤 기능을 지원하는지(예를 들면 지원하는 메서드) 클라이언트(혹은 프락시)가 알아볼 수 있게 해줍니다. 서로 다른 기능 수준의 서버와 프락시가 더 쉽게 상호작용할 수 있도록 클라이언트는 OPTIONS를 이용해 서버의 능력을 먼저 알아낼 수 있습니다.

✔ 별표(*): 서버 전체의 능력에 대해 묻는 것
  OPTIONS * HTTP/1.1`

✔ URI가 실제 리소스라면, 특정 리소스에 대해 가능한 기능을 묻는 것
  OPTIONS http://www.joes-hardware.com/index.html HTTP/1.1
  static HTML file wouldn't accept a POST method.

성공한다면, OPTIONS 메서드는 서버에서 지원하거나 지정한 리소스에 대해 가능한 선택적인 기능들을 서술하는 여러 헤더 필드를 포함한 200 OK 응답을 반환합니다. 하지만 HTTP/1.1이 명시한 헤더는 서버에 의해 어떤 메서드가 지원되는지 서술하는 Allow 헤더 하나뿐입니다.

Allow 헤더

Allow 엔터티 헤더 필드는, 요청 URI에 의해 식별되는 자원에 대해 지원되는 메서드들이나 서버가 지원하는 모든 메서드를 열거합니다.
예를 들면, Allow: GET, HEAD, PUT

Allow 헤더는 새 리소스가 지원했으면 하는 메서드를 추천하기 위해 요청 헤더로 사용될 수 있습니다. 서버는 추천 받은 메서드를 모두 지원해야 할 의무는 없으며, 그 요청에 대한 응답에는 실제로 지원하는 메서드들을 열거하는 Allow 헤더를 포함시켜야 합니다.
만약 프락시가 지정된 모든 메서드를 이해할 수는 없다고 해도, 프락시는 Allow 헤더 필드를 수정할 수 없습니다. 왜냐하면 클라이언트는 원 서버와 대화하는 다른 경로를 갖고 있을 수도 있기 때문입니다.

Reference

📗 ISP란?
📗 DHCP란?
📗 What is a Web Proxy Server?

DevSeong2

차근차근

이전 포스트

웹 서버

다음 포스트

프락시