웹 중개자 (프락시)
- 웹 프락시 서버는 클라이언트의 입장에서 트랜잭션을 수행하는 중개인
- 웹 프락시가 있다면, 자신의 입장에서 서버와 대화해주는 프락시와 대화한다.
- HTTP 프락시 서버는 웹 서버이기도 하고 웹 클라이언트이기도 한다.
- 프락시 종류
- 개인 프락시: 흔하진 않으나 브라우저의 기능을 확장하거나 성능 개선, 무료 ISP 서비스를 위한 광고를 운영하기 위해 사용
- 공용 프락시: 여러 사용자들의 공통된 요청을 처리하므로 비용효율이 높고 관리가 쉬움
- 프락시 vs 게이트웨이
: 프락시는 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결하고, 게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결한다.
왜 프락시를 사용하는가?
: 보안을 개선하고, 성능을 높여주며, 비용을 절약한다.
- 프락시 사용 예
- 어린이 필터: 성인 콘텐츠 차단
- 문서 접근 제어자: 중앙 프락시 서버에서 접근 제어 설정
- ex) 클라이언트에게 제약 없이 서버의 뉴스 페이지에 접근할 수 있도록 허가
- ex) 클라이언트에게 제약 없이 인터넷 콘텐츠에 접근할 수 있는 권한을 준다.
- ex) 클라이언트에게 서버에 접근하기 전에 비밀번호를 요구한다.
- 보안 방화벽: 조직 안에 들어오거나 나가는 응용 레벨 프로토콜의 흐름을 통제
- 웹 캐시: 문서의 로컬 사본을 관리하고 해당 문서에 대한 요청이 오면 빠르게 제공한다.
- 대리 프락시: 웹 서버인 것처럼 위장
- 콘텐츠 라우터: 맞춤형 콘텐츠 라우팅 프락시를 이용해 구성
- 트렌스코더: 콘텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 수정 ex) 이미지 변환 (GIF -> JPG), 파일 압축, 문서 번역 등
- 익명화 프락시: HTTP 메시지에서 신원을 식별할 수 있는 특성들을 제거하여 개인 정보 보호와 익명성 보장에 기여
프락시는 어디에 있는가?
- 프락시 서버가 배치될 수 있는 방법
- 출구 프락시: 로컬 네트워크 출구에 위치, 학생들이 부적절한 콘텐츠를 브라우징하는 것을 막기 위해 필터링 출구 프락시 등
- 접근(입구) 프락시: 고객으로부터의 모든 요청을 종합적으로 처리하기 위해 ISP 접근 지점에 위치
- 대리 프락시: 웹 서버 바로 앞에 위치하며 웹 서버로 향하는 모든 요청을 처리하고 필요할 때만 웹 서버에게 자원을 요청
- 네트워크 교환 프락시: 캐시를 이용해 혼잡을 완화하고 트래픽 흐름을 감시하기 위해 네트워크 사이 인터넷 피어링 교환 지점에 위치
- 프락시 계층
: 프락시에서 프락시로 계층을 이뤄 연쇄를 구성
프락시 계층에서 프락시 서버들은 부모와 자식의 관계를 갖는다.
정적 프락시가 아닌 동적 부모 선택의 몇가지 예
- 부하 균형
- 지리적 인접성에 근거한 라우팅
- 프로토콜/타입 라우팅
- 유료 서비스 가입자를 위한 라우팅
- 클라이언트 트래픽이 프락시로 가도록 만드는 방법
- 클라이언트를 수정하는 방법: 웹 클라이언트들은 수동, 자동 프락시 설정을 지원
- 네트워크를 수정하는 방법: 스위칭 장치와 라우팅 장치를 필요로 함(인터셉트 프락시)
- DNS 이름 공간을 수정하는 방법: 웹 서버 앞에 위치하는 대리 프락시는 웹 서버의 이름과 IP를 자신이 직접 사용한다. 이는 DNS 서버를 이용하여 조정될 수 있다.
- 웹 서버를 수정하는 방법: HTTP 리다이렉션 명령(305)을 클라이언트에게 돌려줌으로써 클라이언트의 요청을 프락시로 리다이렉트하도록 설정
클라이언트 프락시 설정
- 수동 설정: 구글 크롬에서 설정 > 고급 설정 표시 > 프록시 설정 변경...
- 브라우저 기본 설정: 브라우저 배포자는 브라우저를 소비자에게 전달하기 전에 미리 설정해 높을 수 있다.
- 프락시 자동 설정(PAC): 자바스크립트 프락시 자동 설정 파일에 대한 URI 제공
- WPAD 프락시 발견
프락시 요청 특징
- 프락시 URI는 서버 URI와 다르다.
: 단일 서버는 자신의 호스트 명과 포트번호를 알고 있으므로 클라이언트는 불필요한 정보 발송을 피하기 위해 스킴과 호스트 가 없는 부분URI만 보냈다. 그러나 프락시는 서버의 이름을 알 필요가 있으므로 서버로는 부분 URI를, 프락시로는 완전한 URI를 보낼 필요가 있다.
- 가상 호스팅에서 일어나는 같은 문제
: '스킴/호스트/포트번호 누락'문제는 가상 호스팅에도 같은 문제다.
- 명시적인 프락시는 요청 메시지가 완전한 URI를 갖도록 함으로써 이 문제를 해결했다.
- 가상으로 호스팅되는 웹 서버는 호스트와 포트에 대한 정보가 담겨 있는 Host 헤더를 요구한다.
- 인터셉트 프락시는 부분 URI를 받는다.
: 클라이언트에게 보이지 않은 프락시가 있거나, 프락시를 사용하고 있다고 설정되어 있찌 않아도 클라이언트의 트래픽은 여전히 대리 프락시나 인터셉트 프락시를 지날 수 있다. 이 경우, 클라이언트는 완전한 URI를 보내지 않을 것
- 프락시는 프락시 요청과 서버 요청을 모두 다룰 수 있다.
: 다목적 프락시 서버는 요청 메시지의 완전한 URI와 부분 URI를 모두 지원해야 한다.
- 완전 URI와 부분 URI를 사용하는 규칙
- 완전한 URI가 주어지면 프락시는 그것을 사용
- 부분 URI가 주어졌으나 헤더가 없다면...
- 프락시가 대리 프락시라면, 프락시에 실제 서버의 주소와 포트 번호가 설정되어 있을 수 있다.
- 이전에 어떤 인터셉트 프락시가 가로챘던 트래픽을 받았고, 원 IP주소와 포트번호를 사용할 수 있도록 해두었다면, 그 IP주소와 포트번호를 사용할 수 있다.
- 모두 실패할 경우, 에러 메시지 반환
- 전송 중 URI 변경
: 프락시 서버는 요청 URI 변경에 신경 써야함. 프로토콜을 엄격하게 강제해선 안된다. 이는 기존에 잘 동작하던 기능을 망가뜨릴 수 있기 때문이다. 또한 인터셉트 프락시가 URI를 전달할 때 절대 경로를 고쳐쓰는 것을 금지한다.
- URI 클라이언트 자동확장과 호스트 명 분석
- 일반적인 웹 사이트 이름 가운데 부분만 입력했다면, 'www' 접두사를 붙이고 'com' 접미사를 붙인다.
- 몇몇 브라우저는 해석할 수 없는 URI를 서드파티 사이트로 넘기기도 하는데, 이 사이트는 오타 교정을 시도하고 사용자가 의도했을 URI를 제시
- DNS는 사용자가 호스트 명의 앞부분만 입력하면 자동으로 도메인을 검색하도록 설정되어 있다.
- 프락시가 없는 URI 분석
: 브라우저는 명시적인 프락시가 존재하지 않는 경우 부분 호스트 명을 자동으로 확장한다.
- 명시적인 프락시를 사용할 때의 URI 분석
: 브라우저는 명시적인 프락시가 있는 경우 부분 호스트 명을 자동 확장하지 않는다.
- 인터셉트 프락시를 이용한 URI 분석
: 인터셉트 프락시를 사용하고 있는 브라우저는 죽은 서버의 IP 주소를 탐지할 수 없다. 브라우저가 명시적인 프락시를 사용하도록 설정되어 있는 경우 장애 허용은 프락시에 달려있기 떄문에 죽은 서버의 DNS 분석에 대한 장애 허용을 지원해야 한다.
프락시 인증
- 제한된 콘텐츠에 대한 요청이 프락시 서버에 도착했을 때 프락시 서버는 접근 자격을 요구하는 407 상태코드를 Proxy-Authenticate 헤더 필드와 함께 반환 할 수 있다.
- 클라이언트는 407응답을 받게 되면 요구되는 자격을 수집한다.
- 자격을 획득하면 클라이언트는 Proxy-Authenticate 헤더 필드에 담아 요청을 다시 보낸다.
- 자격이 유효하다면 통과, 유효하지 않다면 407응답을 보낸다.
프락시 상호운용성
: 클라이언트, 서버, 프락시는 HTTP 명세의 여러 버전에 대해 여러 벤더에 의해 만들어진다.
- 지원하지 않는 헤더와 메서드 다루기
: 프락시는 이해할 수 없는 헤더 필드는 반드시 그대로 전달해야 하며, 같은 이름의 헤더 필드가 여러 개 있는 경우에는 상대적인 순서도 반드시 유지해야한다.
- OPTIONS: 어떤 기능을 지원하는지 알아보기
: HTTP OPTIONS 메서드는 서버나 웹 서버의 특정 리소스가 어떤 기능을 지원하는지 클라이언트가 알아볼 수 있게 해준다.
OPTIONS * HTTP/1.1 => 서버의 전체 능력에 대해 가능한 기능들을 묻는 것
- Allow 헤더
: 요청 URI에 의해 식별되는 자원에 대해 지원되는 메시지들이나 서버가 지원하는 모든 메서드를 열거
Allow: GET, HEAD, PUT
'개발도서 읽기 > HTTP 완벽 가이드' 카테고리의 다른 글
[2. HTTP 아키텍처] 8장) 통합점: 게이트웨이, 터널, 릴레이 (0) | 2021.05.02 |
---|---|
[2. HTTP 아키텍처] 7장) 캐시 (0) | 2021.05.02 |
[2. HTTP 아키텍처] 5장) 웹 서버 (0) | 2021.04.25 |
[1. HTTP: 웹의 기초] 4장) 커넥션 관리 (0) | 2021.04.18 |
[1. HTTP: 웹의 기초] 3장) HTTP 메시지 (0) | 2021.04.18 |