6장. 프락시

6.1. 웹 중개자

웹 프락시 서버는 클라이언트와 서버 사이에 있는 중개자 역할을 한다.

👉 클라이언트(웹 서버 입장에서 프락시의 역할)와 서버(웹 클라이언트 입장에서 프락시의 역할) 기능을 모두 수행할 줄 알아야 한다

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

1. 개인 프락시

• 흔하지는 않지만 꾸준히 사용되는 프락시
• 브라우저의 기능을 확장하거나 성능을 개선하기 위해 작은 프락시를 사용자 컴퓨터에서 직접 실행

2. 공유 프락시

• 중앙 집중형 프락시를 관리하는 것이 비용 효율이 높고 쉽기에 가장 많이 쓰임
• 사용자가 많을수록 여러 사용자들의 공통 요청에서 이득을 취할 수 있기에 유리하다

6.1.2. 프락시 VS 게이트웨이

1. 프락시

👉 같은 프로토콜을 사용하는 애플리케이션들을 연결

2. 게이트웨이

👉 서로 다른 프로토콜을 사용하는 애플리케이션들을 연결

 

🚫 둘의 차이는 사실 모호하다!

• 프락시는 때때로 브라우저와 서버가 다른 버전의 HTTP를 사용하기에 프로토콜 변환도 수행함
• 프락시는 SSL보안 프로토콜, Socks 방화벽, FTP 접근, 웹 기반 앱 지원을 위해 게이트웨이 기능을 구현하기도 함 

6.2. 프락시 사용 이유

프락시 사용 이유

1.  보안을 개선하고 성능을 절약하며 비용을 줄여준다
2. 모든 HTTP 트래픽을 들여다보고 건드릴 수 있기에 트래픽을 감시하고 수정할 수 있다

프락시 사용 예시

1. 어린이 필터
   • 프락시는 교육 컨텐츠는 제한없는 접근을 허용하지만 성인 컨텐츠는 강제로 거부할 수도 있다.
2. 문서 접근 제어자
   • 프락시 서버는 많은 웹 서버들과 웹 리소스에 대한 단일한 접근 제어 전략을 구현하고 감사 추적(audit trail)을 하기 위해 사용될 수 있다 👉 대기업 환경이나 분산된 관료 조직에서 유용
   • 중앙 프락시 서버에서 접근 제어를 설정하는 방식
3. 보안 방화벽 
   • 조직 안에 들어오거나 나가는 응용 레벨 프로토콜의 흐름을 네트워크의 한 지점에서 통제
   • 바이러스를 제거하는 웹이나 이메일 프락시가 사용할 수 있는 트래픽을 살펴볼 수 있는 Hook을 제공
4. 웹 캐시
   • 프락시 캐시는 문서의 로컬 사본을 관리하고 해당 문서에 대한 요청이 오면 빠르게 제공한다 👉 느리고 비싼 인터넷 커뮤니케이션을 줄임
5. 대리 프락시
   • 대리 프락시들은 진짜 웹 서버인것처럼 위장
   • 웹 서버 요청을 받으면 요청 받은 콘텐츠 위치를 찾기 위해 다른 서버와 커뮤니케이션 시작
   • 공용 컨텐츠에 대한 느린 웹 서버 성능 개선 위해 사용
   • 서버 가속기라고도 불림
6. 콘텐츠 라우터
   • 프락시 서버는 인터넷 트래픽 조건과 콘텐츠의 종류에 따라 요청을 특정 웹 서버로 유도하는 콘텐츠 라우터로 동작할 수 있음
   • 콘텐츠 라우터는 사용자에게 여러 서비스를 제공하는데 사용될 수 있음
     • 사용자나 콘텐츠 제공자가 더 높은 성능을 위해 돈을 지불했다면 콘텐츠 라우터는 요청을 가까운 복제 캐시로 전달할 수 있음
     • 사용자가 필터링 서비스에 가입했다면 HTTP 요청이 필터링 프락시를 통과하도록 할 수 있음
7. 트랜스코더
   • 프락시 서버는 콘텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 수정할 수 있음 👉 데이터의 표현 방식을 변환하는 것을 트랜스코딩이라 함
   • 트랜스코딩 프락시는 크기를 줄이기 위해 GIF 이미지를 JPG로 변환할 수 있음
   • 텍스트파일을 압축하거나 무선 호출기나 스마트폰을 위해 작은 텍스트로 줄인 웹페이지를 생성할 수도 있음
   • 문서를 외국어 문서로 변환하는 것도 가능
