8.1 게이트웨이
게이트웨이는 리소스와 애플리케이션을 연결하는 역할을 한다.
애플리케이션은 게이트웨이에게 요청을 처리해달라고 할 수 있고, 게이트웨이는 그에 응답할 수 있다. 동적인 콘텐츠를 생성하거나 데이터베이스에 질의를 보낼 수 있다.
또한 HTTP 트래픽을 다른 프로토콜로 자동 변환하여, HTTP 클라이언트가 다른 프로토콜을 알 필요 없이 서버에 접속할 수 있게 하기도 한다.
8.1.1 클라이언트 측 게이트웨이와 서버 측 게이트웨이
웹 게이트웨이는 한쪽에서는 HTTP로 통신하고, 다른 한쪽에서는 HTTP가 아닌 다른 프로토콜로 통신한다.
또한 게이트웨이는 클라이언트와 서버 프로토콜을 다음과 같이 빗금(/)으로 구분해 기술한다.
<클라이언트 프로토콜>/<서버 프로토콜>
8.2 프로토콜 게이트웨이
브라우저에서 명시적으로 게이트웨이를 설정하여 자연스럽게 트래픽이 게이트웨이를 거쳐 가게 하거나, 게이트웨이를 대리 서버(리버스 프락시)로 설정할 수 있다.
8.2.1 HTTP/*: 서버 측 웹 게이트웨이
서버 측 웹 게이트웨이는 클라이언트로부터 HTTP 요청이 원 서버 영역으로 들어오는 시점에 클라이언트 측의 HTTP 요청을 외래 프로토콜로 전환한다.
예를 들어 HTTP/FTP 게이트웨이는 HTTP 요청을 FTP 요청으로 변환한다.
8.2.2 HTTP/HTTPS: 서버 측 보안 게이트웨이
기업 내부의 모든 웹 요청을 암호화함으로써 개인 정보 보호와 보안을 제공할 수 있다.
클라이언트는 일반 HTTP를 사용하지만, 게이트웨이는 자동으로 사용자의 모든 세션을 암호화한다.
8.2.3 HTTPS/HTTP: 클라이언트 측 보안 가속 게이트웨이
HTTPS/HTTP 게이트웨이는 웹 서버 앞단에 위치하여 보이지 않는 인터셉트 게이트웨이나 리버스 프락시 역할을 한다.
8.3 리소스 게이트웨이
게이트웨이의 가장 일반적인 형태인 애플리케이션 서버는 목적지 서버와 게이트웨이를 한 개의 서버로 결합한다. 애플리케이션 서버는 HTTP를 통해서 클라이언트와 통신하고 서버 측에 있는 애플리케이션 프로그램에 연결하는 서버 측 게이트웨이다.
애플리케이션 게이트웨이에서 유명했던 최초의 API는 공용 게이트웨이 인터페이스(Common Gateway Interface, CGI)였다.
CGI는 특정 URL에 대한 hTTP 요청에 따라 프로그램을 실행하고, 프로그램의 출력을 수집하고, HTTP 응답으로 회신하는데 웹 서버가 사용하는 표준화 된 인터페이스 집합이다.
8.3.1 공용 게이트웨이 인터페이스
CGI는 최초의 서버 확장이자 지금까지도 널리 쓰이는 서버 확장이다. 웹에서 동적인 HTML, 신용카드 처리, 데이터베이스 질의 등을 제공하는 데 사용한다.
8.3.2 서버 확장 API
CGI는 구동중인 HTTP 서버에 외부 인터프리터가 쉽게 접속할 수 있게 해주지만, 서버 자체의 동작을 바꾸고 싶거나 서버의 처리 능력을 최고치로 올리기 위해서는 서버 확장 API가 필요하다.
이런 확장 API는 프로그래머가 자신의 코드를 서버에 연결하거나 서버의 컴포넌트를 자신이 만든 것으로 교체해버릴 수 있다.
8.4 애플리케이션 인터페이스와 웹 서비스
애플리케이션을 연결하면서 생기는 까다로운 이슈 중 하나는, 데이터를 교환하려는 두 애프리케이션 사이에서 프로토콜 인터페이스를 맞추는 일이다.
웹 서비스는 SOAP를 통해 XML을 사용하여 정보를 교환한다.
- SOAP(Simple Object Access Protocol): HTTP 메시지에 XML 데이터를 담는 방식에 관한 표준
- XML(eXtensible Markup Language): 데이터 객체를 담는 데이터를 생성하고 해석하는 방식 제공
8.5 터널
웹 터널은 HTTP 프로토콜을 지원하지 않는 애플리케이션에 HTTP 애플리케이션을 사용해 접근하는 방법을 제공한다.
웹 터널을 사용하는 가장 일반적인 이유는 HTTP 커텍션 안에 HTTP가 아닌 트래픽을 얹기 위해서다. 따라서 이것을 사용하면 웹 트래픽만을 허락하는 방화벽이 있더라도 HTTP가 아닌 트래픽을 전송할 수 있다.
8.5.1 CONNECT로 HTTP 커널 커넥션 맺기
CONNECT 메서드는 터널 게이트웨이가 임의의 목적 서버와 포트에 TCP 커넥션을 맺고 클라이언트와 서버 간에 오는 데이터를 무조건 전달하기를 요청한다.
8.5.2 데이터 터널링, 시간, 커넥션 관리
클라이언트는 성능을 높이기 위해 CONNECT 요청을 보낸 후, 응답을 받기 전에 터널 데이터를 전송할 수 있다. 이는 서버에 데이터를 더 빨리 보내는 방법이지만, 게이트웨이가 요청에 이어서 데이터를 적절하게 처리할 수 있어야 함을 전제로 한다.
터널의 끝단 어느 부분이든 커넥션이 끊어지면, 끊어진 곳으로부터 온 데이터는 반대편으로 전달된다. 그 다음 커넥션이 끊어졌던 터널의 끝단 반대편의 커넥션도 프락시에 의해서 끊어질 것이다. 컨넥션이 끊긴 한쪽에 아직 전송하지 않은 데이터는 버려진다.
8.5.3 SSL 터널링
SSL 트래픽이 기존 프락시 방화벽을 통과할 수 있도록 HTTP에 터널링 기능이 추가되었다. 이 터널링 기능은 HTTP 메시지에 암호화된 날 데이터를 담고 일반 HTTP 채널을 통해 데이터를 전송한다.
8.5.4 SSL 터널링 vs HTTP/HTTPS 게이트웨이
HTTP/HTTPS의 단점
- 클라이언트-게이트웨이 사이에는 보안이 적용되지 않은 일반 HTTP 커넥션이 맺어져 있다.
- 프락시가 인증을 담당하고 있기 때문에 클라이언트는 원격 서버에 SSL 클라이언트 인증을 할수 없다.
- 게이트웨이는 SSL을 완벽히 지원해야 한다.
SSL 터널링을 사용하면 프락시에 SSL을 구현할 필요가 없다. SSL 세션은 클라이언트가 생성한 요청과 보안이 적용된 웹 서버간에 생성된다. 프락시 서버는 트랙잭션의 보안에는 관여하지 않고 암호화된 데이터를 그대로 터널링 한다.
8.6 릴레이
HTTP 릴레이는 HTTP 명세를 완전히 준수하지는 않는 간단한 HTTP 프락시다. 릴레이는 커넥션을 맺기 위한 HTTP 통신을 한 다음 바이트를 맹목적으로 전달한다.
HTTP는 복잡하기에 모든 헤더와 메서드 로직을 수행하지 않고 맹목적으로 트래픽을 전달하는 간단한 프락시를 구현하는 방식이 유용할 때가 있다. 데이터를 맹목적으로 전달하도록 구현하기는 쉽기 때문에 단순 필터링이나 진단 혹은 콘텐츠 변환을 하는데 사용되기도 한다.
하지만 이는 잠재적으로 심각한 상호 운용 문제를 가지고 있기 때문에 주의해서 배포해야 한다.
📌 데이빗 고울리, 브라이언 토티, 마조리 세이어, 세일루 레디, 안슈 아가왈 공저 이응준, 정상일 공역, 『HTTP 완벽 가이드: 웹은 어떻게 동작하는가』, 인사이트(2014)
