1. 1달 전

    18장 웹 호스팅

    HTTP 완벽 가이드 18장 정리

  2. 2달 전

    17장 내용 협상과 트랜스코딩

    HTTP 완벽 가이드 17장 정리

  3. 5달 전

    16장 국제화

    HTTP 완벽 가이드 16장 정리

  4. 5달 전

    15장 엔터티와 인코딩

    HTTP 완벽 가이드 15장 정리

  5. 6달 전

    14장 보안

    HTTP 완벽 가이드 14장 정리

  6. 7달 전

    12장 기본 인증

    HTTP 완벽 가이드 12장 정리

  7. 7달 전

    11장 클라이언트 식별과 쿠키

    HTTP 완벽 가이드 11장 정리

  8. 7달 전

    10장 HTTP 2.0

    HTTP 완벽 가이드 10장 정리

  9. 7달 전

    9장 웹 로봇

    HTTP 완벽 가이드 9장 정리

  10. 7달 전

    8장 통합점 게이트웨이, 터널, 릴레이

    HTTP 완벽 가이드 8장 정리

  11. 7달 전

    7장 캐시

    HTTP 완벽 가이드 7장 정리

  12. 7달 전

    6장 프락시

    HTTP 완벽 가이드 6장 정리

  13. 7달 전

    5장 웹서버

    HTTP 완벽 가이드 5장 정리

  14. 7달 전

    4장 HTTP 커넥션 관리

    HTTP 완벽 가이드 4장 정리

  15. 7달 전

    3장 HTTP 메시지

    HTTP 완벽 가이드 3장 정리

  16. 7달 전

    2장 URL과 리소스

    HTTP 완벽 가이드 2장 정리

  17. 7달 전

    1장 HTTP 개관

    HTTP 완벽 가이드 1장 정리

Tamm자바스크립트 웹 개발 환경을 좋아하고 사람들에게 재미를 주는 것에 관심이 많은 개발자 입니다.

6장 프락시

HTTP 완벽 가이드 6장 정리

featured image thumbnail for post 6장 프락시

이 장에서 다룰 내용들

  • HTTP 프락시와 웹 게이트웨이를 비교하고 HTTP 프락시가 어떻게 배치되는지 그림으로 보여주면서 설명한다.
  • 몇 가지 유용한 활용방법을 보여준다.
  • 프락시가 실제 네크워크에 어떻게 배치되어 있는지 그리고 트래픽이 어떻게 프락시 서버로 가게 되는지 설명한다.
  • 브라우저에서 프락시를 사용하려면 어떻게 설정해야 하는지 보여준다.
  • HTTP 프락시 요청이 서버 요청과 어떻게 다른지, 그리고 프락시가 어떻게 브라우저의 동작을 미묘하게 바꾸는지 보여준다.
  • 일련의 프락시 서버들을 통과하는 메시지의 경로를, Via 헤더와 TRACE 메서드를 이용해 기록하는 방법을 설명한다.
  • 프락시에 기반한 HTTP 접근 제어를 설명한다.
  • 어떻게 프락시가 클라이언트와 서버 사이에서 각각의 다른 기능과 버전 들을 지원하면서 상호작용 할 수 있는지 설명한다.

6.1 웹 중개자

웹 프락시 서버는 클라리언트의 입장에서 트랜잭션을 수행하는 중개인이다. 나 대신 서버에 요청을 하기 때문에 프락시 서버는 웹 클라이언트이면서 웹 서버이기도 하다.

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

공용 프락시 - 여러 클라이언트가 사용하는 프락시

개인 프락시 - 흔하지 않지만 하나의 클라이언트가 독점적으로 사용

6.1.2 프락시 vs 게이트웨이

프락시: 둘 이상의 애플리케이션을 연결하는데 같은 프로토콜을 사용

게이트웨이: 둘 이상의 애플리케이션을 연결하는데 다른 프로토콜을 사용

Untitled d0b25c8e aae1 4b5e b4f6 0fd95ef0c195

