[HTTP 완벽 가이드] 6장. 프록시

웹 프록시

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

프록시와 게이트웨이

• 프록시는 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결한다.
• 게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결한다.

프록시 서버의 배치

• Egress Proxy
  • 로컬 네트워크와 더 큰 인터넷 사이를 오가는 트래픽을 제어하기 위해 로컬 네트워크의 출구에 위치시킬 수 있다.
• Ingress Proxy
  • 클라이언트의 모든 요청을 종합적으로 처리하기 위해 위치시킨다.
• Reverse Proxy
  • 네트워크의 가장 끝에 있는 웹 서버들의 바로 앞에 위치한다.
  • 웹 서버로 향하는 모든 요청을 처리하고 필요할 때만 웹 서버에게 자원을 요청할 수 있다.
  • 웹 서버에 보안 기능을 추가하거나 빠른 웹 서버 캐시를 느린 웹 서버의 앞에 놓음으로써 성능을 개선할 수 있다.
  • 라운드로빈을 통해 웹 서버의 부하를 분산시키는 역할을 할 수 있다.

프록시 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와 서버 URI가 다른 이유

• 원래의 HTTP 설계에서, 클라이언트는 단일한 서버와 직접 통신했고, 프록시에 대한 대비책이 없었다.

• 단일 서버는 자신의 호스트와 포트번호를 알고 있으므로, 클라이언트는 불필요한 정보 발송을 피하기 위해 스킴과 호스트, 포트번호가 없는 부분 URI만 전송했다.

• 프록시가 이후에 부상하면서 부분 URI는 문제가 됐는데, 프록시 서버는 목적지 서버와 커넥션을 맺어야 하므로 그 서버의 이름을 알아야 했기 때문이다.

• 명시적으로 설정된 클라이언트 프록시 설정의 경우, 클라이언트는 어떻게 요청을 보내야하는지 알고 있다.

  • 프록시를 사용하지 않도록 설정 -> 부분 URI를 보낸다.
  • 프록시를 사용하도록 설정 -> 완전한 URI를 보낸다.

• 프록시와 서버 요청에 모두에 대해 HTTP/1.1은 현재 서버들이 완전한 URI를 다룰 것을 요구한다.

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

• 명시적인 프로깃 요청에 대해서는 완전한 URI를 사용하고, 아니면 부분 URI를 사용한다.
• 웹 서버 요청의 경우에는 가상 Host 헤더를 사용해야 한다.
• 완전 URI와 부분 URI를 사용하는 규칙
  • 완전한 URI가 주어졌다면 그것을 사용한다.
  • 부분 URI가 주어졌고 Host 헤더가 있다면, Host 헤더를 이용하여 원 서버의 이름과 포트번호를 알아내야 한다.
  • 부분 URI가 주어졌으나 Host 헤더가 없다면, 다음의 방법으로 원 서버를 알아내야 한다.
    • 프록시가 원 서버를 대신하는 대리 프록시라면, 프록시에 실제 서버의 주소와 포트 번호가 설정되어 있을 수 있다.
    • 이전에 어떤 인터셉트 프록시가 가로챘던 트래픽을 받았고, 그 인터셉트 프록시가 원 IP 주소와 포트번호를 사용할 수 있도록 해두었다면, 그 IP 주소와 포트번호를 사용할 수 있다.
    • 모두 실패했다면, 프록시는 원서버를 알아낼 수 있는 충분한 정보를 가지고 있지 못한 것이므로 반드시 에러 메시지를 반환해야 한다. (사용자에게 Host 헤더를 지원하는 웹브라우저로 업그레이드 할 것을 요청)

메시지 추적

최근에는 요청이 프록시를 지나게 되는 일이 흔하게 일어난다. 프록시가 점점 더 흔해지면서, 메시지의 흐름을 추적하고 문제점을 찾아내는 일도 필요하게 되었다.

Via 헤더

• 메시지가 지나는 각 중간 노드(프록시나 게이트웨이)의 정보를 나열한다.
• 메시지가 또 다른 노드를 지날 때마다, 중간 노드는 Via 목록의 끝에 반드시 추가되어야 한다.
• 다음은 메시지가 두 개의 프록시를 자나갔음을 말해준다.

  Via: 1.1 proxy-12.hello.com, 1.0 cache.world.com
  

