Description 통합점 : 게이트웨이, 터널, 릴레이
게이트웨이: 서로 다른 프로토콜과 애플리케이션 간의 HTTP 인터페이스
애플리케이션 인터페이스: 서로 다른 형식의 웹 애플리케이션이 통신하는 데 사용한다.
터널: HTTP 커넥션을 통해서 hTTP 가 아닌 트래픽을 전송하는 데 사용한다.
릴레이: 일종의 단순한 HTTP 프락시로, 한번에 한 개의 홉에 데이터를 전달하는데 사용한다.
게이트웨이
모든 리소스를 한 개의 애플리케이션으로만 처리할 수 없다는 것은 분명해졌다. 개발자들은 이 문제에 대한 해결책으로, 인터프리터 같이 리소스를 받기 위한 경로를 안내하는 역할을 하는 게이트웨이를 고안해냈다.
게이트웨이는 리소스와 애플리케이션을 연결하는 역할을 한다.
애플리케이션은 게이트웨이에게 요청을 처리해달라고 할 수 있고, 게이트웨이는 그에 응답할 수 있다.
게이트웨이는 요청을 받고 응답을 보내는 포털 같이 동작하는데, 동적인 콘텐츠를 생성하거나 데이터베이스에 질의를 보낼 수 있다.
게이트웨이는 FTP URL을 가리키는 HTTP 요청을 받는다.
게이트웨이는 FTP 커넥션을 맺고 FTP 서버에 적절한 명령을 전송한다.
클라이언트는 적절한 HTTP 헤더와 함께 HTTP를 통해서 문서를 받는다.
클라이언트 측 게이트웨이와 서버측 게이트웨이
웹 게이트웨이는 한쪽에서는 HTTP로 통신하고 다른 한쪽에서는 HTTP가 아닌 다른 프로토콜로 통신한다.
게이트웨이는 클라이언트 측 프로토콜과 서버 측 프로토콜을 빗금(/)으로 구분해 기술한다.
서버 측 게이트웨이는 클라이언트와 HTTP로 통신하고, 서버와는 외래 프로토콜로 통신한다.
클라이언트 측 게이트웨이는 클라이언트와 외래 프로토콜로 통신하고, 서버와는 HTTP로 통신한다.
프로토콜 게이트웨이
HTTP 트래픽을 바로 보낼 수 있다. 브라우저에 명시적으로 게이트웨이를 설정하여 자연스럽게 트래픽이 게이트웨이를 거쳐 가게 하거나, 게이트웨이를 대리 서버(리버스 프락시)로 설정할 수도 있다.
일반적인 HTTP 트래픽에는 영향을 끼치지 않는다.
브라우저는 일반 HTTP 트래픽은 원 서버로 바로 보낸다.
FTP URL을 포함한 요청은 게이트웨이로 HTTP 요청을 보낸다.
게이트웨이는 클라이언트 측의 요청을 FTP 요청으로 변환하여 처리한 뒤 클라이언트에게 그 결과를 HTTP로 전송한다.
HTTP/*: 서버 측 웹 게이트웨이
서버 측 웹 게이트웨이는 클라이언트로부터 HTTP 요청이 원 서버 영역으로 들어오는 시점에 클라이언트 측의 HTTP 요청을 외래 프로토콜로 전환한다.
게이트웨이는 원 서버의 FTP 포트(21 PORT)로 FTP 커넥션을 연결하고 FTP 프로토콜을 통해서 객체를 가져온다.
게이트웨이는 다음과 같은 일을 한다.
USER와 PASS 명령을 보내서 서버에 로그인한다.
서버에서 적절한 디렉토리로 변경하기 위해 CWD 명령을 내린다.
다운로드 형식을 ASCII로 설정한다.
MDTM으로 문서의 최근 수정 시간을 가져온다.
PASV로 서버에게 수동형 데이터 검색을 하겠다고 말한다.
게이트웨이는 객체를 받는 대로 HTTP 응답에 실어서 클라이언트에 전송할 것이다.
HTTP/HTTPS: 서버 측 보안 게이트웨이
기업 내부의 모든 웹 요청을 암호화함으로써 개인 정보 보호와 보안을 제공하는데 게이트웨이를 사용할 수 있다.
클라이언트는 일반 HTTP를 사용하여 웹을 탐색할 수 있지만, 게이트웨이는 자동으로 사용자의 모든 세션을 암호화할 것이다.
HTTPS/HTTP: 클라이언트 측 보안 가속 게이트웨이
HTTPS/HTTP 게이트웨이는 보안 가속기로 유명하다.
HTTPS/HTTP 게이트웨이는 웹 서버의 앞단에 위치하고, 보이지 않는 인터셉트 게이트웨이나 리버스 프락시 역할을 한다.
이 게이트웨이는 보안 HTTPS 트래픽을 받아서 복호화하고, 웹 서버로 보낼 일반 HTTP 요청을 만든다.
이 게이트웨이는 원 서버보다 더욱 효율적으로 보안 트래픽을 복호화하는 암호화 하드웨어를 내장해서 원 서버의 부하를 줄여주기도 한다.
하지만 이 게이트웨이와 원 서버간의 암호화하지 않은 트래픽을 전송하기 때문에, 게이트웨이와 원 서버간에 있는 네트워크가 안전한지 확인이 필요하다.
리소스 게이트웨이
게이트웨이의 가장 일반적인 형태인 애플리케이션 서버는 목적지 서버와 게이트웨이를 한 개의 서버로 결합한다.
애플리케이션 서버는 HTTP를 통해서 클라이언트와 통신하고 서버 측에 있는 애플리케이션 프로그램에 연결하는 서버 측 게이트웨이다.
애플리케이션 게이트웨이에서 유명했던 최초의 API는 공용게이트웨이 인터페이스(CGI)였다.
CGI는 특정 URL에 대한 HTTP 요청에 따라 프로그램을 실행하고, 프로그램의 출력을 수집하고, HTTP 응답으로 회신하는데 웹 서버가 사용하는 표준화된 인터페이스 집합이다.
게이트웨이를 통해야 받을 수 있는 리소스 요청이 들어오면, 서버는 헬퍼 애플리케이션을 생성하여 요청을 처리한다.
헬퍼 애플리케이션은 필요한 데이터를 전달 받는다.
전달받은 데이터는 요청 전체이거나 사용자가 데이터베이스에서 실행시키려는 질의 같은 것이다.
그 다음, 바로 클라이언트로 전달할 응답이나 응답 데이터를 서버에 반환한다.
서버와 게이트웨이는 별개의 애플리케이션이기 때문에 각각 가지고 있는 책임은 분명히 나뉘어 있다.
공용 게이트웨이 인터페이스
CGI는 최초의 서버 확장이자 지금까지도 널리 쓰이는 서버 확장이다.
이는 웹에서 동적인 HTML, 신용카드 처리, 데이터베이스 질의 등을 제공하는 데 사용한다.
CGI가 내부에서 어떤 처리를 하는지는 사용자에게 보이지 않는다.
사용자의 시각에서는 CGI가 내부적으로 일반적인 요청을 만드는 것일 뿐이다.
서버 확장 API
CGI 프로토콜은 구동중인 HTTP 서버에 외부 인터프리터가 쉽게 접속할 수 있게는 해주지만, 서버 자체의 동작을
확장 API는 프로그래머가 자신의 코드를 서버에 연결하거나 서버의 컴포넌트를 자신이 만듣 것으로 교체해버릴 수 있게 하였다.
애플리케이션 인터페이스와 웹 서비스
웹 서비스는 SOAP을 통해 XML을 사용하여 정보를 교환한다.
XML은 데이터 객체를 담는 데이터를 생성하고 해석하는 방식을 제공한다.
SOAP은 HTTP 메시지에 XML 데이터를 담는 방식에 관한 표준이다.
터널
웹 터널은 HTTP 프로토콜을 지원하지 않는 애플리케이션에 HTTP 애플케이션을 사용해 접근하는 방법을 제공한다.
웹 터널을 사용하면 HTTP 커넥션을 통해서 HTTP가 아닌 트래픽을 전송할 수 있고, 다른 프로토콜을 HTTP 위에 올릴 수 있다.
웹 터널을 사용하는 이유는 HTTP 커넥션 안에 HTTP가 아닌 트래픽을 얹기 위해서이다.
CONNECT로 HTTP 터널 커넥션 맺기
터널은 HTTP의 CONNECT 메서드를 사용하녀 커넥션을 맺는다.
CONNECT 프로토콜은 HTTP/1.1 명세에 자세히는 나와있지 않다.
CONNECT 메서드는 터널 게이트웨이가 임의의 목적 서버와 포트에 TCP 커넥션을 맺고 클라이언트와 서버 간에 오는 데이터를 무조건 전달하기를 요청한다.
CONNECT 요청
CONNECT 문법은 다음과 같다.
CONNECT home.netscape.com:433 HTTP/1.0
CONNECT 응답
HTTP/1.0 200 Connection Established
데이터 터널링, 시간, 커넥션 관리
터널을 통해 전달되는 데이터는 게이트웨이에서 볼 수 없어서, 게이트웨이는 패킷의 순서나 흐름에
터널이 일단 연결되면, 데이터는 언제 어디로든 흘러가버릴 수 있다.
클라이언트는 성능을 높이기 위해 CONNECT 요청을 보낸 다음, 응답을 받기 전에 터널 데이터를 전송할 수 있다.
하지만 이는 게이트웨이가 요청에 이어서 데이터를 적절하게 처리할 수 있어야함을 전제로 깔고 있다.
게이트웨이는 네트워쿠 I/O 요청이 헤더 데이터만을 반환해줄 거라고 가정할 수 없어서, 게이트웨이는 커넥션이 맺어지는 대로 헤더를 포함해서 읽어들인 모든 데이터를 서버에 전송해야 한다.
터널의 끝단 어느 부분이든 커넥션이 끊어지면, 그 끊어진 곳으로부터 온 데이터는 반대편으로 전달된다.
그 다음 커넥션이 끊어졌던 터널의 끝단 반대편의 커넥션도 프락시에 의해서 끊어질 것이다.
커넥션이 끊긴 한쪽에 아직 전송하지 않은 데이터는 버려진다.
SSL 터널링
터널을 사용하면 SSL 트래픽을 HTTP 커넥션으로 전송하여 80 포트의 HTTP만을 허용하는 방화벽을 통과 시킬수 있다.
SSL 트래픽이 기존 프락시 방화벽을 통과할 수 있도록 HTTP 터널링 기능이 추가되었다.
이 터널링 기능은 HTTP 메시지에 암호화된 데이터를 담고 일반 HTTP 채널을 통해 데이터를 전송한다.
직접SSL 커넥션 vs 터널링된 SSL 커넥션
SSL 터널링 vs HTTP/HTTPS 게이트웨이
HTTPS 프로토콜은 원격 HTTPS 서버와 SSL 세션을 시작하는 게이트웨이를 두고 클라이언트 측의 HTTPS 트랜잭션을 수행하는 방식이다.
응답은 프락시로 받아서 복호화하고 난 후에, HTTP를 통해 클라이언트로 전송한다.
이 접근의 단점
클라이언트-게이트웨이 사이에는 보안이 적용되지 않은 일반 HTTP 커넥션이 맺어져 있다.
프락시가 인증을 담당하고 있기 때문에, 클라이언트는 원격 서버에 SSL 클라이언트을 할수 없다.
게이트웨이는 SSL을 완벽히 지원해야 한다.
이 상황에서 SSL 터널링을 사용하면, 프락시에 SSL을 구현할 필요가 없다.
SSL 세션은 클라이언트가 생성한 요청과 목적지 웹 서버간에 생성된다.
터널 인증
릴레이
HTTP 명세를 완전히 준수하지 않는 간단한 HTTP 프락시다.
릴레이는 커넥션을 맺기 위한 HTTP 통신을 한 다음, 바이트를 맹목적으로 전달한다.
단순 필터링이나 진단 혹은 콘텐츠 변환을 하는데 사용되기도 한다.
일반적인 문제중 하나는, 맹목적 릴레이가 Connection 헤더를 제대로 처리하지 못해서 keep-alive 커넥션이 행(hang)에 걸리는 것이다.
You can’t perform that action at this time.
