[HTTP] 프락시

프락시는 클라이언트와 서버 사이에 위치하여 그들 사이의 HTTP 메시지를 정리하는 중개인이다.

6.1 웹 중개자

웹 프락시가 있다면, 클라이언트는 HTTP 서버와 직접 이야기하는 대신 자신의 입장에서 서버와 대화해주는 프락시와 이야기 한다.

• 웹 클라이언트 입장에서의 프락시는 서버처럼 동작하면서 요청 메시지를 받고 응답 메시지를 돌려준다.
• 웹 서버 입장에서의 프락시는 클라이언트처럼 동작하면서 웹 요청 메시지를 보내고 웹 응답 메시지를 받는다.

6.1.1 개인 프락시와 공유 프락시

공용 프락시

• 여러 클라이언트가 함께 사용하는 프락시
• 대부분의 프락시의 형태이며, 중앙 집중형 프락시를 관리하는 것이 비용 효율이 높고 쉽다.

개인 프락시

• 하나의 클라이언트만을 위한 프락시
• 흔하지는 않지만 꾸준히 사용되는 형태

6.1.2 프락시 대 게이트웨이

차이점을 엄밀히 말한다면 프락시는 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결하고, 게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결한다.

6.2 왜 프락시를 사용하는가?

어린이 필터

프록시를 사용함으로써, 교육 콘텐츠에는 제한 없는 접근을 허용하면서 어린이에게 부적절한 사이트의 접근은 강제로 거부할 수 있다.

문서 접근 제어자

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

보안 방화벽

애플리케이션 레벨 프로토콜의 흐름을 네트워크의 한 지점에서 통제할 수 있다.

웹 캐시

프락시 캐시는 자주 사용하는 문서의 로컬 사본을 관리하고 해당 문서에 대한 요청이 오면 빠르게 제공하여 느리고 비싼 인터넷 커뮤니케이션을 줄인다.

대리 프락시(Surrogate)

리버스 프락시라고도 알려져 있다. 공용 콘텐츠에 대한 느린 웹 서버 성능을 개선하기 위해 사용될 수 있다.

콘텐츠 라우터

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

트랜스코더

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

익명화 프락시(Anonymizer)

HTTP 메시지에서 신원을 식별할 수 있는 특성들으 제거함으로써 개인 정보 보호와 익명성 보장에 기여한다.

6.3 프락시는 어디에 있는가?

6.3.1 프락시 서버 배치

출구(Egress) 프락시

로컬 네트워크와 더 큰 인터넷 사이를 오가는 트래픽을 제어하기 위한 배치

접근(입구) 프락시

고객으로부터의 모든 요청을 종합적으로 처리하기 위한 ISP 접근 지점 배치

대리 프락시

리버스 프락시. 웹 서버 바로 앞에 배치하여 웹 서버로 향하는 모든 요청을 처리하고 필요할 때만 웹 서버에게 자원을 요청할 수 있다.

네트워크 교환 프락시

캐시를 이용해 인터넷 교차로의 혼잡을 완화하고 트래픽 흐름을 감시하기 위한 배치

6.3.2 프락시 계층

프락시들은 계층이라고 불리는 연쇄 구성을 할 수 있다. 서버와 가까운 쪽인 인바운드 프락시를 부모라고 부르고, 클라이언트와 가까운 쪽 아웃바운드 프락시를 자식이라고 부른다.

프락시 계층 콘텐츠 라우팅

프락시 계층은 기본적으로 정적으로 구성되지만, 여러 가지 판단 근거에 의해 메시지를 다양하고 유동적인 프락시 서버와 원 서버들의 집합에 보낼 수 있다.

• 부하 균형
• 지리적 인접성에 근거한 라우팅
• 프로토콜/타입 라우팅
• 유료 서비스 가입자를 위한 라우팅

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

HTTP 트래픽이 어떻게 프락시로 향하는 길을 찾아내는가?

• 클라이언트를 수정한다
• 네트워크를 수정한다
• DNS 이름 공간을 수정한다
• 웹 서버를 수정한다

6.4 클라이언트 프락시 설정

모든 브라우저는 프락시를 사용할 수 있도록 설정할 수 있다.

• 수동 설정
• 브라우저 기본 설정
• 프락시 자동 설정(Proxy auto-configuration, PAC)
• WPAD 프락시 발견

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

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

• 클라이언트가 프락시를 사용하지 않도록 설정되어 있다면, 스킴, 호스트, 포트 번호가 없는 부분 URI를 가진다.

GET /index.html HTTP/1.0
User-Agent: SuperBrowser v1.3

• 클라이언트가 프락시를 사용하도록 설정되어 있다면, 완전한 URI를 보낸다.

GET http://www.marys-antiques.com/index.html HTTP/1.0
User-Agent: SuperBrowser v1.3

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

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

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

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

6.5.5 전송 중 URI 변경

프락시 서버는 요청 URI의 변경에 매우 신경을 써야한다. 프로토콜을 엄격하게 준수하도록 강제하는 프로토콜 경찰처럼 되서는 안된다. 이는 기존에 잘 동작하던 기능들을 심각하게 망가뜨릴 수 있기 때문이다.

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

브라우저는 프락시 존재 여부에 따라 요청 URI를 다르게 분석한다. 프락시가 없다면 사용자가 타이핑한 URI를 가지고 그에 대응하는 IP 주소를 찾는다.

• 만약 호스트명이 발견되면 그에 대응하는 IP 주소들을 연결 할 때까지 시도한다.
• 호스트가 발견되지 않는다면, 많은 브라우저들은 자동화된 호스트 명 확장을 시도한다.

6.5.7 프락시 없는 URI 분석

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

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

프락시를 명시적으로 사용한다면 브라우저는 확장을 수행할 수 없다. 브라우저의 URI가 프락시를 그냥 지나쳐버리기 때문이다.

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

6.6 메시지 추적

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

6.6.1 Via 헤더

Via 헤더 필드는 메시지의 전달을 추적하고, 메시지 루프를 진단하고, 요청을 보내고 그에 대한 응답을 돌려주는 과정에 관여하는 모든 메시지 발송자들의 프로토콜을 다루는 능력을 알아보기 위해 사용된다.

6.6.2 TRACE 메서드

HTTP/1.1의 TRACE 메서드는 요청 메시지를 프락시의 연쇄를 따라가면서 어떤 프락시를 지나가고 어떻게 각 프락시가 요청 메시지를 수정하는지 관찰/추적할 수 있도록 해준다. 이것은 프락시 흐름을 디버깅하는데 매우 유용한다.

6.7 프락시 인증

프락시는 접근 제어 장치로서 제공될 수 있다.

6.8 프락시 상호운용성

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

프락시는 이해할 수 없는 헤더 필드는 반드시 그대로 전달해야 하며, 같은 이름의 헤더 필드가 여러 개 있는 경우 그들의 상대적인 순서도 반드시 유지해야 한다.

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

HTTP OPTIONS 메서드는 서버나 웹 서버의 특정 리소스가 어떤 기능을 지원하는지 클라이언트 혹은 프락시가 알아볼 수 있게 해준다.

6.8.3 Allow 헤더

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

📌 데이빗 고울리, 브라이언 토티, 마조리 세이어, 세일루 레디, 안슈 아가왈 공저 이응준, 정상일 공역, 『HTTP 완벽 가이드: 웹은 어떻게 동작하는가』, 인사이트(2014)