#1. 게이트웨이
게이트웨이는 리소스와 애플리케이션을 연결하는 역할을 한다. 게이트웨이는 요청을 받고 응답을 보내는 포털 같이 동작하는데 동적인 콘텐츠를 생성하거나 데이터베이스에 질의를 보낼 수 있다.
(a) : 게이트웨이는 FTP URL을 가리키는 HTTP요청을 받고 FTP커넥션을 맺고 FTP서버에 명령 전송
(b) : 게이트웨이는 암호화된 웹 요청을 SSL을 통해 받고 요청을 해독해서 HTTP요청을 목적지 서버로 전달
(c) : 애플리케이션 서버 게이트웨이 API를 통해 클라이언트를 서버 측 애플리케이션 프로그램에 연결 (물건사기, 주식시세, 일기예보 ....)
클라이언트 측 게이트웨이와 서버 측 게이트웨이
웹 게이트웨이는 한쪽에서는 HTTP로 통신, 다른 한쪽에서는 HTTP가 아닌 다른 프로토콜로 통신한다. 클라이언트 측 프로토콜과 서버 측 프로토콜을 빗금 ( / )으로 구분한다. (EX. HTTP/FTP)
- 서버 측 게이트웨이는 클라이언트와 HTTP로 통신하고 서버와는 외래 프로토콜로 통신한다.
- 클라이언트 측 게이트웨이는 클라이언트와 외래 프로토콜로 통신하고 서버와는 HTTP로 통신한다.
#2. 프로토콜 게이트웨이
프락시에 트래픽을 바로 보내는 것과 같이 게이트웨이에도 HTTP 트래픽을 바로 보낼 수 있다. 브라우저에 명시적으로 게이트웨이를 설정하여 자연스럽게 트래픽이 게이트웨이를 거쳐 가게 하거나 게이트웨이를 대리 서버(리버스 프락시)로 설정할 수도 있다.
모든 FTP URL에 대한 HTTP/FTP 게이트웨이를 설정한 결과 브라우저는 일반 HTTP 트래픽은 원 서버로 바로 보내지만 FTP URL을 포함한 요청은 게이트웨이를 거쳐서 요청을 보내고 있다.
HTTP/* : 서버 측 웹 게이트웨이
서버 측 웹 게이트웨이는 클라이언트로부터 HTTP 요청이 원 서버 영역으로 들어오는 시점에 클라이언트 측의 HTTP 요청을 외래 프로토콜로 전환한다.
- USER와 PASS 명령을 보내서 서버에 로그인한다
- 서버에서 적절한 디렉터리로 변경하기 위해 CWD 명령을 내린다.
- 다운로드 형식을 ASCII로 설정한다.
- MDTM으로 문서의 최근 수정 시간을 가져온다.
- PASV로 서버에게 수동형 데이터 검색을 하겠다고 말한다.
- RETR로 객체를 검색한다.
- 제어 채널에서 반환된 포트로 FTP 서버에 데이터 커넥션을 맺는다. 데이터 채널이 열리는 대로 객체가 게이트웨이로 전송된다.
HTTP/HTTPS : 서버 측 보안 게이트웨이
클라이언트는 일반 HTTP를 사용하여 웹을 탐색할 수 있지만 게이트웨이는 자동으로 사용자의 모든 세션을 암호화한다.
HTTPS/HTTP : 클라이언트 측 보안 가속 게이트웨이
웹 서버의 앞단에 위치하고 보이지 않는 인터셉트 게이트웨이나 리버스 프락시 역할을 한다. 이 게이트웨이는 보안 HTTPS 트래픽을 받아서 복호화하고 웹 서버로 보낼 일반 HTTP 요청을 만든다.
게이트웨이와 원 서버 간의 암호화하지 않은 트래픽을 전송하기 때문에 게이트웨이와 원 서버 간에 있는 네트워크가 안전한지 확인을 확실히 하고 사용해야 한다.
#3. 리소스 게이트웨이
게이트웨이의 가장 일반적인 형태인 애플리케이션 서버는 목적지 서버와 게이트웨이를 한 개의 서버로 결합한다.
공용게이트웨이 인터페이스
공용 게이트웨이 인터페이스(CGI)는 최초의 서버 확장이자 지금까지도 가장 널리 쓰이는 서버 확장이다. 이는 웹에서 동적인 HTML, 신용카드 처리, 데이터베이스 질의 등을 제공하는 데 사용된다.
- CGI는 단순하므로 거의 모든 HTTP 서버가 지원한다.
- CGI가 내부에서 어떤 처리를 하는지는 사용자에게 보이지 않는다.
- 클라이언트가 CGI 애플리케이션이 무언가를 하고 있다는 것을 알 수 있는 단서는 URL에 있는 'cgi' 혹은 '?' 이다.
- 모든 CGI 요청마다 새로운 프로세스를 만들어 부하가 크고 서버 장비에 부담을 준다.
- 새로운 CGI 형식인 Fast CGI가 개발되어 요청마다 새로운 프로세스를 만들고 제거하면서 성능저하 문제를 해결
서버 확장 API
서버 확장 API는 프로그래머가 자신의 코드를 서버에 연결하거나 서버의 컴포넌트를 자신이 만든 것으로 교체할 수 있게 한다.
마이크로소프트, 넷스케이프, 아파치 등 서버들은 개발자가 서버의 동작을 변경하거나 다른 리소스에 대한 사용자 맞춤 인터페이스를 제공하는 데 쓸 수 있는 API를 가지고 있다. 이러한 맞춤 인터페이스는 개발자에게 매우 유용하다.
#4. 터널
웹 터널은 HTTP 프로토콜을 지원하지 않는 애플리케이션에 HTTP 애플리케이션을 사용해 접근하는 방법을 제공한다. 웹 터널을 사용하면 HTTP 커넥션을 통해서 HTTP가 아닌 트래픽을 전송할 수 있고 다른 프로토콜을 HTTP 위에 올릴 수 있다.
CONNECT로 HTTP 터널 커넥션 맺기
CONNECT 메서더는 터널 게이트웨이가 임의의 목적 서버와 포트에 TCP 커넥션을 맺고 클라이언트와 서버 간에 오는 데이터를 무조건 전달하기를 요청한다.
- 클라이언트는 케이트웨이에 터널을 연결하려고 CONNECT 요청을 보냄.
- CONNECT 메서드는 TCP 커넥션을 위해 게이트웨이에 터널 연결을 요청
- TCP 커넥션이 맺어지면 게이트웨이는 클라이언트에게 HTTP 200 Connectioin Established 응답을 전송하고 연결
- 터널이 연결되고 HTTP 터널을 통해 전송된 클라이언트의 모든 데이터는 TCP 커넥션으로 전달
- 서버로부터 전송된 모든 데이터 역시 HTTP 터널을 통해서 클라이언트에게 전달
데이터 터널링, 시간, 커넥션 관리
클라이언트는 성능을 높이기 위해 CONNECT 요청을 보낸 다음 응답을 받기 전에 터널 데이터를 전송할 수 있다. 이는 서버에 데이터를 더 빨리 보내는 방법이지만 게이트웨이가 요청에 이어서 데이터를 적절하게 처리할 수 있어야 함을 전제로 한다.
터널의 끝단 어느 부분이든 커넥션이 끊어지면 그 끊어진 곳으로부터 온 데이터는 반대편으로 전달된다. 그 다음 커넥션이 끊어졌던 터널의 끝단 반대편의 커넥션도 프락시에 의해서 끊어질 것이다. 커넥션이 끊긴 한쪽에 아직 전송되지 않은 데이터는 버려진다.
SSL 터널링
웹 터널은 원래 방화벽을 통해서 암호화된 SSL 트래픽을 전달하려고 개발되었다. 터널을 사용하면 SSL 트래픽을 HTTP 커넥션으로 전송하여 80포트의 HTTP만을 허용하는 방화벽을 통과시킬 수 있다.
터널은 HTTP가 아닌 트래픽이 포트를 제한하는 방화벽을 통과할 수 있게 해준다. 이는 보안 SSL 트래픽이 방화벽을 통과하는 데 유용하게 사용될 수 있다. 하지만 터널은 악의적인 트래픽이 사내로 유입되는 경로가 될 수도 있다.
SSL 터널링 VS HTTP/HTTPS 게이트웨이
HTTP/HTTPS의 단점
- 클라이언트-게이트웨이 사이에는 보안이 적용되지 않은 일반 HTTP 커넥션이 맺어져 있다.
- 프락시가 인증을 담당하고 있기 때문에 클라이언트는 원격 서버에 SSL 클라이언트 인증을 할수 없다.
- 게이트웨이는 SSL을 완벽히 지원해야 한다.
SSL 터널링을 사용하면 프락시에 SSL을 구현할 필요가 없다. SSL 세션은 클라이언트가 생성한 요청과 보안이 적용된 웹 서버간에 생성된다. 프락시 서버는 트랙잭션의 보안에는 관여하지 않고 암호화된 데이터를 그대로 터널링 한다.
#5. 릴레이
HTTP 릴레이는 HTTP 명세를 완전히 준수하지는 않는 간단한 HTTP 프락시다. 릴레이는 커넥션을 맺기 위한 HTTP 통신을 한 다음 바이트를 맹목적으로 전달한다.
HTTP는 복잡하기에 모든 헤더와 메서드 로직을 수행하지 않고 맹목적으로 트래픽을 전달하는 간단한 프락시를 구현하는 방식이 유용할 때가 있다. 데이터를 맹목적으로 전달하도록 구현하기는 쉽기 때문에 단순 필터링이나 진단 혹은 콘텐츠 변환을 하는데 사용되기도 한다.
하지만 이는 잠재적으로 심각한 상호 운용 문제를 가지고 있기 때문에 주의해서 배포해야 한다.
여러 문제를 예방하기 위해서 HTTP를 제대로 준수하는 프락시를 사용하는 게 좋다.
참고 자료
- HTTP완벽가이드 , 인사이트
'HTTP' 카테고리의 다른 글
| [HTTP] 배포 시스템 : FrontPage와 WebDAV (0) | 2020.05.04 |
|---|---|
| [HTTP] 웹 로봇 (0) | 2020.05.04 |
| [HTTP] 캐시(Cache) (0) | 2020.05.03 |
| [HTTP] 프락시(Proxy) (0) | 2020.05.02 |
| [HTTP] 웹 서버 (0) | 2020.05.02 |
