8장 통합점: 게이트웨이, 터널, 릴레이
1. 게이트웨이
- 복잡한 리소스들을 한 개의 어플리케이션으로만 처리할 수 없다는 문제를 해결하기 위해서 만들었다.
- 리소스와 애플리케이션을 연결하는 역할을 한다.
- 요청을 받고 응답을 보내는 포털 같이 동작하는데, 동적인 콘텐츠를 생성하거나 데이터베이스에 질의를 보낼 수 있다.
- HTTP 트래픽을 다른 프로토콜로 자동으로 변환하여, HTTP 클라이언트가 다른 프로토콜을 알 필요 없이 서버에 접속할 수 있게 한다.
2. 프로토콜 게이트웨이
- 게이트웨에서 HTTP 트래픽을 바로 보낼 수 있다.
- 브라우저에 명시적으로 게이트웨이를 설정하여 자연스럽게 트래픽이 게이트웨이를 거쳐가게 하거나, 게이트웨이를 대리 서버(리버스 프락시)로 설정할 수 있다.
3. 리소스 게이트웨이
- 일반적으로 애플리케이션 서버는 목적지 서버와 게이트웨이를 한 개의 서버로 결합한다.
3.1 공용 게이트웨이 인터페이스
- 공용 게이트웨이 인터페이스(CGI)는 최초의 서버 확장이자 지금까지도 가장 널리 쓰이는 서버 확장이다.
- CGI 애플리케이션이 서버와 분리되면서 다양한 언어로 구현되며, 거의 모든 HTTP서버가 지원한다.
- CGI가 내부에서 어떤 처리를 하는지 사용자에게 보이지 않고, 내부적으로 일반적인 요청을 만든다.
3.2 서버 확장 API
- 서버 개발자는 웹 개발자가 자신의 모듈을 HTTP와 직접 연결할 수 있는 강력한 인터페이스인 서버 확장 API를 제공한다.
- 확장 API는 프로그래머가 자신의 코드를 서버에 연결하거나 서버의 컴포넌트를 자신이 만든 것으로 교체해버릴 수 있게 한다.
4. 애플리케이션 인터페이스와 웹 서비스
- 애플리케이션을 연결하면서 데이터를 교환하려는 두 애플리케이션 사이에서 프로토콜 인터페이스를 맞추는 일이 가장 까다로운 이슈이다.
- 웹 애플리케이션이 서로 통신하는데 사용할 표준과 프로토콜 집합을 개발하였다.
- 웹 서비스는 SOAP를 통해 XML을 사용하여 정보를 교환한다.
5. 터널
- HTTP 프로토콜을 지원하지 않는 애플리케이션에 HTTP 애플리케이션을 사용해 접근하는 방법을 제공한다.
- HTTP 커넥션을 통해서 HTTP가 아닌 트래픽을 전송할 수 있고, 다른 프로토콜을 HTTP 위에 올릴 수 있다.
- 주로 HTTP 커넥션 안에 HTTP가 아닌 트래픽을 얹기 위해서 사용한다.
5.1 CONNECT로 HTTP 터널 커넥션 맺기
- 웹 터널은 HTTP의 CONNECT 메서드를 사용해 커넥션을 맺는다.
- CONNECT 메서드는 터널 게이트웨이가 임의의 목적 서버와 포트에 TCP 커넥션을 맺고 클라이언트와 서버 간에 오는 데이터를 무조건 전달하기를 요청한다.
CONNECT 요청
시작줄을 제외하고는 다른 HTTP 메서드와 같다.
각 행은 CRLF로 끝나고, 헤더 목록의 끝은 빈 줄의 CRLF로 끝난다.
CONNECT home.netscape.com:443 HTTP/1.0
User-agent: Mozilla/4.0
CONNECT 응답
클라이언트는 요청을 전송한 다음, 게이트웨이의 응답을 기다린다.
커넥션이 메시지를 전달하는 대신 바이트를 그대로 전달하기 때문에 콘텐츠의 형식을 기술하는
Content-Type헤더를 포함할 필요가 없다.HTTP/1.0 200 Connection Established
Proxy-agent: Netscape-Proxy/1.1
5.2 데이터 터널링, 시간, 커넥션 관리
- 터널을 통해 전달되는 데이터는 게이트웨이에서 볼 수 없어서, 게이트웨이는 패킷의 순서나 흐름에 대한 어떤 가정도 할 수 없다.
- 게이트웨이는 커넥션이 맺어지는 대로 헤더를 포함해서 읽어들인 모든 데이터를 서버에 전송해야 한다.
- 터널의 어느 부분이든 커넥션이 끊어지면, 그 곳으로부터 온 데이터는 반대편으로 전달되고, 그 다음 커넥션이 끊어졌던 터널의 끝단 반대편의 커넥션도 프락시에 의해서 끊어진다.
5.3 SSL 터널링
- 웹 터널은 방화벽을 통해서 암호화된 SSL 트래픽을 전달하려고 개발되었다.
- SSL 트래픽을 HTTP 커넥션으로 전송하여 80포트의 HTTP만을 허용하는 방화벽을 통과 시킨다.
5.4 SSL 터널링 vs HTTP/HTTPS 게이트웨이
- HTTPS 프로토콜은 다른 프로토콜과 같은 방식으로 게이트웨이를 통과할 수 있다.
- 게이트웨이가 FTP를 처리하는 방식과 같다.
단점
- 클라이언트-게이트웨이 사이에는 보안이 적용되지 않은 일반 HTTP 커넥션이 맺어져 있다.
- 프락시가 인증을 담당하고 있기 때문에, 클라이언트는 원격 서버에 SS?L 클라이언트 인증을 할 수 없다.
- 게이트웨이는 SSL을 완벽히 지원해야 한다.
5.5 터널 보안에 대한 고려사항들
- 터널 게이트웨으는 통신하고 있는 프로토콜이 터널을 올바른 용도로 사용하고 있는지 검증할 방법이 없다.
- 터널의 오용을 최소화하기 위해서, 게이트웨이는 HTTPS 전용 포트인 443같이 잘 알려진 특정 포트만을 터널링할 수 있게 허용해야 한다.
6. 릴레이
HTTP 명세를 완전히 준수하지 않는 간단한 HTTP 프락시다.
커넥션을 맺기 위한 HTTP 통신을 한 다음, 바이트를 전달한다.
릴레이는
Connection 헤더를 제대로 처리하지 못해서 keep-alive 커넥션이행(hang)에 걸리는 문제점이 생긴다.
- 웹 클라이언트는
Connection: Keep-Alive헤더를 보내서, 릴레이에 커넥션을 맺기를 원한다는 내용의 요청 메시지를 전송한다. - 릴레이가 HTTP 요청을 받지만, Connection 헤더를 이해하지 못하므로 요청을 서버로 넘긴다.
- 웹 서버가 프락시로부터
Connection: Keep-Alive헤더를 받으면, 릴레이가 keep-alive를 하기 바란다고 잘못된 결론을 내려버린다. 이 시점부터 웹 서버는 릴레이와 함께 keep-alive 통신을 하고, keep-alive의 규칙에 맞게 동작할 것이다. - 릴레이는 웹 서버로부터 받은
Connection: Keep-Alive헤더를 포함한 응답 메시지를 클라이언트에게 전달한다. 클라이언트와 서버는 keep-alive로 통신한다고 믿고 있지만, 실제로 통신하는 릴레이는 keep-alive가 무엇인지도 모른다. - 원서버는 릴레이가 자신에게 커넥셔능ㄹ 계속 맺고 있기를 요청했다고 믿기 때문에 커넥션을 끊지 않을것이다. 따라서 릴레이는 커넥션이 끊길 때를 기다리며 계속 커넥션을 맺고
(hang)있을 것이다. - 클라이언트가 응답 메시지를 받으면, 바로 다음 요청을 keep-alive 커넥션을 통해 릴레이에게 전송한다. 브라우저는 계속 돌고 있지만, 아무런 작업도 진행되지 않는다.