이번 장에서 살펴볼 주제
- 게이트웨이 : 서로 다른 프로토콜과 애플리케이션 간의 HTTP 인터페이스다.
- 애플리케이션 인터페이스 : 서로 다른 형식의 웹 애플리케이션이 통신하는 데 사용한다.
- 터널 : HTTP 커넥션을 통해서 HTTP가 아닌 트래픽을 전송하는데 사용한다.
- 릴레이 : 일종의 단순한 HTTP 프락시로, 한 번에 한 개의 홉에 데이터를 전달하는데 사용한다.
게이트웨이
웹이 더 복잡한 리소스를 올려야 할 필요가 생기면서, 모든 리소스를 한 개의 애플리케이션으로만 처리할 수 없습니다. 그래서 개발자들은 인터프리터 같이 리소스를 받기 위한 경로를 안내하는 역할을 하는 게이트웨이를 고안해냈습니다. 게이트웨이는 리소스와 애플리케이션을 연결하는 역할을 수행합니다.
클라이언트 측 게이트웨이와 서버 측 게이트웨이
웹 게이트웨이는 한쪽에서는 HTTP로 통신하고 다른 한쪽에서는 HTTP가 아닌 다른 프로토콜로 통신합니다. 게이트웨이는 클라이언트 측 프로토콜과 서버측 프로토콜을 빗금(/)으로 구분합니다.
- 서버 측 게이트웨이 : 클라이언트와 HTTP로 통신하고, 서버와는 외래 프로토콜로 통신합니다.
- 클라이언트 측 게이트웨이 : 클라이언트와 왜래 프로토콜로 통신하고, 서버와는 HTTP로 통신합니다.
프로토콜 게이트웨이
프락시에 트래픽을 바로 보내는 것과 같이 게이트웨이에도 HTTP 트래픽을 바로 보낼 수 있습니다. 서버 프로토콜 변환기, 서버 측 보안 게이트웨이, 클라이언트 측 보안 게이트웨이, 애플리케이션 서버 같은 게이트웨이의 종류를 알아보겠습니다.
HTTP/* : 서버 측 웹 게이트웨이
서버 측 웹 게이트웨이는 클라이언트로부터 HTTP 요청이 원 서버 영역으로 들어오는 시점에 클라이언트 측의 HTTP 요청을 외래 프로토콜로 전환합니다. 게이트웨이는 객체를 받는 대로 HTTP 응답에 실어서 클라이언트에 전송할 것입니다.
HTTP/HTTPS : 서버 측 보안 게이트웨이
기업 내부의 모든 웹 요청을 암호화함으로써 개인 정보 보호와 보안을 제공하는데 게이트웨이를 사용할 수 있습니다. 클라이언트는 일반 HTTP를 사용하여 웹을 탐색할 수 있지만, 게이트웨이는 자동으로 사용자의 모든 세션을 암호화할 것입니다.
HTTPS/HTTP : 클라아인터 측 보안 가속 게이트웨이
HTTPS/HTTP 게이트웨이는 보안 가속기로 유명합니다. 웹 서버의 앞단에 위치하고 있으며, 보이지 않는 인터셉트 게이트웨이나 리버스 프락시 역할을 합니다. 이 게이트웨이는 보안 HTTPS 트래픽을 받아서 복호화하고, 웹 서버로 보낼 일반 HTTP 요청을 만듭니다.
리소스 게이트웨이
게이트웨이의 가장 일반적인 형태인 애플리케이션 서버는 목적지 서버와 게이트웨이를 한 개의 서버로 결합합니다. 애플리케이션 서버는 HTTP를 통해서 클라이언트와 통신하고 서버 측에 있는 애플리케이션 프로그램에 연결하는 서버 측 게이트웨이입니다.
공용 게이트웨이 인터페이스
공용 게이트웨이 인터페이스(CGI)는 최초의 서버 확장이자 지금까지도 가장 널리 쓰이는 서버 확장입니다. 이는 동적 HTML, 신용카드 처리, 데이터베이스 질의 등을 제공하는데 사용합니다.
그리고 단순하기 때문에 거의 모든 HTTP 서버가 지원합니다. CGI가 내부에서 어떤 처리를 하는지는 사용자에게 보이지 않으며 사용자의 시각에서는 CGI가 내부적으로 일반적인 요청을 만드는 것일 뿐입니다.
그리고 서버와 CGI 애플리케이션 간에 진행되는 처리 단계를 감춥니다. 그래서 CGI 애플리케이션이 뭔가를 하고 있다는 것을 알 수 있는 유일한 단서는 URL에 있는 'cgi' 혹은 "?" 같은 것입니다.
이런 점에서 CGI는 훌륭하다고 보일 수 있지만, 그럴 수도 그렇지 않을 수도 있습니다.
CGI는 거의 모든 리소스 형식과 서버의 접점에 있으면서 필요에 따라 어떤 변형이든 처리해내는 단순한 기능을 제공합니다. 인터페이스는 문제가 많은 호가장으로부터 서버를 보호한다는 점에서 훌륭하다고 할 수 있습니다.
하지만 이런 분리 때문에 모든 CGI 요청마다 새로운 프로세스를 만드는 데 따르는 부하가 크고, 서버의 성능을 제한하며 장비에 부담을 주기 때문에 성능 관련한 비용이 발생합니다.
서버 확장 API
CGI 프로토콜을 구동 중일 때 서버 자체의 동작을 바꾸고 싶거나 서버의 처리능력을 최고치로 끌어올릴 때는 어떻게 해야할까요? 바로 웹 개발자가 자신의 모듈을 HTTP와 직접 연결할 수 있는 강력한 인터페이스인 서버 확장 API를 사용하는 것입니다. 이는 프로그래머가 자신의 코드를 서버에 연결하거나 서버의 컴포넌트를 자신이 만든 것으로 교체해버릴 수 있게 합니다.
애플리케이션 인터페이스와 웹 서비스
애플리케이션을 연결하면서 생기는 까다로운 이슈 중 하나는, 데이터를 교환하려는 두 애플리케이션 사이에서 프로토콜 인터페이스를 맞추는 일입니다. 웹 서비스는 SOAP을 통해 XML을 사용하여 정보를 교환합니다. XML은 데이터 객체를 담는 데이터를 생성하고 해석하는 방식을 제공합니다. SOAP는 HTTP 메시지에 XML 데이터를 담는 방식에 관한 표준입니다.
터널
웹 터널은 HTTP 프로토콜을 지원하지 않는 애플리케이션에 HTTP 애플리케이션을 사용해 접근하는 방법을 제공해줍니다. 웹 터널을 사용하면 HTTP 커넥션을 통해서 HTTP가 아닌 트래픽을 전송할 수 있고, 다른 프로토콜을 HTTP 위에 올릴 수 있습니다.
CONNECT로 HTTP 터널 커넥션 맺기
웹 터널은 HTTP의 CONNECT 메소드를 사용하여 커넥션을 맺습니다. CONNECT 메소드는 터널 게이트웨이가 임의의 목적 서버와 포트에 TCP 커넥션을 맺고 클라이언트와 서버 간에 오는 데이터를 무조건 전달하기를 요청합니다. 전달 과정은 아래와 같습니다.
- 클라이언트는 게이트웨이에 터널을 연결하려고 CONNECT 요청을 보냅니다. CONNECT 메소드는 TCP 커넥션을 위해 게이트웨이에 터널 연결을 요청합니다.
- TCP 커넥션이 맺어지면 게이트웨이는 클라이언트에게 200 상태를 전달합니다.
- 터널이 연결되고 데이터가 전달됩니다.
CONNECT 요청
요청 URI는 호스트 명이 대신하여 콜론에 이어 포트를 기술합니다.
CONNECT xxxx:443 HTTP/1.0
User-agent: xxxCONNECT 응답
클라이언트는 요청을 전송한 다음, 게이트웨이의 응답을 기다립니다. 일반 HTTP 메시지와 같이 200 응답 코드는 성공을 뜻합니다.
HTTP/1.0 200 Connection Established일반적인 응답과 달리 Content-Type 헤더를 포함할 필요는 없습니다.
데이터 터널링, 시간, 커넥션 관리
터널을 통해 전달되는 데이터는 게이트웨이에서 볼 수 없어서, 게이트웨이는 패킷의 순서나 흐름에 대한 어떤 가정도 할 수 없습니다. 터널이 일단 연결되면 데이터는 언제 어디로든 흘러가버릴 수 있습니다. 게이트웨이는 네트워크 I/O 요청이 헤더 데이터만을 반환해줄 거라고 가정할 수 없어서, 게이트웨이는 커넥션이 맺어지는 대로 헤더를 포함해서 읽어들인 모든 데이터를 서버에 전송해야합니다.
요청 후 터널을 통해 데이터를 전송한 클라이언트는 인증요구나 200 외의 응답이 왔을 때 요청 데이터를 다시 보낼 준비가 되어있어야 합니다. 터널의 끝단 어느 부분이든 커넥션이 끊어지면, 그 끊어진 곳으로부터 온 데이터는 반대편으로 전달됩니다. 그렇게 되면 반대편 커넥션도 프락시에 의해 끊어질 것입니다. 이러면 데이터는 전송되지 않게 되는데 버려지게 됩니다.
SSL 터널링
웹 터널은 원래 방화벽을 통해서 암호화된 SSL 트래픽을 전달하려고 개뱔되었습니다. 터널을 사용하면 SSL 트래픽을 HTTP 커넥션으로 전송하여 80 포트의 HTTP만을 허용하는 방화벽을 통과시킬 수 있습니다. SSL 트래픽이 기존 프락시 방화벽을 통과할 수 있도록 HTTP에 터널링 기능이 추가되었습니다. 이 터널링 기능은 HTTP 메시지에 암호화된 날 데이터를 담고 일반 HTTP 채널을 통해 데이터를 전송합니다.
SSL 터널링 vs HTTP/HTTPS 게이트웨이
HTTPS 프로토콜은 다른 프로토콜과 같은 방식으로 게이트웨이를 통과할 수 있습니다. 원격 HTTPS 서버와 SSL 세션을 시작하는 게이트웨이를 두고 클라이언트 측의 HTTPS 트랜잭션을 수행하는 방식입니다. 응답은 프락시가 받아서 복호화하고 난 후에 HTTP를 통해 클라이언트로 전송합니다. 이 접근은 단점이 있습니다.
- 클라이언트-게이트웨이 사이에는 보안이 적용되지 않은 일반 HTTP 커넥션이 맺어져 있습니다.
- 프락시가 인증을 담당하고 있기 때문에, 클라이언트는 원격 서버에 SSL 클라이언트 인증을 할 수 없습니다.
- 게이트웨이는 SSL을 완벽히 지원해야합니다.
터널 인증
프락시 인증 기능은 클라이언트가 터널을 사용할 수 있는 권한을 검사하는 용도로 터널에서 사용할 수 있습니다.
터널 보안에 대한 고려사항들
터널 게이트웨이는 통신하고 있는 프로토콜이 터널을 올바른 용도로 사용하고 있는지 검증할 방법이 없습니다. 때문에 터널의 오용을 최소화 하기 위해서, 게이트웨이는 HTTPS 전용 포트인 443 같이 잘 알려진 특정 포트만을 터널링 할 수 있게 허용해야 합니다.
릴레이
HTTP 릴레이는 HTTP 명세를 완전히 준수하지는 않는 간단한 HTTP 프락시입니다. 릴레이는 커넥션을 맺기 위한 HTTP 통신을 한 다음, 바이트를 맹목적으로 전달합니다. 여기서 일어나는 문제는 맹목적 릴레이가 Connection 헤더를 제대로 처리하지 못해서 keep-alive 커넥션이 행(hang)에 걸리는 것입니다. 이러한 위험을 예방하기 위해서 HTTP를 제대로 준수하는 프락시를 사용하는게 좋습니다.