[http 완벽 가이드] 8장 통합점: 게이트웨이, 터널 , 릴레이

이 내용은 http 완변 가이드란 책을 읽고 정리한 내용입니다.

 

더 자세한 내용이 궁금하시면 책을 직접 읽어보시는 걸 추천합니다.

 

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

• 이 장에서는 여러 종류의 리소스에 접근하는데 HTTP 가 어떻게 쓰이는지 알아보고, 다른 프로토콜이나 애플리케이션 간 통신에 HTTP 를 어떻게 사용하는지 알아볼 것이다.
• 게이트웨이: 서로 다른 프로토콜과 애플리케이션 간의 HTTP 인터페이스
• 애플리케이션 인터페이스: 서로 다른 형식의 웹 애플리케이션이 통신하는 데 사용
• 터널: HTTP 커넥션을 통해서 HTTP 가 아닌 트랙픽을 전송하는데 사용한다.
• 릴레이: 일종의 단순한 HTTP 프락시로 , 한 번에 한개의 홉에 데이터를 전달하는 데 사용한다.

1. 게이트웨이

• 웹이 더 복잡한 리소스를 올려야 할 필요가 생기면서 한개의 애플리케이션으로만 처리할 수 없다는 것은 분명해졌다.
• 인터프리터 같이 리소스를 받기위한 경로를 안내하는 역할을 하는 게이트웨이를 고안해냈다.
• 게이트웨이는 리소스와 애플리케이션을 연결하는 역할을 한다.
• 애플리케이션은 게이트웨이에게 요청을 처리해달라고 할 수 있고, 게이트 웨이는 응답을 할 수 도 있다
• 동적인 콘텐츠를 생성하거나 DB에 질의를 보낼 수 있다.

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

• 게이트웨이는 애플리케이션 서버 게이트웨이 API를 통해서HTTP 클라이언트를 서버 측 애플리케이션 프로그램에 연결한다.
• 웹에서 물건을 사거나 일기예보를 보거나 주식시세를 볼 때, 사실은 애플리케이션 서버 게이트웨이를 방문한것이다.

1.1 클라이언트 측 게이트웨이와 서버 측 게이트웨이

• 웹 게이트웨이는 한쪽에서는 HTTP로 통신하고 , 다른 한쪽에서는 HTTP가 아닌 다른 프로토콜로 통신한다.
• 게이트웨이는 클라이언트 측 프로토콜과 서버 측 프로토콜을 빗금(/)으로 구분한다.
• HTTP 클라이언트와 NNTP 뉴스 서버 사이에 있으면가 된다.
• HTTP/NNTP
• 게이트웨이가 어느 쪽 역할을 하고 있는지 설명하기 위해서
  • 서버측 게이트웨이(클라이언트와 HTTP 통신, 서버와 외래 프로토콜)
  • 클라이언트측 게이트웨이(서버와 HTTP 통신, 클라이언트와 외래 프로토콜)

2. 프로토콜 게이트웨이

• 프락시에 트래픽을 바로 보내는 것과 같이 게이트웨이에도 HTTP 트래픽을 바로 보낼수 있다. 보통, 브라우저에 명시적으로 게이트웨이를 설정하여 자연스럽게 트래픽이 게이트웨이를 거쳐 가게 하거나 ,
• 게이트웨이를 대리서버(리버스 프락시)로 설정할 수 있다.

• 다음 절에서는 서버 프로토콜 변환기, 서버 측 보안 게이트웨이, 클라이언트 측 보안 게이트웨이, 애플리케이션 서버 같은 일반적인 게이트웨이의 종류를 설명한다.