8. 익명화 프락시
   • 익명화 프락시는 HTTP 메시지에서 신원을 식별할 수 있는 특성들(클라이언트 IP 주소, From 헤더, Referer 헤더, 쿠키, URL 세션 아이디 등)을 제거함으로써 개인 정보 보호와 익명성 보장에 기여
   • 익명화 프락시가 사용자 메시지를 변경하는 과정
     • User-Agent 헤더에서 사용자의 컴퓨터와 OS의 종류를 제거
     • 사용자의 이메일 주소를 보호하기 위해 From 헤더 제거
     • 어떤 사이트를 거쳐왔는지 모르게 하기 위해 Referer 헤더 제거
     • 프로필과 신원 정보 없애기 위해 Cookie 헤더 제거 
   • 익명화된 메시지는 공통 식별 정보 헤더를 포함하지 않는다

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

6.3.1. 프락시 서버 배치

사용 목적에 따라 프락시는 어디에든 배치할 수 있음

1. 출구(Egress) 프락시
   • 로컬 네트워크와 더 큰 인터넷 사이를 오가는 트래픽을 제어하기 위해 프락시를 로컬 네트워크의 출구에 넣음
   • 방화벽을 제공하거나 인터넷 트래픽 성능을 개선하기 위해 회사에서 사용할 수 있음
   • 학교에서는 학생들이 부적절한 컨텐츠를 브라우징하는 것을 막기 위해 사용
2. 접근(입구) 프락시
   • 고객으로부터의 모든 요청을 종합적으로 처리하기 위해 프락시를 ISP(Internet Service Provider) 접근 지점에 위치시킴
   • ISP는 사용자들의 다운로드 속도를 개선하고 인터넷 대역폭 비용을 줄이기 위해 캐시 프락시를 사용해 많이 찾는 문서들의 사본을 저장함
3. 대리 프락시
   • 네트워크의 가장 끝에 있는 웹 서버들의 바로 앞에 위치
   • 웹 서버로 향하는 모든 요청을 처리하고 필요할 때만 웹 서버에게 자원을 요청
   • 웹 서버에 보안 기능을 추가하거나 빠른 웹 서버 캐시를 느린 웹 서버 앞에 놓음으로써 성능을 개선시키기도 함
   • 프락시는 웹 서버의 이름과 IP 주소로 위장하기 때문에 모든 요청은 서버가 아닌 이 프락시로 가게 됨
4. 네트워크 교환 프락시
   • 네트워크 사이의 인터넷 피어링 교환 지점에 놓임
   • 캐시를 이용해 인터넷 교차로의 혼잡을 완화하고 트래픽 흐름을 감시

6.3.2. 프락시 계층

프락시 계층이란 프락시가 연쇄적으로 연결되어 있는 것을 말함

메시지는 원 서버에 도착할 때까지 프락시와 프락시를 거쳐 이동한다.

프락시 계층의 프락시 서버들은 부모-자식 관계를 맺음

👉 인바운드 프락시(서버에 가까운 쪽)을 부모라고 부르고 아웃바운드 프락시(클라이언트 가까운 쪽)을 자식이라 부른다.

프락시 계층

프락시 계층 콘텐츠 라우팅

1. 정적인 프락시 계층
   • 프락시는 언제나 메시지를 부모 프락시에게만 보낼 수 있음
2. 동적인 프락시 계층
   
   • 메시지를 다양하고 유동적인 프락시 서버나 원 서버에게 보낼 수 있음
   • 요청된 객체가 컨텐츠 분산을 위해 돈을 지불한 웹 서버에 속할 경우, 프락시는 요청을 캐시 서버에게 보내 캐시된 객체를 반환하거나 서버에서 가져오게 할 수 있음
   • 요청이 특정 종류의 이미지에 대한 것이면 접근 프락시는 요청을 특화된 압축 프락시에게 보내 빠르게 클라이언트가 다운로드 할 수 있도록 함
   • 동적 부모 선택의 예시
     • 부하 균형: 자식 프락시는 부하를 분산하기 위해 현재 부모들의 작업량 수준에 근거해 부모 프락시를 고름
     •  지리적 인접성에 근거한 라우팅: 자식 프락시는 원 서버의 지역을 담당하는 부모를 선택할 수 있음
     • 프로토콜/타입 라우팅: 자식 프락시는 URI에 근거해 다른 부모나 원 서버로 라우팅 할 수 있음. 특정 종류의 URI를 갖고 있는 요청이라면 특별한 프락시 서버로 보내져 특별한 프로토콜로 처리될 수 있음
     • 유료 서비스 가입자를 위한 라우팅: 유료 서비스 가입자들의 URI는 대형 캐시나 성능 개선을 위한 압축 엔진으로 라우팅 될 수 있음

6.3.3. 프락시가 트래픽을 처리하는 방법

클라이언트 트래픽이 프락시로 가게 하는 방법

1. 클라이언트 수정
   • 웹 클라이언트가 HTTP 요청을 프락시로 보내도록 설정
2. 네트워크 수정
   
   • 인터셉트 프락시를 이용해 HTTP 트래픽을 가로채 클라이언트 모르게 프락시로 트래픽을 전송한다
