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

6.1 웹 중개자

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

• 웹 프락시가 없다면 HTTP 서버와 직접 이야기해야 하지만
• 있다면 자신의 입장에서 서버와 대화해주는 프락시와 이야기 한다.

트랜잭션을 완료하는 건 여전히 클라이언트지만, 프락시 서버가 제공하는 좋은 서비스 이용 가능.

프락시는 서버이면서 동시에 클라이언트여야 한다.

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

따라서 HTTP 프락시를 만든다면 HTTP 클라이언트와 HTTP 서버의 양쪽 규칙 모두를 주의깊게 따라야 한다.

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

• 개인 프락시 : 하나의 클라이언트가 독점적으로 사용
• 공용 프락시 : 여러 클라이언트가 공유해서 함께 사용

공용 프락시

• 대부분의 프락시는 공용.
• 중앙 집중형 프락시가 관리하기 더 쉽고 효율적.
• 캐시 프락시 서버와 같은 몇몇 프락시 애플리케이션은 프락시를 이용하는 사용자가 많을 수록 유리. (여러 사용자들의 공통된 요청에서 이득을 취할 수 있음)

개인 프락시

• 흔하진 않지만 꾸준히 사용. (특히 클라이언트 컴퓨터에서 직접 실행되는 형태로)

6.1.2 프락시 대 게이트웨이

프락시는 같은 프로토콜로 말하고 게이트웨이는 서로 다른 프로토콜을 연결해준다.

브라우저와 서버가 다른 버전의 HTTP 를 구현하면 프락시는 때때로 약간의 프로토콜 변환을 하는 게이트웨이처럼 작동하기도 한다.
그리고 상용 프락시 서버는 SSL 보안 프로토콜, SOCKS 방화벽, FTP 접근, 웹 기반 애플리케이션을 지원하기 위해 게이트웨이 기능을 구현한다.

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

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

어린이 필터

어린이에게 부적절한 사이트의 접근을 강제로 거부할 수 있다.

문서 접근 제어자

많은 웹서버들과 웹리소스에 대한 단일한 접근 제어 전략을 구현하고 감사 추적을 하기 위해 사용. 대기업이나 분산된 관료조직에서 유용.

각기 다른 조직에서 관리되는 다양한 수맣은 웹 서버들에 대한 접근 제어를 수시로 갱신할 필요 없이, 중앙 프락시 서버에서 접근 제어를 설정할 수 있다.

보안 방화벽

• 보안을 강화하기 위해 사용.
• 조직 안에 들어오거나 나가는 응용 레벨 프로토콜의 흐름을 네트워크의 한 지점에서 통제.
• 트래픽을 세심히 살펴볼 수 있는 후크 제공(바이러스 제거 웹이나 이메일 프락시가 사용)
  

웹 캐시

인기 있는 문서의 로컬 사본을 관리하고 해당 문서에 대한 요청이 오면 빠르게 제공하여 느리고 비싼 인터넷 커뮤니케이션을 줄인다.
클라이언트에게 가까운 근처 웹 캐시의 문서에 접근한다.

대리 프락시

• 웹 서버인 것처럼 위장.
• 진짜 웹 서버 요청을 받지만 웹서버와 다르게 요청 받은 콘텐츠의 위치를 찾아내기 위해 다른 서버와 커뮤니케이션을 시작한다.
• 공용 콘텐츠에 대한 느린 웹 서버의 성능 개선 가능
• 이를 서버 가속기라고 부른다.
• 콘텐츠 라우팅 기능과 결합되어 주문형 복제 콘텐츠의 분산 네트워크를 만들기 위해 사용될 수 있다.
  

콘텐츠 라우터

• 인터넷 트래픽 조건과 콘텐츠의 종류에 따라 요청을 특정 웹서버로 유도.
• 사용자들에게 제공할 여러 서비스를 구현하는 데 사용.
• 예를 들어, 더 높은 성능을 위해 돈을 지불했다면 콘텐츠 라우터는 요청을 가까운 복제 캐시로 전달 / 사용자가 필터링 서비스에 가입했다면 HTTP요청이 필터링 프락시를 통과하도록 할 수 있다.
  

