프록시, 게이트웨이, 터널 (22.10.04 TIL)

 HTTP 는 클라이언트와 서버 이외에 프록시, 게이트웨이, 터널 같은 통신을 중계하는 프로그램과 서버를 연계하는 것도 가능하다. 이러한 프로그램과 서버는 그 다음에 있는 다른 서버에 리퀘스트를 중계하고, 그 서버로부터 받은 리스폰스를 클라이언트에 반환하는 역할을 담당한다.

*프록시 vs 게이트웨이
-> 프록시는 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결한다.
-> 게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결한다.

프록시

 서버와 클라이언트의 양쪽 역할을 중계하는 프로그램으로, 클라이언트로의 리퀘스트를 서버에 전송하고, 그에 대한 서버의 리스폰스를 클라이언트에 전송한다. 받은 리퀘스트 URI 를 변경하지 않고 그 다음의 리소스를 가지고 있는 서버에 보낸다.

 리소스의 본체를 가진 서버는 오리진 서버라고 한다. 오리진 서버로부터 되돌아온 리스폰스는 프록시 서버를 경유해서 클라이언트에 돌아온다. 

*사용 이유
(1) 캐시를 이용해 네트워크 대역을 효율적으로 사용하기 위함
(2) 조직 내 특정 웹 사이트에 대한 액세스를 제한하기 위함
(3) 액세스 로그를 획득하는 정책을 지키기 위함

 HTTP 통신을 할 때, 프록시 서버를 여러 대 경유하는 것도 가능하다. 프록시를 경유하는 경우 프록시들은 자신의 정보를 Via 헤더 필드에 남기게 된다. Via 헤더를 통해 어떤 서버들을 경유했는지 확인할 수 있다. 프록시 서버를 사용하는 이유는 캐시를 사용해서 네트워크 대역 등을 효율적으로 사용하는 것과, 조직 내에 특정 웹사이트에 대한 액세스를 제한, 액세스 로그를 획득하는 정책을 철저하게 지키려는 목적으로 사용하는 경우도 있다. 

*Via 헤더
-> 메시지가 지나는 각 중간 노드(프록시나 게이트웨이) 의 정보를 나열한다.
-> 메시지가 또 다른 노드를 지나갈 때마다 중간 노드는 Via 목록의 끝에 추가되어야 한다.
-> 아래는 메시지가 두 개의 프록시를 지나갔음을 말해준다.

Via: 1.1 proxy-12.hello.com, 1.0 cache.world.com
// 첫 번째 프록시는 HTTP/1.1 프로토콜을 구현했으며, proxy-12.hello.com 이라 불린다.
// 두 번째 프록시는 HTTP/1.0을 구현했고 cache.world.com 으로 불린다.

 프록시의 사용방법은 2개의 기준으로 분류한다.

• 캐시하는지의 여부 (캐싱 프록시)
• 메시지를 변경하는지의 여부 (투명 프록시)

 캐싱 프록시 : 프록시로 리스폰스를 중계하는 때에는 프록시 서버 상에 리소스 캐시를 보존해두는 타입의 프록시이다. 프록시에 다시 같은 리소스에 리퀘스트가 온 경우, 오리진 서버로부터 리소스를 획득하지 않고 캐시를 리스폰스로 되돌려 준다.

 투명 프록시 : 프록시로 리퀘스트와 리스폰스를 중계할 때 메시지 변경을 하지 않는 타입의 프록시이다. 반대로는 비투과 프록시라고 한다.

게이트웨이

 다른 서버를 중계하는 서버로 클라이언트로부터 수신한 리퀘스트를 리소스를 보유한 서버인 것처럼 수신한다. 그래서 클라이언트는 상대가 게이트웨이라는 것을 알지 못하는 경우도 있다.

 게이트웨이의 동작은 프록시와 매우 유사하다. 게이트웨이는 그 다음에 있는 서버가 HTTP 서버 이외의 서비스를 제공하는 (ex. DB 에 접속해 쿼리를 사용해 데이터를 얻는 경우, 쇼핑 사이트 등에서 신용 카드 결제 시스템 등과 연계하는 경우) 서버가 된다.

 클라이언트와 게이트웨이 사이를 암호화하는 등으로 안전하게 접속함으로써 안정성을 높이는 역할을 한다.

터널

 서로 떨어진 두 대의 클라이언트와 서버 사이를 중계하며 접속을 주선하는 중계 프로그램이다. SSL 과 같은 암호화 통신을 통해 서버와 안전하게 통신을 하기 위해 사용한다. 통신 중인 양쪽 끝의 접속이 끊어질 때 종료된다.