07. 게이트웨이&터널&릴레이

캐시 이외에도 유명한 3가지 용어인, 게이트웨이 터널 릴레이에 대해 알아봅시다.

 

게이트웨이

현대의 웹 사이트를 보면 로그인부터, 광고, 다른 기능 등등.. 여러 기능들이 구현되어 있습니다. 

이렇게 많은 기능을 구현하기 위해서는 많은 리소스와 또 이를 처리할 여러 애플리케이션이 필요합니다.

이 애플리케이션들에게 리소스의 접근 경로를 안내하는 인터프리터 역할을 하는 것이 게이트웨이의 시작이었습니다

애플리케이션들은 게이트웨이에게 리소스를 요청하고, 게이트웨이는 그에 대한 응답을 처리하는 식이죠.

 

게이트웨이의 역할

1. 리소스 게이트웨이 (애플리케이션 서버)

앞서 말한 여러 애플리케이션들과 리소스들을 연결해주는 역할을 하는 게이트웨이를 말합니다.

게이트웨이와 애플리케이션들을 묶은 애플리케이션 서버와 클라이언트를 연결해 요청을 처리합니다.

이때 서버의 동작은 CGI와 API에 의해 결정됩니다.

그림 1 리소스 게이트웨이

 

 

CGI(공용 게이트웨이 인터페이스)

HTTP 요청에 따라 프로그램을 실행, 출력 수집, 응답 등 웹 서버가 사용하는 표준화된 인터페이스 집합을 말합니다.

단순한 구조이기 때문에 모든 HTTP 서버가 지원하며 구현할 수 있는 언어도 다양합니다.

장점으로는 내부 동작을 사용자가 몰라도 된다는 것입니다. 하지만 이러한 분리 때문인지 성능 관련 이슈가 있고, 

모든 CGI 요청마다 새로운 프로세스를 만드는 방식이기 때문에 부하가 큽니다.

이를 해결하기 위해 FAST CGI가 개발되었습니다.

 

API

CGI는 단순하게 사용하려면 좋은 프로토콜이지만, 서버의 동작을 바꾸거나 처리능력을 향상하기엔 부족합니다.

그래서 등장하게 된 것이 API입니다.

API는 개인이 작성한 코드를 서버에 연결하거나, 컴포넌트를 커스텀해 교체할 수 있기 때문에, 입맛에 맞게 서버의 변화를 줄 수 있습니다.

 

2. 프로토콜 게이트웨이 (클라이언트와 서버 연결)

서로 다른 프로토콜끼리 연결하는 역할을 하는 게이트웨이를 의미합니다. 덕분에 요청을 하는 측은 다른 프로토콜을 굳이 알지 않아도 됩니다.

 

1) HTTP/*^[각주:1] 서버 측 게이트웨이

클라이언트에게 HTTP 요청을 받아 각 서버가 호환되는 프로토콜로 변환을 해 서버에게 보내는 방법입니다.

 

2) HTTP/HTTPS 서버 측 보안 게이트웨이

여러 가지 이유로 서버에서는 보안을 유지해야 할 필요가 있습니다. 하지만, 일일이 사용자 측에서부터 보안을 유지하는 것보다는 트래픽이 모이는 게이트웨이에서 부터 서버 사이에 보안을 유지하는 것이 더 효율적입니다. 그래서 클라이언트 측은 부담 없이 HTTP로 탐색을 하고 게이트웨이에서 HTTPS로 암호화를 한 뒤 서버에 전달하는 방식입니다.

그림2 HTTP/HTTPS 보안 게이트웨이

 

3) HTTPS/HTTP 클라이언트 측 보안 가속 게이트웨이

서버가 여러 암호화된 트래픽을 받으면, 그를 복호화하느라 부하가 갈 수 있습니다. 속도도 당연히 느려지겠죠.

이를 해결하기 위해서, 원 서버보다 성능이 우수한 게이트웨이를 두어 복호화를 대신 수행합니다.

(비슷하게는 프록시의 네트워크 가속을 설명했었습니다.)

그래서 이러한 역할을 하는 게이트웨이를, 보안 가속 게이트웨이라고 합니다.

주의해야 할 점은, 서버가 아닌 게이트웨이에서 복호화를 하기 때문에, 게이트웨이와 서버 사이의 네트워크는 안전해야 합니다.

그림 3 보안 가속 게이트웨이

---

터널

게이트웨이와 비슷한 역할을 하는 터널입니다. 이 역시 타 프로토콜을 지원하지 않는 애플리케이션에 접근하는 방법입니다. (특히 HTTP 커넥션에서 HTTP가 아닌 트래픽을 전송)

특히 SSL 터널링을 주로 사용합니다.

 

 

SSL 터널링

프록시를 공부하며 보안을 위해서 라우터를 통해 모든 트래픽이 보안 기능이 강화된 프록시를 거친다는 것은 알고 있을 것입니다. 이 경우 만약 HTTP 보안 프록시가 암호화된 패킷(프로토콜도 암호화)의 프로토콜을 판별할 능력이 없다면, 프록시를 통과하지 못할지도 모릅니다. 이런 경우를 방지하기 위해서 터널을 사용합니다. SSL 트래픽을 일반 HTTP 커넥션으로 전송할 수 있기 때문이죠! 이렇게 되면 프록시를 따로 SSL도 호환이 되게 공을 들일 필요가 없어집니다.

 

HTTP/HTTPS 게이트웨이 VS SSL 터널링

두 가지 모두 같은 기능을 수행하나, 차이점이 존재합니다.

 

1. 네트워크 취약성

HTTP/HTTPS 게이트웨이 :  클라이언트 ~ 게이트웨이가 취약하다.

SSL 터널링 :  처음부터 끝까지 SSL 암호화를 하기 때문에, 보안에 유리

 

2. 게이트웨이 호환 여부 (프록시도 마찬가지)

HTTP/HTTPS 게이트웨이 : 게이트웨이가 HTTP를 HTTPS로 변환하기 때문에, SSL을 지원해야 한다.

SSL 터널링 : SSL 터널링에서 게이트웨이는 그저 데이터를 넘겨주는 역할이기 때문에, 필수가 아니다.

 

---

릴레이

릴레이는 게이트웨이의 기능을 정말 간단하게 구현해야 할 경우에 사용합니다.

간단하게 구현을 하다 보니, 로직은 매우 간단하나, 데이터를 무조건적으로 전달해 홉 별 헤더의 경우 오류가 발생할 가능성이 매우 큽니다. (프록시 장에서 Dumb Proxy의 'Connection 헤더'를 떠올려봅시다.)

이를 보완하는 방법이 있으나, 그럴 바에는 프록시나 게이트웨이를 사용하는 것이 더 유리합니다.

 

주석

1. 클라이언트/서버 순서로 표기합니다. [본문으로]