근데 요새 차이점이 모호한게 프락시도 HTTP, SSL, FTP 등 다른 프로토콜로 연결하는 기능도 포함하기 때문이다.

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

프락시는 실용적이고 유용한 모든 것을 한다. 보안, 성능, 비용 절감 등이다. 성인 콘텐츠 필터나, 접근 제어, 보안 방화벽, 캐시, 트랜스코더(데이터를 수정), 익명화 등의 작업을 한다.

캐시의 경우는 예를들어 AWS서버를 접근할 수록 비용이 들 수 있는데, 더 적은 비용의 웹 캐시 서버를 두면 비용 절감을 할 수 있다.

트랜스 코더를 좀 더 설명하면, 이미지 같은 것을 좀 더 효율적인 포맷으로 처리 한다든지 내용을 변경하는 일이다.

익명화는 개인의 정보가 있을 수 있는 IP 주소, From 헤더, Referer 헤더, 쿠키, URI 세션 아이디드을 제거하여 클라이언트의 정보를 유추할 수 없게 하는 것이다.

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

6.3.1 어떻게 프락시가 네트워크에 배치되는가?

사용하는 방식에 따라 어디든 배치될 수 있다.

출구(a) - 컨텐츠 필터링, 보안

입구(b) - 캐시

대리(c)- 캐시, 웹서버의 이름과 IP를 스스로 사칭

네트워크 교환(d) - 프락시에 트래픽을 감시한다고 함

Untitled 35a0948a f01b 477f a37b 9ea465715292

6.3.2 어떻게 프락시의 연쇄가 계층을 이루는가?

Untitled bbd6ef3a 8ad9 4669 a44b 3c636a5eef3e

서버쪽으로 갈 수록 부모 서버가 되고, 자식 프락시는 자신이 수행할 일을 요청할 부모 프락시를 정할 수 있다.

Untitled 1f0ac184 04ed 470d ad9b a7dc221bd31b

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

어떻게 원서버로 요청한 메시지가 프락시한테 갈까? 네 가지 방법이 있다.

Untitled db5385b5 609a 4b55 84e1 2bbba6ab7cb5

  • 클라이언트를 수정 - 의도적으로 원 서버가 아닌 프락시 서버로 요청이 간다.
  • 네트워크를 수정 - 스위칭, 라우팅 장치에서 처리하는 인터셉트 프락시
  • DNS에서 수정 - 대리 프락시에서 자신의 DNS 테이블을 사용한다.
  • 웹 서버를 수정 - 웹서버에서 HTTP 리다이렉션을 실행시킨다.

6.4 클라이언트 프락시 설정

브라우저에서 프락시를 제공한다.

수동설정, 브라우저 기본 설정, 프락시 자동 설정(PAC), WPAD 프락시 발견 등의 방법이 있다.

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

브라우저에서 프록시 설정

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

프락시 설정하는 PAC 파일이 존재, 자바스크립트 코드로 프락시 선택

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

  • PAC URI를 찾기 위해 WPAD를 사용한다.
  • 주어진 URI에서 PAC 파일을 가져온다.
  • 프락시 서버를 알아내기 위해 PAC 파일을 실행한다.
  • 알아낸 프락시 서버를 이용해서 요청을 처리한다.

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

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

클라이언트가 요청을 보내면 스킴, 호스트, 포트 번호가 없는 URI를 보낸다. 그런데 프락시 서버는 완전한 URI를 사용한다. 클라이언트는 프락시가 존재하면 완전한 URI를 보내야 한다. 프락시는 요청하는 원 서버의 IP와 포트번호를 모른다. (대리 프락시의 경우는 알고 있다)

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

스킴/호스트/포트번호 누락 문제는 가상 호스팅에서도 문제가 된다. 클라이언트가 완전한 URI를 사용하거나 Host 헤더를 요구한다.

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

인터셉터는 원 서버로 요청이 가기전에 받아서 지가 처리 해버리기 때문에 부분 URI이든지 완전 URI인지 상관 없다.

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

다목적 프락시 서버는 완전한 URI가 오든 부분 URI가 오든 적절하게 처리할 수 있어야 한다.