3. DNS 이름공간 수정
   • DNS 이름 테이블을 편집하거나 사용할 프락시나 서버를 계산해주는 동적 DNS 서버를 이용해 전송 정보를 수정할 수 있음
   • 이런 방식을 사용해 클라이언트는 웹 서버의 이름을 사용하는 대리 프락시에게 데이터 전송
4. 웹 서버를 수정
   • HTTP 리다리렉션 명령을 클라이언트에게 보내 클라이언트의 요청을 프락시로 리다이렉트시킴 

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

프락시 설정 방법

1. 수동 설정: 프락시 사용하겠다고 명시적으로 설정
2. 브라우저 기본 설정: 브라우저 벤더나 배포자는 브라우저를 소비자에게 전달하기 전에 프락시를 미리 설정할 수 있음
3. 프락시 자동 설정(Proxy auto-configuration, PAC): 자바스크립트 PAC 파일에 대한 URI를 제공. 클라이언트는 자바스크립트 PAC 파일 실행을 통해 프락시 사용해야 하는 이유와 어떤 프락시 서버를 써야하는지 판단할 수 있음
4. WPAD 프락시 발견: 웹 프락시 자동발견 프로토콜을 통해 자동설정 파일을 다운받을 수 있는 '설정 서버'를 자동으로 찾을 수 있음

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

크롬과 인터넷 익스플로러의 프락시 설정 방법 설명

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

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

수동 설정에 비해서 좀 더 동적인 해결책

PAC파일은 프락시 설정을 상황에 맞게 계산해주는 자바스크립트 프로그램이다.

👉 문서에 접근할 때마다 자바스크립트 함수가 적절한 프락시 서버를 선택

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

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

WPAD프로토콜이 구현된 클라이언트가 하는 일

1. PAC URI를 찾기 위해 WPAD 사용
2. 주어진 URI에서 PAC 파일 가져옴
3. 프락시 서버 알아내기 위해 PAC 파일 실행
4. 알아낸 프락시 서버 이용해 요청 처리

WPAD의 리소스 발견 기법

1. 동적 호스트 발견 규약(DHCP)
2. 서비스 위치 규약(SLP)
3. DNS 잘 알려진 호스트 명
4. DNS SRV 레코드
5. DNS TXT 레코드 안의 서비스 URI

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

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

