8. 통합점: 게이트웨이, 터널, 릴레이

• 브라우저 같은 HTTP 애플리케이션은 인터넷상의 통일된 콘텐츠 접근 방법을 제공함.

• HTTP는 웹에 있는 모든 리소스에 대한 프로토콜로 사용됐으며, 애플리케이션 간에 서로 다른 프로토콜을 상호 운용하는 용도로 사용함.

게이트웨이

• 웹에 더 복잡한 리소스를 올려야 할 필요가 생기면서, 모든 리소스를 한 개의 애플리케이션으로만 처리할 수 없다는 문제를 해결하기 위해 게이트웨이가 생김.

• 게이트웨이는 리소스와 애플리케이션을 연결하는 역할.

• 리소스를 받기위한 경로를 연결함.

• 요청을 받고 응답을 보내는 포털 같이 동작하는데, 동적인 콘텐츠를 생성하거나 데이터 베이스에 질의를 보낼 수 있음.

• HTTP 트래픽을 다른 프로토콜로 자동 변환하여, HTTP 클라가 다른 프로토콜을 알 필요 없이 서버에 접속할 수 있게 함.

1. 게이트웨이는 FTP URL을 가리키는 HTTP 요청을 받음. 게이트웨이는 FTP 커넥션을 맺고 FTP 서버에 적절한 명령을 전송함. 클라는 HTTP를 통해 적절한 HTTP 헤더를 포함한 문서를 받음.

2. 암호화된 웹 요청을 SSL을 통해 받고, 요청을 해독(게이트웨이에 서버 인증서가 설치되어 있어야 함.)해서 생성한 일반 HTTP 요청을 목적지 서버로 전달함. 특히 보안쪽은 서버에 고성능 암호화 기능을 제공할 목적으로 서버 앞단에 위치시킴.

3. 게이트웨이는 서버 게이트웨이 API를 통해 HTTP 클라를 서버 측 애플리케이션에 연결함.

• 웹 게이트웨이는 한쪽에서는 HTTP로 통신하고, 다른 한쪽에서는 HTTP가 아닌 다른 프로토콜로 통신함.

• 통신 설정 방법
• 브라우저에 명시적으로 게이트웨이를 설정하여 트래픽이 게이트웨이를 거쳐 가게 하거나, 대리 서버(리버스 프락시)로 설정할 수 있음.
• ex) HTTP/FTP 게이트웨이로 FTP URL을 포함한 요청은 설정한 주소의 게이트웨이로 HTTP 요청을 보냄(특정 프로토콜에 게이트웨이 설정).

• 클라이언트와 서버 프로토콜을 다음과 같이 빗금(/)으로 구분함.
• ex) 게이트웨이가 HTTP 클라와 NNTP 뉴스 서버 사이에 있다면 HTTP/NNTP 게이트웨이임.

프로토콜 게이트웨이