트랜스코더

• 콘텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 수정.
• 이와 같이 데이터의 표현 방식을 자연스럽게 변환하는 것을 트랜스코딩이라 한다.(중개자에 의한 콘텐츠 변형)
• 예) 크기를 줄이기 위해 프락시를 지나가는 GIF 이미지를 JPG 이미지로 변환. / 외국어 문서로 변환 / HTML 문서를 휴대전화에서도 잘 볼 수 있도록 텍스트로 변환
  

익명화 프락시

• HTTP 메시지에서 신원을 식별할 수 있는 특성들을 적극적으로 제거해서 개인정보 보호 & 익명성 보장

  	- User-Agent 헤더에서 사용자의 컴퓨터와 OS의 종류를 제거한다.
  	- 사용자의 이메일 주소를 보호하기 위해 From 헤더는 제거된다.
  	- 어떤 사이트를 거쳐서 방문했는지 알기 어렵게 하기 위해 Referer 헤더는 제거된다.
  	- 프로필과 신원 정보를 없애기 위해 Cookie 헤더는 제거된다.

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

프락시가 무엇을 하는지 설명.

6.3.1 프락시 서버 배치

용도에 따라 프락시 배치.

출구 프락시

로컬 네트워크와 더 큰 인터넷 사이를 오가는 트래픽 제어를 위해 프락시를 로컬 네트워크의 출구에 넣는다.

• 회사 밖의 악의적인 해커를 막는 방화벽 제공
• 인터넷 요금 절약과 트래픽 성능 개선을 위해 회사에서 출구 프락시 사용
• 어린이들에게 부적절한 콘텐츠를 브라우징 하는 것을 막기 위한 필터링 출구 프락시

접근(입구) 프락시

고객으로부터의 모든 요청을 종합적으로 처리하기 위해 프락시를 ISP 접근 지점에 위치

• ISP는 사용자들의 다운로드 속도를 개선하고 인터넷 대역폭 비용을 줄이기 위해 캐시 프락시를 사용해 많이 찾는 문서들의 사본 저장

대리 프락시

대리 프락시 = 리버스 프락시.
네트워크의 가장 끝에 있는 웹 서버들의 바로 앞에 위치해서 웹 서버로 향하는 모든 요청을 처리 & 필요할 때만 웹 서버에게 자원 요청

• 웹 서버에 보안 기능 추가
• 빠른 웹 서버 캐시를 느린 웹 서버 앞에 놓아 성능 개선
• 일반적으로 웹 서버의 이름과 IP 주소로 스스로를 가장하므로 모든 요청은 서버가 아닌 프락시로 간다.

네트워크 교환 프락시

캐시 이용, 인터넷 교차로의 혼잡 완화, 트래픽 감시를 위해 프락시가 네트워크 사이의 인터넷 피어링 교환 지점들에 놓인다.

6.3.2 프락시 계층

프락시 계층이라고 불리는 연쇄를 구성할 수 있다.

• 프락시 계층에서 프락시 서버들은 부모와 자식관계를 가진다. (서버와 가까운 쪽인 다음번 인바운드 프락시가 부모, 클라이언트와 가까운 쪽인 다음 번 아웃바운드 프락시가 자식이다.)
  

프락시 계층 콘텐츠 라우팅

위의 그림의 프락시 계층은 정적이지만 아래 그림처럼 동적일 수도 있다. 여러 판단 근거에 의해 메시지를 다양하고 유동적인 프락시 서버와 원 서버들의 집합에게 보낸다. 즉 프락시 계층은 동적으로 매 요청에 따라 바뀌어 상황에 따라 라우팅한다.

• 예
  • 요청된 객체가 콘텐츠 분산을 위해 돈을 지불한 웹 서버에 속한 경우, 프락시는 요청을 가까운 캐시 서버에게 보내 캐시된 객체를 반환하거나 그럴 수 없는 경우에는 서버에서 가져오게 할 수 있다.
  • 요청이 특정 종류의 이미지에 대한 것인 경우, 접근 프락시는 그 요청을 특화된 압축 프락시에게 보내 그 프락시가 이미지를 가져와 압축하게 하여 느린 모뎀으로 접속해도 빠르게 클라이언트가 다운로드할 수 있게 한다.

