1. 게이트웨이
웹에 더 복잡한 리소스를 올려야 할 필요가 생기면서, 모든 리소스를 한 개의 애플리케이션으로만 처리할 수 없다는 것은 분명해졌습니다. 게이트웨이는 리소스와 애플리케이션을 연결하는 역할을 합니다. 게이트웨이는 요청을 받고 응답을 보내는 포털 같이 동작하는데, 동적인 콘텐츠를 생성하거나 데이터 베이스에 질의를 보낼 수 있습니다.
게이트웨이는 클라이언트 측 프로토콜과 서버 측 프로토콜을 빗금(/)으로 구분해 기술합니다. 우리는 게이트웨이가 어느쪽 역할을 하고 있는지 설명하기 위해서 서버 측 게이트웨이와 클라이언트 측 게이트웨이라는 용어를 사용할 것입니다.
<클라이언트_프로토콜>/<서버_프로토콜>- 서버 측 게이트웨이: 클라이언트와 HTTP로 통신하고, 서버와는 외래 프로토콜로 통신합니다.
- 클라이언트 측 게이트웨이: 클라이언트와 외래 프로토콜로 통신하고, 서버와는 HTTP로 통신합니다.
1.1. 프로토콜 게이트웨이
프락시에서 트래픽을 바로 보내는 것과 같이 게이트웨이에도 HTTP 트래픽을 바로 보낼 수 있습니다. 보통, 브라우저에 명시적으로 게이트웨이를 설정하여 자연스럽게 트래픽이 게이트웨이를 거쳐 가게 하거나, 게이트웨이를 대리 서버(리버스 프락시)로 설정할 수 있습니다.
HTTP/*: 서버 측 웹 게이트웨이
클라이언트로부터 HTTP 요청이 원 서버 영역으로 들어오는 시점에 클라이언트 측의 HTTP 요청을 외래 프로토콜로 전환
HTTP/HTTPS: 서버 측 보안 게이트웨이
기업 내부의 모든 웹 요청을 암호화함으로써 개인 정보 보호와 보안을 제공하는데 게이트웨이를 사용할 수 있습니다.
HTTPS/HTTP: 클라이언트 측 보안 가속 게이트웨이
HTTPS/HTTP 게이트웨이는 보안 가속기로 유명합니다. HTTPS/HTTP 게이트웨이는 웹 서버의 앞단에 위치하고, 보이지 않는 인터셉트 게이트웨이나 리버스 프락시 역할을 합니다
1.2. 리소스 게이트웨이
게이트웨이의 가장 일반적인 형태인 애플리케이션 서버는 HTTP를 통해서 클라이언트와 통신하고 서버 측에 있는 애플리케이션 프로그램에 연결하는 서버 측 게이트웨이입니다. 애플리케이션 서버는 게이트웨이의 애플리케이션 프로그래밍 인터페이스(Application Programming Interface, API)를 통해서 요청을 서버에서 동작하고 있는 애플리케이션에 전달합니다.
공용 게이트웨이 인터페이스(Common Gateway Interface, CGI)
공용 게이트웨이 인터페이스(CGI)는 최초의 서버 확장이자 지금까지도 가장 널리 쓰이는 서버 확장입니다. CGI는 특정 URI에 대한 HTTP 요청에 따라 프로그램을 실행하고, 프로그램의 출력을 수집하고, HTTP 응답으로 회신하는데 웹 서버가 사용하는 표준화된 인터페이스 집합입니다. 이는 웹에서 동적인 HTML, 신용카드 처리, 데이터베이스 질의 등을 제공하는 데 사용합니다.
CGI는 거의 모든 리소스 형식과 서버의 접점에 있으면서 필요에 따라 어떤 변형이든 처리해내는 단순한 기능을 제공합니다. 인터페이스는 문제가 많은 확장으로부터 서버를 보호한다는 점에서 훌륭하다고 할 수 있습니다. 하지만 이런 분리 때문에 성능 관련한 비용이 발생합니다. 모든 CGI 요청마다 새로운 프로세스를 만드는 데 따르는 부하가 꽤 크고, CGI를 사용하는 서버의 성능을 제한하여 서버 장비에 부담을 줍니다. 이 문제를 피하고자 새로운 CGI 형식인, 그 이름도 적절한 Fast CGI가 개발되었습니다. 인터페이스는 CGI와 유사하지만, 데몬으로 동작함으로써 요청마다 새로운 프로세스를 만들고 제거하면서 생기는 성능 저하 문제를 해결했습니다.
서버 확장 API
CGI 포로토콜은 구동 중인 HTTP 서버에 외부 인터프리터가 쉽게 접속할 수 있게는 해주지만, 서버 자체의 동작을 바꾸고 싶거나 서버의 처리능력을 최고치로 끌어올리고자 할 때는, 웹 개발자가 자신의 모듈을 HTTP와 직접 연결할 수 있는 강력한 인터페이스인 서버 확장 API를 제공합니다. 확장 API는 프로그래머가 자신의 코드를 서버에 연결하거나 서버의 컴포넌트를 자신이 만든 것으로 교체해버릴 수 있습니다.
1.3. 애플리케이션 인터페이스와 웹 서비스
웹 애플리케이션이 더 많은 형식의 서비스를 제공함에 따라, HTTP가 애플리케이션을 연결하는 도구로 활용할 수 있다는 게 더 확실해졌습니다. 애플리케이션을 연결하면서 생기는 까다로운 이슈 중 하나는, 데이터를 교환하려는 두 애플리케이션 사이에서 프로토콜 인터페이스를 맞추는 일입니다. 애플리케이션이 상호 운용을 하다보면 HTTP 헤더로는 표현하기 힘든 복잡한 정보를 교환해야 할 수도 있습니다.
웹 서비스는 SOAP를 통해 XML을 사용하여 정보를 교환합니다. XML(eXtensible Maekup Language)은 데이터 객체를 담는 데이터를 생성하고 해석하는 방식을 제공합니다. SOAP(Simple Object Access Protocol)은 HTTP 메시지에 XML 데이터를 담는 방식에 관한 표준입니다.
2. 터널
웹 터널은 HTTP 프로토콜을 지원하지 않는 애플리케이션에 HTTP 애플리케이션을 사용해 접근하는 방법을 제공합니다. 웹 터널을 사용하면 HTTP 커넥션을 통해서 HTTP가 아닌 트래픽을 전송할 수 있고, 다른 프로토콜을 HTTP 위에 올릴 수 있습니다.
2.1. CONNECT로 HTTP 터널 커넥션 맺기
웹 터널은 HTTP의 CONNECT 메서드를 사용하여 커넥션을 맺습니다. CONNECT 프로토콜은 HTTP/1.1 명세에 자세히 나와 있지는 않지만, 많이 구현하는 확장입니다.
CONNECT 요청
CONNECT 문법은 시작줄을 제외하고 다른 HTTP 메서드와 같습니다. 요청 URI는 호스트 명이 대신하며 콜론에 이어 포트를 기술합니다. 호스트와 포트는 다음과 같이 기술해야 합니다. 커넥션이 메시지를 전달하는 대신 바이트를 그대로 전달하기 때문에 콘텐츠의 형식을 기술하는 Content-Type 헤더를 포함할 필요가 없습니다.
CONNECT home.netscape.com:443 HTTP/1.0
User-agent: Mozila/4.02.2. 데이터 터널링, 시간, 커넥션 관리
터널을 통해 전달되는 데이터는 게이트웨이에서 볼 수 없어서, 게이트웨이는 패킷의 순서나 흐름에 대한 어떤 가정도 할 수 없습니다. 터널이 일단 연결되면, 데이터는 언제 어디로든 흘러가버릴 수 있습니다. 클라이언트는 성능을 높이기 위해 CONNECT 요청을 보낸 다음, 응답을 받기 전에 터널 데이터를 전송할 수 있습니다. 이는 서버에 데이터를 더 빨리 보내는 방법이지만, 게이트웨이가 요청에 이어서 데이터를 적절하게 처리할 수 있어야 함을 전제로 합니다. 게이트웨이는 커넥션이 맺어지는 대로 헤더를 포함해서 읽어들인 모든 데이터를 서버에 전송해야 합니다. 요청 후에 터널을 통해 데이터를 전송한 클라이언트는 인증 요구(Authentication Challenge)나 200 외의 응답이 왔을 때 요청 데이터를 다시 보낼 준비가 되어 있어야 합니다.
2.3. 터널 인증
HTTP의 다른 기능들은 터널과 함계 적절히 사용할 수 있습니다. 특히 프락시 인증 기능은, 클라이언트가 터널을 사용할 수 있는 권한을 검사하는 용도로 터널에서 사용할 수 있습니다.
2.4. 터널 보안에 대한 고려사항들
보통, 터널 게이트웨이는 통신하고 있는 포로토콜이 터널을 올바른 용도로 사용하고 있는지 검증할 방법이 없습니다. 터널의 오용을 최소화하기 위해서, 게이트웨이는 HTTPS 전용 포트인 443 같이 잘 알려진 특정 포트만을 터널링할 수 있게 허용해야 합니다.
3. 릴레이
HTTP 릴레이는 HTTP 명세를 완전히 준수하지 않는 간단한 HTTP 프락시입니다. 릴레이는 커넥션을 맺기 위한 HTTP 통신을 한 다음, 바이트를 맹목적으로 전달합니다. HTTP는 복잡하기에, 모든 헤던와 메서드 로직을 수행하지 않고 맹목적으로 트래픽을 전달하는 간단한 프락시를 구현하는 방식이 유용할 때가 있습니다. 데이터를 맹목적으로 전달하도록 구현하기는 쉽기 때문에, 단순 필터링이나 진단 혹은 콘텐츠 변환을 하는데 사용되기도 합니다. 하지만 이는 잠재적으로 심각한 상호 운용 문제를 가지고 있기 때문에 주의해서 배포해야 합니다.
4. 출처
- [HTTP 완벽 가이드 - 웹은 어떻게 동작하는가] - 프로그래밍 인사이트
