[http 완벽 가이드] 6장 프락시

이 내용은 http 완변 가이드란 책을 읽고 정리한 내용입니다.

 

더 자세한 내용이 궁금하시면 책을 직접 읽어보시는 걸 추천합니다.

 

 

 

6장 프락시

• 웹 프락시 서버는 클라이언트와 서버 사이에 중개자 역할을 한다.
• 이 글은 프락시가 어떤 일을 하는지와 어느 위치에 있는지 등을 다룬다.

1. 웹 중개자 ( 프락시란)

• 프락시는 트랜잭션을 수행하는 중개인이다.
• 클라이언트 입장에선 서버처럼 서버 입장에선 클라이언트 처럼 작동하므로 HTTP 클라이언트와 서버의 규칙을 잘따라야 한다.

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

• 프락시의 종류는 크게
  • 개인 프락시
  • 공유 프락시로 나뉜다.
• 공유 프락시
  • 여러 클라이언트가 함께 사용하는 프락시
  • 대부분 공유 프락시이고 중앙 집중형 프락시를 관리하는게 비용 효율이 좋다.
  • 캐시 프락시 같은 공유 프락시는 이용자가 많을 수록 유리하다.
• 개인 프락시
  • 한개의 클라이언트만을 위한 프락시
  • 많이 사용하진 않지만 꾸준히 보인다.

1.2 프락시 대 게이트웨이

• 요약
  • 프락시: 같은 프로토콜을 사용하는 중개인
  • 게이트 웨이: 다른 프로토콜을 사용하는 중개인(=프로토콜 변환기)
• 하지만
  • 프락시와 게이트 웨이의 차이는 모호하다.
  • 이유는 프락시도 약간의 프로토콜 변화를 하기도 하기 때문

2. 왜 프락시를 사용하는가

• 프락시는 실용적이고 유용한 일을 수행한다.
• 보안개선 , 성능 향상, 비용 절감, 그리고 모든 HTTP 트래픽을 들여다보고 건드릴 수 있기에 부가적인 가치를 주는 여러가지 유용한 일을 수행한다.

어린이 필터

 

• 유해 사이트를 걸러내는 필터 역할을 할 수도 있다.

문서 접근 제어자

 

• 클라이언트가 서버의 보안적인 데이터의 접근을 제어하고 일반적인 뉴스 페이지 같은 웹 페이지에 접근하는 것을 제어하는 역할을 수행한다.

보안 방화벽

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

웹 캐시

 

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

대리 프락시

 

• 웹 서버인 것 처럼 직접 요청을 받는 프락시
• 대리 프락시 또는 리버스 프락시라고 불린다.
• 클라이언트한테 요청을 받아 해당 커텐츠가 있는 서버에 요청을 전달한다.

콘텐츠 라우터

 

• 인터넷 트래픽 조건과 콘텐츠의 종류에 따라 요청을 특정 웹 서버로 유도하는 콘텐츠 라우터 동작할 수 있다.
• 콘텐츠 라우터는 만약 사용자가 돈을 더 지불한 사용자라면 가까운 웹 캐시 서버로 라우팅 할 것이다.
• 만약 필터링 서비스에 가입했다면 필터링 프락시로 통과하도록 라우팅할 것이다.

트랜스코더

• 프록시 서버는 콘텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 수정할 수 있다.
• 이와 같이 데이터 표현 방식을 자연스럽게 변환하는 것을 트랜스 코딩이라한다.

 

• 이미지 변환 파일 압축 같은것도 트랜스 코딩이라 할 수 있다.

입명화 프록시

 

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

3. 프락시는 어디에 있는가

1. 프락시 서버 배치

• 어떻게 사용할지에 따라서 어디에 배치할지를 정할 수 있다.

 

• 출구 프락시: 로컬 네트워크 출구에 위치한 프락시
  • 해커들을 막는 방화벽
  • 기업의 인터넷 요금 절감
  • 유해 컨텐츠 필터링 등
• 접근 프락시: 고객으로부터의 모든 요청을 종합적으로 처리하기 위해 프락시는 ISP 접근 지점에 위치하기도 한다.
  • 인터넷 대역폭 비용을 줄이기 위해 캐시 프락시를 사용한다.
• 대리 프락시
  • 웹 서버로 행하는 모든 요청을 처리하고 필요할 때만 웹 서버에게 자원을 요청할 수 있다.
  • 보안기능을 추가하거나 빠른 웹 서버 캐시를 느린 웹 서버의 앞에 놓음으로써 성능을 개선할 수도 있다.
• 네트워크 교환 프락시
  • 인터넷 교차로의 혼잡을 완화하고, 트래픽을 감시하기 위해 사용

3.2 프락시 계층

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

 