부하 균형

자식 프락시는 부하를 분산하기 위해 현재 부모들의 작업량 수준에 근거해서 부모 프락시를 구한다.

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

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

프로토콜/타입 라우팅

URI에 근거해서 다른 부모나 원 서버로 라우팅

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

빠른 서비스를 위해 추가금 지불 시, 대형 캐시나 성능 개선을 위한 압축 엔진을 라우팅

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

어떻게 클라이언트 트래픽이 프락시로 가도록 하는 것일까

클라이언트를 수정

크롬 등 많은 웹 클라이언트들은 수동 혹은 자동 프락시 설정을 지원한다. 프락시를 사용하도록 설정 시, 클라이언트는 HTTP 요청을 바로 그리고 의도적으로 원서버가 아닌 프락시로 보낸다.

네트워크를 수정

네트워크 인프라를 가로채서 웹 트래픽을 프락시로 가도록 조정한다. 스위칭 장치와 라우팅 장치가 필요하며 이것을 인터셉트 프락시라 한다.

DNS 이름공간을 수정한다.

웹 서버 앞에 위치하는 프락시 서버인 대리 프락시는 웹 서버의 이름과 IP 주소를 자신이 직접 사용한다. 그래서 모든 요청이 서버 대신 대리 프락시로 간다.

웹 서버를 수정한다.

몇몇 웹 서버는 HTTP 리다이렉션 명령(305)을 클라이언트에게 돌려주어 요청을 프락시로 리다이렉트하도록 설정한다.

6.4 클라이언트 프락시 설정

브라우저와 같은 클라이언트가 어떻게 프락시를 설정하는지에 대한 방법들.

수동 설정

프락시 사용을 명시적으로 설정

브라우저 기본 설정

브라우저를 소비자에게 전달하기 저에 프락시를 미리 설정.

프락시 자동 설정(PAC)

자바스크립트 프락시 자동설정(PAC) 파일에 대한 URI 제공.

WPAD 프락시 발견

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

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

프락시의 호스트와 포트를 지정한다. 몇몇 ISP는 그들의 요구에 맞춰 미리 설정된 브라우저나 웹 트래픽을 프락시 서버로 리다이렉트 하는 맞춤형 운영체제를 구입한다.

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

수동 프락시 설정에 비해 유연하다. 보다 동적인 해결책이다. 왜냐하면 PAC파일은 그때그때 상황에 맞게 프락시 설정을 계산해주는 작은 자바스크립트 프로그램 때문이다. 문서에 접근할 때마다 자바스크립트 함수가 적절한 프락시 서버를 선택한다.

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

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

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

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

클라이언트가 프락시 대신 서버로 요청을 보내면 요청의 URI가 달라진다. (이외 메시지 문법은 같다.)

• 클라이언트 -> 웹 서버 : 요청줄은 스킴, 호스트, 포트번호가 없는 부분 URI를 가진다.

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

• 클라이언트 -> 프락시 : 완전한 URI를 갖는다.

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

왜냐하면 단일 서버는 자신의 호스트명과 포트번호를 알고 있어 불필요한 정보 발송을 피하기 위해 & 프락시는 목적지 서버와 커넥션을맺어야 하기 때문에 서버의 이름을 알아야 하고 프락시 기반 게이트웨이는 URI의 스킴을 알 필요가 있었다.

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

• 스킴/호스트/포트번호 누락 문제 : 가상으로 호스팅 되는 웹서버(여러 웨 사이트가 물리적 웹 서버를 공유하여 요청이 접근하고자하는 웹 사이트의 호스트명을 알 필요가 있다)와 같은 문제
  해결법은 다르다.
  • 명시적인 프락시 : 요청 메시지가 완전한 URI를 갖도록 하여 해결
  • 가상으로 호스팅되는 웹 서버 : 호스트와 포트에 대한 정보가 담긴 Host 헤더 요구

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

몇몇 프락시가 클라이언트에게 안 보일 수 있기 떄문에 클라이언트가 자신이 프락시와 대화하고 있는 걸 항상 알고 있는 것은 아니다.
클라이언트가 몰라도 트래픽이 대리프락시나 인터셉트 프락시를 지날 수 있다. 그러면 클라이언트가 완전한 URI를 보내지 않는다.

