모든 리소스를 한 개의 애플리케이션으로만 처리할 수 없는 문제를 해결하기 위해
인터프리터 같이 리소스를 받기 위한 경로를 안내하는 역할을 하는 게이트웨이
를 고안해냈다.
다음은 게이트웨이의 세 가지 예시이다.
HTTP/FTP 서버 측 FTP 게이트웨이
게이트웨이는 FTP 커넥션을 맺고 FTP 서버에 적절한 명령을 전송한다.
클라이언트는 적절한 HTTP 헤더와 함께 HTTP를 통해서 문서를 받는다.
HTTPS/HTTP 클라이언트 측 보안 게이트웨이
게이트웨이는 암호화된 웹 요청을 SSL을 통해 받고, 요청을 해독해서 생성한 일반 HTTP 요청을
목적지 서버로 전달한다.
HTTP/CGI 서버 측 애플리케이션 게이트웨이
게이트웨이는 애플리케이션 서버 게이트웨이 API를 통해서 HTTP 클라이언트를 서버 측 애플리케이션 프로그램에 연결한다.
웹에서 물건을 사거나 일기예보를 보거나 주식시세를 볼 때, 사실은 애플리케이션 서버 게이트웨이를 방문하는 것이다.
웹 게이트웨이는 한쪽에서는 HTTP로 통신하고 다른 쪽에서는 HTTP가 아닌 다른 프로토콜로 통신한다.
게이트웨이는 클라이언트 측 프로토콜과 서버 측 프로토콜을 빗금(/)으로 구분해 기술한다.
(ex- HTTP/NNTP 게이트웨이)
서버 측 게이트웨이
클라이언트 측 게이트웨이
프락시에 트래픽을 바로 보내는 것과 같이 게이트웨이에도 HTTP 트래픽을 바로 보낼 수 있다.
브라우저에 명시적으로 게이트웨이를 설정하여 자연스럽게 트래픽이 게이트웨이를 거쳐 가게 하거나, 게이트웨이를
대리 서버(리버스 프락시)로 설정할 수 있다.
브라우저에 gw1.joes-hardware.com
HTTP/FTP 게이트웨이를 사용하게 설정을 하면 아래와 같이 동작한다.
서버 측 웹 게이트웨이는 클라이언트로부터 HTTP 요청이 원 서버 영역으로 들어오는 시점에
클라이언트 측의 HTTP 요청을 외래 프로토콜로 전달한다.
예를 들어, 게이트웨이는 원 서버의 FTP 포트(21 포트)로 FTP 커넥션을 연결하고 FTP 프로토콜을 통해서 객체를 가져온다.
게이트웨이는 다음의 일들을 한다.
기업 내부의 모든 웹 요청을 암호화함으로써 개인 정보 보호와 보안을 제공하는데 게이트웨이를 사용할 수 있다.
게이트웨이는 자동으로 사용자의 모든 세션을 암호화할 것이다.
애플리케이션 게이트웨이에서 유명했던 최초의 API는 공용 게이트웨이 인터페이스(Common Gateway Interface, CGI) 였다.
CGI
특정 URL에 대한 HTTP 요청에 따라 프로그램 실행, 프로그램의 출력을 수집, HTTP 응답으로 회신하는데
웹 서버가 사용하는 표준화된 인터페이스 집합
공용 게이트웨이 인터페이스(CGI)는 최초의 서버 확장이자 지금까지도 가장 널리 쓰이는 서버 확장
인터넷 커뮤니티는 각 웹 애플리케이션이 서로 통신하는데 사용할 표준과 프로토콜 집합을 개발하였다.
이 표준은 원래 웹 서비스가 독립형 웹 애플리케이션 그 자체를 의미함에도 불구하고, 그냥 그대로 웹 서비스로 불리게 되었다.
웹 서비스가 새로운 용어는 아니지만, 여기서 웹 서비스는 애플리케이션이 정보를 공유하는데 사용하는 새로운 메커니즘을 의미한다.
웹 서비스는 HTTP 같은 표준 웹 기술 위에서 개발한다.
웹 터널은 HTTP 프로토콜을 지원하지 않는 애플리케이션에 HTTP 애플리케이션을 사용해 접근하는 방법을 제공한다.
웹 터널은 HTTP의 CONNECT 메소드를 사용하여 커넥션을 맺는다.
CONNECT 메소드는 터널 게이트웨이가 임의의 목적 서버와 포트에 TCP 커넥션을 맺고 클라이언트와 서버간에
오는 데이터를 무조건 전달하기를 요청한다.
다음은 SSL 터널을 연결하기 위해 사용되는 CONNECT 순서이다.
CONNECT 요청
CONNECT home.netscape.com:443 HTTP/1.0
User-agent: Mozilla/4.0
CONNECT 응답
HTTP/1.0 200 Connection Established
Proxy-agent: Netscape-Proxy/1.1
웹 터널은 원래 방화벽을 통해서 암호화된 SSL 트래픽을 전달하려고 개발되었다.
터널을 사용하면 SSL 트래픽을 HTTP 커넥션으로 전송하여 80 포트의 HTTP만을 허용하는 방화벽을 통과시킬 수 있다.
SSL 트래픽이 기존 프락시 방화벽을 통과할 수 있도록 HTTP에 터널링 기능이 추가되었다.
이 터널링 기능은 HTTP 메시지에 암호화된 날 데이터를 담고 일반 HTTP 채널을 통해 데이터를 전송한다.
터널은 HTTP가 아닌 트래픽이 포트를 제한하는 방화벽을 통과할 수 있게 해줘서 보안 SSL 트래픽이 방화벽을
통과하는 데 유용하게 사용될 수 있다.
하지만 터널은 악의적인 트래픽이 사내로 유입되는 경로가 될 수도 있다.
HTTPS 프로토콜(SSL상의 HTTP)은 다른 프로토콜과 같은 방식으로 게이트웨이를 통과할 수 있다.
원격 HTTPS 서버와 SSL 세션을 시작하는 게이트웨이를 두고 클라이언트 측의 HTTPS 트랜젝션을 수행하는 방식이다.
응답은 프락시가 받아서 복호화하고 난 후, HTTP를 통해 클라이언트로 전송한다.
위 접근은 몇 가지 단점이 존재한다.
이 상황에서 SSL 터널링을 사용하면, 프락시에 SSL을 구현할 필요가 없다.
프락시 서버는 트랜젝션의 보안에는 관여하지 않고 암호화된 데이터를 그대로 터널링 할 뿐이다.
HTTP의 다른 기능들은 터널과 함께 적절히 사용할 수 있다.
특히 프락시 인증 기능은, 클라이언트가 터널을 사용할 수 있는 권한을 검사하는 용도로 터널에서 사용할 수 있다.
터널의 오용을 최소화하기 위해, 게이트웨이는 HTTPS 전용 포트인 443 같이 잘 알려진 특정 포트만을 터널링할 수 있게 허용해야 한다.
HTTP 릴레이는 HTTP 명세를 완전히 준수하지는 않는 간단한 HTTP 프락시이다.
단순 맹목적 릴레이를 구현하는데 관련된 더 일반적인 문제 중 하나는, 맹목적 릴레이가 Connction 헤더를
제대로 처리하지 못해서 keep-alive 커넥션 행에 걸리는 것이다.
자세히 설명하자면 다음과 같다.
웹 클라이언트 -> Connection: Keep-Alive
헤더를 보내서, 릴레이에 keep-alive 커넥션 요청 메시지 전송.
keep-alive 채널에 대한 요청이 받아들여졌는지 확인하기 위해 응답을 기다린다.
릴레이가 HTTP 요청을 받지만, Connection 헤더를 이해하지 못하므로, 요청을 서버로 넘긴다.
하지만 Connection 헤더는 홉과 홉 사이에만 사용하는 헤더다. 단일 전송 링크만을 지원하고 체인을 따라 전달할 수 없다.
릴레이 된 HTTP 요청이 웹 서버에 도착. 웹 서버는 아무것도 모른채 keep-alive 통신에 동의하고
Connection: Keep-Alive 응답 헤더로 응답한다.
이 시점부터 웹 서버는 릴레이와 함께 keep-alive 통신을 하고, keep-alive의 규칙에 맞게 동작할 것이다.
하지만 릴레이는 keep-alive에 대해 모른다.
릴레이는 웹 서버로 부터 받은 헤더를 포함한 응답을 클라이언트에게 전달한다.
클라이언트는 릴레이가 keep-alive 통신에 동의했다고 추측한다.
서버, 클라이언트가 keep-alive 통신을 하고 있다고 믿지만, 실제로 통신하는 릴레이는 keep-alive를 모르는 상태
릴레이는 keep-alive를 모르기 때문에, 원 서버가 커넥션을 끊기를 기다리며 받은 데이터를 전부
클라이언트에게 전달한다.
원 서버는 릴레이가 자신에게 커넥션을 맺고 있기를 요청했다고 생각하여 커넥션을 끊지 않는다.
릴레이는 커넥션이 끊길 때를 기다리며 계속 커넥션을 맺고(hang) 있다.
클라이언트가 응답을 받으면, 바로 다음 요청을 keep-alive 커넥션을 통해 릴레이에게 전송한다.
단순한 릴레이는 같은 커넥션으로 또 다른 요청이 오는 것을 예측하지 못한다.
브라우저는 계속 돌고 있지만, 아무런 작업도 진행되지 않는다.
이러한 문제를 예방하기 위해 릴레이를 조금 똑똑하게 만드는 방법도 있지만, 여러 문제를 예방하기 위해서
HTTP를 제대로 준수하는 프락시를 사용하는게 좋다.