• 프락시 계층은 항상 요청이 어떤 프락시로 갈지 어떤 서버로 갈지가 정해진 정적 계층을 가지기도 하지만
• 컨텐츠에 따라 다른 프락시로 전달하고 다른 서버로 전달하는 동적 계층 구조를 가질 수 있다.
• 동적 계층 예
  • 부하균형
  • 지리적 인접성에 근거한 라우팅
  • 프로토콜/타입 라우팅
  • 유료 서비스 가입자를 위한 라우팅
  • ….

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

• 클라이언트가 프락시와 대화하기 위해 HTTP 요청이 어떻게 프록시를 찾아갈지에 대한 4가지 방법

 

• 클라이언트를 수정한다.
  • 많은 브라우저가 프록시로 보내는 설정을 지원한다 수동으로 지원하던 자동으로 지원하던 만약 지원한다면 의도적으로 원 서버가 아닌 프락시로 보낸다.
• 네트워크를 수정한다.
  • 네트워크 인프라를 가뢔서 웹 트래픽을 프락시로 가도록 조정하는 몇 가지 기법이 있다.
  • 이 가로챔은 일반적으로 HTTP 트래픽을 지켜보고 가로채어 클라이언트 모르게 트래픽을 프락시로 보내는 스위칭 장치와 라우팅 장치를 필요로 한다.
  • 이것을 인터셉트 프락시라고 부르기도 한다.
• DNS 이름 공간을 수정한다.
  • 웹 서버 앞에 위치하는 프락시 서버인 대리 프락시는 웹 서버의 이름과 IP 주소를 자신이 직접 사용한다.
• 웹 서버를 수정한다.
  • 웹 서버는 HTTP 리다이렉션을 클라이언트에게 돌려줌으로써 클라이언트의 요청을 프락시로 리다이렉트 하도록 설정할 수 있다.

4. 클라이언트 프락시 설정

• 모든 현대적인 브라우저는 프락시를 사용할 수 있도록 설정할 수 있다.
• 수동설정
• 브라우저 기본 설정
  • 브라우저 벤저나 배포자는 브라우저를 소비자에게 전달하기 전에 프락시를 미리 설정할 수 있다.
• 프락시 자동 설정(PAC)
  • 프락시 설정을 상황에 맞게 계산해주는 자바스크립트 프로그램
• WPAD 프락시 발견
  • 대부분의 브라우저는ㅇ 자동설정 파일을 다운받을 수 있는 설정서버를 자동으로 찾아주는 웹 프락시 자동발견 프로토콜을(WPAD) 제공한다.
  • 알맞는 PAC 파일을 찾게 해준다.

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

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

• 프락시가 원래는 없었기 때문에 클라이언트와 서버는 직접 통신했다.
• HTTP 문법을 보면 부분 URI만 시작줄에 있는 것을 볼 수 있다.
• 하지만 이는 프락시가 생겨나면서 문제가 되었다.
• 프락시는 서버와 직접 대화하는데 부분 URI로는 호스트가 어딘지 알 수 없었다.
• 그래서 우리는 서버로는 부분 URI를 ,그리고 프락시로는 완전한 URI로 보낼 필요가 있다.

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

• 위 프락시를 다룰때 부분 URI가 문제가 되듯이
• 가상 호스팅도 이와 같은 문제가 있다.
  • 가상 호스팅은 호스트명을 필요로한다.

 

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

• 항상 전체 URI를 받지는 않는다.
• 대리 프락시와 인터셉트 프락시를 생각해보면
• 대리 프락시는 서버와 같은 역할을 하고 인터셉트는 중간에 트래픽을 클라이언트 모르게 가로챈다.
• 그래서 대리 프락시와 인터셉트 프락시와의 트랜잭션은 클라이언트 입장에서 프락시와 대화하는 것을 모를것이다.

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

• 다목적 프락시 서버는 요청 메시지의 완전한 URI와 부분 URI를 모두 지원해야한다.
• 웹 서버 요청의 경우에는 가상 Host 헤더를 사용해야 한다.
• 완전 URI와 부분 URI를 사용하는 규칙은 다음과 같다
  1. 완전한 URI가 주어졌다면 → 프락시는 그것을 사용한다.
  2. 부분 URI가 주어졌고 Host 헤더가 있다면, → Host 헤더를 이용해 원 서버의 이름과 포트번호를 알아내야 한다.
  3. 부분 URI가 주어졌으나 Host 헤더가 없다면
     1. 프락시가 원서버를 대신하는 대리 프락시라면 , 프락시에 실제 서버의 주소와 포트 번호가 설정되어 있을 수 있다.
     2. 이전에 어떤 인터셉트 프락시가 가로챘던 트래픽을 받았고 , 그 인터셉트 프락시가 원 IP 주소와 포트번호를 사용할 수 있게 했다면 그것을 사용
     3. 위 2방법이 아니라면 에러를 반환한다.