• 대리 프락시 : 원서버의 호스트명과 아이피 주소를 사용해 원서버를 대신한다.
• 인터셉트 프락시 : 네트워크 흐름에서 클라이언트에서 서버로 가는 트래픽을 가로채 캐시된 응답을 돌려주는 등의 일을 하는 프락시 서버. 클라이언트에서 서버로 가는 트래픽을 가로채기 때문에 부분 URI 를 얻는다.

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

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

• 명시적 프락시 요청 : 완전한 URI 사용
• 명시적 프락시 요청이 아니면 : 부분 URI 사용
  • Host 헤더 있음 : Host 헤더 사용해서 원서버의 이름과 포트번호 알아냄
  • 없음
    • 대리 프락시 인 경우 : 프락시에 실제 서버의 주소와 포트번호가 설정되어 있을 수 있음
    • 인터럽트 프락시가 가로챘던 트래픽을 받은 경우 : 그 인터럽트 프락시가 원 IP 주소와 포트번호를 사용할 수 있도록 해두었다면 그것을 사용
    • 그 외 : 원서버를 알아내지 못한 것으로 에러메시지를 반환
• 웹 서버 요청 : 가상 Host 헤더 사용

6.5.5 전송 중 URI 변경

프락시가 요청 URI 변경에 신경 쓰지 않으면 다운스트림 서버(다음 홉)와 상호운용성 문제를 일으킬 수 있다.
최대한 경로를 고치지 말자.

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

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

• 프락시 없음 : 사용자가 타이핑한 URI가지고 그에 대응하는 IP 주소 찾는다.
  • 호스트 찾음 : 그에 대응하는 IP 주소들을 연결에 성공할 때까지 시도
  • 못찾음 : 많은 브라우저들은 사요자가 호스트명의 짧은 약어를 타이핑한 것으로 보고 자동화된 호스트명의 확장을 제공하고자 시도한다.
    ex) 웹사이트 가운데만 입력 -> www와 .com을 붙여본다. / 오타 교정 / 호스트명의 앞부분만 입력하면 자동으로 도메인 검색

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

브라우저는 명시적인 프락시가 존재하지 안는 경우 부분 호스트명을 자동으로 확장한다.

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

명시적인 프락시가 있는 경우 브라우저는 부분 호스트명을 자동확장하지 않는다.

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

인터셉트 프락시를 사용하고 있는 브라우저는 죽은 서버의 IP 주소를 탐지할 수 없다.

6.6 메시지 추적

오늘날 많은 요청이 둘 이상의 프락시를 지나가는 경우가 많아졌다. 보안 및 비용 절감을 위해 많은 회사가 캐시 프락시 서버를 사용하고 대형 ISP들이 성능 개선 및 기능 구현을 위해 프락시 캐시를 사용한다.
또 성능상의 이유로 세계 곳곳에 흩어져 있는 대리 캐시 저장고에 콘텐츠를 복제해두는 방식이 흔해졌다. (CDN의 대리캐시)
이렇게 프락시가 흔해지면서 프락시를 넘나드는 메시지의 흐름을 추적하고 문제점을 찾아내는 것이 필요해졌다.

6.6.1 Via 헤더

Via 헤더 필드는 메시지가 지나는 각 중간 노드의 정보를 나열한다. 메시지가 또 다른 노드를 지날 때마다 중간 노드는 Via 목록의 끝에 반드시 추가되어야 한다.

• 메시지 전달을 추적
• 메시지 루프를 진단
• 요청을 보내고 응답을 돌려주는 과정에서 관여하는 모든 메시지 발송자들의 프로토콜을 다루는 능력을 알아봄
• 네트워크의 라우팅 루프 탐지(프락시 자신을 가리키는 유일한 문자열을 Via 헤더에 삽입해야 한다. -> 네트워크 라우팅 루프를 감지하기 위해 이 문자열이 들어온 요청에 있는지 확인)
  

Via 문법