1. 클라이언트가 웹 서버로 요청 보낼 때 URI: 스킴, 호스트, 포트번호가 없는 부분 URI를 가짐 (GET /index.html HTTP/1.0)
2. 클라이언트가 프락시로 요청 보낼 때 URI: 완전한 URI를 가짐 (GET /http://www.naver.com/index.html HTTP/1.0)
3. 요청 형식이 다른 이유
   • 원래 HTTP 설계에서 클라이언트는 단일 서버와 직접 대화했음, 단일 서버는 클라이언트의 호스트 명과 포트번호를 알고 있기에 스킴과 호스트, 포트번호가 없는 부분 URI를 전송함
   • 프락시는 목적지 서버와 커넥션을 맺어야 하기에 서버의 이름을 알아야 됨. 프락시 기반 게이트웨이는 FTP 리소스나 그 외의 스킴과 연결하기에 URI의 스킴을 알아야 됨. 👉 완전한 URI를 전송받아야 함

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

프락시의 '스킴, 호스트, 포트번호 누락'문제는 가상으로 호스팅 되는 웹 서버가 직면하는 문제와 같음

가상 호스팅되는 웹 사이트는 물리적 웹 서버 공유.

요청 하나가 부분 URI로 오면 가상으로 호스팅 되는 웹 서버는 해당 요청을 보낸 웹 사이트의 호스트 명을 알아야 함

👉 호스트와 포트에 대한 정보가 담겨 있는 Host 헤더를 요구함으로써 해결

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

대리 프락시의 경우 클라이언트는 자신이 서버와 대화하고 있다고 생각하기 때문에 부분 URI를 전송받음.

인터셉트 프락시는 서버로 가는 트래픽을 가로채기 때문에 부분 URI를 얻게 됨

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

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

명시적인 프락시 요청일 경우에는 완전한 URI를 사용하고 아니면 부분 URI 사용, 웹 서버의 요청이면 가상 Host 헤더 사용

6.5.5. 전송 중 URI 변경

사소하게 URI 변경돼도 프락시 서버는 다운스트림 서버와 상호운용성 문제를 일으킬 수 있음

❓ 사소한 변경: URI에서 기본 HTTP 포트를 명시적인 ':80'으로 변경하거나 글자를 이스케이프해 교체하는 등의 변경

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

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

프락시가 없으면 URI에 대응되는 IP 주소 찾음

👉 호스트명 발견되면 그에 대응하는 IP 주소들을 연결에 성공할 때까지 시도해봄

👉 호스트명 발견 안되면 브라우저들은 사용자가 호스트명의 약어를 입력했다 판단해 호스트 명을 '확장'시킴

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

프락시 없는 브라우저 호스트명 자동확장 과정

1. 사용자가 'naver'를 브라우저 URI 창에 입력. 브라우저는 'naver'를 호스트 명으로 사용하고 기본 스킴을 'http://'로, 기본 포트를 '80'으로, 기본 경로를 '/'로 간주
2. 브라우저는 호스트 'naver'를 찾아봄 👉 실패
3. 브라우저는 'naver'를 'www.naver.com'으로 자동 확장한 후 DNS에 'www.naver.com'의 주소 분해(resolve)를 요청 👉 성공
4. 브라우저는 'www.naver.com' 연결 성공

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

명시적인 프락시를 사용할 경우에는 브라우저는 부분 호스트 명을 자동확장하지 않는다.

사용자가 'naver'를 입력하면 'http://naver/'라고 밖에 안됨

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

호스트 명 분석은 인터셉트 프락시를 사용할 경우 일반 서버 동작과 다름

6.6. 메시지 추적

요즘에는 많은 회사들이 보안과 비용 절감 위해 캐시 프락시 서버 사용

대리 캐시 저장고에 컨텐츠를 복제해두는 방식이 흔해지고 있음

프락시는 여러 벤더에 의해 개발 

👉 벤더들은 서로 다른 기능과 버그들을 갖고 있으며 여러 조직에 의해 관리

프락시가 더 많아지면서 메시지의 흐름을 추적하고 문제점을 찾는 것이 중요해짐

6.6.1. Via 헤더

1. 메시지가 지나는 각 중간 노드(프락시나 게이트웨이)의 정보를 나열
2. 메시지의 전달을 추적하고, 메시지 루프를 진단하고, 요청을 보내고 그에 대한 응답을 돌려주는 과정에 관여하는 모든 메시지 발송자들의 프로토콜을 다루는 능력을 알아보기 위해 사용

Via 문법

Via 헤더 필드는 쉼표로 구분된 경유지(waypoint)의 목록. 각 경유지는 개별 프락시 서버나 게이트웨이 홉을 나타내며 중간 노드의 프로토콜과 주소에 대한 정보를 담고 있음.

Via: 1.1 proxy-62.irenes-isp.net, 1.0, cache.joes-hardware.com

Via 요청과 응답 경로

응답 메시지는 요청과 같은 경로로 되돌아감

👉 응답의 Via 헤더는 언제나 요청의 Via 헤더와 반대

 

Via와 게이트웨이

몇몇 프락시는 서버에게 비 HTTP 프로토콜을 사용할 수 있는 게이트웨이 기능 제공

Via 헤더는 이러한 프로토콜 변환을 기록하므로 HTTP 애플리케이션은 프락시 연쇄에서 프로토콜 능력과 변환이 있었는지를 알아챌 수 있음

 

Server 헤더와 Via 헤더

Server 응답 헤더 필드는 원 서버에 의해 사용되는 소프트웨어를 알려줌. 응답 메시지가 프락시를 통과할 때, 프락시는 Server 헤더를 수정하지 않고 Via항목을 추가해야 함

 

6.6.2. TRACE 메서드

1. 요청 메시지를 프락시의 연쇄를 따라가며 어떤 프락시를 지나가고 어떻게 각 프락시가 요청 메시지를 수정하는지 관찰 및 추적할 수 있음
2. TRACE 요청이 서버에 도착하면 서버는 전체 요청 메시지를 HTTP 응답 메시지의 본문에 포함시켜 송신자에게 돌려보냄
3. TRACE 응답이 클라이언트에 도착하면 클라이언트는 서버가 받은 메시지와 메시지가 지나간 프락시들의 목록(Via 헤더에 있음)을 검사할 수 있음

6.7. 프락시 인증

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

프락시 인증 메커니즘

1. 제한된 컨텐츠에 대한 요청이 프락시 서버에 도착하면 프락시 서버는 접근 자격을 요구하는 407 Proxy Authorization Required 상태 코드와 자격 제출 방법을 설명해주는 Proxy-Authenticate 헤더 필드와 반환
2. 클라이언트는 407 응답 받으면 요구되는 자격 수집
3. 자격 획득 후, 클라이언트는 자격을 Proxy-Authorization 헤더 필드에 담아 요청 보냄
4. 자격 유효하면, 프락시는 원 요청을 연쇄를 따라 통과시킴

6.8. 프락시 상호운용성

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

프락시는 이해할 수 없는 헤더 필드를 받으면 그대로 전달해야 하며, 같은 이름의 헤더 필드가 여러개 있으면 순서도 유지시켜줘야 한다.

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

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

6.8.3. Allow 헤더

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