• HTTP/*: 서버 측 웹 게이트웨이
• HTTP 요청이 원 서버 영역으로 들어오는 시점에 클라이언트 측의 HTTP 요청을 외래 프로토콜로 전환.

• HTTP/HTTPS: 서버 측 보안 게이트웨이
• 게이트웨이는 일반 클라이언트의 HTTP 요청을 사내망과 같은 환경에서 모두 암호화하여 개인정보 보호와 보안을 제공하는 역할을 수행.

• HTTPS/HTTP: 서버 측 보안 가속 게이트웨이
• 게이트웨이는 웹 서버의 앞단에 위치하여 HTTPS 요청을 복호화하고, 웹 서버에는 HTTP 요청을 보내는 역할을 수행.
• 이 경우 게이트웨이와 원 서버 사이에 암호화하지 않은 트래픽을 전송하므로 네트워크 안전성이 보장되어야 함.

리소스 게이트웨이

• 게이트웨이의 가장 일반적인 형태인 애플리케이션 서버는 목적지 서버와 게이트웨이를 한 개의 서버로 결합함.

• 클라가 HTTP를 사용하여 애플리케이션 서버로 연결하면, 서버로부터 파일이 전송되는 대신, 애플리케이션 서버는 게이트웨이 API를 통해 요청을 서버에서 동작하고 있는 애플리케이션에 전달함.

• 공용 게이트웨이 인터페이스(CGI, Common Gateway Interface)
• CGI는 최초의 서버 확장이자 지금까지도 가장 널리 쓰이는 서버 확장임.
• 단순해서 거의 모든 HTTP 서버가 지원함.
• 동적인 HTML, 데이터베이스 질의와 같은 기능들을 제공.
• CGI 내부 동작을 사용자로부터 숨김으로써 다양한 확장으로부터 서버를 보호함.
• 클라가 CGI 애플리케이션 무언가 하고 있다는 것을 알 수 있는 유일한 단서는 URL에 있는 cgi, ?같은 것들임.
• 문제가 많은 확장으로부터 서버를 보호한다는 장점이 있지만 요청 당 프로세스 생성에 대한 부하로 성능 저하가 있다는 문제가 있었음.
• 만약 문제가 있는 확장이 서버 자체에 들어가면, 에러를 발생시키고 서버를 뻗게 함.
• 하지만 데몬 프로세스로 동작하는 Fast CGI 등장함으로 문제 해결.

• 서버 확장 API
• 서버의 컴포넌트를 웹 개발자의 코드로 교체하거나 연결할 수 있게 해주는 API.
• 서버 자체의 동작을 바꾸거나 서버의 처리능력을 최대한 활용하기 위해 등장함.
• 웹 개발자가 자신의 모듈을 HTTP와 직접 연결할 수 있는 강력한 인터페이스임.
• ex) 웹 출판 서비스를 지원해주는 마이크로소프트의 프론트 페이지 서버 확장(FPSE).

애플리케이션 인터페이스와 웹 서비스

• 애플리케이션을 연결하면서 생기는 까다로운 이슈 중 하나는, 데이터를 교환하려는 두 애프리케이션 사이에서 프로토콜 인터페이스를 맞추는 일임.

• 웹 서비스는 SOAP를 통해 XML을 사용하여 정보를 교환함.
• SOAP(Simple Object Access Protocol): HTTP 메시지에 XML 데이터를 담는 방식에 관한 표준
• XML(eXtensible Markup Language): 데이터 객체를 담는 데이터를 생성하고 해석하는 방식 제공

터널

• HTTP 프로토콜을 지원하지 않는 애플리케이션을 사용해 접근하는 방법을 제공함.

• 일반적으로 HTTP 커넥션 안에 HTTP가 아닌 트래픽을 얹기 위해 사용함.
• 보통 이 목적(더 강력한 보안)으로 개발됨. 뒤에 SSL 터널링 부분에서 다시 설명.
• 웹 트래픽만 허락하는 방화벽이 있더라도 웹 터널로 HTTP가 아닌 트래픽을 전송할 수 있음.

• 웹 터널은 HTTP의 CONNET로 메서드를 사용하여 커넥션을 맺음.
• CONNECT 메서드는 터널 게이트웨이가 임의의 목적 서버와 포트에 TCP 커넥션을 맺고 클라이언트와 서버 간에 오는 데이터를 무조건 전달하기를 요청함.

1. 클라는 게이트웨이에 터널을 연결하려고 CONNECT 요청을 보냄.

2. CONNECT 메서드는 TCP 커넥션을 위해 게이트웨이에 터널 연결을 요청함.

3. (같은 과정)

4. TCP 커넥션이 맺어지면 게이트웨이는 클라이언트에게 HTTP 200 Connectioin Established 응답을 전송하고 연결.

5. 터널이 연결되고 HTTP 터널을 통해 전송된 클라이언트의 모든 데이터는 TCP 커넥션으로 전달. 서버로부터 전송된 모든 데이터 역시 HTTP 터널을 통해서 클라이언트에게 전달.

• CONNECT 요청

CONNECT home.netscape.com:443 HTTP/1.0
User-agent: Mozilla/4.0

• CONNET 응답
• 일반적인 HTTP 응답과 달리 Content-Type 헤더를 포함할 필요는 없음. 커넥션이 메시지를 전달하는 대신 바이트를 그대로 전달하기 때문.

HTTP/1.0 Connection Established
Proxy-agent: Netscape-Proxy/1.1

• 클라이언트는 성능을 높이기 위해 CONNECT 요청 후 응답을 받기 전에 터널 데이터를 전송할 수 있음. 이는 서버에 데이터를 더 빨리 보내는 방법이지만 게이트웨이가 요청에 이어서 데이터를 적절하게 처리할 수 있어야 함을 전제로 함.

• 터널의 끝단 어느 부분이든 커넥션이 끊어지면 전송 중이던 데이터까진 전달됨. 반대편의 커넥션도 프락시에 의해서 끊어짐. 커넥션이 끊긴 한쪽에 아직 전송되지 않은 데이터는 버려짐.

• SSL 터널링
• SSL 트래픽이 기존 프락시 방화벽을 통과할 수 있도록 HTTP에 터널링 기능이 추가됨.



• 터널을 사용하면 SSL 트래픽을 HTTP 커넥션으로 전송하여 80포트의 HTTP만을 허용하는 방화벽을 통과시킴.
• ex) 터널은 443 포트에 전송해야 할 SSL 트래픽을 기존 HTTP 커넥션(포트 80)을 통해 전송함.
• 터널링 기능은 HTTP 메시지에 암호화된 raw data를 담고 일반 HTTP 채널을 통해 데이터를 전송함.
• 이처럼 터널은 HTTP가 아닌 트래픽이 포트를 제한하는 방화벽을 통과할 수 있게 해줌.
• 이는 보안 SSL 트래픽이 방화벽을 통과하도록 활용할 수 있지만, 악의적인 트래픽이 유입되는 경로가 될 수도 있음.

• SSL 터널링 vs HTTP/HTTPS 게이트웨이
• 게이트웨이의 경우 원격 HTTPS 서버와 SSL 세션을 시작하는 게이트웨이를 두고 클라측 트랜잭션을 수행함. 응답은 프록시가 받아서 복호화하고 난 후에, HTTP를 통해 클라로 전송. 단, 이 접근은 몇 가지 단점이 있음.
• 클라이언트-게이트웨이 사이에는 보안이 적용되지 않은 일반 HTTP 커넥션이 맺어짐.
• 프록시가 인증을 담당하고 있기에, 클라이언트는 원격 서버에 SSL 클라이언트 인증(X509 인증서 기반)을 할 수 없음.
• 게이트웨이는 SSL을 완벽히 지원해야 함.
• SSL 터널링을 사용하면, 프록시에 SSL을 구현할 필요가 없음. SSL 세션은 클라가 생성한 요청과 목적지 웹 서버 간에 생성됨. 프록시 서버는 트랜잭션의 보안에는 관여하지 않고 암호화된 데이터를 그대로 터널링함.

• 터널 게이트웨이는 통신하고 있는 프로토콜이 터널을 올바르게 사용하고 있는지 검증할 방법이 없음. 터널의 오용을 최소화하기 위해서, 게이트웨이는 HTTPS 전용 포트인 443과 같은 특정 포트만 커널링할 수 있게 허용해야 함.

HTTP 릴레이

• HTTP 릴레이는 HTTP 명세를 완전히 준수하지는 않는 간단한 HTTP 프락시임.

• 릴레이는 커넥션을 맺기 위한 HTTP 통신을 한 다음 바이트를 맹목적으로 전달함.

• HTTP는 복잡하기에 모든 헤더와 메서드 로직을 수행하지 않고 맹목적으로 트래픽을 전달하는 간단한 프락시를 구현하는 방식이 유용할 때가 있음.

• 데이터를 맹목적으로 전달하도록 구현하기는 쉽기 때문에 단순 필터링이나 진단 혹은 콘텐츠 변환을 하는데 사용되기도 함.

• 하지만 이는 잠재적으로 심각한 상호 운용 문제를 가지고 있기 때문에 주의해서 배포해야 함.

• 여러 문제를 예방하기 위해서 HTTP를 제대로 준수하는 프락시를 사용하는 게 좋음.