• 쉼표로 구분된 경유지의 목록.
• 중간 노드의 프로토콜과 주소에 대한 정보를 담고 있다.

프로토콜 이름

• 중개자가 받은 프로토콜
• HTTP 가 기본으로, HTTP 라면 프로토콜 이름을 붙이지 않아도 됨

프로토콜 버전

• 수신한 메시지의 버전.
• 애플리케이션들은 자신 이전의 모든 중개자들이 어떤 버전을 다룰 수 있는지 알 수 있다.

노드 이름

• 중개자의 호스트와 포트 번호(없다면 사용 프로토콜의 기본 포트로 간주)
• 호스트명 가명 대체 가능(조직의 정보보호 목적)

노드 코멘트

• 중개자 노드를 서술하는 선택적인 코멘트

Via 요청과 응답경로

• 요청 메시지 & 응답메시지 모두 Via 헤더를 가진다. (둘다 프락시를 지나는 건 마찬가지니까)
• 요청과 응답은 보통 같은 TCP 커넥션을 지나가므로 보통 같은 경로를 되돌아감.(요청 : A-B-C / 응답 : C-B-A) 즉, Via 헤더가 반대.
  

Via와 게이트웨이

• 몇몇 프락시는 서버에게 게이트웨이(비 HTTP 프로토콜을 사용하도록)기능을 제공.
• Via 헤더는 이런 프로토콜 변환을 기록.

Server 헤더와 Via 헤더

• Server 응답 헤더 필드는 원 서버에 의해 사용되는 소프트웨어를 알려줌.
• 응답 메시지가 프락시를 통과할 때 프락시는 Server 헤더를 수정하면 안된다. Server헤더는 원서버를 위해 존재하는 것.
• 대신 프락시는 Via 항목을 추가한다.

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

• 명시적으로 동작이 켜져 있지 않다면 프락시는 방화벽 뒤에 숨어있는 호스트의 이름과 포트를 전달하면 안 된다. (악의적인 집단에게 이용될 수 있기 때문)
• 호스트명을 적당한 가명으로 교체한다. 그래도 프락시는 각 서버에 대한 Via 경유지 항목을 유지하려 해야 한다.

6.6.2 Trace 메서드

• 프락시 네트워크의 쉬운 진단을 위해 HTTP 프락시 네트워크를 통해 홉에서 홉으로 전달될 때마다 메시지의 내용이 어떻게 변하는지 편리하게 관찰할 방법 필요 -> TRACE사용
• TRACE 메서드는 요청 메시지를 프락시의 연쇄를 따라가면서 어떤 프락시를 지나가고, 어떻게 각 프락시가 요청 메시지를 수정하는지 관찰/추적할 수 있다.

Max-Forwards

일반적으로 프락시 개수를 신경 쓰지 않지만 TRACE와 OPTIONS의 프락시 홉 개수를 제한하기 위해 사용된다.

• 전달되는 메시지가 무한 루프에 빠지지 않는지 프락시 연쇄를 테스트
• 연쇄 중간의 특정 프락시 서버들의 효과를 체크할 때 유용(Max-Forwards가 0이 되면 원서버가 아니더라도 TRACE 메시지를 더이상 전달하지 않고 클라이언트에게 돌려준다. -> 어떤 특정 홉에서의 요청을 볼 수 있다)

6.7 프락시 인증

• 프락시를 접근 제어장치로 사용 가능
• 사용자가 유효한 접근 권한 자격을 프락시에 제출하지 않으면 한 콘텐츠에 대한 요청을 차단하는 프락시 인증이라는 메커니즘 정의.

6.8 프락시 상호운용성

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

• 프락시 서버가 이해하지 못하는 헤더 필드는 반드시 그대로 전달.
• 같은 이름의 헤더 필드가 여러개 있어도 그들의 상대적인 순서도 반드시 유지.
• HTTP/1.1은 메서드 확장을 허용하므로, 메서드에 대해 친숙하지 않더라도 가능한 그 메시지를 다음 홉으로 전달.

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

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

6.8.3 Allow 헤더

요청 URI에 의해 식별되는 자원에 대해 지원되는 메서드들이나 서버가 지원하느 모든 메서드(요청 URI가 *이면)를 열거한다.