5.5 전송중 URI 변경

• 몇몇 프락시는 URI 변경을 다음 홉으로 보내기 전 정규화하는 것으로 알려졌다.
• 아무리 무해해 보이는 변경이라도 이는 상호운용성 문제를 일으킬 수 있다.
• 프락시는 최대한 관대하게 다음 홉으로 보내야한다.

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

• 브라우저는 프락시의 존재 여부의 따라 URI를 다르게 분석한다.
• 프락시가 없다면 사용자가 타이핑한 URI를 가지고 그에 대응하는 IP 주소를 찾는다.
• 만약 호스트명이 발견되면 그에 대응하는 IP 주소들을 연결에 성공할 때까지 시도해본다.
  • 그러나 발견되지 않으면 자동화된 URI확장을 통해 찾는다.

5.7 프락시 없는 URI 분석

 

• 프락시가 없는 브라우저는 호스트 명 자동 확장을 보여준다.
• 브라우저는 유효한 호스트 명이 발견될 때까지 다양한 호스트 명의 가능성들을 검색한다.

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

• 명시적으로 프락시가 존재한다면, 위와 같이 소트명 자동 확장 기능을 사용하지 않는다.
• 확장되지 않은 부분 URI를 얻는다.
• 그리고 몇몇 프락시는 자동확장을 지원하는 등의 기능을 지원할려고 한다.

 

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

• 인터셉터 프락시의 경우 클라이언트는 웹서버와 연결을 맺었다고 생각한다.
• 하지만, 살아 있지 않은 웹서버와 연결이 될 수 있음
• 그래서 브아우저에서 제공하는 것과 동등한 수준의 장애 허용을 제공하기 위해서, 프락시는 호스트 헤더에 들어 있는 호스트 명을 다시 분석하든 아니면 IP 주소에 대한 역방향 DNS 룩업을 해서든 다른 IP 주소를 시도해야 한다.

 

6. 메시지 추적

• 요즘에 프락시를 둘 이상의 프락시를 지나게 되는 것은 흔하다.
• 캐시 프락시나 방화벽 ISP … 과 같은 프락시들을 지나는 메시지의 흐름을 추적하고 문제점을 찾아내는 것도 필요한 일이 되었다.

6.1 via 헤더

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

 

• via와 게이트웨이
  • 게이트웨이를 통해 프로토콜이 변환되면 이러한 변환도 기록한다.
• via가 개인정보 보호와 보안에 미치는 영향
  • 각 노드들을 기록하므로 정확한 호스트명이 들어가서는 안된다.
  • 만약 들어가도록 허용하더라도 가명으로 대체되어야 한다.
  • 가명으로 실제 이름을 알기 어렵더라도 경유지 항목을 유지해야한다.

6.2 TRACE 메서드

 

• TRACE 란 HTTP 메서드를 이용하면 서버는 클라이언트가 보낸 요청이 중간 노드들을 거치고 난 후의 메시지를 응답 요청 본문에 보낸다.
• 이로써 프락시 흐름을 디버깅하는데 용이하지만, 다른 메서드에 적용하기엔 어렵다
• → HTTP 메서드 참고

7. 프락시 인증

• 프락시는 앞에서 말한 것과 같이 접근 제어 장치로서 제공될 수 있다.
• HTTP는 사용자가 유효한 접근 권한 자격을 프락시에 제출하지 않는 한 콘텐츠에 대한 요청을 차단하는 프락시 인증이라는 메커니즘을 정의한다.
• 제한된 콘텐츠에 대한 요청이 프락시 서버에 도착했을 때, 프락시 서버는 접근 자격을 요구하는 407 응답코드를 보낼 수 있다.

 

8. 프락시 상호운용성

• 프락시 서버는 서로 다른 프로토콜을 구현했을 수도 있고 골치 아프게 이상한 동작을 할 수도 있는 클라이언트와 서버 사이를 중개해야 한다.

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

• 프락시가 이해하지 못하는 헤더 필드들을 만날 수 있다.
• 이때 프락시는 이 이해하지 못하는 헤더필드와 헤더필드들의 순서를 유지하고 그대로 변환 없이 다음 홉으로 넘겨야 한다.

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

• HTTP 메서드인 OPTIONS 는 클라이언트와 프락시가 서버의 특정 리소스가 어떤 기능을 지원하는지 클라이언트가 알아볼 수 있게 해즌다.
• Allow 헤더 하나에 정보를 담고, 더 많은 정보를 위해 선택적으로 응답 본문을 허용하지만 정의된 것은 없다.