2.1 HTTP/*: 서버 측 웹 게이트웨이

• 서버 측 웹 게이트웨이는 클라이언트로부터 HTTP 요청이 원 서버 영역으로 들어오는 시점에 클라이언트 측의 HTTP 요청을 외래 프로토콜로 전환한다.
• 응답을 할때도 외래 프로토콜을 클라이언트 측에 HTTP 로 변환 후 보낸다.

2.2 HTTP/HTTPS: 서버 측 보안 게이트웨이

• 기업 내부의 모든 웹 요청을 암호함으로써 개인 정보 보호와 보안을 제공하는데 게이트웨이를 사용할 수 있다.
• 클라이언트는 일반 HTTP를 사용하여 웹을 탐색할 수 있지만, 게이트웨이는 자동으로 사용자의 모든 세션을 암호화할 것이다.

2.3 HTTPS/HTTP : 클라이언트 측 보안 가속 게이트웨이

• 웹 서버의 앞단에 위치하고, 보이지 않는 인터셉트 게이트웨이나 리버스 프락시 역할을 한다.
• 이 게이트웨이는 보안 HTTPS 트래픽을 받아서 복호화하고, 웹 서버로 보낼 일반 HTTP 요청을 만든다.
• 이런 게이트웨이는 원서버의 부하를 줄여주지만
• 게이트웨이와 원서버 간의 암호화하지 않는 트래픽을 전송하기 때문에, 게이트웨이와 원서버 간에 있는 네트워크가 안전한지 확인을 확실히 하고 사용해야 한다.

3. 리소스 게이트웨이

• 여기까지 네트워크상에서 클라이언트와 서버를 연결하는 게이트웨이에 관해 이야기하였다.
• 이번부터는 게이트웨이의 가장 일반적인 형태인 애플리케이션 서버는 목적지 서버와 게이트웨이를 한개의 서버로 결합한다.
• 애플리케이션 서버는 HTTP를 통해서 클라이언트와 통신하고 서버 측에 있는 애플리케이션 프로그램에 연결하는 서버 측 게이트웨이이다.

• 두개의 클라이언트가 HTTP 를 사용하여 애플리케이션 서버로 연결한다.
• 하지만 서버로부터 파일이 전송되는 대신에, 애플리케이션 서버는 게이트웨이의 애플리케이션 프로그래밍 인터페이스를(API) 통해서 요청을 서버에서 동작하고 있는 애플리케이션에 전달한다.
• 애플리케이션 게이트웨이에서 유명했던 최초의 API는 공용 게이트웨이 인터페이스(Common Gateway Interface , CGI) 였다.
  • CGI는 특정 URL에 대한 HTTP 요청에 따라 프로그램을 실행하고, 프로그램의 출력을 수집하고, HTTP 응답을 회신하는데 웹 서버가 사용하는 표준화된 인터페이스의 집합이다.

• 게이트웨이를 통해야 받을 수 있는 리소스 요청이 들어오면 , 서버는 헬퍼 애플리케이션을 생성하여 요청을 처리한다.
• 헬퍼 애플리케이션은 필요한 데이터를 전달 받는다.
• 전달받은 데이터는 요청 전체이거나 사용자가 데이터베이스에서 실행시키려는 질의 같은 것이다.
• 위 그림은 CGI의 모습

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

• 공용 게이트웨이 인터페이스(CGI)는 최초의 서버 확장이자 지금까지도 가장 널리 쓰이는 서버 확장이다.
• 이는 웹에서 동적인 HTML, 신용카드 처리, 데이터 베이스 질의 등을 제공하는데 사용한다.
• CGI 애플리케이션이 서버와 분리 되면서 펄이나 C 같은 다양한 언어로 구현할 수 있게 되었다.
• CGI는 내부에 어떤 처리를 하는지 사용자에게 감추고 서버와 애플리케이션이 어떤 작용을 하는지 사용자는 모른다.
• 하지만 서버와 분리 때문에 성능 관련한 비용이 발생했다.
  • 모든 CGI 요청마다 새로운 프로세스를 만드는데 비용이 크고, 서버에 부담을 준다.
• 이 문제를 해결하고자 Fast CGI가 개발 되었다.

3.2 서버 확장 API

• CGI 프로토콜은 구동중인 HTTP 서버에 외부 인터프리터가 쉽게 접속할 수 있게 해주지만,

서버 자체의 동작을 바꾸고 싶거나 서버의 처리능력을 최고치로 끌어올리지는 못한다.

• 그래서 서버 개발자는 웹개발자는 자신의 모듈을 HTTP와 직접 연결할 수 있는 강력한 인터페이스인 서버 확장 API를 만들었다.
• 유명한 서버들은 서버 확장 API를 하나씩 가지고 있고, 개발자가 서버의 동작을 변경하거나 다른 리소스에 대한 사용자 맞춤 인터페이스를 제공하는 데 쓸 수 있는 API를 가진다.

5. 터널

• 웹 터널은 HTTP 프로토콜을 지원하지 않는 애플리케이션을 사용해 접근하는 방법을 제공한다.
• 웹 터널을 사용하면 HTTP 커넥션을 통해서 HTTP 가 아닌 트래픽을 전송할 수 있고, 다른 프로토콜을 HTTP 위에 올릴 수 있다.

5.1 CONNET로 HTTP 터널 커넥션 맺기

• 웹 터널은 HTTP의 CONNECT 메서드를 사용하여 커넥션을 맺는다

5.3 SSL 터널링

• 웹 터널은 원래 방화벽을 통해서 암호화된 SSL 트래픽을 전달하려고 개발되었다.
• 방화벽 프락시는 HTTP 트래픽만을 통과한다.
• 하지만 클라이언트 측에서 SSL 트래픽을 전달하려고 하면 프락시는 이를 처리하지 않을 것이다.
• 그래서 SSL 터널링을 이용하면 HTTP 커넥션에 SSL 트래픽을 보낼 수 있다.
• 하지만 터널은 악의적인 트래픽이 사내로 유입되는 경로가 될 수도 있다.

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

• HTTP/HTTPS 게이트웨이를 사용하면 HTTP프로토콜과 HTTPS를 변환하여 전송할 수 있다는 걸 위에서 배웠다.
• 하지만 이는 단점이 있다.
  • 클라이언트-게이트웨이 사이에는 보안이 적용되지 않은 ㅇ리반 HTTP 커넥션이 맺어져 있다.
  • 프락시가 인증을 담당하고 있기 때문에, 클라이언트는 원격 서버에 SSL 클라이언트 인증을 할 수 없다.
  • 게이트웨이는 SSL 을 완벽히 지원해야 한다.
• 이 상황에서 SSL 터널링을 사용하면 ,프락시에 SSL 을 구현할 필요가 없다.

5.5 터널 인증

• HTTP 의 다른 기능들은 터널과 함께 적절히 사용할 수 있다. 특히 프락시 인증 기능은, 클라이언트가 터널을 사용할 수 있는 권한을 검사하는 용도로 터널에서 사용할 수 있다.

5.6 터널 보안에 대한 고려사항들

• 보통, 터널 게이트웨이는 통신하고 있는 프로토콜이 터널을 올바른 용도로 사용하고 있는지 검증할 방법이 없다.
• 터널의 오용을 최소화하기 위해서, 게이트웨이는 HTTPS 전용 포트인 443 같이 잘 알려진 특정 포트만을 터널링할 수 있게 허용해야한다.

6. 릴레이

• HTTP 릴레이는 HTTP 명세를 완전히 준수하지는 않는 간단한 HTTP 프락시이다.
• 명세를 준수하지 않는 간단한 프락시는 HTTP가 복잡하기에 맹목적으로 트래픽만 전달하게 하는 것이다.
  • 트래픽 전달은 구현하기 쉽기 때문
• 하지만 이는 잠재적으로 심각한 상호 운용 문제를 가지고 있다.
  • 문제중 하나는 커넥션 챕터의 Connectioin: Keep-Alive 헤더와 멍청한 프락시 예이다.
• 이러한 위험을 예방하기 위해 릴레이를 조금 똑똑하게 만들기도 하지만
• 여러 문제를 야기할 수도 있기에 HTTP를 제대로 준수하는 프락시를 사용하는게 좋다.