부분 URI이 오면 아래의 방법으로 완전 URI를 얻는다.

  • 부분 URI가 주어졌고 Host 헤더가 있다면, Host 헤더에서 원 서버의 이름과 호스트 포트를 얻는다.
  • 부분 URI가 주어졌으나 Host 헤더가 없다면, 대리 프락시에서 찾거나, 인터셉터 프락시에서 찾는다.
  • 그럼에도 완전 URI를 얻지 못하면 클라이언트에게 실패 메시지를 보낸다. 여기에는 Host 헤더를 사용하라는 메시지일 것이다.

인터셉터 프락시에서 완전 URI를 찾으라고 되어 있는데, 20장에 설명이 되어 있다고 한다.

6.5.5 전송 중 URI 변경

기본적으로 프락시 서버는 URI 변경을 하지 않는 것이 원칙이다. HTTP 포트를 명시적으로 :80으로 한다던가 요청을 이스케이프 하는 것은 무해한 일이라 생각하겠지만, 어떤 부작용을 만들어낼지는 아무도 모른다. 그리고 그런 역할이 프락시가 가지는 것은 아니다. HTTP 명세에도 URL을 전달할 때 절대 경로 고치는 것을 금하지만 예외로 빈 경로를 '/'로 교체하는 것은 허용한다.

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

크롬 같은 경우 google 만쳐도 ww.google.com을 완성해준다. 알아서 .com 접미사를 붙여서 해석하 수 있는 URI 형태로 고친다.

6.5.7 프락시 없는 URI 분석

Untitled a06df774 4616 4ae4 b6cc 02da0a1f4fb1

예를들어 google을 브라우저에 입력하면, http://google:80/ 이렇게 찾는다. 여기서 실패하면 http://www.google.com:80 으로 찾는다. 이것은 성공한다.

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

명시적인 프락시를 사용하면 뭐 확장을 사용하지 않는다. 한다.

Untitled 55761389 a1fa 45b8 87f4 90175a8aaa6f

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

인터셉터 프락시가 좀 다른 동작을 하나 본데,, 잘 모르겠다.

6.3 메시지 추적

오늘날은 통신으 효율을 위해 프락시를 흔히 사용한다. 메시지의 흐름을 추적하고 문제점을 찾는 일도 필요하다.

6.6.1 Via 헤더

프락시 서버는 자신을 통하는 메시지에 Via 헤더값에 자신을 추가 해줘야 한다.

Untitled b2c46515 6bc5 4809 b6ed bebb69797379

6.6.2 TRACE 메서드

클라이언트는 TRACE메소드를 통해 메시지가 원 서버로 가는 사이에 있는 서버들을 추적할 수 있다.

Untitled 6ccc637b eba3 4359 926e 5041bf3e19e9

프락시 루프에 빠질 수 있으니 Max-Forwards라는 옵션도 있다.

Untitled 36882110 0350 4558 959e acf05f526a7c

6.7 프락시 인증

프락시쪽에서 접근제어를 할 수 있다. Proxy-Authenticate 헤더 값을 사용하는 것인데, 널리 구현되지 않아서 사용성은 일단 없어 보인다.

6.8 프락시 상호운용성

클라이언트와 서버 사이에 올바른 통신을 도우는 역할이다.

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

프락시 서버가 모든 헤더를 이해하지 못할 수 있다. 그럼에도 불구하고 적절히 처리한 후 다음 홉에 전달할 의무가 있다.

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

Untitled 647019c9 64a4 4809 8f6a 0057a627c572

6.8.3 Allow 헤더

실제로 지원하는 메서드를 Allow 엔티티 헤더에 넣어서 응답하라고 한다.

Allow: GET, HEAD, PUT

이 부분은 대부분이 구현 안됐다. google은 에러가 발생하고, mdn은 get 처럼 동작한다.

내가 성공한건 애플인데, https://www.apple.com/ 로 넣으면 아래 처럼 나왔다.

 2019 07 11  8 cfae201c f4b5 4823 b4c1 e9fd5d2e0d10 58 40