// 첫 번째 프록시는 HTTP/1.1 프로토콜을 구현했으며, proxy-12.hello.com 이라 불린다.
// 두 번째 프록시는 HTTP/1.0을 구현했고 cache.world.com 으로 불린다.

* 프록시는 네트워크의 라우팅 루프를 탐지하기 위해 Via 헤더를 사용할 수 있다.
* 프록시는 요청을 보내기 전에 자신을 가리키는 유일한 문자열을 Via 헤더에 삽입해야 하며 네트워크에 라우팅 루프가 있는지 탐지하기 위해 이 문자열이 들어온 요청에 있는지 검사해야 한다.

#### Via와 게이트웨이
* 몇몇 프록시는 서버에게 비 HTTP 프로토콜을 사용할 수 있는 게이트웨이 기능을 제공한다.
* Via 헤더는 이러한 프로토콜 변환을 기록하므로 HTTP 애플리케이션은 프록시 연쇄에서 프로토콜 변환이 있었는지를 알아챌 수 있다.

#### Server 헤더와 Via 헤더
* Server 응답 헤더 필드는 원 서버에 의해 사용되는 소프트웨어를 알려준다. 예를 들면 다음과 같다.
```text
Server: Apache/1.3.14 (Unix) PHP/4.0.4
Server Netscape-Enterprise/4.1
Server: Microsoft-IIS/5.0

• 응답 메시지가 프록시를 통과할 때, 프록시는 Server 헤더를 수정해서는 안된다. (Server 헤더는 원 서버를 위해 존재한다. 대신 프록시는 Via 항목을 추가해야 한다.)

Trace 메서드

• HTTP/1.1의 TRACE 메서드는 요청 메시지를 프록시의 연쇄를 따라가면서 어떤 프록시를 지나가고 어떻게 각 프록시가 요청 메시지를 수정하는지 관찰/추적할 수 있다.
• TRACE 요청이 목적지 서버에 도착했을 때, 서버는 전체 요청 메시지를 HTTP 응답 메시지의 본문에 포함시켜 송신자에게 그대로 돌려보낸다.
• TRACE 응답이 도착했을 때, 클라이언트는 서버가 받은 메시지와 그 메시지가 지나간 프록시들의 목록(Via 헤더 안에 있다)을 검사할 수 있다.
• TRACE 응답의 Content-Type은 message/http이며 상태는 200 OK 이다.

Max-Forwards

• 일반적으로 TRACE 메시지는 중간에 프록시들이 몇 개나 있든 신경 쓰지 않고 목적지 서버로의 모든 경로를 여행한다.
• TRACE와 OPTIONS 요청의 프록시 홉 개수를 제한하기 위해 Max-Forwards 헤더를 사용할 수 있다.
• Max-Forwards 헤더는 메시지가 무한 루프에 빠지지 않는지 프록시 연쇄를 테스트하거나 연쇄 중간의 특정 프록시 서버들의 효과를 체크할 때 유용하다.
• Max-Forwards는 OPTIONS 메시지의 전달 횟수도 제한한다.
• Max-Forwards 요청 헤더 필드는 이 요청 메시지가 몇 번 더 다음 홉으로 전달될 수 있는지 말해주는 정수 하나를 담고 있다.
• Max-Forwards 값이 0이라면 수신자는 자신이 원 서버가 아니라더라도 TRACE 메시지를 더이상 전달하지 말고 반드시 클라이언트에 돌려줘야 한다.
• Max-Forwards 는 다음 홉으로 전달될 때, 1씩 감소된 값으로 갱신되어야 한다.

OPTIONS

• HTTP OPTIONS 메서드는 서버나 웹 서버의 특정 리소스가 어떤 기능을 지원하는지(예를 들면 지원하는 메서드) 알게 해준다.
• OPTIONS 메서드는 서버에서 지원하거나 지정한 리소스에 대해 가능한 선택적인 기능들을 서술하는 여러 헤더 필드를 포함한 200 OK 응답을 반환한다.
• HTTP/1.1이 명시한 헤더는 서버에 의해 어떤 세머드가 지원되는지 서술하는 ALLOW 헤더 하나 뿐이다.

ALLOW 헤더

• ALLOW 엔티티 헤더 필드는, 요청 URI에 의해 식별되는 자원에 대해 지원되는 메서드들이나 서버가 지원하는 모든 메서드를 열거한다. 예를 들면 다음과 같다.

  Allow: GET, HEAD, PUT

---

참고자료

HTTP 완벽 가이드