HTTP 완벽 가이드 8장
8장 통합점: 게이트웨이, 터널, 릴레이
1. 게이트웨이
게이트웨이는 서로 다른 프로토콜과 애플리케이션 간의 HTTP 인터페이스이다.
- 웹에서 더 복잡한 리소스들을 한 개의 애플리케이션으로만 처리할 수 없어져, 이에 대한 해결책으로 리소스를 받기 위한 경로를 안내하는 역할을 하는 게이트웨이가 고안되었다.
- 게이트웨이는 리소스와 애플리케이션을 연결하는 역할을 한다.
- 게이트웨이는 HTTP 트래픽을 다른 프로코톨로 자동 변환하여 HTTP 클라이언트가 다른 프로토콜을 알 필요 없이 서버에 접속할 수 있게 한다.
클라이언트 측 게이트웨이와 서버 측 게이트웨이
게이트웨이는 클라이언트 측 프로토콜과 서버 측 프로토콜을 빗금(/)으로 구분한다.
<클라이언트 프로토콜>/<서버 프로토콜>
- ex) HTTP/NNTP
- HTTP 클라이언트와 NNTP 뉴스 서버 사이에 있는 게이트웨이.
서버 측 게이트웨이는 클라이언트와 HTTP로 통신하고, 서버와는 외래 프로토콜로 통신한다.
클라이언트 측 게이트웨이는 클라이언트와 외래 프로토콜로 통신하고, 서버와는 HTTP로 통신한다.
2. 프로토콜 게이트웨이
네트워크 상에서 클라이언트와 서버를 연결하는 게이트웨이
- 서버 프로토콜 변환기
- 서버 측 보안 게이트웨이
- 클라이언트 측 보안 게이트웨이
- 애플리케이션 서버
HTTP/*: 서버 측 웹 게이트웨이
서버 측 웹 게이트웨이는 클라이언트로부터 HTTP 요청이 원 서버 영역으로 들어오는 시점에서 클라이언트 측의 HTTP 요청을 외래 프로토콜로 전환한다.
HTTP/HTTPS: 서버 측 보안 게이트웨이
클라이언트는 일반 HTTP를 통해 요청을 보내지만, 게이트웨이는 자동으로 사용자의 모든 세션을 암호화한다.
웹 요청을 암호화함으로써 개인 정보 보호와 보안을 제공한다.
HTTPS/HTTP: 클라이언트 측 보안 가속 게이트웨이
보안 가속기.
웹 서버의 앞단에 위치하고, 보이지 않는 인터셉트 게이트웨이 또는 리버스 프락시 역할을 한다.
보안 HTTPS 트래픽을 받아서 복호화하고, 웹 서버로 보낼 일반 HTTP 요청을 만든다.
보안 트래픽을 암호화하는 하드웨어를 내장해서 부하를 줄이지만, 게이트웨이와 원 서버 간의 암호화하지 않은 트래픽을 전송하기 때문에, 게이트웨이와 원 서버 간에 있는 네트워크가 안전한지 확인하고 사용해야 한다.
3. 리소스 게이트웨이
애플리케이션 서버
게이트웨이의 가장 일반적인 형태로, 애플리케이션 서버는 목적지 서버와 게이트웨이를 한 개의 서버로 결합한다.
애플리케이션 서버는 HTTP를 통해서 클라이언트와 통신하고, 서버 측에 있는 애플리케이션 프로그램에 연결하는 서버 측 게이트웨이이다.
CGI
Common Gateway Interface: 공용 게이트웨이 인터페이스
최초의 서버 확장이자 지금까지도 널리 쓰이는 서버 확장이다.
특정 URL에 대한 HTTP 요청에 따라 프로그램 실행, 프로그램의 출력 수집, HTTP 응답으로 회신하는데 웹 서버가 사용하는 표준화된 인터페이스 집합이다.
웹에서 동적인 HTML, 신용카드 처리, 데이터베이스 질의 등을 제공하는데 사용된다.
CGI는 단순해 거의 모든 HTTP 서버가 지원한다.
CGI가 내부에서 어떤 처리를 하는지는 사용자에게 보이지 않는다. 오로지 URL에 있는 cgi 혹은 ?를 통해 CGI 애플리케이션이 무언가 하고 있다는 것을 알 수 있다.
서버 확장 API
서버 확장 API는 모듈을 HTTP와 직접 연결할 수 있는 더 강력한 인터페이스이다.
CGI 프로코톨은 구동 중인 HTTP 서버에 외부 인터프리터가 쉽게 접속할 수 있게 해주지만, 서버 자체의 동작을 바꾸거나 서버의 처리능력을 최고치로 끌어올리고자 할 때는 다른 접근이 필요하다.
이 이유로, 서버 확장 API가 제공되었다.
개발자가 서버의 동작을 변경하거나 다른 리소스에 대한 사용자 맞춤 인터페이스를 제공하는데 쓸 수 있는 API를 가진다.
마이크로소프트, 넷스케이프, 아파치 등의 유명한 서버 대부분 확장 API를 한 개 이상 제공한다.
4. 애플리케이션 인터페이스와 웹 서비스
애플리케이션을 연결하면서 생기는 까다로운 이슈 중 하나는, 데이터를 교환하려는 두 애플리케이션 사이에서 프로토콜 인터페이스를 맞추는 일이다.
애플리케이션이 상호 운용을 하다보면 HTTP 헤더로는 표현하기 힘든 정보를 교환해야 할 수도 있다.
HTTP 위에 프로토콜을 덧씌워 사용자 맞춤 정보를 교환하는 내용(RPC, XML 등)에 대해서는 19장에서 다뤄진다.
5. 터널
웹 터널은 HTTP의 또 다른 사용 방식이다.
HTTP 프로토콜을 지원하지 않는 애플리케이션에 HTTP 애플리케이션을 사용해 접근하는 방법을 제공한다.
HTTP 커넥션을 통해서 HTTP가 아닌 트래픽을 전송할 수 있고, 다른 프로토콜을 HTTP 위에 올릴 수 있다.
CONNECT로 HTTP 터널 커넥션 맺기
웹 터널은 HTTP의 CONNECT 메서드를 사용해 커넥션을 맺는다.
CONNECT 메서드는 클라이언트와 서버 간에 오는 데이터를 무조건 절달하기를 요청한다.
CONNECT 요청
CONNECT home.netscapt.com:443 HTTP/1.0
User-agent: Mozilla/4.0
시작줄을 제외하면 다른 HTTP 메서드와 동일하다.
요청 URI는 호스트 명이 대신하며, 콜론에 이어 포트를 기술한다.
CONNECT 응답
HTTP/1.0 200 Connection Established
Proxy-agent: Netscape-Proxy/1.1
일반적인 HTTP 응답과 달리 콘텐츠의 형식을 기술하는 Content-Type 헤더를 포함할 필요가 없다.
커넥션이 메시지를 전달하는 대신 바이트를 그대로 전달하기 때문.
SSL 터널링
SSL(Secure Sockets Layer, 보안 소켓 계층)
- SSL: 웹사이트와 브라우저 사이(또는 두 서버 사이)에 전송되는 데이터를 암호화하여 인터넷 연결을 보호하기 위한 표준 기술
웹 터널은 방화벽을 통해 암호화된 SSL 트래픽을 전달하려고 개발되었다.
SSL 같이 암호화된 프로토콜은 정보가 암호화되어 있기 때문에 낡은 방식의 프락시에서는 처리되지 않는다.
터널을 사용하면 SSL 트래픽을 HTTP 커넥션으로 전송하여 방화벽을 통과시킬 수 있다.
터널은 보안 SSL 트래픽이 방화벽을 통과하는데 유용하게 사용된다.
하지만 악의적인 트래픽이 유입되는 경로가 될 수도 있다.
터널 인증
HTTP의 다른 기능들은 터널과 함께 적절히 사용할 수 있다.
특히 프락시 인증 기능은 클라이언트가 터널을 사용할 수 있는 권한을 검사하는 용도로 터널에서 사용할 수 있다.
터널 보안에 대한 고려사항들
터널 게이트웨이는 통신하고 있는 프로토콜이 터널을 올바른 용도로 사용하고 있는지 검증할 방법이 없다.
터널의 오용을 최소화하기 위해서, 게이트웨이는 HTTPS 전용 포트인 443 같이 잘 알려진 특정 포트만을 터널링할 수 있게 허용해야 한다.
6. 릴레이
HTTP 릴레이는 HTTP 명세를 완전히 준수하지는 않는 간단한 HTTP 프락시다.
릴레이는 커넥션을 맺기 위한 HTTP 통신을 한 다음, 바이트를 맹목적으로 전달한다.
HTTP는 복잡하기에, 모든 헤더와 로직을 수행하지 않고 맹목적으로 트래픽을 전달하는 간단한 프락시를 구현하는 방식이 유용할 때가 있다.
- 단순 필터링, 진단, 콘텐츠 변환 등에 사용
그러나 이는 심각한 상호 운용 문제를 가지고 있기 때문에 주의해야 한다.
맹목적 릴레이가 Connection 헤더를 제대로 처리하지 못해서 keep-alive 커넥션이 행(hang)에 걸릴 수 있다.
위와 같은 위험을 예방하기 위해 HTTP를 제대로 준수하는 프락시를 사용하는게 좋다.